Ой, да я вообще о байтах не говорю - ни о первых, ни о вторых, и не о последующих. Не важны они для описанного механизма - раз уж присобачили таймер, так пусть он все проблемы со скоростями и калибровками решает совершенно автономно от UART и протоколов передачи данных.

С одной стороны говорите об универсализме, с другой стороны начинаете «высасывать из пальца» алгоритм универсальной автоподстройки.
Брейк — это усложнение, неужели не очевидно? В случае калибровки — да, я с вами согласился.
Скорость может меняться по разным причинам, не будем об этом.
Ладно, всем удачи. Спасибо за общение.


Я писал не вам, а отвечал SasaVitebsk. Просто вы успели написать сообщение между.

Наверное просто надо расставить все точки над i. Точнее говоря систематизировать понятия и знания. Кстати, недавно был удивлён. Оказывается основным достижением Менделеева во всём мире считается не таблица элементов, а то что он заложил основы систематизации как таковой. И, как мне кажется, это очень показательно что мы это его изобретение незаметили. Уж очень восточные славяне сумбурны и слабо поддаются причёсыванию. Не то что немцы. У тех даже в концлагерях шёл чёткий учёт выбитых зубов.

Поскольку я являюсь рядовым представителем нации, то тоже всегда взлохмачен. Поправьте меня те, кто ближе к немцам.

Я бы всётаки тоже постарался не сваливать всё в кучу и сделал бы максимально независимыми задачи.
Давайте сначала их выделим.

1) Подстройка частоты проца.
2) Автоопределение скорости передачи
3) Приём байта
4) Приём пакета (инфы).

Автоопределение скорости, на мой взгляд, должно работать уже при гарантированной частоте кварца. Так как при любом алгоритме вы не получите точной величины. Например при частоте МК AVR в 8МГц, без применения специальных мер (типа завести Rx на две ноги), полингом вы получите точность измерения импульса 4 такта. При скорости 115200 точность измерения длительности составит ~6%. То есть совершенно очевидно, что для подстройки частоты кварца необходимо выбирать больший интервал. Один из вариантов вам предлогал zltigo. Кто-то на форуме предлогал по часовому кварцу калиброваться. Это уже другой вопрос как.

А если калибровка присутствует, то само автоопределение скорости может быть сделано и мастером. Например он посылает пакеты на разных скоростях и ждёт ответа. С момента установки соединения посылает команду перестройки частоты. Если идут ошибки в линии слэйв переходит на более низкую скорость. Это я как пример привёл.

Тоже как пример. Камень из серии PIC12 - простенький MK c 8-ю ногами. Две ноги - питание и земля. Занимать еще две кварцем - слишком расточительно (хотя и возможно). Обычно используется встроенный генератор 4МГц. Имеется возможность программно откалибровать, но не вижу в этом особого смысла. Все равно частота немного будет плыть от питания и температуры.
Аппаратный UART не предусмотрен, поэтому - только программный. Калибрую по своей методе, получаю значение БИ с точностью в 1 команду (номинально 1мкс) - лучше, в данном случае, не бывает. При скорости 9600 (длительность БИ 104мкс) имею погрешность порядка 1%. Для нормальной работы UART вполне достаточно. Все всегда работает.


Мастера, предпочитаю, не нагружать дополнительными задачами (у него своих хватает). Мастер выбирает скорость сам, из собственных соображений, а я под него подстраиваюсь (если это возможно).

Вот ниграмма не возражаю и даже поддерживаю. Если вы внимательно читали, то в моём посте от 25.08 я оговариваюсь "Если обрабатывать поток непрерывно...". Это как раз данный случай.
Если реализовывать совтовый UART, то вы полностью контролируете всё: последовательность бит/байт/пакет. Это даёт вам возможность гарантировано востанавливать инфу (с момента однозначности), а также контролировать любые интервалы. То есть подстраивать кварц можно не побитно, а побайтно или 1 раз в 4 байта. Иными словами к моменту завершения приёма пакета вы имеете откалиброванный RC и выдаёте ответ с откалиброванным генератором.

Но я писал про другой вариант (думаю zltigo тоже). Думаю что вы не возражаете, против того, что совтовый UART с автободом и автокалибровкой отнимает значительное количество ресурсов? Кроме того, бывают ситуации, когда требуется реальное время и по другим задачам. То есть есть ещё источники прерываний. Поэтому приходится принять первый байт, а потом перейти в аппаратный режим чтобы иметь возможность отрабатывать параллельно другую задачу. В этом случае ваш вариант непролазит. Так как:

1) С момента переключения на аппаратный UART - автокалибровка и приём - совершенно разные задачи
2) По первому байту нет возможности гарантировать точную калибровку.

Вы знаете, я когда-то тоже был "фанатом" универсальных решений, а сейчас все больше склоняюсь к прямо противоположной позиции. Все надо применять к месту, в зависимости от поставленной задачи. И универсальность решений - не исключение, imho.
Программный UART имеет свои преимущества и недостатки. Про недостатки Вы уже написали - съедает много ресурсов, накладывает ограничения на использование прерываний, плохо работает на высоких скоростях...
Но есть и неоспоримые преимущества перед аппаратным UART-ом: во-первых - на многих простых МК аппаратного UART-та просто нет (а он нужен), во-вторых - нет необходимости калибровать тактовый генератор (используем как есть), в третьих - можно использовать встроенный генератор и сэкономить на кварце. Кроме того, в некоторых случаях, кварц вообще нельзя использовать, например в случае сильных ударных вибраций. Много случаев, когда программному UART-у просто нет альтернативы...
К процедуре автоопределения скорости (автокалибровке) - у меня аналогичный подход... Конечно, общение с единичным устройством по MODBUS - частный случай. Тем не менее - достаточно широко распространенный, чтобы специально под него сделать процедуру автоопределения скорости. Причем, не налагая каких-либо дополнительных ограничений на сам протокол...

Ещё раз повторюсь. Я ничуть не оспариваю принятое вами решение. Считаю его правильным и обоснованным. Поддерживаю вас и в плане универсальности. Программа на МК уже сама по себе неуниверсальна.
Вместе с тем данное решение задачи не везде применимо - вот она неуниверсальность.

А к универсальности мы всётаки двигаемся. И это заметно. Кто раньше на 20 ногом МК планировал применить вытесняющую ОС и писал на С++?