Geum.ru

Операционные системы реального времени

Вид материалаДокументы
2.8. Ose rtos
Contiki [DGV04] разработана в Швеции (Swedish Institute of Computer Science) для систем с ограниченной памятью. Система Contiki
Рис. 9. Сердцевина Contiki и загруженные программы.
Подобный материал:
1   ...   7   8   9   10   11   12   13   14   ...   23

2.8. OSE RTOS


Операционная система реального времени OSE RTOS, разработанная в корпорации ENEA, имеет ядро с приоритетным планированием [OSERTOS]. Это ядро сильно оптимизировано для обеспечения высокой производительности и достаточно компактно для использования во встраиваемых системах. OSE имеет архитектуру, управляемую сообщениями, с простыми системными вызовами. Передача сообщений в OSE служит концептуальным шлюзом в распределенных многопроцессорных встраиваемых системах. Задачи посылают сообщения друг другу напрямую через ОС без поддержки очередей, почтовых ящиков или других промежуточных механизмов. OSE RTOS поддерживает подкачку, дублирование, динамическое обновление кода и многие коммуникационные протоколы.

OSE RTOS предлагает три варианта ядра, построенные по одному принципу. OSE Epsilon – для глубоко встраиваемой и SoC (system-on-chip) разработки. OSEck – компактное ядро для DSP. OSE Link Handler – для многочисленных смешанных CPU/DSP проектов. Все они поддерживают очень маленькое количество системных вызовов – от шести до восьми.

Архитектура OSE RTOS основана на многослойной модели (рис. 8).

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

OSE RTOS оперирует разными типами и категориями процессов.

Типы процессов:
  • Процессы прерываний возникают в ответ на аппаратные или программные прерывания, выполняются до конца, имеют самый высокий приоритет и такой же контекст, как и все другие процессы,
  • таймерные процессы прерывания аналогичны процессам прерываний, за исключением того, что они предусматриваются планировщиком периодически в соответствии с указанным периодом времени,
  • приоритетные процессы являются самыми распространенными процессами в OSE RTOS и выполняются до тех пор, пока не будут вытеснены процессом прерывания или процессом с более высоким приоритетом,
  • фоновые процессы выполняются строго в режиме циклического обслуживания с квантованием времени на приоритетном уровне, который находится ниже всех приоритетных процессов.



Рис.8. Многослойная архитектура OSE RTOS.

Под категориями процессов в OSE RTOS понимается разделение процессов на динамические и статические. Статические процессы создаются ядром, когда система стартует, и существуют на всем протяжении существования системы. Динамические процессы создаются и уничтожаются во время выполнения.

Источником потенциальных возможностей OSE RTOS является механизм прямой передачи сообщений. Сообщение, посланное одним процессом другому, содержит идентификатор, адреса отправителя и получателя и данные. Как только сообщение послано, отправитель уже не имеет к нему доступа, т.е. собственность сообщения никогда не разделяется. Это важное свойство исключает конфликты доступа к памяти. Прямая передача сообщений концептуально более проста, чем стандартная косвенная модель, а уникальная разработка такой передачи оказалась чрезвычайно эффективной.

2.9. Contiki


Операционная система Contiki [DGV04] разработана в Швеции (Swedish Institute of Computer Science) для систем с ограниченной памятью. Система Contiki позволяет динамически загружать и отгружать приложения и сервисы. С целью минимизации размеров операционной системы было спроектировано ядро Contiki, которое основано на модели управления событиями [HSW00].

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

Многопоточный режим с приоритетами в системе Contiki реализован с помощью библиотеки приложений, которые выполняются над ядром, управляемым событиями. Приложения, обеспечивающие многопоточную обработку, компонуются с выполняющимся приложением по мере необходимости, т.е. если оно явно требует многопоточной модели вычислений. Выполняющаяся система Contiki разделяется на две части – сердцевину (core) и загруженные программы. Сердцевина (core) состоит из собственно ядра (kernel), базовых сервисов и фрагментов библиотек поддержки, в том числе языковой поддержки времени выполнения. Разделяемая функциональность реализуется через сервисы как некоторая форма разделяемых библиотек. Эти сервисы можно обновлять или замещать динамически независимо друг от друга во время выполнения, что, по мнению разработчиков, ведет к гибкой структуре системы.

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

Системы, управляемые событиями, имеют свои проблемы. Модель программирования, управляемая состояниями, сложна для программистов. К тому же не все программы укладываются в конечно-автоматную модель.

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

Рис. 9. Сердцевина Contiki и загруженные программы.




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

Contiki написана на языке C и адаптирована для ряда микроконтроллерных архитектур, включая Texas Instruments MSP430 и Atmel AVR, а также для платформы ESB.