LINUX.ORG.RU

Мультиплексирование ввода/вывода на голом железе

 ,


0

3

В некотором проектике есть встроенный шелл. Команды принимает из аппаратного USART порта, либо через другие интерфейсы. Вывод отдает туда же. Сейчас все реализовано вручную, на прерываниях и DMA. Никакой ОС с готовым механизмом синхронизации или блокирования задач нет. Так вот, вопрос, можно ли будет упростить код используя некую ОС, например freeRTOS. Мне кажется, что я получу больше проблем, чем их решу. Блокирование же надо самому будет делать.

Код

Немного подробнее о задаче. Все потоки байтовые, передается текст. У шелла есть два потока, на ввод и на вывод. Есть USART который тоже может на ввод и вывод. Сейчас они соединены перекрестно, выход одного на вход другого. Может появится другой порт, несколько сложнее чем USART, данные будут обернуты в пакеты. У него тоже будет ввод и вывод. И тогда понадобится соединить не два конца а три. То есть читать из одного места а записывать в два и наоборот. Это можно сделать и тем способом, что есть сейчас, но хочется сделать код простым и понятным, не обязательно за счет использования rtos.

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

Спасибо.

★★

В некотором проектике есть встроенный шелл. Команды принимает из аппаратного USART порта, либо через другие интерфейсы. Вывод отдает туда же. Сейчас все реализовано вручную, на прерываниях и DMA.

Нормальное решение.

Вопрос использования той или иной ОС нужно решать, исходя из требуемого функционала, ограничений по времени разработки, ограничений по изменениям в аппаратную часть:

1. Если ресурсов процессора достаточно для выполнения всех наличных задач - оставь как есть, не трать время, во всяком случае пока ты можешь разрулить все проблемы с schedulabilitу (не знаю как перевести) за счет приоритетов прерываний.

2. Если ресурсы процессора могут ВНЕЗАПНО закончиться, тогда есть варианты:

a) Поставить процессор «потолще» и перенести софт туда (софт изначально должен писаться с учетом обновлений железа).

Недостатки: может потребоваться более дорогой процессор, это критично на массовых изделиях.

б) Использовать ОС, данный вариант позволяет «разгрузить» процессор, писать в любом стиле (императив\автоматы), использовать любые доступные библиотеки, применять более низкоквалифицированных программистов.

Недостатки:

i над обезьянкамипрограммистами нужен присмотр от человека, который шарит в программировании под ОС ибо... ii они могут: переусложнить софт; попутать что-нибудь с приоритетами и синхронизацией задач; замутить повреждение данных на стеке и т.д.. Ошибки могут быть ОЧЕНЬ трудоемкими в обнаружении. Соответственно...

iii нужен толковый архитектор/наставник.

iiii нужна оперативная память на стеки задач, это может быть узким местом в случае микроконтроллера.

shkolnick-kun ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.