Есть два микроконтроллера связанных по одному из интерфейсов 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 МГц) на той же плате нужно?
Или это не понимание о чем идет речь?