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

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

У меня в одном устройстве используется по приему кольцевой буфер DMA плюс прерывание по совпадению байта, и RFC1055 (SLIP).
Основано на том, что в SLIP есть специальный байт "конец фрейма", только по нему и прерываюсь.
под FreeRTOS это выглядит замечательно: прерывание добавляет адрес начала нового фрейма в очередь для задачи, которая разбирается с пакетами.
А разборки идут уже в самой задаче, которая ждет непустой очереди или таймаута(по таймауту проверяется работоспособность и отсутствие ошибок в работе модуля приема-передачи).
Таким образом, удается обеспечить прием не одного фрейма, а многих (сколько влезет в кольцо), если они идут группой и иногда обрабатываются дольше чем начинается новый фрейм.
Очень дубово, надежно, и не ест лишних ресурсов.

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

СУПЕР!!
COBS - это как раз именно то, что мне нужно.
и реализация миниатюрнейшая

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

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

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

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

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