Решил написать 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

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

0

Сейчас ось пишут все кому не лень, даже у меня есть. http://forum.ixbt.com/topys.cgi?id=48:11735
На плюсах тоже есть готовая ось, ничего изобретать не требуется.
Посмотри как сделана https://www.segger.com , если-б код был полностью открытым - то эта ось могла-б стать стандартом в стане мк. Потому как имеет максимальное быстродействие на большом количестве одновременно активных!!! задач. Всякие FriiRTOS и чибиось - теряют в производительности после добавления второй активной задачи - ровно половину мощи мк, а если задач 100 - то система превращается в черепаху.

Кстати, на своей оси запускал 300 копий червяка, в результате частота кадров упала с 60 до 30, ну это так, к слову.

0

Сообщение от u37 IMHO, пользователи бы выбрали не С++. Меня уже колбасит от необходимости содержать и адаптировать софт только из-за одной rtos. Разрабы считают, что им удобнее было пару инструкций написать на С++, а проблемы пользователя - это не их проблема.

А где я писал про С++? :}

0

Сообщение от OVY-srok Всякие FriiRTOS и чибиось - теряют в производительности после добавления второй активной задачи - ровно половину мощи мк, а если задач 100 - то система превращается в черепаху.

Интересно почему? По идее не должна так сильно страдать производительность. Честно говоря мне не верится, что есть волшебная пилюля, которую использовали в этой embOS и она стала сто задач крутить без накладных расходов. Такого не бывает, значит у нее есть какие-то ограничения в чем-то другом. Контекст переключать надо? Надо. Чем больше задач тем больше переключений контекста и соответственно накладных расходов. Можно придумать какой-нибудь алгоритм планировщика, чтобы он пореже переключал задачи, но вот сразу и возникают ограничения. Он будет или очень долго работать, или будет не сразу переключаться. Бесплатно ничего не дается. Кому-то это может быть критично, кому-то нет.

Посмотри как сделана https://www.segger.com

Попытался скачать, но чтобы это сделать надо 9 кругов ада пройти, так что бросил это дело.

0

Mimzodo, "Что бы вы, как пользователи, выбрали?"

0

Так я же сразу написал, что я не пользователь. Мне сейчас не нужна RTOS, соответственно каких-то требований я к ней предъявлять не могу. Мне хочется над этим поработать из чистого интереса, чтобы новый опыт получить, не более. Но вообще мне нравится последний вариант, потому что он относительно простой и надежный. Где действительно нужно постоянное создание/удаление задач я представить себе не могу, поэтому вариант с динамическим выделением памяти мне не очень по душе. Но это только мне, с моей :) "чисто академической" точки зрения так кажется. Возможно, если бы мне это понадобилось для каких-то реальных задач, я бы выбрал что-то другое.

Это знаете, как академические языки программирования, Haskell например. Он весь такой красивый, идеальный, основан на чистых математических принципах, но в реальной жизни используется какой-нибудь C++ где сплошные хаки и костыль на костыле. Я вот не хочу совсем уж отрываться от реальности и делать нечто абстрактное. Поэтому спрашиваю тут что да как, с какими трудностями сталкивались, что бы хотели, что не хотели. Так сказать использую чужой опыт и учусь на чужих ошибках. Если учиться на своих, то это понадобиться на всех возможных реальных задачах перебрать все возможные варианты реализаций, на что и жизни не хватит.

P.S. Так как вероятность сваливания данной темы в пространные разглагольствования в духе "зачем это тебе надо", "все и так уже есть", "а что бы ты сам выбрал" очень велика, то предлагаю все же не отклоняться от начальной цели. Я задал вполне конкретный технический вопрос, привел разные варианты решения, и хотел бы услышать в ответ конкретное мнение.

0

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

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

0

Прочитал "пожелания" и подумалось - может взять что-то готовое и творчески переработать? Скажем, несть неплохая (IMHO НЕ_плохая!) простенькая RTOS, которую удобно применять в обыденных задачах. Я говорю о scmRTOS. Вот если бы ее портировать на нормальный С, то это было бы не только "поучительно", но еще и полезно практически.
В любой программе есть мультитаскинг, вот только его реализуют на костылях. Небольшая простенькая RTOS на 2-3 потока без какого-либо "динамического выделения" - это то самое, что нужно. Да и ... самый юзабельный камень (IMHO) - STM32F030F4, ресурсов у него не так, чтоб мало (это на avr), но и не черезчур.
Короче говоря, мне было бы интересно что-то простое, без изысков, как scmRTOS, но и без всяких Cpp.
Для "больших" камней (F4 и выше) нужны другие RTOS и ... они уже есть. Проверенные и отлаженные. Оно уже мало кому надо. А вот "мелкое и пушистое" без большой ресурсоемкости, будет очень к месту.
Поэтому и предлагаю рассмотреть порт scmRTOS на человеческий язык.

0

Сообщение от u37 Короче говоря, мне было бы интересно что-то простое, без изысков, как scmRTOS, но и без всяких Cpp.

Что за ненависть к плюсам?

0

Сообщение от u37 Поэтому и предлагаю рассмотреть порт scmRTOS на человеческий язык.

Форт (Forth)? :)

0

Сообщение от KPK Форт (Forth)? :)

Форт++...

0

Сообщение от KPK Сообщение от u37 Поэтому и предлагаю рассмотреть порт scmRTOS на человеческий язык.

Форт (Forth)? :)

"язык порт рассмотреть"? в восторге мастер Йода будет :)

0

Сообщение от ivsy Сообщение от KPK Сообщение от u37 Поэтому и предлагаю рассмотреть порт scmRTOS на человеческий язык. Форт (Forth)? :)

"язык порт рассмотреть"? в восторге мастер Йода будет :)
Это лишь мыслительные придирки :)

P.S. To Dosikus_2: Forth++ ecть в в виде разных ООП расширений! (к сведению) :)
Навскидку:
Real Time Forth by Tim Hendttoss
pdf файл тоже есть. (наши учителя)
P.P.S. Evsi, не уподобляйтесь Dosikus_2, расширяйте кругозор.

0

Сообщение от Mimzodo Сообщение от OVY-srok Всякие FriiRTOS и чибиось - теряют в производительности после добавления второй активной задачи - ровно половину мощи мк, а если задач 100 - то система превращается в черепаху.

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

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

https://www.segger.com - даёт каждой задаче разное время - аналог приоритета. Время может быть от 1мкс до 1мс, когда время выйдет -задача переключится автоматически. Если в самой задаче стоит команда "шев, усё готово" - то ос сама переключает контекст, и не через диспетчер задач - а моментально.
Можно писать тупой опрос периферии, и в случае промаха - отдавать процессорное время. Получается гораздо быстрее чем через диспетчер задач, очередь сообщений, прерывания и так далее..., от слова - мгновенно.
Есно самая жирная задача, которая действительно выполняет полезную работу - будет иметь полное время 1мс (равное 100%), но вот 99 других не столь сложных и не столь актуальных на данный момент - будут работать суммарно 1-10мкс. Время на переключение никуда не денется, но сами потери не столь высоки.

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

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

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

Почти все ключевые задумки segger - реализованы в моей ос http://forum.ixbt.com/topys.cgi?id=48:11735 . Там есть пробелы, но мне уже лень.

0

Сообщение от KPK P.S. To Dosikus_2: Forth++ ecть в в виде разных ООП расширений! (к сведению) :) Навскидку: Real Time Forth by Tim Hendttoss pdf файл тоже есть. (наши учителя) P.P.S. Evsi, не уподобляйтесь Dosikus_2, расширяйте кругозор.

Ох довели фортиста, везде ему под***ки видятся. :)))))))
Ну тогда форт--...
А по теме и С с крестами и форты в эмбедде путь в никуда...

0

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

не нагрев тупой, а использование оси тупое. когда юзаешь ос - не должно быть таких "тупых нагревов присталла".

0

Сообщение от OVY-srok Ну для начала нужно всё-таки понять - как разные ос переключают контекст. Всякие FriiRTOS и чибиось ...

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

0

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

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

Сообщение от OVY-srok даёт каждой задаче разное время - аналог приоритета

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

Сообщение от u37 Небольшая простенькая RTOS на 2-3 потока без какого-либо "динамического выделения" - это то самое, что нужно.

Кстати uC/OS II именно такая.

Сообщение от u37 без какого-либо "динамического выделения" - это то самое, что нужно... Короче говоря, мне было бы интересно что-то простое, без изысков, как scmRTOS, но и без всяких Cpp.

Вот тут я поддерживаю. Все эти FriiRTOS довольно пухлые, и дальше будут только пухлеть.

Сообщение от ivsy По поводу "динамического" распределения памяти: резервируется статический массив байт и делается указатель на начало. "Выделение" просто возвращает текущее значение указателя, а сам указатель инкрементируется на величину выделяемого блока. Поскольку освобождения при этом не предусматривается (да оно и не нужно, вобщем), то накладных расходов никаких, а скорость максимальна. При этом нет кучи макросов по всему коду и писать можно под достаточно комфортный режим как если бы динамическое выделение было на самом деле доступно.

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

0

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

Во FriiRTOS примерно так и сделано: метод выделение памяти отдан на выбор пользователя. А пользователь уже сам может выбрать один из нескольких вариантов, предложенных ОС, либо написать свой. Там и статичный массив, из которого только выделяется память, там и самодельные менеджеры памяти, и библиотечный malloc, и что-то еще.

0