Опять UART, надоело городить самопальные протоколы Опции

[Tsvetik]

Нужно передавать массивы двоичных данных по UART между двумя устройствами.

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

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

Один из вариантов это /xon /xoff. Его минусы в том, что символы /xon /xoff могут встретиться в передаваемых двоичных данных и их надо экранировать. Плюс этого метода в том, что экранирование можно проводить "на лету" при приеме. Промежуточный буфер для этого не требуется.

Второй вариант использовать для кодирования двоичных данных некоторую кодировку. Например, BASE64 или семибитную кодировку, а старшие биты пристегивать отдельным байтом.
Тогда символы, не входящие в алфавит BASE64 или со взведенным старшим битом можно считать управляющими. На них можно повесить функции управления протоколом, начала-конца фрейма, повтора передачи, может-быть и адреса устройства и т.п. Обычно кодирование-декодирование требует промежуточного буфера и вносит дополнительные временные издержки.

Так вот, подскажите какие-нибудь популярные реализации логических протоколов поверх UART.
Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR.

Да, желательно без 9-го бита UART, чтобы с PC было проще отлаживаться

Сообщение отредактировал Tsvetik - Mar 14 2016, 11:37

[Baser]

Один из вариантов это /xon /xoff. Его минусы в том, что символы /xon /xoff могут встретиться в передаваемых двоичных данных и их надо экранировать.

Что вы называете "экранировать", не знаю, но для выделения уникального кода для управления применяется метод байт-стаффинга (byte stuffing).
Но отлаживаться с ним неудобно.

Обычно для простейших протоколов применяют разделение пакетов по тайм-аутам.
Самый простой и удобный метод.

А вообще для простеньких применений чаще всего применяют самопальные протоколы.
Правда, хороший самопальный протокол можно придумать только при достаточном опыте работы и предварительном написании кучи плохих самопальных протоколов

[Tsvetik]

Что вы называете "экранировать", не знаю, но для выделения уникального кода для управления применяется метод байт-стаффинга (byte stuffing).
Но отлаживаться с ним неудобно.

Обычно для простейших протоколов применяют разделение пакетов по тайм-аутам.
Самый простой и удобный метод.

А вообще для простеньких применений чаще всего применяют самопальные протоколы.
Правда, хороший самопальный протокол можно придумать только при достаточном опыте работы и предварительном написании кучи плохих самопальных протоколов

Байт-стаффинг и есть экранировать иначе, escape sequence

Тайм-ауты нафиг. Медленно и не хочу зависимость от таймера.

[Baser]

Байт-стаффинг и есть экранировать иначе, escape sequence

Тайм-ауты нафиг. Медленно и не хочу зависимость от таймера.

Ну так типовая структура любого протокола (набор полей):
Стартовый байт
Поле адреса
Поле длины данных
Поле данных
Поле CRC

На все это накладываете байт-стаффинг для стартового байта.
Дальше просто вариации из вышеперечисленного.

Но 99% протоколов промышленного применения, что я видел, не применяют байт-стаффинг
и используют тайм-ауты

[Tsvetik]

Ну так типовая структура любого протокола (набор полей):
Стартовый байт
Поле адреса
Поле длины данных
Поле данных
Поле CRC

На все это накладываете байт-стаффинг для стартового байта.
Дальше просто вариации из вышеперечисленного.

Но 99% протоколов промышленного применения, что я видел, не применяют байт-стаффинг
и используют тайм-ауты

Да вот что-то не нравится мне эта схема вот чем:
Длина идет не первым байтом. Если МК с DMA, то нужно будет несколько входов в обработчик прежде чем можно будет включить DMA.

Все, что здесь предлагали это какой-то самопал.
Неужели нет чего-то более-менее стандартног-популярного? Может, рекомендованного IEC или еще каким-то международным институтом?

Сообщение отредактировал Tsvetik - Mar 14 2016, 12:43

[jcxz]

Длина идет не первым байтом. Если МК с DMA, то нужно будет несколько входов в обработчик прежде чем можно будет включить DMA.

Не смешивайте уровни обработки. Драйвер DMA не должен никак зависеть от протокола в котором передаётся поток. Он вообще ничего не должен знать о протоколе.
Программируете DMA на любой удобный размер, запускаете и дополнительно, по таймеру отслеживаете состояние работы DMA, с принудительным завершением и перезапуском при простое принимаемого потока.

См. посто №1: "Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR."

Ну понятно. Это просто вспомнилось. К месту или не к месту

[Tsvetik]

Не смешивайте уровни обработки. Драйвер DMA не должен никак зависеть от протокола в котором передаётся поток. Он вообще ничего не должен знать о протоколе.
Программируете DMA на любой удобный размер, запускаете и дополнительно, по таймеру отслеживаете состояние работы DMA, с принудительным завершением и перезапуском при простое принимаемого потока.


Ну понятно. Это просто вспомнилось. К месту или не к месту

Ну, с одной стороны tiny, а с другой ARM7 или PC при тестах и отладке. Так что требование к DMA вторично.

С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций.

[jcxz]

С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций.

Не понял - о чём Вы? Сколько каких уровней?
Вам же вроде надо только выделять кадры из потока байт (определять границы кадра в потоке байт)?
Тут хоть с DMA хоть без (на прерываниях) будет только два процесса: 1-ый пишущий в кольцевой буфер байт; 2-ой - читающий из кольцевого буфера поток байт и разбирающий его на кадры. Всё.
Если в этих кадрах у Вас инкапсулирован другой протокол - тогда да - дальше будет уровень парсинга уже его кадров из полученных ранее кадров протокола 1-го уровня. Но у Вас вроде только один протокол без вложенных.

Если драйвер UART реализован без DMA: ISR UART пишет принимаемые байты в кольцевой буфер и пингует задачу, читающую этот буфер и парсящую поток байт на кадры.
Если с DMA - то же самое: DMA пишет в тот же самый буфер и ISR завершения DMA-транзакции так же пингует задачу парсера. Единственно, что наверное записываемые группы байт будут больше, чем в варианте драйвера по прерываниям.
В остальном - никакой разницы. Парсер протокола никак не должен зависеть от реализации драйвера UART и каким образом тот кладёт байты в кольцевой буфер.