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

[AlexandrY]

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

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

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

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

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

[Fujitser]

Сериализацию тут зачем-то вспомнили, это вообще из другой оперы. Мне кажется, тут все достаточно просто: если контроллеры расположены на одной плате, то между ними можно организовать быстрый обмен по SPI или через параллельный интерфейс. Если это разные платы (или разные устройства), то в зависимости от дальности/помехоустойчивости/цены - I2C, RS232, RS485, 1-wire, CAN или еще 100500 вариантов, вплоть до Ethernet.
А какой заголовок прикрутить к кадру данных, какая разница, по сути...

[AlexandrY]

Сериализацию тут зачем-то вспомнили, это вообще из другой оперы. Мне кажется, тут все достаточно просто: если контроллеры расположены на одной плате, то между ними можно организовать быстрый обмен по SPI или через параллельный интерфейс. Если это разные платы (или разные устройства), то в зависимости от дальности/помехоустойчивости/цены - I2C, RS232, RS485, 1-wire, CAN или еще 100500 вариантов, вплоть до Ethernet.
А какой заголовок прикрутить к кадру данных, какая разница, по сути...

Вариантов не так много на самом деле.
1-wire, RS232, RS485 и CAN названные здесь не к месту.
Они все требую внешних драйверов которые в пределах платы совсем не нужны.
А вот заголовок любой не прилепишь без глубокого планирования функциональности.
Потому что если ошибетесь и напишите протокол, то потом смена структуры заголовков будет сложнее чем прилепить гигабитный Ethernet.

[ViKo]

1-wire, RS232, RS485 и CAN названные здесь не к месту.
Они все требую внешних драйверов которые в пределах платы совсем не нужны.

Я использую для связи между микроконтроллерами UARTы, без драйверов. Скорость 250000 bps. Любой из микроконтроллеров может начать передавать по собственному желанию.

[AlexandrY]

Я использую для связи между микроконтроллерами UARTы, без драйверов. Скорость 250000 bps. Любой из микроконтроллеров может начать передавать по собственному желанию.

А почему именно UART-ы? Только из-за асинхронности?
Или в расчете на большую помехоустойчивость, поскольку они сэмплируются по нескольку раз на бит?

И почему вы считаете модель взаимодействия типа peer-to-peer ("Любой ... может начать ... по собственному желанию") достоинством?

Это ведь сильно усложняет программирование и отладку.