Хочу посоветовать обратить внимание на систему сообщений в 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 посвежее, тк допиливать по месту что-то старое довольно сложно

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

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

суть сего топика в виде статьи для журнала будет нарушением авт. прав ? А 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, а сделал просто вызов общих функций на слэйве. Это сделало хидер очень коротким - байт на идентификатор функции и байт на длину тела.
Переложил на приложение задачу разруливания возможных гонок при обращении к общим функциям.
Правда это делает такое решение малопортабельным.

не очень быстро ?




а не все ли равно как ? если физически железо работает и интерфейс не генерит ошибки и этого уровня устойчивости достаточно по тз все остальное на 90 % перестраховка

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

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

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

Аналогично. Плюс RTS/CTS - позволяет минимизировать протокольные навороты.

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

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

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

У меня обмен между микроконтроллерами простенький, и протокол простенький. Но то, что любой из них может инициировать передачу, для меня важно. Не нужно ждать своего часа, чтобы сообщить желаемое.
Помехоустойчивость не важна, потому что платы расположены рядом. Общий путь сигналов - сантиметров 15. Если бы помехи сбивали стандартные логические сигналы, то там вообще ничего бы не работало.

У вас используется пересылка без подтверждения?
Иначе как вы отличаете подтверждение от асинхронного начала новой передачи?
Это же дополнительные трудности при анализе пакетов и куча потенциальных ошибок.

В таком стиле идет обмен с GSM модулями по AT командам (с асинхронными сообщениями), и все признают что это весьма трудный для работы способ.

В одну сторону - с подтверждением. В другую - только упомянутое подтверждение и еще одна команда. У меня совсем немного команд, так что и говорить не о чем. Все они отличаются друг от друга и от следующих за ними данных. То есть, если говорить о протоколе, то он упрощен до предела. Хотя поначалу тоже собирался посылать подлиннее, с контрольной суммой, или ASCII символами...

Intel SDCC, chipkill - для серверной DDR памяти вполне применяется (по сути данные в память загоняются с ECC битами, соответственно защищаются и при передаче, и защита от bit flipping).

Сообщение отредактировал denyslb - Jun 29 2013, 01:35