FX-RTOS: компонентная ОС для встраиваемых систем
Вслед за развитием электроники, встраиваемые системы получили большое распространение в современном мире. Большое разнообразие задач и требований, предъявляемых к этим системам, определило также и большой выбор встраиваемого ПО. В отличие от серверов и настольных компьютеров, в мире встраиваемых систем требования для разных устройств могут изменяться вплоть до противоположных: одним устройствам требуется работа в жестком реальном времени, другим - как можно меньшее энергопотребление (возможно, в ущерб всем остальным характеристикам), третьим - как можно меньший объем потребляемых ресурсов, для возможности использования более дешевых процессоров. Важнейшим компонентом встраиваемой системы является ОС. В большинстве случаев она имеет вид статической библиотеки и реализует вытесняющую многозадачность и обработку прерываний. Было написано немало литературы на тему "необходимо ли вообще использовать какую-либо ОС во встраиваемых системах?", поэтому подробно этот вопрос в настоящей статье рассматриваться не будет, однако можно вкратце перечислить преимущества использования ОС: абстракция оборудования (перенос приложения на другие аппаратные платформы без изменений, что обеспечивает гибкость в выборе аппаратного обеспечения и независимость от конкретной архитектуры/производителя), использование проверенного решения сокращает сроки вывода продукта на рынок и менее подвержено ошибкам, и т.д. В отличие от настольных и серверных ОС, которые определяют интерфейс для приложений и требуют, чтобы приложение работало в соответствии с требованиями ОС, в мире встраиваемых систем дело обстоит с точностью до наоборот: т.к. устройство обычно предназначено для выполнения какой-то определенной функции, и его встраиваемое ПО изначально рассчитано на реализацию этой функции, то в данном случае не приложение должно соответствовать ОС, а наоборот, ОС должна идеально соответствовать требованиям именно данного конкретного приложения. Это означает, что ОС не должна содержать никакого избыточного функционала, который не будет использоваться в данном устройстве, не должна содержать дополнительных накладных расходов, и в то же время соответствовать тем же требованиям, которым соответствует приложение, например требованиям жесткого реального времени, а также использоваться совместно с теми инструментами (компилятор, IDE, отладчик и т.д.), с помощью которых разрабатывается приложение.
Так же как и приложение, ОС является обычной программой, поэтому достаточно трудно разработать ее так, чтобы она могла соответствовать всем требованиям, включая те, которые могут быть даже неизвестны на этапе ее разработки. Поэтому в настоящее время существуют десятки и сотни встраиваемых ОС, каждая из которых предназначена для использования в определенном классе устройств с определенными требованиями. Многие из них реализуют т.н. "компонентную модель": программная платформа для приложений состоит из нескольких компонентов, таких как, собственно ядро ОС, стеки коммуникационных протоколов, реализация файловой системы и т.д., что позволяет задавать конфигурацию системы на уровне этих компонентов, исключая неиспользуемые и задавая параметры используемым. Разрабатываемая компанией Eremex ОС FX-RTOS является дальнейшим развитием идеи компонентно-ориентированного ПО с распространением принципов "компонентности" на само ядро ОС. Если в таких системах как eCos или MQX ядро является неделимым компонентом, среди множества других компонентов, в FX-RTOS нет четко определенного понятия "ядра": необходимый функционал составляется из более мелких "кирпичиков". Нельзя сказать, что эта идея нова, уже не один десяток лет существуют библиотеки, и ничто не мешает разделить на отдельные компоненты любой код, в том числе и ядро ОС, однако такой подход до сих пор во встраиваемых системах применялся редко, потому что использование баблиотек содержит накладных расходы времени выполнения. Подход FX-RTOS отличается тем, что используются компоненты уровня исходных текстов. То есть "компонентность" как таковая не несет никаких накладных расходов, а конфигурирование выполняется путем "внедрения зависимостей".
Компоненты FX-RTOS ничего не знают ни о структуре проекта, ни друг о друге, не привязаны к системе сборке и к структуре директорий исходных текстов. Такая модель конфигурирования позволяет масштабировать ОС в очень широких пределах. Например, FX-RTOS позволяет запустить 3-5 потоков на 16-битном контроллере TI MSP430 FR5739, который содержит всего 1Кб оперативной памяти. В этом объеме содержатся данные ОС, данные приложения, стеки потоков и стек прерываний, стек одного потока имеет размер порядка 150-200 байт. В то же время существует версия FX-RTOS работающая на многоядерных процессорах семейства ARM Cortex-A. При этом используются все вычислительные ядра, возможна миграция потоков между ядрами по запросу, балансировка нагрузки и т.д. ОС при этом не содержит никаких глобальных блокировок, то есть производительность не деградирует с ростом числа ядер и приложения работающие на разных ядрах не влияют друг на друга. Эти системы принципиально различаются по своей внутренней структуре и механизмам синхронизации, однако API, предоставляемое пользователю, остается неизменным и подобная масштабируемость достигается путем замены компонентов ядра ОС с сохранением внутренних интерфейсов. Отдельным вопросом является вопрос производительности. Хотя компонентно-ориентированная модель разработки ПО содержит некоторые накладные расходы из-за небходимости поддерживать постоянными интерфейсы внутри ядра ОС, принцип замены частей ОС на те, которые идеально соответствуют решаемой задаче, позволяет добиться лучшей производительности, чем в случае "статического" ядра. Можно привести следующий пример: алгоритмы имеют определенную асимптотическую сложность, как правило, улучшение асимптотических характеристик связано с усложнением алгоритма. Например, некоторые операции работы со списком (вроде поиска или вставки элемента в упорядоченный список) имеют сложность O( n): при росте количества элементов, время, затрачиваемое на работу алгоритма растет линейно, и при большом количестве элементов список становится неэффективной структурой. Можно использовать дерево, например красно-черное или AVL, которые имеют сложность O(log n), однако преимущество дерева над списком начнет проявляться только с некоторого N, так как сбалансированные деревья - довольно сложные структуры данных требущие относительно большого (по сравнению со списком) объема кода. Поэтому ни один алгоритм не может обеспечить идеальную производительность для всех возможных случаев, решить данную проблему можно только с помощью конфигурирования и дополнительного знания о том, в каких условиях системе предстоит работать. Для оценки производительности ОС использовался тест Preemptive scheduling test или пакета Thread Metrics, разработанного компанией Express logic (www.rtos.com. Этот тест создает 5 нитей, имющих разный приоритет. Затем наименее приоритетная нить увеличивает свой счетчик итераций, после чего активирует более высокоприоритетную нить, которая делает то же самое с еще более приоритетной нитью и т.д.
while(1)