Можете разжевать? Нужно продумать интерфейс к системным вызовам (read, write, open, ioctl...) и реализовать весь функционал через него. Для чего-то вроде block device или character device всё достаточно очевидно. Для чего-то вроде звука или видео может быть не удобно лишний раз копировать и разумней будет сделать асинхронный ввод-вывод сразу в пользовательскую память. Там весь интерфейс окажется внутри ioctl(), нужно будет предусмотреть свой набор функций через ioctl() вызываемых.
retargeting применительно к gcc-arm-none-eabi, ARMCC, IAR, CCS (те среды, которые я знаю) это не сущность RTOS, а свойство кастомизации CRT под конкретные нужды. Правильно ли я понимаю, что RTOS должна подменять всю CRT, входящую в состав компилятора (раз в NuttX упоминается libc, то наверное она собирается из исходников NuttX)? Иначе замучаешься связывать open/write из CRT компилятора со средствами защиты RTOS и гарантировать работу в многопоточном режиме.
Например, драйвер для АЦП. Свои (вместо системных) open/write при использовании CRT из компилятора способны понять по имени файла, что идёт обращение к АЦП. Дальше что? Вызывать требуемые функции драйвера АЦП из open/write/read/ioctl? Думать о многопоточности (защищаться мьютексами) в драйвере? Каким-то образом переключаться в защищённый режим при вызове функций CRT?
Где можно почитать об "асинхронном вводе-выводе сразу в пользовательскую память"? Тот же АЦП предоставляет данные, допустим, с периодом 1 мс, по множеству каналов (у меня 20 каналов). Сейчас у меня сделано так, что драйвер АЦП в IRQ вызывает требуемую функцию преобразования в физическую величину и обновляет переменную, адрес которой был указан при открытии конкретного канала АЦП (то есть канал АЦП прямо связывается с адресом переменной, хранящей результат преобразования), поэтому прикладному ПО не надо вызывать read/write -- драйвер сам обновит указанную переменную. Ну дополнительно обновляется "время преобразования", "код АЦП" для всяких там калибровок и проверки работоспособности АЦП.
Может, мои вопросы и кажутся "чайниковскими", но я иду снизу вверх (из мира МК в мир ПК) и имею некоторые сложности с пониманием механизмов работы RTOS.
VVB (16.11.2014 11:08, просмотров: 539) ответил fk0123 на п.1 это скорей "мелкие технические подробности" вызванные использованием функций libc в ядре, как я понимаю. п.2 -- две кучи это от бедности (отсутствия MMU). В нормальных ОС куча у каждой задачи своя. А память выделяется линейно через sbrk(). Но
)