Решил написать RTОS для МК в академических целях.

Думаю тут многие это делали, для разминки мозгов вещь вполне подходящая. Разработку решил вести поэтапно - от самой простейшей кооперативной (простая замена super loop), до более-менее вменяемой. Тему создал чтобы поспрашивать о тех или иных архитектурных решениях. Основная проблема заключается в том, что мне в голову лезет куча идей как реализовать тот или иной функционал. А так как это все затеяно ради научного интереса, то определенных целей у меня нет, и становиться очень сложно выбрать между той или иной реализацией. Вот тут то и нужен коллективный разум. Может вы подскажите какую-нибудь идею, которая не пришла мне в голову, или скажите, что-де вот эта идея самая лучшая а остальные полная ерунда.

Начать я хочу с вопроса управления памятью. Для задач, семафоров и всякой другой ерунды нужны управляющие структуры и их нужно где-то и как-то создавать. После отметания явно бредовых идей, у меня остались следующие варианты:

<ol style="list-style-type: decimal"><li>Самый тупой способ - сделать все управляющие структуры публичными и дать пользователю возможность создавать их статически. Не нравится, потому что грубо нарушает инкапсуляцию. Как то это нехорошо.</li><li>Чуть получше - заставить пользователя реализовать специальную функцию, которую ОС будет вызывать, когда ей нужна память, эдакий mallocHook(). Откуда будет браться память - это уж проблемы пользователя. Решение мне в принципе нравится, довольно гибкое, но для простейшей ОС сложноватое. Неохота заставлять пользователя реализовывать свой менеджер памяти, каким бы он простым ни был. Вроде FriiRTOS поддерживает этот способ.</li><li>Классический вариант - ОС сама статически выделяет пул объектов, количество которых задается дефайном. Решение простое, инкапсуляция соблюдается, лишних телодвижений не требует, но какое-то топорное. Не нравятся мне эти дефайны и не нравится заранее загадывать сколько и чего мне нужно. Знаю, что uC/OS II так работала.</li><li>Последнее решение - похоже на первое, но оно не так явно нарушает инкапсуляцию. Суть в том, что для каждой управляющей структуры, пользователю предоставляется её близнец-пустышка с размером и выравниванием соответствующим оригиналу. То есть пользователь создает пустышку не зная о её устройстве, а внутри ОС она уже приводится к реальному типу. Мне нравится это решение, не идеальное но вполне простое и надежное. Так же имеется во FriiRTOS</li></ol>
Что бы вы, как пользователи, выбрали? Может есть другие варианты?

0

Mimzodo, не смешно.

В 2006 на uC-OC было три типа лицензии - на одиночный продукт - $3500, на продуктовую линейку - ~$20K, и на конретную архитектуру CPU - ~$30K. Эти цены - только на саму ОС, за сетевой и прочие стеки - там еще отдельными прайсами цена немалая назначалась, IP + ICMP + UDP +TCP + DHCPc + DNSc - в сумме хорошо ~$100K переваливало за "архитектурную" лицензию.

0

Сообщение от Mimzodo Сообщение от OVY-srok А вот с малыми циклами - проблема. Получается тупой нагрев кристалла бесполезным числодроблением.

Такого быть не должно. Задача должна проверить свой флаг (или что она там проверяет), и если ей нечего делать - вызвать delay() или yield(), чтобы отдать время другим. А если не отдаст, значит её насильно вытеснят, но только более приоритетные задачи. Вот более низкоприоритетные она действительно заставит голодать. Если не будет вызывать yield().

Всё верно, но сама суть операции упущена. Задача при проверке своего флага будет работать отпущенное ей время, равное 1мс. Перевод задачи в режим сна может произойти исключительно через диспетчер, который будет запущен либо сразу после этой задачи, либо в самом конце общей цепочки активных задач. А все активные задачи кушают ровно 1мс, и всё это множится на их количество.

Добавлю что все прерывания в обёртках, смысл их срабатывания появляется после обработки диспетчером задач. Что есно не добавляет быстродействия.

Вытеснение может произойти после запуска диспетчера задач, который есть суть отдельной задачи с временем работы в 1мс.

Моментальное и безусловное переключение контекста выполняется тупым переключателем, который просто сохраняет стек активной загружает стек следующей задачи. Тупой переключатель работает совместно с функцией задержки, которой собственно и нужны те самые интервалы в 1мс. И кстати - там реально накапливается ошибка.

То-есть, если не обращать внимание на скорость реакции - вытесняющая ос вполне быстрая, но назвать её осью реального времени уже нельзя.

Сообщение от omooro Недавно начал использовать FriiRTOS, ничего из сказанного вами там не обнаружил.

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

0

Сообщение от u37 Mimzodo, не смешно.

Цена это да, хотя если совесть не будет мучать можно украсть, исходники раздаются под честное слово. А если будет мучать... Не знаю, может у меня что-нибудь выйдет, я как раз для Sortix-M делаю. ;)

0

OVY-srok, вот я читаю и чет не понимаю. программирование под ос - это немного не так, как без ос. там не должны опрашиваться флаги в цикле, задача не должна запускаться, если ей нечего делать. для этого придуманы всякие там семафоры и прочее. все эти циклы с делеями - жрут ресурсы за зря и "делают ос не реального времени". просто не надо говнокодить и не будет проблем.
в той же фриртос, емнип (а я ее последний раз активно юзал аж 8 лет назад), не было проблем с реакцией на события и числодроблением. скажем есть прерывание по внешнему событию, отдельному таймеру или хз чему, оно работает как обычное прерывание мк, никак не связанное с ос. и если нужно по нему очень срочно запустить какую-то задачу - просто прям из программы прерывания отпускается семафор. всё. при выходе из прерывания произойдет передиспетчеризация и запустится тот "срочный" поток, который висел ждал семафора (при условии более высокого приоритета, конечно). все это за известное время, никак не привязанное к 1мс.

0

Сообщение от KPK P.P.S. Evsi, не уподобляйтесь Dosikus_2, расширяйте кругозор.

Первый форт, с которым мне довелось поиграться, был графический форт на писюках. Название сходу не вспомню, поскольку это было году в 1988-м.
Так что вы там говорили насчет кругозора?

0

Сообщение от dosykus_2 А по теме и С с крестами и форты в эмбедде путь в никуда...

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

0

Сообщение от OVY-srok https://www.segger.com - даёт каждой задаче разное время - аналог приоритета.

Время ну ни разу не может быть "аналогом приоритета", поскольку время и приоритет ортогональны.

Время может быть от 1мкс до 1мс, когда время выйдет -задача переключится автоматически. Если в самой задаче стоит команда "шев, усё готово" - то ос сама переключает контекст, и не через диспетчер задач - а моментально.

Господи, они тоже додумались до yield()? Аффигеть достижение...

0

Сообщение от Mimzodo Да, был такой вариант, но я его отмел в пользу варианта номер 2, где я дергаю пользовательскую функцию, а он уж там может сам реализовать такой буфер и выдавать мне из него память сколько я запрошу. Мне кажется это не намного сложнее будет, но значительно гибче, потому что дает пользователю выбор, как именно реализовать выделение памяти.

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

0

Сообщение от OVY-srok Всё верно, но сама суть операции упущена.

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

0

Сообщение от OVY-srok То-есть, если не обращать внимание на скорость реакции - вытесняющая ос вполне быстрая, но назвать её осью реального времени уже нельзя.

А я бы ещё и осями эти экзокернелы не назвал )

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

Может уже сразу в вальхаллу? )

0

Сообщение от vt340 А я бы ещё и осями эти экзокернелы не назвал )

Предлагаете устроить тут филиал ru.os.cmp ? :)

0

Сообщение от Ymk OVY-srok, вот я читаю и чет не понимаю. программирование под ос - это немного не так ~~ ~~ все это за известное время, никак не привязанное к 1мс.

Вам наверное нужно ознакомится с современными FriiRTOS и ChibiOS. Костыль на костыле.
Насчёт правильного программирования - да без проблем.

Например разовая передача данных по физике:
Запускается задача, ей в параметрах передаётся адрес буфера, задача опрашивает занятость периферии, если не свободно - впадает в ожидание, либо сразу настраивает периферию (когда в первый раз). Потом резервирует канал дма и настраивает под конкретную передачу, пинает его, и уходит в ожидание пинка от дма. По окончанию рапортует в структуру связи, и если там не установлен флаг конвейера - то освобождает канал дма и полностью самоубивается из системы.
Подобная связь по физике не требуется каждую секунду. Возможно что за всё время от включения мк до выключения - такая задача не потребуется вовсе.
Сложно? Однако в FriiRTOS и ChibiOS будет затык уже на стадии резервации канала дма, там подобной функции просто нет. Держать подобную задачу в неактивном запущенном состоянии - просто не выгодно, так-же как и выделять под эту задачу память стека и данных.

И главное, подобных задач может быть сотни, не все работают с физикой, не всем требуется дма - но каждая так или иначе имеет зависимости от основного алгоритма. Это означает что выкинуть их нельзя - потеряется функционал девайса.

Задачи которые должны что-то успеть посчитать к определённому моменту времени. Можно конечно всё свалить в один громадный конвейер, но это уже получится собственная ос внутри оси. Можно сделать попытку поднять приоритет в FriiRTOS и ChibiOS, но тогда основной алгоритм вообще никогда не будет запущен. Можно сделать всё в прерывании, и потерять математику.
Вариантов очень много, самый щадящий - использование разного рабочего времени цикла активности задачи.

Повторюсь, когда задач две-три - FriiRTOS и ChibiOS более чем подходит. Но когда количество задач переваливает за сотню - ос уровня segger единственный вариант.
Сотня разных задач легко набирается в проекте музыкального центра. Просто потому что алгоритмы там разные, и все хотят памяти, и одновременно не могут быть запущены.

Сообщение от Mimzodo Мне хочется над этим поработать из чистого интереса, чтобы новый опыт получить, не более.

Для начала попробуй найти строчки кода переключающие контекст. То-есть с самого простого.
У меня это на асме в открытом виде.
В segger в закрытом виде в готовом бинарнике - который необходимо подключать к своему проекту.
В ChibiOS это в открытом виде, но найти у вас не получится, даже в режиме отладки этот код на дифлайнах на отображается в отладчике. Так-что если не знать где копать - можно и не найти.
В FriiRTOS тоже вроде как открыто, и даже можно конкретно указать на нужные файлы. Но вот какой из кусков кода под дебрями дифлайнов будет исполняться, а какой будет пропущен - узнать можно только под отладкой.

Ну и в качестве учебника по созданию собственной ос на асме - http://badymbid.ru/assembler-p... konteksta/
Ос на чистом С, учебный вариант http://chipenable.ru/index.php/programm ... schik.html
Ещё немного по ос, общего плана http://www.pvsm.ru/c-3/52568

0

Сообщение от OVY-srok У меня это на асме в открытом виде. В segger в закрытом виде в готовом бинарнике - который необходимо подключать к своему проекту. В ChibiOS это в открытом виде, но найти у вас не получится, даже в режиме отладки этот код на дифлайнах на отображается в отладчике. Так-что если не знать где копать - можно и не найти. В FriiRTOS тоже вроде как открыто, и даже можно конкретно указать на нужные файлы. Но вот какой из кусков кода под дебрями дифлайнов будет исполняться, а какой будет пропущен - узнать можно только под отладкой.

Какой кошмар, сверхсекретные 10 строк на ассемблере.
Вот, нашел с трудом (за минуту) https://github.com/scmrtos/scmrtos/btob ... _asm.s#L79

0

Сообщение от tuko Вот, нашел с трудом (за минуту) /scmrtos/

Стоило-ли так надрываться, яж написал что у меня это в открытом виде, да ещё и ссылку дал на материал для опытов.

0

Сообщение от OVY-srok Сложно? Однако в FriiRTOS и ChibiOS будет затык уже на стадии резервации канала дма, там подобной функции просто нет. Держать подобную задачу в неактивном запущенном состоянии - просто не выгодно, так-же как и выделять под эту задачу память стека и данных.

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

Сообщение от OVY-srok Сотня разных задач легко набирается в проекте музыкального центра. Просто потому что алгоритмы там разные, и все хотят памяти, и одновременно не могут быть запущены.

а можно пример вот этих вот хотя бы 15 задач в муз центре?
и если они не могут быть запущены одновременно - почему всё это отдельные задачи?

0

Сообщение от OVY-srok Но вот какой из кусков кода под дебрями дифлайнов будет исполняться, а какой будет пропущен - узнать можно только под отладкой.

Вообще-то для этого есть препроцессор.

0

Сообщение от OVY-srok Сообщение от Ymk OVY-srok, вот я читаю и чет не понимаю. программирование под ос - это немного не так ~~ ~~ все это за известное время, никак не привязанное к 1мс.

Вам наверное нужно ознакомится с современными FriiRTOS и ChibiOS. Костыль на костыле.

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

И да, они таки додумались до сопрограмм. Правда в их реализации это копрограммы.

0

Сообщение от Mikomk И да, они таки додумались до сопрограмм. Правда в их реализации это копрограммы.

coroutine это и есть "сопрограмма" в переводе на российский. Если кто-то перевел это как "копрограммы", то это его проблема.

0

Сообщение от ivsy Сообщение от Mikomk И да, они таки додумались до сопрограмм. Правда в их реализации это копрограммы.

coroutine это и есть "сопрограмма" в переводе на российский. Если кто-то перевел это как "копрограммы", то это его проблема.

Если их так реализовали, то это чья проблема?

0

Сообщение от Ymk а можно пример вот этих вот хотя бы 15 задач в муз центре? и если они не могут быть запущены одновременно - почему всё это отдельные задачи?

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

Сообщение от OVY-srok создание-удаление задач на мк - это нонсенс.

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

Написание и использование собственного менеджера дма под ос типа FriiRTOS и ChibiOS - невозможно по простой причине, сами ос юзают дма своими встроенными драйверами периферии, бесконтрольно.

0