[zltigo 1]

P.S. Попробуйте на некалиброванном RC-генераторе UART реализовать, в целях экономии...

Не валите в кучу две разных задачи. Подстройка под RC генератор может вообще осуществляться периодически по длительности специально передаваемого Break и соответственно совершенно не быть завязаным на какие-либо протокольные вещи.

[x736C 0]

Не валите в кучу две разных задачи. Подстройка под RC генератор может вообще осуществляться периодически по длительности специально передаваемого Break и соответственно совершенно не быть завязаным на какие-либо протокольные вещи.

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

 

P. S. Попытка с менторским тоном придумать эту разницу уважения к вашему профессионализму, в котором лично у меня не возникает никаких сомнений, не добавляет.

[zltigo 1]

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

При этом налагая ДОПОЛНИТЕЛЬНЫЕ НЕНУЖНЫЕ ограничения на эту самую процедуру, вместо того, что-бы процедура только выбрасывала битые фреймы в ней начинают наворачивать поиск пауз, подсчет фронтов в байте следущим после паузы, протокольные ограничения....

Попытка с менторским тоном придумать эту разницу...

Эта разница, простите, совершенно не придумана :(, она объективно есть. Любую задачу можно решить максимально извращенным способом - тут спору нет, но лучше проще. Предки, например, заложили тот-же Break совсем не зря.

[rezident 0]

Может, с autobaud'ом перепутали, а?

Скорее уж асинхронный приемопередатчик (UART) с самосинхронизирующимся, использующего что-то типа манчестерского кода.

[x736C 0]

Вы тоже налагаете ограничение в виде постоянной посылки break. Шило на мыло.

Замена одного априорно известного байта, на другой «байт», который надо:

1. отделить от других данный (в том числе на стороне передатчика);

2. измерить тем же счетчиком.

Ну и третье. Так как скорость передачи неизвестна, то как этот break не спутать с нулевым БИ или их комбинацией, следующей на пониженной скорости, мне не ясно.

Опять-таки, в кучу свалено две задачи, калибровка и автоподстройка.

 

Калибровка RC-генератора при известной скорости передачи не представляется настолько простецкой, чтобы в данном контексте ей пренебрегать.

http://www.atmel.com/dyn/resources/prod_do...nts/doc2563.pdf

 

Добавить сюда еще autobaud rate — вообще сомнительное предприятие для случая @Ark.

 

Добавлю: что в предложенном appNote от Atmel к сигналу break добавлен еще байт синхронизации. Разве ж это проще. :)

 

Так что где изврат — это еще вопрос. :)

С уважением.

Изменено 25 августа, 2009 пользователем x736C

[zltigo 1]

Вы тоже налагаете ограничение в виде постоянной посылки break. Шило на мыло.

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

1. отделить от других данный (в том числе на стороне передатчика);

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

и выбрасывается.

2. измерить тем же счетчиком.

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

Ну и третье. Так как скорость передачи неизвестна, то как этот break не спутать с нулевым БИ или их комбинацией, следующей на пониженной скорости, мне не ясно.

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

Опять-таки, в кучу свалено две задачи, калибровка и автоподстройка.

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

[x736C 0]

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

(То, что это существует аппаратно где-то и в чем-то отношения к теме не имеет).

Я ничего не сваливал в кучу, вы что-то напутали по ходу наших рассуждений, все было свалено до меня. :)

«Для решения одной из двух задач..» Да кто ж с этим спорит? Только зачем навязывать «простое» решение для задачи, которая перед человеком не стояла. :)

В общем бессмысленный спор, думаю, вы со мной согласитесь хотя бы в этом.

[zltigo 1]

«Break должен быть длиннее самого длинного байта».. Это ли не ограничение на протокол передачи?

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

Длинный break, перекрывающий все возможное, решает проблему калибровки. Но остается необходимость реализовывать отдельно autobaud rate.

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

[x736C 0]

Мы уже пошли по кругу.

Если вам надо в линию что-то передавать кроме данных, то это уже ограничение.

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

То есть протокол должен учитывать тот факт, что на 3,3 мс передача ему будет недоступна.

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

Я вроде понятно излагаю.

 

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

Тут я вижу ошибку.

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

 

Например break на скорости 115200 просто удивительно точно совпадает с 1 нулем на скорости 9600.

То есть байт синхронизации или брейк делиметер тут необходим со всем вытекающим.

Я же говорю, это шило на мыло.

[zltigo 1]

Я вроде понятно излагаю.

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

[Гость @Ark]

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

Не валите в кучу две разных задачи...

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

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

Аналогично поступаем в случае сбоев (возможно из-за "ухода" текущего значения частоты RC)...

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

[SapegoAL 0]

«Восстанавливается инфа включая первый байт с вероятностью 98%».

Странно, что вы указываете вероятность успешного приема первого байта, хотя не известна вероятность получения конкретных байт.

Вероятность успешного приема первого байта, имхо, сильно зависит от того, какой это будет байт. Поэтому откуда взята цифра 98% ? :)

Честно говоря так по памяти выдал. Немного ошибся. Сейчас посчитал примерно 95% получается.

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

 

Вероятность появления неблагоприятного байта при «случайном» обмене, конечно, можно посчитать, но не думаю, что вы это делали.

@Ark этот вопрос решил просто, сделал её единицей (около того), пожертвовав первым байтом.

И потом, по моему мнению, вы сильно усложнили. Проверять одно, второе, прогнозировать третье. В погоне за этим первым байтом что ли?

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

[x736C 0]

Как правило наименьший БИ двигает скорость в сторону увеличения, а у вас специальный символ брейк двигает скорость в сторону уменьшения. Это конечно «проще», это конечно «эффективнее».

Обратно как собираетесь скорость возвращать, если она изменится?

Вы с таким упорством пытаетесь доказать, что предложили нечто лучшее, чем реализовал @Ark для тех элементарных требований, которые у него были.

Проще вы это не сделаете так, как описываете. Я вам попытался доказать, но у меня не получилось.

 

SasaVitebsk, сложно, не значит плохо и я лишь предположил. Я рад за вас, что все работает успешно.

У вас, опять же, видимо была своя задача. Немного не понимаю, почему вы говорите о восстановлении потока. Что-то связано с модем.

95% это очень мало. Скорее всего мы о разном тут говорим.

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

[zltigo 1]

реализовал @Ark для тех элементарных требований, которые у него были.

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

Проще вы это не сделаете так, как описываете.

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

Обратно как собираетесь скорость возвращать, если она изменится?

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

[x736C 0]

Ой, да, мы о разном. :)

Вы о первом байте, а я вообще.

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