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