Easyelectronics.ru

Нет, я даже не заметил где оно там есть.

Странные, какие-то необоснованно резкие у вас претензии к freertos.



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

Тогда это будет ошибка выполнения. Лучше вываливать ошибку еще на этапе компиляции. Ну и получается неоднозначное поведение функции: иногда она работает, иногда не работает. Лишние неочевидные сущности о которых нужно помнить.

Согласен, да, там есть свои косяки.

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

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


Ну тут уже компромисс. Получаем либо одно, либо другое. Возможность вызывать функции ОС в разных контекстах дает и плюсы и минусы. И "правильного" решения нет.[/quote]

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

Я понимаю что все правила хорошего кода чисто рекомендательные. Но многие из них вполне обоснованны.

А вот расскажите мне за разрешение/запрет прерываний, они же критические секции. Часто вижу, что при запрете прерываний (входе в критическую секцию) сохраняется текущее состояние запрета, а соответственно при разрешении прерываний (выходе из критической секции) данное состояние восстанавливается. Это вместо того, что бы просто запретить/разрешить. У меня возникло два объяснения данному поведению.

Первое. Это нужно для того, чтобы можно было делать вложенные запреты/разрешения прерываний. По мне, использовать вложенные запреты - весьма сомнительное решение. Критические секции должны быть максимально короткими и строго ограниченными, а не размазываться по всему коду. Существует ли какая-нибудь ситуация, при которой без вложенных критических секций не обойтись?

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

Я это все к чему? Реализовывать поддержку вложенных критических секций несколько сложнее, работают они чуть медленнее, использовать их не так удобно (нужно каждый раз объявлять переменную, в которой будет храниться текущее состояние). Стоят ли они того? Я считаю, что нет, но что вы думаете?

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

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

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

Оба случая обрабатываются одним механизмом, разница лишь в назначении приоритетов.

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

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

я это называю RTFM. если вы кинулись портировать проект под другую ось, не ознакомившись с ней - это только ваши проблемы, зачем вы их перекладываете на кого-то еще? потом, когда вы изучите новую ось, у вас опять что-то будет не так, потому что вы доку на новый компилятор не прочитали. потом еще и еще удивительные открытия. давно пора понять, что идеала не существует, всегда и везде - если не косяки, то компромиссы. их надо знать ДО того, как начинаешь работу. у фриртос еще 8 лет назад была ОЧЕНЬ ясная дока, с кучей примеров, с обьяснениями. как можно было не знать, что для прерываний свои функции? вы вот возьмите и посчитайте процент ваших "нормальных ос", которые не разделяют контекст юзерспейс и прерываний/ядра. даже такие гиганты как линукс и виндовс, имея огромный запас (вычисл.) ресурсов, не делают то, что вы тут яро защищаете.


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

и что это меняет?

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

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

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

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

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

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

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



Не скажу за автора топика, но у меня есть своя ос. И пока её не было в планах - приходилось есть общедоступный кактус.

А у вас?

Однажды одна компания забахала урезанную, но зато сертифицированную freertos в rom, в смысле не просто в бинарник, а намертво в мк, cortex-m3 кстати.
Ни компании, ни мк уже нет, я думал, что и мануал затерялся, но оказалось не затерялся - http://www.ti.com/lit/ug/spmu040a/spmu040a.pdf
Как вам такая идея - "rtos" в отдельном готовом к употреблению бинарнике?

Не плохое описание.
В принципе если freertos запихать в system flash - ничего плохого не будет. Не хочешь - не пользуйся. Но если использовать - часть флэша освободится. Процесоор точно известен - так с настройками проблем нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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