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

[AlexandrY]

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

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

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

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

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

[juvf]

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

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

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

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

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

Так что минимум CRC8

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

[AlexandrY]

Например 1)modbus на уарте...

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

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

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

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

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

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

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

[denyslb]

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

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

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