[jcxz 184]

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

Не понял - о чём Вы? Сколько каких уровней?

Вам же вроде надо только выделять кадры из потока байт (определять границы кадра в потоке байт)?

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

Если в этих кадрах у Вас инкапсулирован другой протокол - тогда да - дальше будет уровень парсинга уже его кадров из полученных ранее кадров протокола 1-го уровня. Но у Вас вроде только один протокол без вложенных.

 

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

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

В остальном - никакой разницы. Парсер протокола никак не должен зависеть от реализации драйвера UART и каким образом тот кладёт байты в кольцевой буфер.

[Ruslan1 14]

У меня в одном устройстве используется по приему кольцевой буфер DMA плюс прерывание по совпадению байта, и RFC1055 (SLIP).

Основано на том, что в SLIP есть специальный байт "конец фрейма", только по нему и прерываюсь.

под FreeRTOS это выглядит замечательно: прерывание добавляет адрес начала нового фрейма в очередь для задачи, которая разбирается с пакетами.

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

Таким образом, удается обеспечить прием не одного фрейма, а многих (сколько влезет в кольцо), если они идут группой и иногда обрабатываются дольше чем начинается новый фрейм.

Очень дубово, надежно, и не ест лишних ресурсов.

[=AK= 10]

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

 

Если массивы не очень большие, не более 255 байт, то проще всего использовать COBS. Тогда появление в потоке 0 будет означать "конец сообщения", этого будет достаточно. COBS можно применять и для длинных сообщений, но тогда продется заводить отдельный буфер для кодирования, ибо в процессе кодирования длина сообщения может немного увеличиваться. А для коротких сообщений заранее известно, что после кодирования COBS длина сообщения увеличится ровно на 1 байт, поэтому можно без дополнительного буфера обойтись.

[Tsvetik 0]

Если массивы не очень большие, не более 255 байт, то проще всего использовать COBS. Тогда появление в потоке 0 будет означать "конец сообщения", этого будет достаточно. COBS можно применять и для длинных сообщений, но тогда продется заводить отдельный буфер для кодирования, ибо в процессе кодирования длина сообщения может немного увеличиваться. А для коротких сообщений заранее известно, что после кодирования COBS длина сообщения увеличится ровно на 1 байт, поэтому можно без дополнительного буфера обойтись.

 

СУПЕР!!

COBS - это как раз именно то, что мне нужно.

и реализация миниатюрнейшая

 

Большое спасибо.

Изменено 17 марта, 2016 пользователем Tsvetik

[AlexandrY 2]

COBS - это как раз именно то, что мне нужно.

 

Однако это кодировка с размножением ошибок.

Скверный выбор.

[Tsvetik 0]

Однако это кодировка с размножением ошибок.

Скверный выбор.

 

Что вы имеете ввиду?

[zltigo 0]

Однако это кодировка с размножением ошибок.

Скверный выбор.

Да это как раз проблема равная 0, если в этот фреймер не запихивать данные с избыточным кодированим для восстановления. А вот то, что на лету нельзя кодировать, это уже может для очень многих случаев быть тоскливым. Причем пробегать буфер придется два раза - для контрольной суммы и собственно кодирования. А вообще этот COBS муть голубая - подставив вместо первого байта размер, а вместо последного 0x00 гарантированный таймаут получим привычную хрень, которая первой приходит в голову любому начинающему изобретателю фреймера. Только это будет уже БЕЗ ненужных дополнительных плясок с "кодированием" и с бонусом в виде аварийного выброса неполного фрейма по таймауту.