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

Сообщение от vt340 Как вам такая идея - "rtos" в отдельном готовом к употреблению бинарнике?

Вот о чём я и говорил, там где большие деньги - всегда найдётся обиженный. Но сама идея хороша.
Если в том-же направлении , то вот http://forum.ixbt.com/topys.cgi?id=48:11835
Человек в домашних условиях создаёт новый проц, есно на фпга.
Отличие от стандарта - ос на уровне ядра, общение тасков на уровне спец команд на асме - напрямую, ну и переключатель полностью аппаратный.

0

В академических целях я бы посоветовал обратить внимание на TinyOS.
А сам бы (если бы, конечно :) ) попытался реализовать транслятор, который бы перекладывал функционал шедулера и сервисов RTOS на голый NVIC и DMA (в STM32)

0

Сообщение от OVY-srok Некую очередь... Уже это подразумевает отложенное исполнение, а значит медленную реакцию системы.

Это совершенно не обязательно. Вполне возможно, что даже наоборот, поскольку позволяет минимизировать время с запрещенными прерываниями. И, что весьма полезно, минимизировать риск потери прерывания.

0

Сообщение от Mikomk Legacy имеет только одно значение - устаревший. На самом деле объяснять другими словами несколько долго

ну да, ты его только пишешь, а ему уже 20 лет. это не так давно "устоявшийся" термин того, что простые люди называли любительским (не промышленным) кодом, write-only кодом или говнокодом. слово "говнокод" даже лучше характеризует это, чем модное слово "устаревший".

Сообщение от Mikomk Каким образом Вы подумали иначе, не знаю.

я не думал иначе.

Сообщение от Mikomk Зато теперь мне понятно на что Вы так обиделись. На остальное смысла отвечать не вижу, там сплошные наезды.

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

Сообщение от OVY-srok у меня есть своя ос ... А у вас?

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

0

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

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

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

0

А я давно предлагаю обсудить, что все-таки нужно микроконтроллерной ОС.

FriiRtos мягко говоря не дотягивает по уровню.

nuttx, берет курс на упрощенное копирование линукса, что хорошо, но мне как-то печально с этого.
embox, ИМХО, как-то слишком любит статические структуры. Плюс, там как-то понатаскано все из разных мест.

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

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

Очень важен вопрос стека протоколов. Стек TCP/IP неподъёмен и сложен в поддержке, но определенно требуется какая-то унификация каналов связи.

Необходимость файловой системы или нэймспейсов ака QNX

Это все крайне интересные вопросы, товарищи.

0

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

0

Сообщение от Myrmyk ... embox, ИМХО, как-то слишком любит статические структуры. ... Уметь, кто бы что ни говорил, работать с динамической памятью.

Бывают такие требования (в критических системах, типа тех, что поддерживают жизнедеятельность организма человека), где нельзя ничего динамического. Самый максимум - это на старте все динамически выделить, и потом работать в статическом режиме.
Так что embos как раз этому требованию удовлетворяет.

0

А что, динамическое считается небезопасным?
Звучит немного нелепо.

0

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

Я пытаюсь сочинить диспетчер, который умеет кооперацию и форс одновременно. Впринципе работать может.

0

Сообщение от Myrmyk А что, динамическое считается небезопасным? Звучит немного нелепо.

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

Потом будете рассказывать следователям, что динамическое выделение памяти это не опасно ;-)

Но такие вещи вылавливаются на стадии проектирования и составление списка FMEA (Fault Mitigation чего то там, я так глубоко не лазил, так как в манагеры не вхож), и если там в этом списке проблем нет решения проблемы (ресет - НЕ решение у данного класса железок) - железку продавать вам не дадут.

0

Сообщение от Myrmyk Я пытаюсь сочинить диспетчер, который умеет кооперацию и форс одновременно. Впринципе работать может.

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

0

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

dmk793
Любопытно. ИМХО, в контексте микроконтроллеров диспетчеризацию следует делать максимально явной и многовариантной.
У меня, например, есть опция процесса, которая говорит диспетчеру, можно ли его вытеснять. Есть процессы, которые не могут быть вытеснены просто потому, что не имеют собственного стека (Автоматные, прям как dymyurk1978 любит). Вообще допустимо очень много разных типов процессов. Это, впрочем, мешает строить продвинутые алгоритмы планирования и требует корректного построения каждого процесса. Я не уверен, что это хорошо.

0

Сообщение от Myrmyk MostirOtyxiy Это называется "плохое использование хорошего инструмента."

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

И каким бы не было, хорошим или плохим, использование инструмента, им (FDA и Со.) как бы похер.

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

Риторический вопрос, конечно, и на этом можно завершить дискуссию в этом направлении.

0

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

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

0

Сообщение от Otixomdr_1 ... Почему бы в такой задаче не поставить отдельный МК ....

Вы правильно все описали. Так в реале все и делается (в нормальных системах).
Канальность, называется по буржуйскому (там чтото про sil надо читать, так глубоко я не лазил), по нашему - редундантность, но не полная.

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

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

Дополнение - бесконечное количество контроллеров не поставишь, денег не хватит, как у производителя, так и у покупателя, такое покупать - конкуренция не спит.

По этой (и скорее всего это основная) причине на каждую микроконтроллерную единицу вешают несколько задач, а не только одно что-то.

0

Не, ребят, это все, конечно, хорошо, но это не по теме. Тема заключается в построении удобной OS а не в уходе от необходимости таковой.

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

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

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

0

Сообщение от MostirOtyxiy Дополнение - бесконечное количество контроллеров не поставишь, денег не хватит, как у производителя, так и у покупателя, такое покупать - конкуренция не спит. По этой (и скорее всего это основная) причине на каждую микроконтроллерную единицу вешают несколько задач, а не только одно что-то.

Насчёт денег.
Один большой или несколько малых МК — разница в цене очень незначительна.
Несколько МК ставят в достаточно сложных устройствах, цена которых десятки и сотни тысяч рублей, поэтому такая разница в цене не имеет значения. А упрощение разработки и связанное с этим повышение надежности и снижение времени разработки существенно.
Конечно, каждый МК в своём функциональном блоке может выполнять далеко не одну задачу. В своём блоке периферийный МК может обрабатывать несколько датчиков, исполнительных устройств, следящих систем и т. д.

Сообщение от MostirOtyxiy При этом как мелкий контроллер, так и большой контроллер - они мониторили друг друга обоюдно :)

Зачем МК мониторят друг друга — не ясно.
На мой взгляд, контролирует ситуацию центральный МК, а периферийные МК только обслуживают его: выполняют команды центрального МК и передают ему информацию о состояние дел в его блоке, показания датчиков и т. д.

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

Зачем «отдельно взятая единица должна иметь возможность решать широкий круг задач»?
Периферийный МК решает определенную чётко поставленную задачу или несколько задач, скажем, подачу кислорода. Программа для такого МК будет простой, без всяких наворотов с ОС, соответственно, её легко написать и она будет надёжной.

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

В каких устройствах должен стоять именно один МК?
Я предполагал, разработчик выбирает число МК согласно поставленной задаче.

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

Если разработчик ставит 10 МК, где без проблем можно поставить один, то тут вопрос в невысокой квалификации разработчика, а не в подходе.

Myrmyk писал(а):

Не, ребят, это все, конечно, хорошо, но это не по теме. Тема заключается в построении удобной OS а не в уходе от необходимости таковой.

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

Myrmyk писал(а):

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

С этим, наверно, все согласятся.
Тут большой вопрос, как тестировать, чтобы «работало, как часы».
Да и жизнь порой подбрасывает труднорешаемые задачи.

0

Сообщение от Otixomdr_1 Сообщение от MostirOtyxiy При этом как мелкий контроллер, так и большой контроллер - они мониторили друг друга обоюдно :)

Зачем МК мониторят друг друга — не ясно.
На мой взгляд, контролирует ситуацию центральный МК, а периферийные МК только обслуживают его: выполняют команды центрального МК и передают ему информацию о состояние дел в его блоке, показания датчиков и т. д.

Почитайте стандарты IEC 60601-xxx. В частности IEC 60601-1ed3.0 пункт 14.8. И за одно IEC 62304, IEC 61508
Ну и еще статейку на тему:
http://www.todaysmedicaldivelopments.co ... ot-safety/
Там на первой картинке средний и правый столбцы, ну и вообще вся статья целиком.
Особенно про Protection type CPP -One control system wyth two or more independent protective measures.
Ну и еще можно погуглить на ключевые слова - Ctoss C Software Ctossification.
Тогда такие вопросы, я думаю, не станут возникать.

0

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

Зачем?
Я же это уже сделал еще более 15-ти лет назад. И мою RTOS Вам всё равно не переплюнуть

0