Здравствуйте!
Мной подготовлена серия статей, посвященных конкретной российской ОСРВ, одним из создателей которой я являюсь. Получилась своеобразная «Книга знаний», неформальное руководство для программиста, которое, надеюсь, поможет тем, кто эту ОСРВ использует.
Я расскажу об особенностях работы этой ОСРВ. Если о чём-то другом, то только потому, что без этого будут непонятны особенности.
Ниже я расскажу об особенностях ОСРВ вообще, и об особенностях ОСРВ МАКС в частности. Представлю ее архитектуру.
В дальнейшем я буду регулярно размещать новые публикации: вторая будет посвящена ядру системы, в последующих я представлю структуру простейшей программы, работающей под управлением ОСРВ МАКС с элементами кода, расскажу, как настроить ОСРВ МАКС для работы, затрону вопросы строгой типизации и драйверов.
Я, конечно, лицо аффилированное, поэтому, если пост перенесут в раздел «Я пиарюсь», то не очень обижусь. Но, с другой стороны, уже написан целый цикл статей, посвященный особенностям операционки, и было бы странно все их удалять-переносить. Тем более, что я старался максимально быть объективным и избежать рекламности.
Что такое операционные системы реального времени и особенности новой ОСРВ МАКС
Удивительно, но под термином «операционная система реального времени» многие понимают совсем не то, что надо. Они смотрят на термин «Операционная система» через призму тех ОС, с которыми им доводилось работать, а работать им доводилось на 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-м году, очень сложно бросить старые наработки. Проще сделать новую ОС. Чем, собственно, мы и занялись.
Кроме того, в ОСРВ МАКС заранее заложены функции прозрачного взаимодействия между изделиями, но этому будет посвящена отдельная статья.
Общие сведения об ОСРВ МАКС
Рассмотрим более подробно архитектуру ОСРВ МАКС. На рисунке приведена общая архитектура системы.
Приложение — это собственно программа пользователя.
Ядро осуществляет планирование и взаимодействие потоков программы пользователя друг с другом. Правда, слово «поток» было приведено для преемственности с понятиями из операционных систем общего пользования. В рамках ОСРВ МАКС они называются задачами. Поэтому правильнее будет сказать, что ядро осуществляет планирование и взаимодействие задач программы пользователя.
Если заняться совсем буквоедством, то следует писать не «ядро», а «микроядро». Функции у этих двух сущностей похожие, но в ядрах операционных систем общего пользования тысячи функций, а в микроядре — хорошо, если сотни, а может — даже десятки. Микроядро по своей структуре крайне простое.
Сервисы ОС отделены от ядра. По своей сути они являются библиотеками, которые унифицируют обращение программы пользователя к аппаратуре. Эти сервисы могут обращаться к ядру как обычные программы, а могут даже и не обращаться. В частности, драйверы нижнего уровня не имеют никакой зависимости от ядра ОС. В этом состоит отличие ОСРВ МАКС от операционных систем общего пользования, где драйверы являются частью ядра.
В следующей статье я расскажу про ядро ОСРВ МАКС и приоритет задач.
Автор: EasyLy
