Мной подготовлена серия статей, посвященных конкретной российской ОСРВ, одним из создателей которой я являюсь. Получилась своеобразная «Книга знаний», неформальное руководство для программиста, которое, надеюсь, поможет тем, кто эту ОСРВ использует.
Я расскажу об особенностях работы этой ОСРВ. Если о чём-то другом, то только потому, что без этого будут непонятны особенности.
Ниже я расскажу об особенностях ОСРВ вообще, и об особенностях ОСРВ МАКС в частности. Представлю ее архитектуру.
В дальнейшем я буду регулярно размещать новые публикации: вторая будет посвящена ядру системы, в последующих я представлю структуру простейшей программы, работающей под управлением ОСРВ МАКС с элементами кода, расскажу, как настроить ОСРВ МАКС для работы, затрону вопросы строгой типизации и драйверов.
Я, конечно, лицо аффилированное, поэтому, если пост перенесут в раздел «Я пиарюсь», то не очень обижусь. Но, с другой стороны, уже написан целый цикл статей, посвященный особенностям операционки, и было бы странно все их удалять-переносить. Тем более, что я старался максимально быть объективным и избежать рекламности.
Что такое операционные системы реального времени и особенности новой ОСРВ МАКС
Удивительно, но под термином «операционная система реального времени» многие понимают совсем не то, что надо. Они смотрят на термин «Операционная система» через призму тех ОС, с которыми им доводилось работать, а работать им доводилось на PC или более ранних компьютерах. Не раз и не два после рассказа о том, какую ОС мы начали проектировать, доводилось слышать предложения, которые было просто невозможно внедрить. Все собеседники шли по следующей цепочке: «Это операционная система, но для слабеньких (относительно современных PC) процессоров, значит, это что-то типа ДОС», и дальше шли предложения, исходящие из этого неверного посыла.
А неверно там всё.
Начнём с того, что время однозадачных ОС (какой была ДОС) ушло в прошлое. Если не требуется многозадачность, то необходимо и достаточно взять какую-либо штатную библиотеку для контроллеров. К STM32 прилагается несколько альтернативных библиотек от производителя (HAL, Cube MX и т.п.), для AVR также имеются библиотеки LUFA, Arduino и многие другие. Все они, наряду с открытыми библиотеками TCP/IP, FAT, USB, EmWin и прочими, полностью перекрывают функции ДОС (кто помнит — Int 21h, Int 13h, Int 10h). ОС для этого не требуется.
Таким образом, чтобы быть хоть как-то нужной:
Современная ОС должна быть многозадачной.
Рассмотрим, где эта ОС должна работать. А работать она будет не на компьютере общего назначения, а в каком-то конечном изделии, будь то робот, станок, интеллектуальный выключатель или что-то подобное.
Следовательно:
- в изделии не требуется запускать или выгружать программы. Набор программ — постоянный. Включили изделие — они запустились. Пока изделие работает, они также работают;
- ОС не получает никаких команд от оператора. Самой ОС не требуется никакой консоли. Всё взаимодействие с пользователем осуществляют прикладные программы. При этом зачастую средства интерфейса могут быть специфическими (кнопки, лампы), но может быть и сенсорный экран;
- в компьютере общего пользования задержка исполнения того или иного потока, да и вообще того или иного процесса на десятые доли секунды не создаст никаких проблем. В работе с оборудованием такие задержки неприемлемы. Масса аппаратных вещей требует миллисекундных реакций — поддержка скорости работы двигателя, отслеживание работы датчиков, генерация шаговых импульсов, и многое другое: малейшая задержка приведёт к сбою работы всей аппаратной системы. Именно поэтому ОС для работы с аппаратурой называются «операционными системами реального времени». В такой ОС все потоки обязаны получать гарантированное процессорное время за гарантированный промежуток времени. Иными словами, в правильно спроектированной программе будет соблюдаться гарантированное время реакции на те или иные события.
Кроме того, ОСРВ МАКС в текущей реализации предназначена для работы на недорогих микроконтроллерах. В них не предусмотрено средств виртуализации памяти (блока MMU). Кроме того, у этих контроллеров имеется большой объём флэш-памяти, иногда — специально адаптированной на быстрое исполнение программ. Объём ОЗУ в самом контроллере обычно невелик, а исполнение программ во внешнем ОЗУ медленнее, чем во встроенной флэш-памяти.
Поэтому:
- в ОСРВ МАКС нет понятия «процесс». Их невозможно изолировать друг от друга (нет соответствующей аппаратуры), правда, потом будет показано, что понятие «процесс» может быть реализовано за счёт особенностей ОСРВ МАКС при исполнении в нескольких контроллерах одновременно, но в пределах одного микроконтроллера изолированные процессы запустить невозможно;
- ОС компилируется и компонуется монолитно, вместе с программой пользователя. Они обе располагаются во флэш-памяти, так как исполнение в ОЗУ на некоторых контроллерах снижает производительность, а в некоторых случаях — просто невозможно (если в системе нет внешней микросхемы ОЗУ).
Собственно, основные особенности всех ОС, исполняемых на подобной аппаратуре, мы рассмотрели. В принципе, если воспользоваться поисковой системой, то в Интернете можно быстро найти несколько готовых ОСРВ, которые также придерживаются тех же принципов.
Зачем же было делать ещё одну?
Начнём с того, что все найденные на момент начала работ операционные системы — процедурно ориентированы. Процедурные программы плохо структурированы, их сложно сопровождать, в них проще допускать досадные ошибки, но не буду долго останавливаться на преимуществах объектно-ориентированного подхода. Сошлюсь только на то, что гиганты вроде Microsoft давно стараются переводить свои системы на объектно-ориентированный подход, внедряя .NET.
Нельзя сказать, что процедурно-ориентированный подход в существовавших ОСРВ вызван особенностями аппаратуры. Объектно-ориентированная библиотека Arduino прекрасно используется на 8-битных микроконтроллерах. Результирующий ассемблерный код нельзя назвать неповоротливым. Объектно-ориентированная библиотека mcucpp Константина Чижова, на тех же восьми-битных контроллерах, показывает такие чудеса оптимизации ассемблерного кода, какие сложно получить даже вручную. А уж в 32-х-битной среде, для которой предназначена ОСРВ МАКС, о проигрыше объектно-ориентированного подхода и совсем нельзя говорить.
Следовательно, процедурная ориентированность других ОС — это скорее тяжёлое наследие. Начав разработку в 90-м году, очень сложно бросить старые наработки. Проще сделать новую ОС. Чем, собственно, мы и занялись.
Кроме того, в ОСРВ МАКС заранее заложены функции прозрачного взаимодействия между изделиями, но этому будет посвящена отдельная статья.
Общие сведения об ОСРВ МАКС
Рассмотрим более подробно архитектуру ОСРВ МАКС. На рисунке приведена общая архитектура системы.
Приложение — это собственно программа пользователя.
Ядро осуществляет планирование и взаимодействие потоков программы пользователя друг с другом. Правда, слово «поток» было приведено для преемственности с понятиями из операционных систем общего пользования. В рамках ОСРВ МАКС они называются задачами. Поэтому правильнее будет сказать, что ядро осуществляет планирование и взаимодействие задач программы пользователя.
Если заняться совсем буквоедством, то следует писать не «ядро», а «микроядро». Функции у этих двух сущностей похожие, но в ядрах операционных систем общего пользования тысячи функций, а в микроядре — хорошо, если сотни, а может — даже десятки. Микроядро по своей структуре крайне простое.
Сервисы ОС отделены от ядра. По своей сути они являются библиотеками, которые унифицируют обращение программы пользователя к аппаратуре. Эти сервисы могут обращаться к ядру как обычные программы, а могут даже и не обращаться. В частности, драйверы нижнего уровня не имеют никакой зависимости от ядра ОС. В этом состоит отличие ОСРВ МАКС от операционных систем общего пользования, где драйверы являются частью ядра.
В следующей статье я расскажу про ядро ОСРВ МАКС и приоритет задач.
Комментарии (34)
Firelander
24.08.2017 18:19+4Я понимаю, что это только первая статья из цикла, но именно в ней хотелось бы видеть основные отличия вашей системы от существующих популярных RTOS. Я так понимаю, модель распространения у неё отлична от свободной, иначе бы вы это указали.
И ещё. Объектно ориентированный подход чаще всего используется с динамической моделью выделения памяти. Я понимаю, что на современных контроллерах использование динамической памяти не есть что-то из ряда вон выходящее, но одновременно с этим вы ограничиваете вашу систему статическим набором задач. Здесь я вижу некоторое противоречие. Если вы не используете динамическую память, значит ваша программа не очень сложная и процедурный подход оправдывает себя. Или же наоборот, если вы делаете сложную динамическую систему, зачем её ограничивать фиксированным набором задач. Или ООП здесь для только тех кто пересел с высокоуровневых языков и уже не хочет отказываться от ООП-мышления в пользу процедурного?
EasyLy Автор
24.08.2017 20:45И ещё. Объектно ориентированный подход чаще всего используется с динамической моделью выделения памяти.
В дальнейших частях будет глава о том, что динамическое выделение и ОС реального времени — две вещи несовместных. Но не будем забегать вперёд. В целом, ООП здесь — это скорее методика организации классов. А объекты этих классов достаточно просто либо раскидать по глобальной памяти и стеку, либо — выделить в куче при инициализации системы.
В общем, от ООП мы взяли именно организацию. Скажем, меня всегда бесила функция потока. Её надо знать, в неё можно передать только один параметр. А в нашей ОС — функция потока является всего лишь виртуальной функцией, которую можно перекрыть, а в классе потока можно хранить что угодно. Но опять, я-то знаю дальнейший текст… Предлагаю дождаться его…
Итого — ООП здесь для структурированности. И потому что виртуальные функции — это здорово. Они тоже придают структурированности (это чтобы не было желания уйти в дебри, что структуры есть и в чистых Сях).
А когда начнётся описание драйверов — там ещё будут шаблоны, которые не только не усложняют результирующий ассемблерный код, но и здорово его оптимизируют…Indemsys
24.08.2017 21:15+1Бесила!?
Вот тут поподробней.
Какие RTOS вы изучали и что из них скопировали.EasyLy Автор
24.08.2017 21:26-1Эээээ. Вообще-то это не совсем законно, изучать для того, чтобы скопировать. Давайте скажем мягче, просто изучили, чтобы получить опыт…
Рассматривали FreeRTOS, CMSIS RTOS, uC OSII, Альтеровскую RTOS. Сейчас точно не вспомню, что ещё рассматривалось более поверхностно.
Из более высоких ОС была рассмотрена QNX, но часть её идей была выбрана, как цель для дальнейших устремлений.
Исходно было решено, что мы делаем ОС для низших контроллеров. Чтобы результат был реализуем, а не где-то на горизонте. Так что никакой изолированной памяти, ничего иного. Были выбраны Cortex M, их операционки и рассматривались. Потом — появились коммерческие задачи, список процессоров был расширен.
Чуть не забыл. Проекту не один год. И даже не два. Так что в те времена список имеющихся ОС был не очень богат.
Ну, а «что скопировали» — мы незаконными делами не занимаемся. Ничего не скопировали. Пропустили через себя и поняли, что нам требуется. Но перечень элементов ядра у всех ОС «для низших контроллеров» был един. В последующих главах это будет.
apro
25.08.2017 02:10Если говорить о объектах и шаблонах и ОСРВ сразу вспоминается eCos. Немногие ОСРВ были написаны в то время на
C++.Indemsys
25.08.2017 13:41У eCOS файловая система и TCP стек были на чистейшем C-и.
Там только ядро да стандартная библиотека были на C++.
Хотя пример удачный.
Вот в таких гибридов превращаются все потуги написать RTOS на C++.
И здесь так будет.
Если бы C++ давал хоть какое-нибудь преимущество в скорости написания или уменьшении отладки или в надежности, то все для embedded было бы давно переписано на C++.
Вон на ПК Python почти мгновенно поднялся, и все библиотеки на него были переписаны. А тут десятилетиями тормоза.
Нет, что ни говорите а в embedded у С++ с текущими либами нет перспектив.EasyLy Автор
25.08.2017 14:01Эти споры можно вести вечно. И обе стороны будут давать массу аргументов.
Текущая позиция, которую отстаиваю лично я — объектно-ориентированный код проще содержать в таком состоянии, что он хорошо понятен. Загадить можно любой код, но процедурный — чуточку проще. А объектный будет самоподдерживаться в читаемом виде.
Дальше, за счёт строгой типизации, ограничений области видимости и прочих подобных вещей, мы ставим себе на службу механизм IntelliSense, который упрощает разработку прикладному программисту. Его же бросают с проекта на проект, везде надо вспоминать, что к чему. И IntelliSense — быстрее введёт в курс дела, чем очередное копание в документации. Опять же… В тексте у меня есть хороший пример, как это помогает, но график выкладывания сюда утверждал не я. Поэтому пока просто предлагаю верить на слово, что есть. Опубликовано будет позже.
А «Этого же можно добиться и другими путями» — ну да, можно. Но там надо добиваться, а тут — оно само получается.
Итого: Заставлять всех переходить на ООП — глупо. Верить, что скоро все перейдут на ООП — наивно. Но по крайней мере, попробовать — достоинства от этого видятся неплохие. Была возможность. Попробовали. Понравилось. Не всё гладко, но не жалею, что попробовали. Продолжаем развивать.
Как потом оказалось (начинали мы давно), попробовали не только мы. И во всех случаях, тоже был успех. А либы — это дело наживное, были бы Заказчики (то есть, оплата работ).
orcy
29.08.2017 17:59Есть интересный разговор про C++ на embedded на cppcon 2016, а если точнее то доклад о том как обсуждать С++ для embedded с C разработчиками. Я не то чтобы имею отношение к embedded разработки, где-то чуть повыше, так что конкретно по этому вопросу у меня прям своего отношения, есть просто какое-то непонимание на уровне того какой оверхед ожидают C разработчики от C++. Но в данном видео довольно мало C++ и скорее больше именно какой-то психологии что мне показалось довольно интересным.
Ссылка: www.youtube.com/watch?v=D7Sd8A6_fYU
EasyLy Автор
24.08.2017 21:05Ну и да. Если у контроллера 190К ОЗУ (это не считая 2М флэша) — уже можно подумать на тему работы с динамической памятью, если быстродействие не сильно поджимает. А если ещё и припаяно 8М SDRAM — и подавно. Есть такая макетка от ST, а у меня на столе есть и реальная плата с ОЗУшкой такой. То есть, динамическая память — это, конечно, зло (так как время работы операций new и delete неизвестно, а также возможна фрагментация адресного пространства), но кому она нравится — почему бы и не воспользоваться ею? На свой страх и риск. Но само собой, это всё вторично. Первична — именно структурированность кода.
sam_satan
25.08.2017 10:33Существует placement new и создание constexpr экземпляров.
Второе дает просто прекрасные результаты, код выглядит как будто написан для пк, но сочетание static constexpr для экземпляра внутри какого то скоупа позволяет компилятору произвести аллокацию на этапе компиляции и поместить экземпляр во флеш.
Выглядит это примерно так, и код ниже может не использоватьт оперативную память вообще (я инитил итуглил светодиодом в бесконечном вайле, на gcc-arm-none-eabi, эта логика вырождалось в 50 байт кода во флеше и 0 байт оперативной памяти)
.constexpr GPIO led1(portA,pin4); //пин и порт светодиода известны компайл тайм led1.init(params); //параметры инициализации тоже led.up(); //тут идет переход по указателю на регистр BSSR порта и сдвинутый на пин, но т.к. мы знаем параметры compile time, то компилятор может подставить нужный регистр
Помимо этого, есть вероятность что в C++ добавят compile time allocator.
Что совсем перевернет методы разработки под мк.EasyLy Автор
25.08.2017 12:52Некоторые реальные Заказчики хотят пользоваться достаточно старомодными компиляторами. Поэтому конкретно Ваш пример сейчас решается через static функции, описанные в библиотеке mcucpp (библиотеку можно найти, мы её тоже нашли исходно). Но тоже неплохо решается. Там в дальнейшем тексте (который уже написан, но ещё не опубликован) показано, как он выглядит на плюсах и в ассемблере. Результаты тоже очень даже ничего. Но увы, увы, увы. Иногда желание применить самые свежие решения разбивается о то, что есть Заказчик, компилятор которого не готов к этим подвигам. А проект оплачивает — он, в том числе. Но вода камень точит, будем точить…
Ghost_nsk
25.08.2017 09:08Системы реального времени, это системы гарантирующие выполнение задачи за заданный промежуток времени с заданной вероятностью. Соответственно делятся на системы жесткого реального времени HRT (вероятность = 1) и мягкого SRT (< 1 но гарантированно заданная). Так вот заданная вероятность выполнения, динамический набор задач и динамическая память мало совместимы между собой.
leahch
24.08.2017 18:19+1Ну вот, на самом интересном месте. Интересует, какой именно подход применяется в качестве «объектного» подхода и как он реализован.
AlexPublic
24.08.2017 19:07+1Процедурный подход в современных ОС применяется в основном потому, что для него есть стандартизированный ABI, понимаемый всеми языками. Ничего аналогичного для ООП мира нет. Более того, если мы возьмём главный системный язык (C++), то его ООП ABI не совместим даже внутри разных компиляторов (и даже разных версий!) этого языка. Что уж тут говоришь о совместимости с другими языками. Другое дело, если у вас всё ПО будет компилироваться исключительно в одну бинарную прошивку вместе с ОС — тогда конечно же нет никаких проблем. Но если ваша ОС подразумевает возможность запуска чужого ПО в виде готовых бинарных сборок, то вряд ли у вас есть какой-то ещё выбор помимо процедурного API. Ну разве что ограничить разработку под вашу ОС одним языком и компилятором. )))
EasyLy Автор
24.08.2017 20:51Сейчас поддерживается один язык и три компилятора. Само собой, «прошивка» собирается одним компилятором. Но исходники можно скормить одному из трёх.
В целом — все RTOS подобного уровня собираются монолитно с приложением. Мы решили пойти тем же путём. Начинать лучше с реальных вещей, а уже потом — расширять, по мере надобности.Indemsys
24.08.2017 21:25В RTOS нет никаких проблем сделать динамическую загрузку.
В версиях Линукс для ядер без MMU (бывшая uLinux) и в NuttX и в VxWorks и других малых RTOS есть такая возможность.
Проблема только в том, что с загрузкой сторонних приложений не будет работы в реальном времени.
А где не нужно реальное время ставят raspberry pi и прочие модули с линуксом и это получается даже дешевле чем с микроконтроллерами и RTOS.
Промежуточное, я так понимаю, будет все тот же избитый набор: FatFS да lwIP.
Но они то написаны на голом С-и.
Поэтому RTOS-ы на С++ еще долго будут не востребованы.EasyLy Автор
24.08.2017 21:34-1Поэтому RTOS-ы на С++ еще долго будут не востребованы.
Можно долго дискутировать на эту тему… Но тут такое дело. Когда я покупаю технику, мощнее нынешней, я не замечаю особой разницы. Но после нескольких месяцев работы, если приходится вернуться к старой — тут-то я и понимаю, что разница ой как была…
Раньше я использовал другие ОС для программирования под STM32. Потом, само собой разумеется, был вынужден делать на нашей. Ну иначе что это за ОС, которой сам не пользуешься? И теперь все иные подходы мне категорически не нравятся. Сложно рассказывать, пока не было статей про те же драйверы. Короче, может, я просто привык, а может — как раз тот случай, когда при переходе на лучшее особо не замечаешь, а при возврате к старому — сразу ощущается.
В общем, особо дискутировать будут или не будут востребованы — смысла нет. Кто привык работать в старом — ничто не заставит его добровольно перейти на новое. Или начальство заставит, тогда потом спросим (не раньше, чем через несколько месяцев), или студентов, не имеющих багажа обучим, а потом — посмотрим…
Arduino же многие пользуются. А там — как раз ООП. И поглядите, что там народ в коде творит. Дух захватывает. Я ради ESP8266 эту библиотеку изучил.
EasyLy Автор
24.08.2017 21:50Подумал и решил добавить: Файловая система ещё не устаканилась, так что она ещё в будущем времени. Там исходно планировался именно объектно-ониентированный вариант а-ля Ардуино. Но потом победила точка зрения плюсовых потоков, так как они являются частью стандарта языка в наше время, а в той же Ардуине есть два вида файловых классов, которые очень похожи друг на друга, но не совместимы по синтаксису. Само собой, всё это будет обёрткой вокруг «избитой» процедурной файловой системы.
И не могу не отметить такой Ардуиновский проект, как Marlin — «прошивка» для 3D принтера. Когда я полтора года переносил этот код на ARM, выучил его почти наизусть. Тут недавно залез в самую последнюю версию — не узнал. Всё переделали на классы. Причём как и у нас, ради структурированности.
То есть, мир медленно, но к плюсам движется. Но медленно. Как в своё время транзисторы активно не внедрялись, пока не ушли на пенсию ламповики.Indemsys
24.08.2017 23:16Реальное время и структурированность (если я правильно понял этот ваш термин) несколько несовместимы.
Я сейчас с удовольствием изучил Zephyr OS. Вся написана на C-и. Современная. Поддерживает последний писк моды — mesh сети на Bloetooth.
А у вас я увидел только декларации IoT и ни одного упоминания стека который вы предлагаете для IoT.
Уверен на 99% что у вас не будет стека IoT написанного на C++, максимум опять обертка.EasyLy Автор
24.08.2017 23:43-1Что до структурированности и реального времени — давайте дождёмся глав с практическими примерами, тогда обсудим конкретные случаи.
Настоящий Mesh у нас в процессе разработки (который соответствует стандартам и прочее, прочее, прочее). А взаимодействие устройств будет описано в последней главе первого тома (текст-то написан давно, так что я знаю, где оно описано). Абсолютно ООПшная штука, но не на сетевом стеке сейчас сделана.
В целом — на самом деле, какая разница, что на чём базируется? Философия — не мой конёк. В конце концов, оно всё в ассемблер превращается. Интереснее, как это выглядит для прикладного программиста. И вот прикладному программисту всё подаётся в классовом виде. А что мы сами делаем с нуля — оно и от роду объектно-ориентированное. Но кое-что приходится и обернуть, так как всё и сразу сделать невозможно. Тем не менее, если можно стремиться к этому — почему бы не устремиться?
Что до IoT, то мы сейчас работаем с Cortex M, дешёвый IoT модуль на Cortex M3 — это RTL8710, он базируется на старом добром LwIP. А в конце концов, всё превратится в ассемблер. Но на пользовательском уровне — наша ОС, она объектная. Аналогия — объектная Arduino вокруг ESP8266 или того же RTL8710. Причём у неё в основе — ну разумеется, LwIP.
apro
25.08.2017 02:17+1Поэтому RTOS-ы на С++ еще долго будут не востребованы.
Есть например eCos ядро на C++, а API для пользователя на C или C++.
Opensource не очень популярна, но вроде коммерческая еще держится.
AlexPublic
25.08.2017 11:42Поэтому RTOS-ы на С++ еще долго будут не востребованы.
Глупости какие. Не стоит путать языка на котором написана ОС и то какие она предоставляет API. Внутри очень многие ОС написаны на C++ и это вполне оправдано, т.к. этот язык абсолютно во всём превосходит C. А вот API чаще его выставляется в процедурном стиле, т.к. он давно стандартен и его использование возможно из любых языков/компиляторов.
P.S. Если что, мы сами с большим удовольствием использую возможности C++17 в программирование под МК. Правда без всяких ОС. )))
AlexPublic
25.08.2017 11:33+1Я к тому, что в других «взрослых» ОС процедурное API является следствием вполне фундаментальных причин, а не чем-то вроде отсталости и т.п. И вы с этими проблемами тоже столкнулись бы, если бы не ограничились упрощённой задачкой с исключительно монолитными прошивками.
Да, и кстати многие из этих взрослых ОС написаны внутри себя с помощью полноценного ООП ещё несколько десятков лет назад, только вот выставить наружу эти интерфейсы в API не получается.EasyLy Автор
25.08.2017 13:03В тексте рассказано про не менее «монолитные» ОС с процедурным подходом. Более мощные в тексте не рассматриваются. Правда, с момента начала разработки появился вполне себе объектный MBED. Ну, и Arduino, хоть это не ОС, а библиотека — но она тоже вполне себе объектная. Что только подтверждает, что для такого типа ОС не только мы на этом деле «повёрнуты», другие идут тем же путём.
Монолитность ОС была заложена, как основополагающий фактор. Исходно было принято решение, что мы попробуем, а не понравится — воспользуемся полученным багажом знаний и сделаем всё с нуля. Оказалось, что ниша для монолитных ОС — на сегодня вполне себе большая. А всё остальное — пока не выходит дальше споров на совещаниях, но иногда обсуждается.
В общем, Вы верно отмечаете, что всё это — следствие монолитности. Но монолитные системы — это же нормально для систем управления. А более широкое применение и не задумывалось пока.
yarric
25.08.2017 08:58+1Процедурный подход в современных ОС
Вообще говоря объектно-ориентированный код можно и на чистом C писать, что и используется во многих ОС, в том числе Linux.
AlexPublic
25.08.2017 11:47+1Ну да, библиотека GLib — это как раз ООП в полный рост. И на этот ужас без слёз смотреть нельзя. )))
EasyLy Автор
25.08.2017 14:27Можно-то можно. Можно вообще много чего. Вопрос в том, какими силами это делается.
Почему-то вспоминается стек USB, прилагаемый к STM32. Там есть чётко выраженные слои, всё замечательно. Но связь — как раз на чистых Сях. И вот выяснилось, что система периодически виснет на больших объёмах передачи, если посылать данные в произвольный момент. Масса исследований, и вот ясно, что она не виснет, если начинать посылать в обработчике прерывания SOF. Осмотр кода показывает, что этот обработчик вполне себе может быть пропущен по слоям, но… Но чтобы протянуть его в готовый «класс» CDC, надо поправить кучу файлов, прописать кучу связей. И каждый раз во время выполнения там идёт проверка на ненулевой указатель — мелкая, но ненужная задержка…
В общем, работать-то оно работает. Но будь там не чистые Си, а Плюсы — при той же подготовительной работе, проделанной авторами стека, было бы достаточно перекрыть виртуальную функцию. И всё. Причём прототип достаточно было бы просто скопировать из родительского класса. Ну проще же было бы. И так — везде по мелочам, на чистых Сях всё достижимо, но усилия — больше.
GarryC
25.08.2017 14:03+1Забавно — начать пост с обещания развенчать ошибочные представления и тут же нагородить новых.
Если не требуется многозадачность, то необходимо и достаточно взять какую-либо штатную библиотеку для контроллеров
— это утверждение в корне неверно, даже если задача может быть сделала с основном цикле, часто ее перенос под многозадачную ОС приводит к успеху. Был очаровательный пост, не помню где, в котором не простеньком МК делали игрушку с прямым выводом на телевизор и музыкой «на ножке», так в ней применение ОСРВ, при всех накладных расходах, оказалось весьма кстати и существенно упростило разработку ПО.
Современная ОС должна быть многозадачной.
— она может быть какой угодно, но должна многозадачность поддерживать.
Самой ОС не требуется никакой консоли.
— расскажите, какая из ОС требует консоль (именно ОС, а не интерпретатор командной строки, который в состав ОС входит, но, например, в ядро не входит)
Масса аппаратных вещей требует миллисекундных реакций… малейшая задержка приведёт к сбою работы всей аппаратной системы.
— требует микросекундных реакций и никак (от слова совсем) не может быть реализована в виде задачи — только аппаратная реализация критичных задержек, поскольку задержка может привести не к сбою, а к повреждению системы.
Иными словами, в правильно спроектированной программе будет соблюдаться гарантированное время реакции на те или иные события.
как было указано в предыдущем параграфе, это время реакции Вас не порадует, поскольку никаких гарантий по железу не дает.
В них не предусмотрено средств виртуализации памяти (блока MMU)
— блок MPU в последнее время есть, а этого уже позволяет реализовать изоляцию процессов.
Кроме того, у этих контроллеров имеется большой объём флэш-памяти, иногда — специально адаптированной на быстрое исполнение программ
МК без ускорителя доступа к Flash — 2017 год на дворе — такие еще делают? — но это придирки.
Объём ОЗУ в самом контроллере обычно невелик
во многих МК делают много ОЗУ именно для ускорения работы критических фрагментов программы, ну и для специфических задач.
но в пределах одного микроконтроллера изолированные процессы запустить невозможно
— смотри предыдущее примечание об MPU.
ОС компилируется и компонуется монолитно, вместе с программой пользователя
— всего лишь один из подходов, никто не мешает делать правильно и разделить их, остро популярная ESP делает именно так и прекрасно себя чувствует.
Они обе располагаются во флэш-памяти, так как исполнение в ОЗУ на некоторых контроллерах снижает производительность
о ложности данного утверждения см. выше, пример в предыдущем параграфе.
Процедурные программы плохо структурированы, их сложно сопровождать, в них проще допускать досадные ошибки, но не буду долго останавливаться на преимуществах объектно-ориентированного подхода
плохо спроектированный объектно-ориентированный код ничуть не лучше, смею Вас уверить.
Проще сделать новую ОС. Чем, собственно, мы и занялись.
ну и главное, у Вашей ОС нет фатального недостатка.
Ну и в заключение — тем, кто интересуется вопросами ОСРВ на МК, настоятельно рекомендую весьма неплохую книгу «Real-Time Embedded Systems. Open-Source Operating Systems Perspective»EasyLy Автор
25.08.2017 14:39Очень сложно ответить по пунктам и не запутаться. Поэтому скажу только, что MPU у нас используется, мы не смогли с его помощью изолировать процессы. Только — защитить ядро ОС и бороться с нулевыми указателями. Это же говорится и в описаниях на Cortex M, включая книги об этом процессоре. Буду рад, если подскажете, как это сделать, обещаю «продавить» на совещаниях реализацию, чтобы не пропало. Я вообще люблю «продавливать» нестандартные решения.
Очень здорово, что пока что фатальный недостаток не обнаружен (нами, кстати, тоже пока что). Надеюсь, он не вылезет до самого конца публикаций, так как дальше пойдёт описание функциональности. Но законов Мерфи никто не отменял, так что он вполне может объявиться.GarryC
25.08.2017 14:50+1Нет, я имел в виду, что в Вашей ОС не будет ФАТАЛЬНОГО недостатка — то, что она сделана не Вами. Все остальные недостатки можно исправить, а этот — никогда.
А по поводу MPU — в указанной книге об этом говорится, накладные расходы великоваты, но реализация есть.EasyLy Автор
25.08.2017 15:00За этот недостаток лично я — спокоен.
Именно я нажимал кнопку «Создать проект», и именно я создавал несколько первых классов для прототипа. От них уже ничего не осталось, ребята постарались на славу, всё переделано неоднократно, но самые первые классы как были созданы мной, так и есть. Так что точно нами всё сделано. И, как я отмечал в комментариях выше, именно сделано, а не позаимствовано.
Исходно считалось, что мы попробуем, наберёмся опыта, а затем — создадим «боевой» проект. Посему не боялись закладывать в архитектуру не устоявшиеся у других варианты, а то, как оно нам виделось правильней (при том, что опыт работы с RTOS в качестве пользователей у нас был, так что виделось нам более-менее чётко). Но потом проект, выросший из прототипа оказался вполне жизнеспособным до сих пор.
Так что за отсутствие этого недостатка я спокоен.
Indemsys
Какое-либо промежуточное ПО планируется?
EasyLy Автор
Не совсем ясен вопрос.
В целом — внутренние разработки на микроконтроллерах, мы теперь делаем на базе своей ОС. Причём не везде нужно ядро, но драйверы нужны везде. Идея драйверов позаимствована у Константина Чижова и его библиотеки mcucpp. Результирующий код получается сверхоптимальным без каких-либо усилий со стороны прикладного программиста.