Easyelectronics.ru

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

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

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

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

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

А я бы ещё и осями эти экзокернелы не назвал )
Может уже сразу в вальхаллу? )

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

пример?

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

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

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

Навскидку
xQueueSendToBack(),
xQueueSendToBackFromISR()
Делают одно и то же, но задача пользователя разруливать состояние. Раньше такого там было много, сейчас не скажу, может что то пофиксили.
Это должно быть проблемой операционки. А тут так старательно разложены грабли.
Так же как и завершение работы задачи по фигурной скобке.



Если вы с самого начала пишете legacy код, то вопросов нет.
А совместимость нужна чтобы в дальнейшем использовать написанные программные модули без использования бубна. И при чем здесь юникс?
Вы выросли как специалист или перешли на другой проект где по требования стоит например uOS. И все, ваши модули туда не подключишь так просто.
Или проект free rtos забросили и встал вопрос миграции.



Я понимаю что вы совместимость видите как то по своему. Это в мире больших компов зависимость от оси сильная. В эмбедд куда сильнее от железа. И если написанные модули от оси не зависят, а слой HAL выделен аккуратно и не содержит острых зависимостей от железа (например использование какого то особого функционала конкретного МК), то перенос на другую ОС вообще незаметен, а на другое железо - все равно только слой HAL переписать.

ОС должна решать задачи организации работы программных модулей и зависимость от нее должна быть минимальной.

И что будет делать этот менеджер подзадач во время прямого вызова подпрограммы? А ничего, он будет выполнять подпрограмму. Как ни крути, смысл не меняется.



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

Кстати, насчёт 15 задач для муз центра, исключительно физика:
0 общий менеджер ресурсов энергосбережения, он-же общий менеджер состояния магнитолы.
1 драйвер физики экрана
2 экранный менеджер слоёв "видео", он-же общий рисовальщик интерфейса, отрисовка по поступающим командам от других тасков.
3 нечто типа прямого доступа к экранной области, полуаппаратное решение, аналог draw режима на современных видеокартах.
4 драйвер флеш носителей, разных чипов и размера.
5 физ драйвер радио, полуаппаратное решение.
6 физ драйвер чипа приёмника телевидения, сразу нескольких стандартов, а так-же аналоговых камер заднего вида.
7 физ драйвер проводного ентернета, для цифровых камер заднего вида и как вариант - регистратора.
8 физ драйвер блюпупа, полуаппаратное решение.
9 физ драйвер вайвая, полуаппаратное решение.
10 физ драйвер спутниковых чипов навигации, и всё что с ними связанно.
11 физ драйвер сотовой связи, и не спрашивайте зачем.
12 драйвер внешней периферии магнитолы, а так-же менеджер сообщений от многочисленных датчиков, начиная от банального стопсигналла, заканчивая прямым подключением к бортовому компу. Ну там голосом человеческим сообщить через колонки - типа масла/бензина/омывайки мало, или явная неисправность не кодом ошибки - а человеческим голосом.
13 есно голосовой синтезатор, как вариант - плеер готовых сообщений.
14 полуаппаратный драйвер звука, с эквалайзером, эффектами, и плюшками.
15 полуаппаратный драйвер вывода цифрового звука на крутые внешние усилители, чтоб бумкало.

Можно придумать ещё несколько отдельных задач под физику, но для средней магнитолы - это уже перебор.
Далее полностью программный уровень:
0 отдельный фоновый таск микшера звука.
1 отдельный таск декодеров разных форматов сжатия музыки и видео.
2 отдельный таск сжатия видео и звука.
3 отдельный "графический" визуальный таск менеджера музыкальных и видео файлов, с поддержкой создания, переименования, удаления, и группировкой в плейлисты.
4 таск для работы с навигацией - отображение, поиск маршрута, подсчёт экономии бензина и прочие плюшки.
И так далее, ещё штук 20 задач - которых нет смысла запускать одновременно.

Самое прикольное - это всё есть в стандартной двухдимовой китайской магнитоле стоимостью в 15к, в которой в качестве центрального чипа стоит мк фирмы st. Это конечно отличается от стандартных примеров из интернета, где средний уровень заканчивается морганием светика.

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

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

эти ваши модные словечки... за деревьями не видите леса;)
если вы в курсе про HAL, откуда же у вас проблемы с миграцией на другую (но похожую!) ось? если эти ваши модули грамотно отделены друг от друга, от железа, от оси - они легко переделаются под другую платформу. это называется кроссплатформенность и она уж никаким боком не относится к оси.
тот проект, который я в 2008м мутил на фриртос под арм, он у меня легко собирался под винду в мсвс, ибо там было куда проще отлаживать. там работали и lwip, и efsl, и еще несколько разных штук задач. просто потому, что код был написан так, что он легко переносился. в железе у меня была и работа с таймерами, с уарт, спи, кучи разного другого железа, но проблемы запустить это под виндой - не было (думаю, ясно, что аппаратная часть была полностью заэмулирована, но основной код задач был без изменений).
если у вас проблемы с этим - не перекладывайте ответственность на ось, разберитесь, что именно вы делаете не так.
а юникс здесь был при том, что вы либо сравниваете разного масштаба системы (все мы знаем что запускать 100500 ПРОЦЕССОВ и связывать их пайпами - нормальный такой юникс-вэй), либо... неправильно проектируете свой софт, раз проблема мигрировать.
так и что не так с фриртос в этом плане-то? работа с железом и обработчики прерываний - это абсолютно аппаратные вещи, всегда разные на разных платформах. апи у всех осей тоже разное (имена функций, параметры и все такое). вы заранее это знаете и иначе не будет. изолируйтесь от этого и проблем с миграцией не возникнет. а суть шедулеров и примитивов синхронизации - одна.
технический смысл очень даже меняется - не надо запускать и останавливать задачи, чего вам так "не хватало". а вот по смыслу именно что все то же самое.
я примерно так и думал:) драйвер драйвер драйвер... вы описали набор ФУНКЦИЙ, а не задач. функции - суть подпрограммы. задачи - параллельные ветви исполнения. я не спорю, можно сделать велик с треугольными колесами, он даже поедет. может и дорогу под него можно подобрать идеальную, что поедет нормально, но блин зачем? сделайте круглые колеса и он поедет везде.

Наверное инициатор топика уже давно всё написал и толку в дискуссиях этих == 0.

Кого волнует гемор кодера free rtos? А так сейчас гемор для кодера который пользуется ОС. Ну да, пришлось бы функции выяснять откуда она вызвана и применять правильный метод. Добавился бы платформозависимый кусочек.



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



Да ладно? А зачем я тогда так подробно объяснял раз вы не читаете? И что Вы называете модными словечками?



Ну тогда зачем вы их смешали? Я специально привел два интерфейса разделения - один от железа, другой от ОС. А проблемы с миграцией возникают как раз таки из-за непродуманности. Работало все в нормальной ОС. Мигрируем например на Free RTOS. Цепляем код. Опа, проблемы. Трудноуловимые. Читаем мануал, оказывается теперь надо отловить вызовы функций ОС и заменить, потому что они зависят от ого откуда вызываются. Ладно, заменили. Проект не работает. Опа, и завершение по скобке нельзя. Таак, сколько там еще граблей...
Это Вы называете легкой миграцией?
Нормальная миграция - вызовы функций ОС осуществляются одинаково, в крайнем случае подмена дефайнами. Действия разрешенные спецификацией языка не должны приводить к проблемам. Как понятно из описания Free Rtos, это все не про нее.

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



У меня нет проблем. Но использовать сырую ОС с некультурно оформленным интерфейсом. Повышать уровень сцепления модулей с ОС. Это глупо.



Вы вообще в своем мире каком то. Я не собираюсь с юникс мигрировать. Я пишу на МК, под задачи МК.



Читать не пробовали? Повторю - разные вызовы одних по сути действий в зависимости от контекста, действия нормальные для языка, запрещены в ОС.



Кэп?

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

ИМХО правильно, что функции разные для контекста тасков и прерываний, так как в любом случае нужно понимать в каком контексте ты находишься. Более того многие вызовы ОС нельзя вызывать из контекста прерывания, например delay. И обертка над прерыванием уже не поможет, и даже если функция сможет выяснять откуда она вызывается (а она это делает и контролирует assert'ом), это уже будет ошибка на уровне проектирования.

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

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

У вас получается что весь девайс должен ждать ответа от одного мелкого контролёра физики, просто ждать и ничего не делать при этом. Как в винде95 при форматировании флопика :) . При таком подходе использовать ос не обязательно, достаточно шейкера задач на банальном switch.