Easyelectronics.ru

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

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

1. Самый тупой способ - сделать все управляющие структуры публичными и дать пользователю возможность создавать их статически. Не нравится, потому что грубо нарушает инкапсуляцию. Как то это нехорошо.
2. Чуть получше - заставить пользователя реализовать специальную функцию, которую ОС будет вызывать, когда ей нужна память, эдакий mallocHook(). Откуда будет браться память - это уж проблемы пользователя. Решение мне в принципе нравится, довольно гибкое, но для простейшей ОС сложноватое. Неохота заставлять пользователя реализовывать свой менеджер памяти, каким бы он простым ни был. Вроде FreeRTOS поддерживает этот способ.
3. Классический вариант - ОС сама статически выделяет пул объектов, количество которых задается дефайном. Решение простое, инкапсуляция соблюдается, лишних телодвижений не требует, но какое-то топорное. Не нравятся мне эти дефайны и не нравится заранее загадывать сколько и чего мне нужно. Знаю, что uC/OS II так работала.
4. Последнее решение - похоже на первое, но оно не так явно нарушает инкапсуляцию. Суть в том, что для каждой управляющей структуры, пользователю предоставляется её близнец-пустышка с размером и выравниванием соответствующим оригиналу. То есть пользователь создает пустышку не зная о её устройстве, а внутри ОС она уже приводится к реальному типу. Мне нравится это решение, не идеальное но вполне простое и надежное. Так же имеется во FreeRTOS

Что бы вы, как пользователи, выбрали? Может есть другие варианты?

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

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

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

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

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


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

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

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

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

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

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

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

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

Форт (Forth)? :)

Форт++...

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

Это лишь мыслительные придирки :)

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

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

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

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


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

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

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

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

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

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

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


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


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


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


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

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

Menzoda, не смешно.

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

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

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

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

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


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

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

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

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