roboforum.ru

2Виталий: Это конечно хорошо искать вопрос на свой ответ думаю обсуждение было бы более предметным, если бы оппоненты обсуждали не гипотетические задачи, а примеры конкретных задач из жизни

да, я выше писал что, имхо, конструкция должна состоять из законченных модулей с четко определенным функционалом...
если функционал модуля должен быть гибким по природе, тут свои заморочки могут быть.. и то вряд ли это будет ОСь..
многоточие - не полная законченность мысли + процесс размышления..

просто привычка..

В роутерах Линь стоит на какомнить ARM9, хотя по сути то круг задач ограничен.

Конечно, имеет смысл ставить готовое отлаженное ПО

Ща расскажу про конкретную задачу.

Есть контроллер электропривода, мощным инвертором управляет. У него есть несколько (2 или 3) каналов связи для подключения пультов управления или связи с АСУ, по всем этим каналам логически он слейв (то есть ему шлют запросы и он на них отвечает). У него есть память параметров (EEPROM) с достаточно медленной (единицы мс) записью. Ну и задача - обеспечить поддержку этих каналов связи, плюс расчет и выдачу всех управляющих сигналов (собственно ШИМ на инвертор, сигналы на дискретные и аналоговые выходы). По каждому каналу связи может прийти запрос на запись параметра или на чтение. Параметрами - 16-битными числами - считаются как уставки, типа максимальной и минимальной рабочей частоты, или параметров S-образной кривой разгона-торможения, так и текущие значения типа текущей частоты или выходного тока. Но при запросе чтения параметра мы его берем прямо из ОЗУ, а вот при записи надо подождать, пока он запишется в еепром, а только потом ответить на запрос. И при этом хотелось, чтобы другие запросы на чтение (по другим каналам) обрабатывались пока оно пишет. А, еще журнал оно должно было вести - это датафлеш на SPI, из этого журнала тоже надо было уметь отдавать записи по запросам.

Вот для такой задачи мы использовали самодельный шедулер, который в принципе можно назвать простейшей ОС. Ядро шедулера быо частично на ассемблере (ARM LPC21xx), частично на С. Навеяно это все было известной uCOS, но за счет ассемблера и оптимизации время полного переключения с одной задачи на другую было менее 1 мкс на 60 МГц. Из сервисов были мьютексы, с помощью которых защищалось общение с епромом, флешкой, еще вроде какими-то аппаратными ресурсами, а также сообщения, передаваемые от процесса или обработчика прерывания другому (ожидающему) процессу. А, еще кажется атомарные операции со счетчиками и флагами были. Ессно адресное пространство общее, поскольку арм7 без мму. Приоритеты фиксированные.

То есть один процесс занимался расчетом управления, по одному процессу на каждый канал связи, один процесс на журналирование, кажись еще что-то было - щас не помню, это года 2 или 3 назад было. Я даже не буду спорить, что все это можно забабахать на флагах, автоматах состояний и т.п. без шедулера. Но насколько с шедулером проще! А - понадобилось нам потом дорисовать одну расчетную задачу туда же, некритичную по времени, но которая тупо долго (десятки секунд) считает некие настроечные параметры, там куча вложенных циклов и все такое. Нет проблем! Низкоприоритетный процесс создали, и не надо думать, как это все считать так, чтобы не мешало управлению.

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

Конкретный пример сразу всё расставил по своим местам, все сразу осознали, что оно бывает нужно и поняли даже куда, например

2Duhas: А почему в серии это неправильно? Если это позволяет писать более надежные и верифицируемые программы - почему нет?