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

[AlexandrY]

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

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

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

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

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

[AndrewN]

Новелла увы, превратилась в устареллу, но попохвалятся хочется. Было нужно организовать

общение ARM и DSP на одном кристалле

- девайс DM6446/DM6467. Сначала попытался сделать попроще, но в итоге пришёл к необходимости сделать синхронный мини-драйвер, на 4 I/O канала

[...] никаких линуксов и стандартных API типа POSIX

естественно, в ОС, но не Linux, не DSP/BIOS и не SYS/BIOS.

разумно ли драйвер нагружать функцией менеджера сообщений?

Соответственно, вся логика такого мини-драйвера указывает (вопиёт) на то, что именно драйвер и должен быть менеджером сообщений и процессов, ожидающих I/O по каналу. Естественно, не имеет значения, какой процесс инициирует передачу, ресивер или трансмиттер и на каком из двух ЦПУ (понятно, что транзакция должна начатся в тот момент, когда на концах канала есть оба процесса, передатчик и приёмник). Приоритеты в очередях не учитываются, очереди - обычные FIFO, но каналов-то несколько, они могут быть поделены для разных приоритетов. И небольшой протокольчик тоже необходим, что бы, по крайней мере, передать ресиверу признак завершения транзакции трансмиттером.

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

В общем, мучился в одиночку, сюда не смотрел, а вы тут уже без меня всё сделали...