Время передачи одного символа по USART

Доброе время суток.
В данный момент задача такая. По USORT надо гонять данные. Один мастер и несколько слейвов. Мастеру необходимо понять, когда слейв закончил передачу и начинать опрос следующего. Каждый слейв может выдать информацию по нескольким каналом, их число и размер заранее не известны. Думаю сделать так, что если после получения последнего символа прошло некое время (ну скажем время передачи символа умноженное на некий коэффициент) а новый символ не поступил, значит слейв закончил передачу.
До этого я думал, что скорость в бодах означает количество бит, проталкиваемых в секунду. Однако засомневался в том, что время передачи одного байта будет равно 1/скорость в бодах и умноженную на 8. Как минимум есть старт и стоп биты. То есть, усреднено можно взять время за 1/скорость в бодах и умноженную на 10 (старт и стоп биты + байт).
Но тут опять засомневался, может есть какие то еще не учтенные задержки типа перезарядки сдвигового регистра, может какого нибудь хендшейка и т.д. На момент передачи первого байта слейвом, у него сформирован весь буфер передачи, то есть данные уходят по готовности передатчика, затрат на формирование данных нет.
Собственно вопрос в том, как в зависимости от скорости USORT определить среднее время передачи (хотя наверное правильнее говорить о приеме) байта?

0

Тут уместней y2s имхо.

Усарт это асинхронный протокол и тут по времени что то ловить не самая лучшая идея. Либо вводить маркеры начала и конца.

0

Сообщение от DY HOTT Тут уместней y2s имхо. Усарт это асинхронный протокол и тут по времени что то ловить не самая лучшая идея. Либо вводить маркеры начала и конца.

Забыл написать, данные будут ходить по RS485.
А вот с маркерами боюсь засада. Маркер начала не особо нужен, как мне кажется, потому, что мастер передает слейву запрос, переключается в режим прослушивания и первый полученный байт будет началом (первым будет передаваться ID слейва). А вот с концом проблемы. На уровне протокола жестко ограничивать размер пакетов данных, как то западло, лишний расход памяти, хрянить все возможные варианты. А вот как сделать маркер конца, ума не приложу. Каким бы я не сделал байт или последовательность байт конца, она все равно сможет совпасть по содержанию с началом или серединой обычных данных, которые по стечению обстоятельств содержат сигнатуру маркера конца передачи.

0

Сообщение от Doimom78 Сообщение от DY HOTT Тут уместней y2s имхо. Усарт это асинхронный протокол и тут по времени что то ловить не самая лучшая идея. Либо вводить маркеры начала и конца.

Забыл написать, данные будут ходить по RS485.
А вот с маркерами боюсь засада. Маркер начала не особо нужен, как мне кажется, потому, что мастер передает слейву запрос, переключается в режим прослушивания и первый полученный байт будет началом (первым будет передаваться ID слейва). А вот с концом проблемы. На уровне протокола жестко ограничивать размер пакетов данных, как то западло, лишний расход памяти, хрянить все возможные варианты. А вот как сделать маркер конца, ума не приложу. Каким бы я не сделал байт или последовательность байт конца, она все равно сможет совпасть по содержанию с началом или серединой обычных данных, которые по стечению обстоятельств содержат сигнатуру маркера конца передачи.
А зачем выдумывать свой протокол, если их раработано и стандартизировано множество?
Проще всего использовать протокол ISIS-II, например. Это "старый добрый HEX-код. Начисто пропадает проблема генерации всевозможных маркеров и контроля ошибок. Его до сих пор используют во множестве программаторов.

0

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

0

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

Как говорят: - Хозяин - Барин! :-)))
Но если один раз хорошо реализовать проект, в будущем меньше проблем будет!
Тем более, что программа получается простой и красивой!

0

Сообщение от vystor_b_k Сообщение от Doimom78 Да я как то и не смотрел в сторону серьезных протоколов, мне надо то всего три-четыре команды реализовать. Видимо лучшим вариантом будет передача первым байтом длины всего сообщения.

Как говорят: - Хозяин - Барин! :-)))
Но если один раз хорошо реализовать проект, в будущем меньше проблем будет!
Тем более, что программа получается простой и красивой!

Погуглил на тему ISIS-II, и нашел только IS-IS (протокол маршрутизации Intermediate System-to--Intermediate System), что то мне подсказывает, что Вы не его имели ввиду :)

0

Сообщение от Doimom78 Сообщение от vystor_b_k Сообщение от Doimom78 Да я как то и не смотрел в сторону серьезных протоколов, мне надо то всего три-четыре команды реализовать. Видимо лучшим вариантом будет передача первым байтом длины всего сообщения. Как говорят: - Хозяин - Барин! :-))) Но если один раз хорошо реализовать проект, в будущем меньше проблем будет! Тем более, что программа получается простой и красивой!

Погуглил на тему ISIS-II, и нашел только IS-IS (протокол маршрутизации Intermediate System-to--Intermediate System), что то мне подсказывает, что Вы не его имели ввиду :)
Нет, не его. Протокол ISIS-II, в основном, знаменит тем, что значение каждого байта передается в HEX-коде. А в начале каждого пакета передается код двоеточия - 0x3A.
Затем следует байт количества передаваемых байтов. После него байт типа пакета: - команда, данные и т.п. Далее, в стандартном протоколе передается адрес загрузки первого байта пакета. Потом передаются байты данных. После них байт дополнения контрольной суммы - ДКС. ДКС - это сумма всех переданных байтов без учета переноса (кроме двоеточия) с обратным знаком. На принимающей стороне для контроля, просто суммируются все байты, и, если нет ошибок, то в сумматоре должен оказаться нуль. После ДКС, обычно добавляют символы "Возврат каретки" (0x0D) и "Перевод строки" (0x0A). Это для того, чтобы можно было удобно читать передаваемую информацию с помощью текстового редактора. Вы можете легко просмотреть любой HEX-файл и убедиться. Но главная фишка этого формата заключается в том, что каждый байт передается в виде HEX-кода. Т.е., например если передается байт, в котором закодирован, например, символ "А" - код его 0x41 - передается вначале код четверки; - т.е. - 0x34, а затем код единички - 0x31. При этом реально любой байт будет содержать только семь битов, что позволит в восьмибитовых передачах осуществлять дополнительно проверку на четность. Это еще больше увеличивает надежность связи.

0

Подобное кодирование часто применялось также при работе с перфолентой. Там иногда кроме "поперечного" контроля каждого байта по нечетности, использовали также "продольный контроль" - четность или нечетность суммы бит каждой битовой дорожки блока.
Помнится, программа загрузчика Intel HEX кода с перфоленты для контроллера на I8080 была длиной всего не то 62, не то 162 байта...
А в "Электранике НЦ-32" с перфоленты сначала загружался загрузчик, потом уже он загружал основную программу (до 32кб). Скорость загрузки доходила до 3 метров в секунду, а край ее мигом резал руки, если грузилось в старт - стопном режиме - перфолента ревела, как реактивный самолет на взлете...

Сообщение от SWK А в "Электранике НЦ-32" с перфоленты сначала загружался загрузчик, потом уже он загружал основную программу (до 32кб). Скорость загрузки доходила до 3 метров в секунду, а край ее мигом резал руки, если грузилось в старт - стопном режиме - перфолента ревела, как реактивный самолет на взлете...

Продолжу такой милый сердцу оффтоп.
У нас на машинах местного производства (уж и забыл, как назывались, выпускал завод Королева, вполне нормальных компах, кстати) была такая же штука. Тот загрузчик мы называли "абсолютным". И эта короткая ленточка всегда должна была быть под рукой - без нее начать работу было нельзя. Даже делали ее не бумажной, а из какой-то пластиковой ленты, чтобы дольше служила.
Но вот прикол: та простенькая прога, что с нее грузилась, была довольно глупо неоптимальна. Проверка готовности перфосчитывателя делалась сразу после выдачи команды "ПРИНЯТЬ 1 БАЙТ". Ждали, а потом производили укладку этогог байта в память и наращивание адреса. И что придумал наш сотрудник Валадя Федив: он переставил проверку готовности ПОСЛЕ упаковки байта в память. То есть, шли параллельно 2 процесса - перфосчитыватель протягивал ленту на 1 байт, а в это время в память укладывался предыдущий байт.
Вы не поверите: результат был ошеломляющий! Лента перестала идти с треском, а начала просто бесшумно ЛЕТЕТЬ. Эти огромные бобины программ загружались теперь так приятно тихо и быстро, что мы ошалели.
Загрузчик после этого стали называть "абсолютный Федив", в честь нашего кулибина.
Ну, а касательно топика, то уважаемые коллеги говорят о способе кодирования информации, а не о способе огранизации обмена между мастером и слейвами. Думаю, автору темы следует посмотреть в сторону старого доброго Модбаса. Там, кстати, именно период тишины и означает, что линия свободна.

0

Большое спасибо отписавшимся, теперь есть материал для работы.

0