jcxz 241 16 марта, 2016 Опубликовано 16 марта, 2016 · Жалоба С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций. Не понял - о чём Вы? Сколько каких уровней? Вам же вроде надо только выделять кадры из потока байт (определять границы кадра в потоке байт)? Тут хоть с DMA хоть без (на прерываниях) будет только два процесса: 1-ый пишущий в кольцевой буфер байт; 2-ой - читающий из кольцевого буфера поток байт и разбирающий его на кадры. Всё. Если в этих кадрах у Вас инкапсулирован другой протокол - тогда да - дальше будет уровень парсинга уже его кадров из полученных ранее кадров протокола 1-го уровня. Но у Вас вроде только один протокол без вложенных. Если драйвер UART реализован без DMA: ISR UART пишет принимаемые байты в кольцевой буфер и пингует задачу, читающую этот буфер и парсящую поток байт на кадры. Если с DMA - то же самое: DMA пишет в тот же самый буфер и ISR завершения DMA-транзакции так же пингует задачу парсера. Единственно, что наверное записываемые группы байт будут больше, чем в варианте драйвера по прерываниям. В остальном - никакой разницы. Парсер протокола никак не должен зависеть от реализации драйвера UART и каким образом тот кладёт байты в кольцевой буфер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 16 марта, 2016 Опубликовано 16 марта, 2016 · Жалоба У меня в одном устройстве используется по приему кольцевой буфер DMA плюс прерывание по совпадению байта, и RFC1055 (SLIP). Основано на том, что в SLIP есть специальный байт "конец фрейма", только по нему и прерываюсь. под FreeRTOS это выглядит замечательно: прерывание добавляет адрес начала нового фрейма в очередь для задачи, которая разбирается с пакетами. А разборки идут уже в самой задаче, которая ждет непустой очереди или таймаута(по таймауту проверяется работоспособность и отсутствие ошибок в работе модуля приема-передачи). Таким образом, удается обеспечить прием не одного фрейма, а многих (сколько влезет в кольцо), если они идут группой и иногда обрабатываются дольше чем начинается новый фрейм. Очень дубово, надежно, и не ест лишних ресурсов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 17 марта, 2016 Опубликовано 17 марта, 2016 · Жалоба Следовательно из 256 вариантов байта необходимо зарезервировать несколько значений для признаков начала (или конца) фрейма и, возможно, каких-то других управляющий символов. Если массивы не очень большие, не более 255 байт, то проще всего использовать COBS. Тогда появление в потоке 0 будет означать "конец сообщения", этого будет достаточно. COBS можно применять и для длинных сообщений, но тогда продется заводить отдельный буфер для кодирования, ибо в процессе кодирования длина сообщения может немного увеличиваться. А для коротких сообщений заранее известно, что после кодирования COBS длина сообщения увеличится ровно на 1 байт, поэтому можно без дополнительного буфера обойтись. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tsvetik 0 17 марта, 2016 Опубликовано 17 марта, 2016 (изменено) · Жалоба Если массивы не очень большие, не более 255 байт, то проще всего использовать COBS. Тогда появление в потоке 0 будет означать "конец сообщения", этого будет достаточно. COBS можно применять и для длинных сообщений, но тогда продется заводить отдельный буфер для кодирования, ибо в процессе кодирования длина сообщения может немного увеличиваться. А для коротких сообщений заранее известно, что после кодирования COBS длина сообщения увеличится ровно на 1 байт, поэтому можно без дополнительного буфера обойтись. СУПЕР!! COBS - это как раз именно то, что мне нужно. и реализация миниатюрнейшая Большое спасибо. Изменено 17 марта, 2016 пользователем Tsvetik Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 17 марта, 2016 Опубликовано 17 марта, 2016 · Жалоба COBS - это как раз именно то, что мне нужно. Однако это кодировка с размножением ошибок. Скверный выбор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tsvetik 0 17 марта, 2016 Опубликовано 17 марта, 2016 · Жалоба Однако это кодировка с размножением ошибок. Скверный выбор. Что вы имеете ввиду? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 17 марта, 2016 Опубликовано 17 марта, 2016 · Жалоба Однако это кодировка с размножением ошибок. Скверный выбор. Да это как раз проблема равная 0, если в этот фреймер не запихивать данные с избыточным кодированим для восстановления. А вот то, что на лету нельзя кодировать, это уже может для очень многих случаев быть тоскливым. Причем пробегать буфер придется два раза - для контрольной суммы и собственно кодирования. А вообще этот COBS муть голубая - подставив вместо первого байта размер, а вместо последного 0x00 гарантированный таймаут получим привычную хрень, которая первой приходит в голову любому начинающему изобретателю фреймера. Только это будет уже БЕЗ ненужных дополнительных плясок с "кодированием" и с бонусом в виде аварийного выброса неполного фрейма по таймауту. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться