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

[AlexandrY]

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

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

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

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

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

[PheeL]

Хочу посоветовать обратить внимание на систему сообщений в QNX. Я сейчас не готов предметно обсуждать возможность использования формата применяемых там сообщений для IPC как универсального протокола обмена через различные аппаратные интерфейсы, но возможно стоит взглянуть на заложенные там идеи (тем более, что документация отличная). Во всяком случае я сам планирую более детально это изучить когда буду чуть более разгружен на работе.

[rsv]

Хочу посоветовать обратить внимание на систему сообщений в QNX. Я сейчас не готов предметно обсуждать возможность использования формата применяемых там сообщений для IPC как универсального протокола обмена через различные аппаратные интерфейсы, но возможно стоит взглянуть на заложенные там идеи (тем более, что документация отличная). Во всяком случае я сам планирую более детально это изучить когда буду чуть более разгружен на работе.

А там есть универсальный верхний уровень ( qnet называется ) , который пока реализован поверх единственного интерфейса - erhernet. Про все остальные интерфейсы в документации дословно написано, что вы легко можете адаптировать этот самый qnet для работы с другими интерфейсами типа pcie или serial rapid io. На самом деле это весьма нелегко. Но в вашем случае ehernet 100 мбит вполне может быть достаточно, опять же никто не мешает гигабит привернуть. Некоторое ухудшение реалтаймности при работе через сеть в документации прописано, но конкретных величин не приведено. Проблема возникает из-за того что много абонентов стучатся в ethernet свич, ну а он, соответственно, притормаживает. Притормозить, судя по сведениям инета, может на пару милисекунд.
Для решения проблемы свича и повышения реалтаймности люди придумали целое семейство протоколов industrial ethernet, fire ware, serial rapid io и еще что то, уже забыл
Кстати, на некоторые армовские камни существуют bsp на qnx http://community.qnx.com/sf/wiki/do/viewPa...i/BSPAndDrivers
Только советую выбирать камень с bsp посвежее, тк допиливать по месту что-то старое довольно сложно

[AlexandrY]

А там есть универсальный верхний уровень ( qnet называется ) , который пока реализован поверх единственного интерфейса - erhernet. Про все остальные интерфейсы ...

Почему нужно засорять тему, когда ясно обозначен класс архитектур для которых ищется решение?
Предлагаю оставить в покое QNX и Ethernet.

Нашел интересную реализация IPC в RTOS MQX.
Там в объект RTOS под названием "Сообщения" встроена возможность пересылать сообщения не только между задачами но им между процессорами.
Причем драйвер для передачи сообщений может быть сделан на любом коммуникационном интерфейсе. В примерах они делают драйвер на UART-е.
Объект Сообщения представляет собой очередь из специальных структур предварительно выделяемых из памяти самим приложением.
Освобождается память структур уже в приемной стороне если это локальная задача или в драйвере если это удаленная задача.
Поскольку процессоров в системе предусматривается до 256, то реализован механизм маршрутизации между микропроцессорами.
С виду неплохая реализация, но пакеты несут внутреннюю информацию RTOS в частности идентификаторы объектов источников и приемников RTOS.
Т.е. протокол привязан к реализации RTOS MQX и эта RTOS должна быть на всех микропроцессорах в системе, а это уже не так интересно.