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

[AlexandrY]

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

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

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

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

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

[DASM]

суть сего топика в виде статьи для журнала будет нарушением авт. прав ? А SYS/BIOS Inter-Processor Communication из Техасовских OMAP это никак не в ту степь ? http://www.ti.com/general/docs/lit/getlite...eNumber=sprugo6 Я пока бегло ознакомился, но вроде в Техасе не идиоты работают, да и общение ARM и DSP на одном кристалле вряд ли медленное.

[AlexandrY]

суть сего топика в виде статьи для журнала будет нарушением авт. прав ? А SYS/BIOS Inter-Processor Communication из Техасовских OMAP это никак не в ту степь ? http://www.ti.com/general/docs/lit/getlite...eNumber=sprugo6 Я пока бегло ознакомился, но вроде в Техасе не идиоты работают, да и общение ARM и DSP на одном кристалле вряд ли медленное.

Статей на эту тему как снежный ком. Вот например аналитика
Про детали реализации только мало пишут.
Использование разделяемой памяти как у TI это конечно удобно ,но это только в пределах одного чипа.
Потом я не согласен с их утверждением о необходимости инвариантности API по отношению к однопроцессорной и многопроцессорной среде.
Это выдает явное пренебрежение риалтаймом. Нельзя мимикрировать под локальные задачи если время доступа становится неопределенным.
Кстати ни в одной статье не нашел еще ни одного намека на какие-то измерения времени передачи сообщений или механизмы его контроля в IPC.

Я свою задачу пока решил хоть и кривовато. Загрузка процессора транспортным протоколом меньше 1% при 1 Мбит/c
Сделал два типа взаимодействия: мастер-слэйв и подписка на трансляцию со слэйва.
Отказался от адресных сообщений между удаленными задачами как в MQX, а сделал просто вызов общих функций на слэйве. Это сделало хидер очень коротким - байт на идентификатор функции и байт на длину тела.
Переложил на приложение задачу разруливания возможных гонок при обращении к общим функциям.
Правда это делает такое решение малопортабельным.