VVB (02.01.2015 12:09, просмотров: 2091)
Подскажите по CAN Интересуюсь идеологией работы с интерфейсами, например, CAN
Как я разумею, имеется три идеологии работы:
1. синхронная работа. Ну как синхронные операции в boost.asio. Пока операция не завершится, системный вызов чтения или записи не возвратит управления. Буферизация не используется.
2. буферизированный режим работы (с использованием очередей, циклических буферов и т.п.). Типичный пример -- stdio (printf, std::cout) в случае, если буферизация не отключена, а также fwrite.
3. асинхронный режим работы, как асинхронные операции в boost.asio. Системным функциям передаётся callback, который вызывается (из прерывания или из сервисной функции, которую должен периодически вызывать пользователь) после завершения операции или возникновения ошибки.
Применительно к области встраиваемых систем управления, предпочтительным является наиболее сложный, третий, вариант (IMHO).
Гляжу я на исходники разных операционок и что-то не врубаюсь (насчёт драйвера CAN).
1. RTEMS. Поддержка CAN в состоянии зачатия, есть всего один драйвер.
2. NuttX. Работает в синхронном режиме.
3. Keil RTX (RL-CAN). Работает в асинхронном режиме.
Как я понимаю, в рамках стандарта POSIX асинхронные операции недопустимы с идеологической точки зрения (кроме сети)?
Кто-нибудь писал драйвер CAN для операционных систем (не ядер) с асинхронным режимом работы?
Что делать, если хочется использовать готовую операционку (из-за наличия IPv4, USB host mass storage, FatFS, SDIO + SDcard, I2C, fread/fwrite), но я понимаю, что с CAN будет невозможно работать? Сейчас я использую библиотеки RL-ARM, от которых хочу отказываться, и ищу альтернативы (затрудняюсь с выбором). Писать аналог RL-ARM для простых ядер операционок не хочется.