Время передачи 1 байта USART

[STM32F0]

Да бред всё это... и свой протокол тоже. ТС партизанит и он сам не знает что он хочет. Здесь вообще разговор в общем и ни о чём.

[eenote]

Отсутствие передачи, imho, ненадежно.

Modbus RTU работает по этому принципу.

[hacker7]

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

[pisetsky]

Если речь идет именно об UART, причем работает он в асинхронном режиме (байт-ориентированный, ежели чо), то:
1. Спереди к байту добавляется стартовый бит (+1)
2. Сзади к байту добавляется (или нет - как заказали) четность (+1) и 1-1.5-2 стоповых (+1 или +1,5 или +2 - как запрограммировали)
Итого, байт "обкладывают" со всех сторон от 2 до 4 служебных бит.
3. А интервал между байтами - сверху - ничем не ограничен (на уровне UART)! Его может ограничивать протокол, но об нем речь не шла! Так что можно ждать следующего байта и до обеда...

[mike-y-k]

Тут ожидание больше похоже на "до морковкина заговенья" .
Пока ТС не расскажет в подробностях про свои условия - только осадок от кофе.
Да и название темы таки стоит ему поправить.

[NewWriter]

Modbus RTU работает по этому принципу.

У модбаса в заголовке указано число передаваемых байт, а в конце - контроньная сумма.
Кароче говоря, основные способы таковы:
- число пересылаемых байт определено заранее протоколом и фиксировано.
- число передаваемых байт передается в заголовке, заголовок фиксированной длины.
- конец передачи определяется по специальному оговоренному символу или нескольким символам. типичный пример - GPS-приемники или GSM-модемы, некоторые устройства. обмен инфой идет в ASCII-синтаксисе, обычным текстом

[AR_Favorit]

У модбаса в заголовке указано число передаваемых байт

Не надо болтать ерундой. Modbus RTU - не имеет никакого числа передаваемых данных. И конец фрейма определяется именно по "тишине" в течение времени, соответствующего времени передачи 14 бит.

- конец передачи определяется по специальному оговоренному символу или нескольким символам. типичный пример - GPS-приемники или GSM-модемы

например, в случае с GSM-модемом, специально оговоренными символами строка не только заканчивается, но и начинается, что приводит к необходимости лишних неудобных телодвижений для определения, получили ли только начало строки и надо не рыпаться, поскольку вот-вот насыплется еще всякоразных символов, либо получили конец, и можно пойти поразбираться, что там нам пришло)

[supercelt]

Да уже писал похожую тему, то ли тут, то ли не тут. Вобщем смысл такой, что я принимаю ответ от модема по usart. RTS, CTS на модеме нет. только Rx, Tx, и Gnd. Так что мне надо как-то без них железно распознать, что закончилась передача. Хотя вы правы. что сказали, ежели модем отвалится и мк как бы распознает конец передачи. Но это уже другая история. Есть одна особенность, почти каждое принимаемое сообщение содержит в конце ответа "\r\nOK\r\n". Можно было бы сделать strstr поискать подстроку. Но получается тогда, что надо это проверять после каждого принятого байта. Строковая функция наверное прожорлива. И к тому же вот встанет такая задача - принимать и СМС. А в СМС легко может кто-то по тексту просто написать OK, да ещё и с символами новой строки. Это конечно мало вероятно, но всё-таки надо учитывать. Вот и думаю, как гарантировано понять что пришло всё.

[OakRidge]

Ну делал. Мастер звал слейва. А его можно быть небыло.
Следил за временем ответа. Больше какогото времени ответа с слейва нету. Звал следующего.
Разумеестся CRC ответа критерий фальшивки.
Не доделал, контора бахнулась. Ушел. Так и осталось, на 3/4 сделано недосделано
Берите CAN BUS, несмотря на дороговизну. Легче будет !

[supercelt]

попробовал сделать по прерыванию IDLE. Штука хорошая, но как только встретит в строке символ \n, выкидывает прерывание. А этот символ, встречается и в середине строки вот так-то((((