Средства и методы разработки

Из протоколов в голове крутится только реализация peer-to-perr с исправлением коллизий. Т.е. два дивайса могут независимо инициировать сообщения друг другу и вести логические сессии запрос-ответ, команда-реакция. На host процессоре крутится задача обслуживания интерфейса с сопроцессором. Эта задача просматривает хидеры всех пакетов поступающих с сопроцессора и определяет в какую логическую сессию их отправить. Логическая сессия для задачи интерфейса представляется просто очередью с идентификатором, которая находится в предварительно созданном пуле очередей. Заинтересованные в услугах сопроцессора клиенты(задачи в RTOS) подписываются на сессии запрашивая у задачи интерфейса свободную очередь из пула очередей и присваивают ей идентификатор. Таким образом клиенты(задачи) на host процессоре передают сообщения сопроцессору напрямую использую публичную функцию передачи, а принимают из очереди которую они сами создали использую процедуру подписки в задаче интерфейса. Никакого хитрого протокола как бы не требуется, просто такая несложная организационная схема транспорта пакетов. Сложнее всего сделать подобный интерфейс с сопроцессором на базе I2C. Там возникают коллизии в режиме мультимастера. Коллизии приводят к тому, что протокол не может быть сильно reltime-овым Насколько это неприятно в реальных приложениях я пока не определился. Исследования продолжаются...