Экономичный и быстрый протокол для обмена между микроконтроллерами с RTOS, Ищу идеи по реализации Опции

[AlexandrY]

Есть два микроконтроллера связанных по одному из интерфейсов UART, SPI, I2C или еще каким либо последовательным интерфейсом.
Обмен между ними достаточно скоростной, не менее 1 Мбит/c.

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

Но а дальше как?

Как упаковывать данные, какие хидеры им давать, как контролировать целостность чтобы все это занимало как можно меньше процессорного времени и полосы пропускания.
Затем вопрос по программной архитектуре приемников.
Делать ли общий конвейер в драйвере приемника куда бы копировались все пакеты или может быть создавать таблицу подписки для драйвера где все заинтересованные задачи регистрировали бы свои принимающие конвейеры или майлбоксы?
Если таблица подписки то разумно ли драйвер нагружать функцией менеджера сообщений? Это будет замедлять драйвер, хотя будет легко добавить механизм приоритетности.
Если делать общий конвейер, то все равно нужен менеджер сообщений, но в отдельной задаче. А это уже расход стека на дополнительную задачу...

Да, и речь идет о жестком риалтайме и малых микроконтроллерах типа Cortex-M4, т.е. никаких линуксов и стандартных API типа POSIX.

[SyncLair]

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

Есть ооочень много сериализаторов (самые знаменитые JSON и прочие соны) -- но к сожалению я не смог освоить ни один из них применительно к контроллером.

Одна из старых разработок ASN -- я даже патч к нему сделал чтобы компилировалось под Windows -- но автор его забросил и перешёл к коммерческому варианту -- а свободный написан уж не так хорошо.

ASN может упаковывать в поток XML струтур, упаковывать на байтовом уровне и даже на битовом.

[AlexandrY]

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

Есть ооочень много сериализаторов (самые знаменитые JSON и прочие соны) -- но к сожалению я не смог освоить ни один из них применительно к контроллером.

Одна из старых разработок ASN -- я даже патч к нему сделал чтобы компилировалось под Windows -- но автор его забросил и перешёл к коммерческому варианту -- а свободный написан уж не так хорошо.

ASN может упаковывать в поток XML струтур, упаковывать на байтовом уровне и даже на битовом.

Боюсь вы сериализации пытаетесь найти неправильное применение.
Есть аппаратная сериализация и есть программная сериализация. Это абсолютно разные вещи.
С аппаратной сериализацией в микроконтроллерах нет никаких проблем. Я начал с того, что у меня есть широкий выбор сериализирующих интерфейсов.
Программная сериализация же в связке двух микроконтроллеров не имеет никакого смысла. Ибо это по сути конверсия данных в формат не зависящий от среды передачи и от аппаратных различий вычислительных платформ и с общей спецификацией.
Но в среде микроконтроллеров, где скажем я применяю только 32-х разрядные ARM-ы, little-endian и единый компилятор совсем не нужна аппаратная независимость и human-readable формат как у JSON, XML и проч.
Т.е. нет никаких оснований для сериализации. Можно брать и тот же тип float как есть из памяти без всяких конверсий посылать в коммуникационный канал и он будет безусловно понят на той стороне. И никаких перекодировок вроде ASN не нужно.
Роль общих спецификаций выполняют разделяемые .h файлы в проектах для обоих микроконтроллеров.
Все предельно просто. Не просто только уложиться в жесткий риалтайм.

Я применяю парсеры JSON, и скажу, что парсинг даже 45 КБайт файла может занять 9000% процессорного времени на 266 МГц ARM9. Т.е. в 100 раз превысить длительность системного цикла.
О риалтайме даже речи быть не может.
ASN тоже применяю в SNMP протоколе. Это крайне избыточное кодирование оправданное только по сравнению с plain текстом. Он занял бы не менее 40% лишних процентов полосы пропускания.
У меня же цель сделать протокол который бы занял при скорости 1 Мбит не более 1% процессорного времени на упомянутой архитектуре и с оверхедом на хидеры не более 10%