Это НЕ ограничение на протокол - протокол совершенно ничего не знает о калибровках. Совсем ничего.

Это вообще-то не байт совсем. Это с точки зрения приемника битый фрейм, который отделяется, даже если у чипа нет поддержки детектирования break по ошибке фрейма
и выбрасывается.

Ну поскольку именно Вы а не я свалили в кучу две задачи и получали уравнение с двумя неизвестными, то для данного случая, да, надо менять.

Все очень просто - break по определению должен быть длиннее самого длинного байта

Это не я так задачу за уши притянул. Для решения одной из двух задач никакие дополнительные таймера и почие извращения не нужны.

«Break должен быть длиннее самого длинного байта».. Это ли не ограничение на протокол передачи? Длинный break, перекрывающий все возможное, решает проблему калибровки. Но остается необходимость реализовывать отдельно autobaud rate.
(То, что это существует аппаратно где-то и в чем-то отношения к теме не имеет).
Я ничего не сваливал в кучу, вы что-то напутали по ходу наших рассуждений, все было свалено до меня.
«Для решения одной из двух задач..» Да кто ж с этим спорит? Только зачем навязывать «простое» решение для задачи, которая перед человеком не стояла.
В общем бессмысленный спор, думаю, вы со мной согласитесь хотя бы в этом.

Повторяю третий и последний раз - протокол передачи НИКАК при этом не ограничивается - ему по барабану есть там break, нет его, и что он там делает или не делает. Break отрабатывает таймер c обработчиком - это исключительно его епархия.

Длинна break и кроме всего прочего и задает baud - получили break, откалибровались по его длительности и вычислили по нему baud на которой с нами хочет общаться master.

Мы уже пошли по кругу.
Если вам надо в линию что-то передавать кроме данных, то это уже ограничение.
Если нужно передавать брейк, который длиннее одного байта (300 бод), то это почти в 400 раза длиннее байта минимально возможной длинны.
То есть протокол должен учитывать тот факт, что на 3,3 мс передача ему будет недоступна.
Передавать брейк на той же скорости, на которой вы планируете передачу, занятие бессмысленное, если приемник не будет ее (эту скорость) знать.
Я вроде понятно излагаю.

«Длинна break и кроме всего прочего и задает baud - получили break, откалибровались по его длительности и вычислили по нему baud на которой с нами хочет общаться master».
Тут я вижу ошибку.
См. выше. Если брейк передается на скорости передатчика, а именно это вы имеете в виду, раз предлагаете по нему подстраивать скорость, то не получится так просто отличить его от данных. Ваша схема может не отличить комбинацию нулей на одной скорости, от сигнала брейк на другой.

Например break на скорости 115200 просто удивительно точно совпадает с 1 нулем на скорости 9600.
То есть байт синхронизации или брейк делиметер тут необходим со всем вытекающим.
Я же говорю, это шило на мыло.

Разумеется нет - ведомое устройство просто должно изначально ожидать соединения на МАКСИМАЛЬНОЙ скорости. Соответсвенно брейк должен только длиннее предлагаемой "новой" скорости. Посему все Ваши последующие рассуждения ложны.

Во, дискуссия развернулась...

Да, я бы рад не валить, но реале они, часто, уже находятся в одной куче... И почему бы это не использовать?
Связать процедуры автоопределения скорости и протокол обмена. Например, предложенная мною методика, достаточно просто и логично вписывается в общеизвестный протокол MODBUS (правда, пока устройство одно на линии). После определения скорости, проверяем контрольную сумму запроса. Если все совпало, то с очень хорошей достоверностью скорость определена правильно. Иначе - не отвечаем и ждем следующего запроса...
Аналогично поступаем в случае сбоев (возможно из-за "ухода" текущего значения частоты RC)...
Самое главное, что абсолютно никаких дополнительных "усилий" со стороны Мастера для реализации автокалибровки в этом случае не требуется. Он даже "не знает" об этом...

Честно говоря так по памяти выдал. Немного ошибся. Сейчас посчитал примерно 95% получается.
Нельзя по первому байту (моим алгоритмом) восстановить следующие байты ff,fe,fc,f8,..,80,00. Короче байты с одним перепадом после старта. Ну и ещё наверное пару байт с 2 перепадами равноширинными. Если модифицировать алгоритм, то можно уменьшить число "неверно детектируемых" байт ещё вдвое. Останутся только ff,fe,f8,80. Если обрабатывать поток непрерывно, либо анализировать возможность ошибки, то можно гарантированно востанавливать поток полностью.


Наоборот. Немного упростил. Поленился. Посмотрел, что US Robotics Courier даёт примерно аналогичный результат и успокоился. Но проанализировал, что можно лучше. Зато получил P&P / диагностику под виндой. А народ даже и не догадывается что работает не аппаратный UART. Сбоев никогда не наблюдал. Выпускали несколько лет.

Как правило наименьший БИ двигает скорость в сторону увеличения, а у вас специальный символ брейк двигает скорость в сторону уменьшения. Это конечно «проще», это конечно «эффективнее».
Обратно как собираетесь скорость возвращать, если она изменится?
Вы с таким упорством пытаетесь доказать, что предложили нечто лучшее, чем реализовал @Ark для тех элементарных требований, которые у него были.
Проще вы это не сделаете так, как описываете. Я вам попытался доказать, но у меня не получилось.

SasaVitebsk, сложно, не значит плохо и я лишь предположил. Я рад за вас, что все работает успешно.
У вас, опять же, видимо была своя задача. Немного не понимаю, почему вы говорите о восстановлении потока. Что-то связано с модем.
95% это очень мало. Скорее всего мы о разном тут говорим.
Если скорость определяется верно, а петля автоподстройки охватывает вероятность появления «неудачных» байт в случайном потоке, то схема автоподстройки должна гарантировать попадание близкое к единице.

Элементарные частные требования были озвучены только в прошлом посте. Я рассуждал и рассуждаю о максимально универсальном независимом и отвязанном от протокола варианте. Частные случаи на то они и частные, что бы позволять применять частные заточенные решения.

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

Что значит "она изменится"? Сама Вы вдуг зачем-то захотите прыгнуть по бодовым скоростям вверх процессе работы? Неведомо зачем, но для этого можно, например, подать брейк многократно превыщающий текущюю байтовую длительность и по этом признаку уйти на максимальную, или использовать длительности break не в сетке бодовых скоростей.

Ой, да, мы о разном.
Вы о первом байте, а я вообще.
Все понял, пересчитывать за вами не буду.

Ой, да я вообще о байтах не говорю - ни о первых, ни о вторых, и не о последующих. Не важны они для описанного механизма - раз уж присобачили таймер, так пусть он все проблемы со скоростями и калибровками решает совершенно автономно от 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 ногом МК планировал применить вытесняющую ОС и писал на С++?