Микрооперационная система реального времени

=DeaD=

2Виталий: Это конечно хорошо искать вопрос на свой ответ

думаю обсуждение было бы более предметным, если бы оппоненты обсуждали не гипотетические задачи, а примеры конкретных задач из жизни

Duhas

Виталий писал(а):

ОС.
1. У вас есть многоканальная система управления, а контроллер всего один.
2. Во время работы ваша система должна запускать и останавливать некоторые задачи (процессы).
3. Опрос каналов должен производится с определенным темпом.

Как тут использовать прерывания? Посчитать все по тактам? А как тогда быть с новыми процессами в контроллере? А для того чтобы добавить процесс нужно перекраивать систему прерываний? Как долго проживут вложенные друг в друга прерывания?

у меня 2 двигателя, на каждый 3 контура управления в каждом ПИД...+ опрос концевиков + прием команд по уарту, ретрансляция на и2ц(возможно) + вазможно будут расчеты... катит под ваше описание? планируется писать все ручками на асме...

что значит добавился процесс? в законченном устройстве не может быть добавления процессов...

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

RoboTok

DeaD Может он новую клавиатуру разрабатывает ?

Сергей

Duhas, а почему ты всегда ставишь многоточие?

Добавлено спустя 1 минуту 27 секунд:
Кстати, ИМХО в законченном устройстве может быть функция добавления задач, смотря что ты понимаешь под законченным устройством

Добавлено спустя 49 секунд:
Вероятно мы просто говорим о разных вещах, ты походу говоришь об "автономных модулях"

Duhas

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

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

blindman

А что такое законченное устройство? Вопрос философский

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

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

никак не могу приучить себя писать предложения покороче

Сергей

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

Виталий

Просто как оказывается адаптировать ядро линя к арму проще чем переписать весь нужный для роутера софт на "чистом СИ".

blindman

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

Виталий

Да, потому что отладка занимает 80% времени разработки, и его нужно сокращать. Верификация - один из способов.

boez

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

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

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

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

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

blindman

boez писал(а):

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

Вот про это я и говорил.

=DeaD=

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

Duhas

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

boez сам сказал, что можно было все сделать на флагах и т.д. и, кстати, в данном случае добавить низкоприоритетную задачу не проблема...

=DeaD=

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

roboforum.ru

Микрооперационная система реального времени

Кто сейчас на конференции