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

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

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

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

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

Для нарезки на пакеты и контроля целостности, я бы использовал упрощенный GFP-F (G.7041), без скремблирования тела пакета.

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

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

GFP работает только на тех каналах, в которых уже есть байтовая
синхронизация (в отличии от HDLC), и все расчеты CRC можно делать побайтно.
Да и нужен подсчет CRC только для 2-х байтового заголовка, чтобы надежно
определять начало кадра.
Главное преимущество GFP-F, по сравнению с другими вариантами нарезки
потока байтов на кадры (SLIP или Async HDLC), состоит в том, что при передаче
данные клиента не изменяются. Т. е. пакет верхнего уровня передается как есть,
с добавлением перед ним небольшого заголовка. И на приеме можно перекидывать
принятые данные из буфера DMA в буфер клиента непрерывными кусками.

интересная задача -- на мой взгляд, она сводится к тому чтобы поток сообщений упаковать в канал и соответственно распаковать -- то есть к сериализации и десериализации.

Есть ооочень много сериализаторов (самые знаменитые JSON и прочие соны) -- но к сожалению я не смог освоить ни один из них применительно к контроллером.

Одна из старых разработок ASN -- я даже патч к нему сделал чтобы компилировалось под Windows -- но автор его забросил и перешёл к коммерческому варианту -- а свободный написан уж не так хорошо.

ASN может упаковывать в поток XML струтур, упаковывать на байтовом уровне и даже на битовом.

Может не в тему, но возникла что-то подобное на Техасовском DSP, задействовал SD card интерфейс, все довольны в итоге. - есть аппаратная поддержка, есть исходники драйверов, есть DMA, есть скорость, есть CRC и командный уровень (который можно и упростить как угодно почти)

Очень кстати... Спасибо!

Но у нас сопряжение с ПЛИС идет, надо глядеть доку на конкретную реализацию SD, например Техасу надо подтверждать хотя CMD24 чтобы он начал передачу. На ПЛИС это все без проблем, а вот реализацию SD slave не очень представляю аппаратными средствами процессора.

Боюсь вы сериализации пытаетесь найти неправильное применение.
Есть аппаратная сериализация и есть программная сериализация. Это абсолютно разные вещи.
С аппаратной сериализацией в микроконтроллерах нет никаких проблем. Я начал с того, что у меня есть широкий выбор сериализирующих интерфейсов.
Программная сериализация же в связке двух микроконтроллеров не имеет никакого смысла. Ибо это по сути конверсия данных в формат не зависящий от среды передачи и от аппаратных различий вычислительных платформ и с общей спецификацией.
Но в среде микроконтроллеров, где скажем я применяю только 32-х разрядные ARM-ы, little-endian и единый компилятор совсем не нужна аппаратная независимость и human-readable формат как у JSON, XML и проч.
Т.е. нет никаких оснований для сериализации. Можно брать и тот же тип float как есть из памяти без всяких конверсий посылать в коммуникационный канал и он будет безусловно понят на той стороне. И никаких перекодировок вроде ASN не нужно.
Роль общих спецификаций выполняют разделяемые .h файлы в проектах для обоих микроконтроллеров.
Все предельно просто. Не просто только уложиться в жесткий риалтайм.

Я применяю парсеры JSON, и скажу, что парсинг даже 45 КБайт файла может занять 9000% процессорного времени на 266 МГц ARM9. Т.е. в 100 раз превысить длительность системного цикла.
О риалтайме даже речи быть не может.
ASN тоже применяю в SNMP протоколе. Это крайне избыточное кодирование оправданное только по сравнению с plain текстом. Он занял бы не менее 40% лишних процентов полосы пропускания.
У меня же цель сделать протокол который бы занял при скорости 1 Мбит не более 1% процессорного времени на упомянутой архитектуре и с оверхедом на хидеры не более 10%

Сдается мне, что автор не вопрос задавал, поскольку явно сам все знает. О цели поста остается только догадываться

У меня похожая ситуация: Cortex-M4 - CPLD, так что еще раз спасибо за идею!

А никто не обещал легких вопросов.

Для большей ясности вот в этой статье неплохо обрисована проблематика:
Programming heterogeneous multiprocessors
Если не обращать внимания на особенности вызванные виртуализацией памяти и кэшированием, то будет практически мой случай.
Но у автора все облегчалось тем, что DSP у него по сути только две задачи и решает - декодирование видео и аудио.
А поскольку обмен идет по параллельной шине с дикой скоростью, то у него там вовсе нет проблем риалтайма и полосы пропускания.
Единственная сложность остается с инверсией приоритетов, которую он предлагает решить примитивно расставив статически приоритеты на стороне сервера.
Я бы подумал о передаче приоритетов в хидерах сообщений.

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

А контролем целостности пренебрегать нельзя, имхо. У вас аппаратные ошибки могут возникать уже при эксплуатации из-за деградации оборудования или помех, например. Так что минимум CRC8 (при небольших пакетах; вообще, тут стоит граничить оверхед для типичного и/или максимального размера пакета).

"Как упаковывать данные, какие хидеры им давать" и т.п. никто вам не скажет, пока не увидит software requirements

Например 1)modbus на уарте: ставим период таймера 3,5 символа. По прерывания урта дергаем дма и запуск таймера (аппаратно). В обработчике прерывания таймера выставляем флаг приема пакета. ну и гдето обрабатываем пакет (подсчет црц, парсинг, подготовка ответа).

2)CAN - 8 байт вам доставятся на аппаратном уровне гарантированно на скорости 1 Мбит/c, с аппаратной защитой црц, с повторами при колизиях.

на 16-ти и 32-х битных процессорах лучше црц-16. защита лучше, а вычислений ровно столько же. (правда код у црц8 меньше памяти займёт)

modbus-то причем к межпроцессорному обмену? А тем более CAN?





Риалтаймом здесь я считал бы независимость и прогнозируемость обмена между задачами на разных микроконтроллерах.

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

Почему контроль целостности на DDR (130 МГц) можно не выполнять, а на UART-е (1 МГц) на той же плате нужно?
Или это не понимание о чем идет речь?

Хочу посоветовать обратить внимание на систему сообщений в 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).

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

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


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

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

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