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

supercelt · 27.03.2017, 23:06

Привет! Я сделал такую штуку. Принимаю байт по USART, записываю его в массив и обнуляю счётчик таймера. И так далее. И вот наступил момент когда последний байт передан (Но я как бы не знаю что он именно последний). Так вот. Таймер настроен таким образом, что если какое-то время нет передачи по usart, значит информация принята вся. Срабатывает прерывание и ставится флаг, что можно кромсать массив. Говорили тут, что время, за которое можно судить о том, что данные приняты - это если нет приёма в течении времени за которое принимается 3 байта. Я бы хотел максимально точно подобрать это время, в зависимости от скорости usart конечно. Как расчитать: сколько времени в секундах тратит usart, что бы передать 1 байт, если скорость 9600 бод?

akegor · 27.03.2017, 23:17

Сообщение от supercelt

Как расчитать: сколько времени в секундах тратит usart, что бы передать 1 байт, если скорость 9600 бод?

Вы забыли о других параметрах передачи.

Сообщение от supercelt

Я бы хотел максимально точно подобрать это время

Смысл в максимальной точности, если

Сообщение от supercelt

Говорили тут, что...

критерий весьма расплывчатый и зависит много от чего?

_SayHello · 27.03.2017, 23:36

Обычно к байту добавляется бит четности и например стоп биты. Берете 9600/(8 + n битов четности + m стоп битов) получаете количество байт в секунду. Если у вас, что то типа модбаса, там вроде 3.5 символа, а не байта. Т.е. ваш 3,5*( байт + оформление к нему).Вроде так

индюк · 28.03.2017, 00:07

Какойто бред. Все нормальные усройства в конце передаюи либо рн либо еще какойто признак и нафиг не упало ждать у моря погоды.
А еще у уарта есть флаг idle line то есть ваше действо с таймером реализовано аппаратно уже

dgrishin · 28.03.2017, 09:16

Сообщение от supercelt

И вот наступил момент когда последний байт передан (Но я как бы не знаю что он именно последний).

А вот именно для этого умные люди написали стандарт и придумали дополнительные цепи для управления потоком данных - RTC, CTS, DTR, DSR.
Можно использовать RTC или DTR для определения конца передачи (завести на отдельную ножку)

_SayHello · 28.03.2017, 10:38

Сообщение от индюк

Какойто бред. Все нормальные усройства в конце передаюи либо рн либо еще какойто признак и нафиг не упало ждать у моря погоды.
А еще у уарта есть флаг idle line то есть ваше действо с таймером реализовано аппаратно уже

Ну тут вы не правы, разделение пакетов интервалом "тишины" достаточно популярный метод. Взять хотя бы протокол Modbus - достаточно известный в промышленности протокол. Я подозреваю что автор пилит что-то под него или подобное.

индюк · 28.03.2017, 10:44

Сообщение от _SayHello

разделение пакетов интервалом "тишины" достаточно популярный метод.

ок, не вопрос - включаем прерывание по флагу idle line

_SayHello · 28.03.2017, 10:51

индюк, это как вариант, хотя я тоже делал с таймером, в f3 есть вообще железная реализация проверки длины Idle в длинах символов для протокола Modbus, только у меня как то не получилось ее завести

mike-y-k · 28.03.2017, 11:22

А может стоит определится с терминологией изначально? Таки UART или USART? Они конечно местами похожи но и разница весьма существенна. А по написанному выше пока таки исключительно UART.
А дальше запрашиваемое ТС считается для одной единственной посылки из параметров, заданных при конфигурации. Считать что-то на основе нескольких переданных байт - примерно как определять погоду на Марсе по косвенным признакам на Земле.
Логику такой передачи надо менять - или по количеству переданных данных, или по признаку завершения в потоке данных, или опросом источника. При асинхронной работе время ну никак не поможет, если только оно опять же не является условием.
Пока в спецификации задачи слишком много пробелов в существенных параметрах для ответа.

nml · 28.03.2017, 11:41

Отсутствие передачи, imho, ненадежно. Например - передающее устройство сдохло/оторвалось. Тишина... Обрабатываем весь массив (который не принят).

Я бы сделал протокол - с маркером, контрольной суммой.