6.2Системные события

Все события принадлежат системе в целом, количество событий ограниченно (максимальное количество событий указано в вашем индивидуальном задании). События имеют идентификаторы SYS_EVENT_1, SYS_EVENT_2, … .

Каждая задача может ожидать одно или несколько из этих событий. Эти события задаются маской событий, которая является структурой данных типа TEventMask (реализуется разработчиком ОСРВ, используется в качестве типа входного параметра в сервисах ОСРВ, связанных с событиями - см. документ "Спецификация API"). Формирование маски осуществляется операцией add_mask. Например (маска на события 1 и 12):

TEventMask mask;

mask= SYS_EVENT_1 add_mask SYS_EVENT_12;

Маски:

1. В системе существует одна маска установленных событий.

2. Каждая задача имеет маску ожидаемых событий.

Задача, находящаяся в состоянии выполнения может начать ожидание событий задаваемых маской и перейти в состояние waiting (предыдущая маска ожидания должна быть сброшена). В состояние ready (возможно running) перейдут все задачи находившиеся в состоянии waiting, и ожидавшие хотя бы одно из произошедших событий. В маске ожидаемых событий каждой “дождавшейся” задачи признаки ожидания произошедших событий должны быть сброшены, признаки ожидания остальных событий должны быть оставлены. Признаки произошедших событий, ожидаемых хотя бы одной задачей (события которых «дождалась» хоть одна задача) в системной маске установленных событий должны быть сброшены до перехода задачи в состояние ready (возможно running).

Установка событий, не ожидаемых задачей, не должна приводить к изменению состояния задачи.

Если к моменту начала ожидания хоть одно из ожидаемых событий установлено состоянии задачи не должно измениться (то есть задача не переводится в состояние waiting и в этом случае не вызывается планировщик). При этом установленные системные признаки события должны быть очищены, маска ожидаемых событий должна быть изменена в соответствии с приведенными правилами.

Работа с системными событиями может осуществляться любой задачей.

7.Требования к api

В этой главе перечислены сервисы из "Спецификации API", которые должны поддерживаться проектами RTOS, выполняемыми в качестве индивидуальных заданий.

Сервисы, которые должны быть реализованы в каждом индивидуальном задании:

• DeclareTask

• ActivateTask

• TerminateTask

• StartOS

• SutdownOS

Управление ресурсами

Необходимо реализовать только те сервисы для управления ресурсами, которые соответствуют протоколу, указанному в вашем индивидуальном задании:

Протокол управления ресурсами	Сервисы, которые необходимо реализовать
HLP	DeclareResource, GetResource, ReleaseResource
PIP	InitRes, PIP_GetRes, PIP_ReleaseRes
P/V – семафоры	InitPVS, P, V

Управление событиями

Если в задание включена поддержка управления событиями, то необходимо реализовать следующие сервисы:

Если события принадлежат задаче:

• DeclareEvent

• SetEvent

• ClearEvent

• GetEvent

• WaitEvent

Для системных событий:

• DeclareSysEvent

• SetSysEvent

• GetSysEvent

• WaitSysEvent

Обработка прерываний

Данные сервисы необходимо реализовать, только если обработка прерываний включена в ваше индивидуальное задание.

• ISRActivateTask

• EnterISR

• LeaveISR

8.Дополнительные требования к ОСРВ

В этой главе приводятся дополнительные требования к ОСРВ, которые не были названы в предыдущих разделах.

8.1Системные требования к платформе

8.1.1Требования к аппаратуре

- Персональный компьютер на базе процессора x86 фирмы Intel

8.1.2Требования к ПО

- Операционная система семейства MS-DOS, Windows 9x или Windows NT фирмы Microsoft. - Компилятор языка C фирмы Borland версии 3.1 или 5.0

8.2

В виде исключения допускается использование других платформ. В этом случае платформа, а также способ проверки правильности выполнения работы должны быть согласованы с преподавателем и одобрены преподавателем до начала выполнения задания.

8.3Требования к языку программирования

Проект должен быть реализован на языке C. Использование языка C++ не допускается. Весьма желательно, чтобы исходный код удовлетворял стандарту ISO/ANSI C. Желательно также исключить использование ассемблера (как внешнего, так и встроенного) с целью повышения переносимости продукта с одной платформы на другую.

8.4Требования к файловой структуре проекта

Рекомендуется следующее распределение модулей ОС по файлам проекта:

Файл	Что содержит
global.c	Описание всех глобальных переменных проекта
int.c	Модуль поддержки ISR (если это задано в индивидуальном задании)
os.c	Модуль, предназначенный для управления ОС
resource.c	Модуль, предназначенный для управления ресурсами
task.c	Модуль, предназначенный для управления задачами
event.c	Модуль, предназначенный для управления событиями (если это задано в индивидуальном задании)

Тем не менее, соблюдение этих рекомендаций не является обязательным. Можно, например, поместить весь полезный код операционной системы в один файл os.c, а остальные оставить пустыми.

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

Для организации взаимодействия модулей операционной системы между собой можно использовать любое количество заголовочных файлов. Их названия и содержимое не регламентируется.

1 Это состояние необходимо реализовать только в проектах с управлением событиями.

2 Вызов диспетчера необходим не во всех случаях. Необходимость вызова диспетчера при захвате/освобождении ресурса зависит от протокола управления ресурсами и определяется тем был ли измены приоритеты задач при вызове планировщика или нет.

3 Вызов диспетчера необходим если флаги нужных задаче событий не установлены и задача переводится в состояние ожидания.