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

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

пример?

Сообщение от Mikomk Задача не может сама завершится. Все, с этого момента мы уже несовместимы с многими ОС.

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

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

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

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

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

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

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

0

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

пример?

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

Сообщение от Ymk Сообщение от Mikomk Задача не может сама завершится. Все, с этого момента мы уже несовместимы с многими ОС.

а зачем нужна эта совместимость в эмбеддед? запускать юниксовые программы?

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

Сообщение от Ymk цели слишком разные у юниксов и встраиваемых ос.

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

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

0

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

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

Сообщение от Ymk "в советские времена" не было во фриртосах никаких встроенных дров для периферии. были примеры, например, для уарт, но и те были куцие

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

Кстати, насчёт 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. Это конечно отличается от стандартных примеров из интернета, где средний уровень заканчивается морганием светика.

0

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

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

0

Сообщение от Mikomk Навскидку xQueueSendToBack(), xQueueSendToBackFromISR() Делают одно и то же, но задача пользователя разруливать состояние.

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

Сообщение от Mikomk Это должно быть проблемой операционки. А тут так старательно разложены грабли. Так же как и завершение работы задачи по фигурной скобке.

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

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

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

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

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

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

технический смысл очень даже меняется - не надо запускать и останавливать задачи, чего вам так "не хватало". а вот по смыслу именно что все то же самое.
OVY-srok писал(а):

Кстати, насчёт 15 задач для муз центра, исключительно физика:

я примерно так и думал:) драйвер драйвер драйвер... вы описали набор ФУНКЦИЙ, а не задач. функции - суть подпрограммы. задачи - параллельные ветви исполнения. я не спорю, можно сделать велик с треугольными колесами, он даже поедет. может и дорогу под него можно подобрать идеальную, что поедет нормально, но блин зачем? сделайте круглые колеса и он поедет везде.

0

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

0

Сообщение от Ymk Сообщение от Mikomk Навскидку xQueueSendToBack(), xQueueSendToBackFromISR() Делают одно и то же, но задача пользователя разруливать состояние.

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

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

Сообщение от Ymk Сообщение от Mikomk Это должно быть проблемой операционки. А тут так старательно разложены грабли. Так же как и завершение работы задачи по фигурной скобке.

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

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

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

[/QUOTE]
эти ваши модные словечки... за деревьями не видите леса;)

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

Ymk"]если вы в курсе про HAL, откуда же у вас проблемы с миграцией на другую (но похожую!) ось? если эти ваши модули грамотно отделены друг от друга, от железа, от оси - они легко переделаются под другую платформу. это называется кроссплатформенность и она уж никаким боком не относится к оси.[/QUOTE]

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

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

Ymk"]если у вас проблемы с этим - не перекладывайте ответственность на ось, разберитесь, что именно вы делаете не так.[/QUOTE]

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

Ymk писал(а):

а юникс здесь был при том, что вы либо сравниваете разного масштаба системы (все мы знаем что запускать 100500 ПРОЦЕССОВ и связывать их пайпами - нормальный такой юникс-вэй), либо... неправильно проектируете свой софт, раз проблема мигрировать.

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

Ymk писал(а):

Mikomk писал(а):

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

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

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

Кэп?

0

Сообщение от Mikomk Навскидку xQueueSendToBack(), xQueueSendToBackFromISR()

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

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

0

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

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

0

Сообщение от Ymk Сообщение от OVY-srok Кстати, насчёт 15 задач для муз центра, исключительно физика:

я примерно так и думал:) драйвер драйвер драйвер... вы описали набор ФУНКЦИЙ, а не задач. функции - суть подпрограммы. задачи - параллельные ветви исполнения.

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

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

0

Сообщение от OVY-srok Сообщение от Ymk "в советские времена" не было во фриртосах никаких встроенных дров для периферии. были примеры, например, для уарт, но и те были куцие

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

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

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

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

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

0

Сообщение от Mikomk Запрет так то можно явно прописать для отдельных функций. А для вызвавшего однозначно вернуть код ошибки.

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

Сообщение от Mikomk Кроме того, я написал, что это пример навскидку. Там много несуразностей. Повторно анализировать эту ОС как то нет смысла. По крайней мере пока не допилят.

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

Сообщение от Mikomk Насчет понимания контекста - в большинстве случаев да, но как понимание скажется на том что один обработчик должен вызываться в разных условиях? Ах, ну да переключатели ставить. Другие ОС справляются.

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

0

Сообщение от itysiy Сообщение от Mikomk Запрет так то можно явно прописать для отдельных функций. А для вызвавшего однозначно вернуть код ошибки.

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

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

Сообщение от Mikomk Насчет понимания контекста - в большинстве случаев да, но как понимание скажется на том что один обработчик должен вызываться в разных условиях? Ах, ну да переключатели ставить. Другие ОС справляются.

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

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

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

0

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

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

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

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

0

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

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

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

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

0

Сообщение от Mikomk Кого волнует гемор кодера free rtos? А так сейчас гемор для кодера который пользуется ОС.

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

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

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

Сообщение от Mikomk Работало все в нормальной ОС. Мигрируем например на Frii RTOS. Цепляем код. Опа, проблемы. Трудноуловимые. Читаем мануал, оказывается теперь надо отловить вызовы функций ОС и заменить, потому что они зависят от ого откуда вызываются. Ладно, заменили. Проект не работает. Опа, и завершение по скобке нельзя. Таак, сколько там еще граблей... Это Вы называете легкой миграцией?

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

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

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

Сообщение от OVY-srok Эти функции как вы говорите, имеют жёсткую привязку к времени исполнения.

и что это меняет?
OVY-srok писал(а):

У вас получается что весь девайс должен ждать ответа от одного мелкого контролёра физики, просто ждать и ничего не делать при этом.

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

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

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

0

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

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

0

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

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

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

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

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

Сообщение от Ymk я конечно не люблю этот прием, но спрошу: когда от вас ждать релиз идеальной ос?

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

А у вас?

0

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

0

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

0