Pull to refresh

Comments 8

В этой статье будет рассмотрена организация пакетов данных для их отправки по интерфейсам связи

а я что-то не обнаружил в изложенном кода отправки? Архитектура есть, конструкторы есть, а где отправка то? Хотя отправка на самом деле не так интересна! Отослать - записать (в уарт например) N байт задача тривиальная! Хотя если делать на прерывании что-то интересное тоже будет. Но гораздо интереснее как вы организуете прием! Во время приема надо не потерять синхронизацию с началом пакета, вот это серьезно не тривиальная задача.

Отправка правда дольно просто выполняется через встроенные функции либо юарта, либо ком-порта
А по поводу приёма информации будет отдельная статья, там много интересных моментов есть)

Есть ещё вариант использовать COBS + ProtocolBuffers (nanopb для ESP, под STM не знаю, что за либа).

COBS гарантирует, что не будет нулевых байтов в данных, поэтому такие байты можно использовать как разделители пакетов. Учитывая, что можно настроить аппаратную детекцию нулевого байта, остаётся только правильно вычитать данные и пробовать декодировать.

Ну а ProtocolBuffers уже использовать или не использовать - на ваше усмотрение, в принципе можно и обычными структурами обмениваться, просто PB кроссязычный

а еще можно начало пакета пометить как-то совсем уникально. например, перейти на 9бит. или протянуть еще один проводок между мастером и слейвом(ами). и заодно в этом уникальном байте кодировать тип пакета - код может определять направление передачи и длину блока данных.

Как будто бы использование ProtocolBuffers может быть немного излишним при небольших пакетах данных. Да и вроде в моей структуре при добавлении новых полей в конец структуры не ломает декодирование пакетов, если оно происходит позиционно (т.е. если априори известно, что 1-4 байты являются float acc_x, 5-8 байты являются float acc_y и так далее).
COBS в работе не использовал, так что ничего сказать не могу, но буду иметь ввиду, спасибо!

Под STM32 тоже nanopb используем.

Самое главное при работе с динамической памятью на микроконтроллерах без MMU- не забывать о том, что можно словить фрагментацию памяти, если в коде идет постоянный вызов конструкторов/деструкторов. Не знаю, как такой код работает на STM-ках сейчас, но раньше это было проблемой, которая решалась либо переопределением аллокаторов, либо проганьем на голом C

если в коде идет постоянный вызов конструкторов/деструкторов

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

Sign up to leave a comment.

Articles