1. Введение: Особенности операционных систем реального времени




страница6/10
Дата20.04.2017
Размер1.03 Mb.
Просмотров1245
Скачиваний0
1   2   3   4   5   6   7   8   9   10
ITRON предлагает спецификации для стандартного ядра реального времени, которое с незначительными настройками могло бы выполняться на различных устройствах. Согласно оценкам японской прессы от трех до четырех биллионов микропроцессоров работают под ОС ITRON.
Несмотря на эту популярность, ОС ITRON имеет большой дефект. Широкие возможности по модификации ОС ITRON, данные разработчикам для того, чтобы они могли подогнать спецификации ядра под свои требования, основано на концепции “слабой стандартизации”. Слабая стандартизация приводит к большим трудностям в создании унифицированной среды разработки ОС
ITRON.
При проектировании спецификаций ITRON учитывались следующие технические требования к спецификациям ОСРВ для встроенных систем:

извлекать максимальную производительность из аппаратуры,

способствовать улучшению эффективности программного обеспечения,

обеспечивать масштабируемость некоторого набора систем.
Для того, чтобы спецификации ITRON удовлетворяли этим требованиям, они проектировались в соответствии со следующими принципами:

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

Учитывать адаптируемость к приложениям. Адаптация к приложению означает изменение спецификаций ядра и внутренних реализационных методов, опирающихся на функции ядра и производительность, требуемую приложением, приводящее к возрастанию производительности всей системы в целом. В случае встроенной системы, объектный код ОС генерируется отдельно для каждого приложения, таким образом, адаптация к приложению работает особенно хорошо (рис. 13). При проектировании спецификаций
ITRON такая адаптация сопровождается обеспечением независимости функций ядра друг от друга, насколько это возможно, тем самым разрешая каждому приложению выбрать только те функции, которые ему необходимы. На практике это выражается в том, что большинство µITRON-спецификационных ядер поставляются в библиотечном формате. Каждый системный вызов обеспечивается единственной функцией, что позволяет легко встраивать только необходимые функции.

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

Организация спецификаций в серии и разделение на уровни. Для того, чтобы обеспечить адаптацию к широкому многообразию аппаратуры, спецификации организуются в серии и подразделяются на уровни.
Например, спецификация µITRON (версия 2.0) была создана, главным образом, для использования в системах с 8- или 16-битовых MCU, в то время как спецификация ITRON2 предназначена для 32-битовых процессоров. Каждая спецификация далее разбивается на уровни, основанные на степени востребованности каждой функции. При реализации ядра соответствующий уровень выбирается на основе предназначения приложений и требуемых для них функций.
Последняя реализованная спецификация µITRON3.0 подразделяет системные вызовы на три уровня, что дает возможность этой одной спецификацией покрывать диапазон от маломасштабных до крупных

55 процессоров.
Спецификации для распределенных и многопроцессорных систем также могут быть стандартизованы с помощью серий ITRON-спецификаций.

Обеспечивать широкий набор функциональностей. Примитивы ядра не ограничиваются малым количеством функций, напротив, они покрывают широкий диапазон разнообразных возможностей.
Выбирая примитивы, которые хорошо подходят для данного типа приложения и аппаратуры, системные разработчики смогут быстро и легко создавать программы, обеспечивающие высокую производительность времени выполнения.
Из доступных версий спецификаций ITRON самой последней является спецификация µITRON4.0. Рассмотрим ее подробно.
Под термином “задача” в системе ITRON понимается единица параллельной обработки. Переключение выполнения с одной задачи на другую называется диспетчеризацией. Процесс выбора следующей задачи для выполнения называется планированием.
Рис. 13. Адаптация в спецификации µITRON.
Система ITRON оперирует следующими понятиями для описания состояния
задач:

Выполняющаяся (running),

Готовая к выполнению (ready),

Блокированная (bloked) o
Ждущая (waiting) – ожидается выполнение каких-либо условий, o
Приостановленная (suspended) – остановлена другой задачей или самой собой,
56 o
Ждущая-приостановленная (waiting-suspended) – ожидаются условия, и приостановлена,

Спящая (dormant) – еще не выполнялась или уже завершилась,

Несуществующая (non-existent) – не существует в системе, или и не создавалась, или уже уничтожена.
Планирование задач основано на приоритетах, присвоенных задачам, и является вытесняющим (preemptive). Совокупность задач с одинаковым приоритетом обслуживается по принципу – “первый пришел, первым обслужен” (FCFS – first come, first served).
Управление задачами. Функции управления задачами включают создание и уничтожение задачи, активацию и завершение задачи, отмену запросов на активацию и получение информации о состоянии задачи. Задача является объектом с уникальным идентификатором (ID).
Обработка прерываний. В спецификации µITRON4.0 обработка внешних прерываний описывается с помощью обработчиков прерываний (interrupt handlers) и программ обслуживания прерываний (interrupt service routines).
Обработчики прерываний управляют устройствами IRC (Interrupt Request
Controller) и зависят от архитектуры прерываний процессора. Они не могут быть переносимыми на другие платформы без изменений. Программы обслуживания прерываний запускаются обработчиками прерываний, и были введены в спецификации µITRON4.0 для улучшения переносимости обработки прерываний.
Спецификация µITRON4.0 определяет интерфейсы приложения для регистрации обработчика прерываний и интерфейсы приложения для программы обслуживания прерываний. Реализация должна обеспечивать либо один набор интерфейсов, либо оба. Если обеспечиваются интерфейсы только для регистрации обработчика прерываний, ядро может обеспечить связующую программу для обработчика прерываний, которая включает процессы, запускающиеся до и после выполнения обработчика прерываний. Если обеспечиваются интерфейсы только для регистрации программы обслуживания прерываний, ядро должно обеспечить для этой программы обработчик прерываний. Поведение системы с использованием обоих интерфейсов определяется реализацией.
Ядро не управляет прерываниями с приоритетами выше порогового приоритетного уровня. Такие прерывания называются неядерными прерываниями. Метод определения порогового приоритетного уровня определяется реализацией. Из обработчиков прерываний, запущенных неядерными прерываниями, нельзя сделать сервисный вызов (вызов функции ядра или программного компонента).
В спецификации µITRON4.0 существует два способа для указания прерывания
– с помощью номера прерывания и через номер обработчика прерывания. К тому же программа обслуживания прерывания идентифицируется уникальным идентификатором объекта (ID).

57
Управление исключительными ситуациями. Спецификация µITRON4.0 определяет управление исключительными ситуациями центрального процессора (CPU) и функции управления исключительными ситуациями на уровне задач.
Обработчик исключительных ситуаций CPU запускается, когда процессор обнаруживает исключительную ситуацию. Обработчик исключительных ситуаций CPU может быть зарегистрирован приложением для каждого вида исключительной ситуации CPU. Ядро может обеспечивать связующую программу (glue routine) для обработчика исключительной ситуации CPU, которая включает процессы, запускаемые до и после выполнения обработчика исключительной ситуации CPU.
Поскольку обработчики исключительных ситуаций CPU являются общими для всей системы, контекст и состояние в точке возникновения исключительной ситуации CPU исследуются самим обработчиком исключительной ситуации
CPU. Если исключительная ситуация CPU возникает в задаче, обработчик исключительной ситуации CPU может позволить провести обработку этой исключительной ситуации соответствующей программе задачи.
Функции управления исключительными ситуациями задачи используются для остановки нормального выполнения задачи и запуска программы управления исключительной ситуации задачи, которая выполняется в контексте данной задачи. После возвращения из этой программы будет продолжено прерванное выполнение задачи. Приложение может зарегистрировать одну программу управления исключительными ситуациями для каждой задачи.
Обработчик исключительных ситуаций CPU определяется реализацией, поскольку сильно зависит от архитектуры управления исключительными ситуациями и реализации ядра. Он не переносим на другие платформы.
Сервисные вызовы, которые могут быть встретиться в обработчике исключительных ситуаций CPU, определяются реализацией. Однако, обработчик исключительных ситуаций CPU должен выполнять следующие операции (метод выполнения определяется реализацией):

Читать контекст и системное состояние при возникновении исключительной ситуации CPU. Ядро должно обеспечивать метод ссылки к информации о системном состоянии.

Читать ID задачи, в которой возникла исключительная ситуация
CPU.

Запросить управление исключительными ситуациями задачи.
Контекст и системное состояние. В спецификации µITRON4.0 ядро управляет выполнением следующих единиц обработки:

Обработчики прерываний. o
Программы обслуживания прерываний.

Обработчики временных событий.

Обработчики исключительных ситуаций CPU.

Программы расширенных сервисных вызовов.
58

Задачи. o
Программы управления исключительными ситуациями задачи.
Обработчики прерываний и программы обслуживания прерываний выполняются в своих собственных независимых контекстах.
Обработчики временных событий запускаются по временному триггеру и выполняются в своих собственных независимых контекстах. Рассматриваются три вида обработчиков временных событий – циклические, аварийные и по переполнению.
Обработчики исключительных ситуаций CPU выполняются в независимом контексте, определяемом исключительной ситуацией CPU и контекстом, в котором она возникла.
Программы расширенных сервисных вызовов регистрируются приложением и запускаются расширенными сервисными вызовами. Программа расширенного сервисного вызова выполняется в независимом контексте, определяемом расширенным сервисным вызовом и контекстом, из которого произошел этот вызов.
Задачи выполняются в своих собственных независимых контекстах.
Программа управления исключительными ситуациями задачи выполняется в ассоциированном контексте задачи.
Процессы ядра не классифицируются как единицы обработки, упомянутые выше. Процессы ядра включают выполнение сервисных вызовов, диспетчер, связующие программы для обработчиков прерываний (или программ обслуживания прерываний), связующие программы для обработчиков исключительных ситуаций CPU. Контекст выполнения процессов ядра никак не влияет на поведение приложения.
Предшествование выполнения каждой единицы обработки специфицируется следующим образом:
1.
Обработчики прерываний, обработчики временных событий, обработчики исключительных ситуаций CPU
2.
Диспетчер (процесс ядра)
3.
Задачи
Предшествование в первой группе определяется реализацией. Относительное предшествование задач определяется с помощью правил планирования.
Сервисные вызовы ядра, главным образом, выполняются атомарно, и состояние действующих процессов сервисных вызовов скрыто. Однако реализация может изменить это положение, чтобы улучшить реакцию системы.
В этом случае операция сервисного вызова должна все же выполняться атомарно, насколько приложение может определить использование сервисного вызова. Такое поведение называется гарантией атомарности сервисного вызова. Однако иногда это трудно гарантировать при поддержке высокого уровня реакции с реализационно-специфическими функциями, которые не

59 покрывает данная спецификация. В таком случае разрешается ослабление атомарности сервисного вызова.
При атомарном выполнении сервисных вызовов их предшествование является самым высоким. При ослаблении атомарности предшествование сервисных вызовов становится реализационно-зависимым до тех пор, пока их предшествование выше приоритета единицы обработки, вызвавшей эти сервисные вызовы.
Другие процессы ядра, такие как диспетчер и связующие программы для обработчиков прерываний и исключительных ситуаций обрабатываются аналогично.
Состояние CPU может быть блокированным или разблокированным. В спецификации µITRON4.0 блокированное состояние CPU рассматривается как состояние, независимое от прерываний и диспетчеризации задач. В блокированное состояние CPU могут быть вызваны только несколько сервисных вызовов.
В заблокированном состоянии обработчики прерываний (за исключением тех, которые были запущены неядерным прерыванием) и обработчики временных событий не запускаются и диспетчеризация не совершается. Блокированное состояние CPU можно рассматривать как состояние, в котором предшествование выполняющейся единицы обработки является наивысшим. Возможно существование и промежуточного состояния, которое не является ни блокированным, ни разблокированным, – такая реализация тоже имеет место.
Состояние CPU после запуска обработчика прерывания является реализационно-зависимым. Однако, как попасть в разблокированное состояние, определяется реализацией обработчиков прерываний. Реализация определяет также, как корректно вернуться из обработчиков прерываний после того, как система перешла в разблокированное состояние. Поведение не определено, если обработчики прерываний не делают возврат так, как специфицировано в реализации.
После запуска программ обслуживания прерываний и обработчиков временных событий система переходит в разблокированное состояние. При возврате из них, система также должна быть в разблокированном состоянии.
Поведение не определено, если система после возврата из них оказалась в блокированном состоянии.
Запуск и возврат из обработчиков исключительных ситуаций CPU не изменяют состояния CPU. Если состояние изменяется в обработчике исключительной ситуации CPU, его следует возвращать в предыдущее состояние перед возвратом из обработчика. Поведение не определено, если это не совершается.
Запуск и возврат из программ расширенных сервисных вызовов не изменяют состояния CPU.
После запуска задачи система находится в разблокированном состоянии. После ее окончания система должна быть в разблокированном состоянии. Поведение не определено, если задача закончилась, а система в блокированном состоянии.
60
Запуск и возврат из программ управления исключительными состояниями задачи не изменяют состояния CPU. Однако не специфицируется, в каком состоянии были запущены программы управления исключительными состояниями задачи. После возврата из программы, состояние CPU остается тем же самым, как установлено программой.
Прерывания обычно (но не всегда) разрешены в разблокированном состоянии
CPU.
Диспетчеризация может пребывать в двух состояниях – разрешенном или запрещенном. В запрещенном состоянии диспетчеризация не совершается.
Запрещенное состояние диспетчеризации может рассматриваться как состояние, в котором предшествование выполняющейся единицы обработки выше, чем у диспетчера. Реализация может допускать существование промежуточного состояния.
Переход к запрещенному состоянию диспетчеризации называется “отключение диспетчеризации”, переход к разрешенному состоянию диспетчеризации называется “включение диспетчеризации”.
В запрещенном состоянии диспетчеризации сервисные вызовы, которые могут быть вызваны из контекста задачи, имеют следующие ограничения. Если вызванный в запрещенном состоянии диспетчеризации сервисный вызов привел к тому, что вызвавшая его задача перешла в блокированное состояние, поведение не определено, если не специфировано иное. Сервисные вызовы, вызванные из незадачного контекста, не имеют ограничений даже в запрещенном состоянии диспетчеризации.
Запуск и возврат из обработчиков прерываний, программ обслуживания прерываний, обработчиков временных событий и исключительных ситуаций
CPU не изменяют состояния диспетчеризации. Поведение не определено, если при возврате из этих обработчиков/программ состояние диспетчеризации не возвращается в предыдущее состояние.
Запуск и возврат из программ расширенных сервисных вызовов не изменяют состояния диспетчеризации.
После запуска задачи систем находится в разрешенном состоянии диспетчеризации. После окончания задачи система должна быть в разрешенном состоянии диспетчеризации. Поведение не определено, если задача заканчивается в запрещенном состоянии диспетчеризации.
Запуск и возврат из программ управления исключительными состояниями задачи не изменяют состояния диспетчеризации.
Состояние диспетчеризации рассматривается независимо от состояния CPU.
В спецификации µITRON4.0 не существует сервисных вызовов в незадачном контексте, которые изменяют состояние диспетчеризации. Следовательно, невозможно изменить состояние диспетчеризации внутри обработчиков прерываний и временных событий, если это не обеспечивается реализационно- специфическим расширением. Эти правила распространяются и на

61 обработчики исключительных ситуаций CPU, когда они выполняются в незадачном контексте.
Диспетчеризация не производится во время выполнения единицы обработки с более высоким предшествованием, чем у диспетчера, в заблокированном состоянии CPU или в запрещенном состоянии диспетчеризации. Эти три состояния называются состоянием задержки диспетчеризации. Состояние задачи во время задержки диспетчеризации можно изменить только с помощью реализационно-специфических расширений. Такие расширения могут делать сервисные вызовы из незадачного контекста, что позволит перевести задачу из состояния
“выполняющаяся” в состояние
“приостановленная” или “спящая”. Кроме того, расширения могут позволять сервисным вызовам выводить задачу из состояния “приостановленная” в запрещенном состоянии диспетчеризации.
Если задачу в состоянии “выполняющаяся” нужно перевести в состояние
“приостановленная” или “спящая”, переход задерживается до тех пор, пока система не выполнит диспетчеризацию. Во время этой задержки считается, что выполняющаяся задача находится в промежуточном состоянии. Интерпретация задачи в этом промежуточном состоянии зависит от реализации. Задача, которая должна поступить следующей на выполнение, остается в состоянии
“готова” до тех пор, пока не произойдет диспетчеризация.
Сервисные вызовы классифицируются согласно следующим трем категориям:

Сервисные вызовы для незадачных контекстов.

Сервисные вызовы, которые могут быть вызваны из любых контекстов.

Сервисные вызовы для задачных контекстов.
Выполнение сервисных вызовов из незадачных контекстов может быть отложено до тех пор, пока не закончится выполнение единиц обработки с более высоким предшествованием, чем у диспетчера. Это позволяет гарантировать атомарность системных вызовов без запрещения прерываний на слишком долгое время. Такой подход называется отложенным выполнением сервисных вызовов. Однако, существует группа сервисных вызовов, для которых не разрешается откладывать их выполнение.
В спецификации µITRON4.0 специфицируется также процедура инициализации системы, а также процедуры регистрации объектов и их уничтожения. Объект идентифицируется уникальным идентификатором и регистрируется ядром с помощью статического вызова некоторого метода интерфейса приложения или сервисного вызова, которые создают этот объект.
Спецификации µITRON4.0 специфицируют формат написания на языке C следующих единиц обработки: программ обслуживания прерываний, обработчиков временных событий, программ расширенных сервисных вызовов, задач и программ управления исключительными ситуациями задачи.
Однако не специфицируется формат написания единиц обработки на языке ассемблера. Формат для написания обработчиков прерываний, обработчиков исключительных ситуаций CPU и атрибутов объектов, которые используются
62 для их регистрации в ядре, определяются реализацией и не специфицируется в спецификации µITRON4.0.
Приложения могут использовать константы и макросы, описывающие конфигурацию ядра, с целью улучшения переносимости приложений. Метод, который используется для определения констант и макросов конфигурации ядра, является реализацинннно-зависимым. Обычно они определяются в заголовочных файлах ядра или могут быть сгенерированы конфигуратором.
Как альтернатива, они могут быть определены в заголовочных файлах приложения и затем использованы для конфигурации ядра.
3.2. Windows CE
Системы семейства Microsoft Windows CE [WinCE] являются открытыми, масштабируемыми ОС, позволяющими компоновать ОС для широкого диапазона современных небольших устройств, которые соединяют в себе компьютерные, телефонные и сетевые возможности. Устройство, на которое может быть установлена Windows CE, обычно проектируется для специализированного использования, часто работает автономно и требует маленькой ОС, которая имеет детерминированные реакции на прерывания.
Последней версией из этого семейства является система Microsoft Windows CE
5.0, в которой объединены возможности систем реального времени и последние технологии Windows. По сравнению с другими ОСРВ Windows CE
проектировалась так, чтобы она была совместимой с универсальными ОС.
ОСРВ Windows CE является модульной с небольшим ядром и необязательными модулями, которые выполняются как независимые процессы.
Планирование в Windows CE осуществляется на основе приоритетов.
Поддерживается защита ядра и процессов друг от друга. Кроме того, возможен режим работы, когда отсутствует защита между процессами и ядром. Следует отметить, что прерывания выполняются как потоки и имеют уровни прио- ритетов потоков. Windows CE поддерживает также нити (fiber), являющиеся потоками, которыми ядро не управляет. Каждая нить выполняется в контексте потока, который ее создал, ее можно использовать для создания планировщика внутри потока. Такие нити используются в экзотических или унаследованных приложениях, но они непригодны в системах реального времени.
Windows CE имеет ограничение на физическую память – 512MB. Microsoft ввел это ограничение для того, чтобы Windows CE могла выполняться на большом диапазоне встраиваемых процессоров без проблем совместимости, поскольку некоторые из этих процессоров способны управлять физической памятью в 512MB. Однако физическая память может быть отображена в адресные регионы, размер которых превышает 512MB.
RAM в устройстве Windows CE разделяется на две области – хранилище объектов и программная память. Хранилище объектов напоминает постоянный виртуальный диск RAM. Данные в таком хранилище запоминаются во время приостановки или операции частичной переустановки (soft reset). Когда операция возобновляется, система находит ранее созданное хранилище объ-

63 ектов и использует его. Программная память состоит из оставшейся RAM, она работает как RAM в персональном компьютере – запоминает стеки и области для динамически выделяемой памяти (heaps) выполняющихся приложений.
Во время старта

Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал