Курсовая работа: Реализация системы управления реального времени в ОС Windows
mov ecx, count
label: xchg eax,eax
loop label
Здесь параметр count определяет, сколько именно холостых циклов нужно выполнить, причем мы даже можем приблизительно предположить, сколько тактов центрального процессора на это уйдет.
Для приблизительного пересчета числа холостых циклов во временные интервалы при начальной инициализации драйвера выполняется порядка 108 холостых циклов с вычислением времени которое было затрачено на эту операцию. Далее необходимое число холостых циклов для организации задержки рассчитывается по следующей формуле:
,
где count 0 и time 0 соответственно количество холостых циклов и время на их выполнение при начальной инициализации драйвера, time — требуемая длина задержки.
3.3 Взаимодействие с драйвером
Управление параметрами работы драйвером производится при помощи следующей структуры:
struct ControlStruct
{ int Priority;
int Frequency;
int Delay;};
Поле Priority задает текущий приоритет рабочего потока драйвера (приоритет управляющего потока всегда 31). Поле Frequency задает частоту прихода данных от эмулируемого внешнего устройства. Поле Delay определяет длительность задержек на обработку данных от устройства.
Передача обновленной структуры из управляющего приложения в драйвер осуществляется следующим образом. Приложение открывает виртуальное устройство, ассоциированное с драйвером, а замет вызовом WriteFile передает в драйвер нужные данные.
Драйвер получает данные в своей функции DispatchWrite и сохраняет их в глобальной переменной, внося необходимые изменения в свою работу.
4. Исследовательская часть
4.1 Цели и задачи
Для того чтобы начать исследование, необходимо определиться, как будет использоваться полученное программное обеспечение в ходе его проведения, и каких результатов мы хотим добиться.
При помощи управляющего потока мы будем имитировать работу реального устройства на некоторой частоте. Начав с небольших частот мы попытаемся довести частоту до 1 кГц и добиться устойчивой работы на ней.
Следует также определиться с тем, что мы будем понимать под устойчивой работой. Поскольку речь идет о системе управление реального времени, то необходимо, чтобы к моменту прихода следующего запроса от устройства предыдущий был уже полностью обработан. Если по приходу запроса мы обнаружим что предыдущий запрос еще обрабатывается, мы будем считать что на данной частоте с данным временем задержки на используемой системе реализация системы управления реального времени невозможна.
4.2 Конфигурация тестового стенда
Исследования проводились на компьютере со следующей конфигурацией: AMD Duron 1000 MHz, EPoX 8KHA+ (VIA KT266A), 384 Mb DDR SDRAM. Файлы подкачки системы располагались на винчестерах Seagate Barracuda и Western Digital со скоростью вращения шпинделя 7200 об/мин, подключенными по интерфейсу IDE.
Операционная система, установленная на тестовой машине, Microsoft Windows XP Pro SP2. Система недавно переустанавливалась, работает стабильно.
4.3 Работа на небольших частотах
Начнем наше исследование с запуска драйвера на небольших частотах, а именно ограничимся частотой в 1 Гц и пронаблюдаем какие максимальные задержки мы сможем выставить сохраним стабильную работу драйвера.
Для простоты пока будем предполагать что кроме нашего драйвера система больше не загружена никакими ресурсоемкими приложениями. То есть в диспетчере задач более 95% процессорного времени приходится на псевдо-процесс Idle («Бездействие системы»). Приоритет рабочего потока выставим в значение 16.
Частота 1 Гц дает нам приход запросов от имитируемого устройства каждые 1000 мс. Изначально была выставлена задержка 100 мс. Это дает системе 900 мс на «накладные расходы», что позволило драйверу стабильно выполнить необходимые действия. На прикладном уровне работа драйвера без привлечения специальных средств не ощущалась.
Затем мы стали увеличивать длительность задержки. Значение было доведено до 990 мс (что дает системе 10 мс на обработку «накладных расходов»). При такой задержке стабильная работа драйвера сохранилась, однако на прикладном уровне серьезно ощущались «рывки» — система тратила 99% времени на обработку в драйвере.
Возможно, длительность задержки можно было еще увеличить, однако это было сделать довольно трудно, т.к. система плохо реагировала на действия пользователя. При значении задержки 1000 мс, как и следовало ожидать, стабильность работы драйвера нарушалась.
Еще нужно сказать о том, что если для частоты 1 Гц затраты на накладные расходы системы длиной в 10 мс можно считать нормальными, то на более высоких частотах (выше 100 Гц) это будет недопустимо большой паузой.
4.4 Точность изменения задержек
Далее по ходу исследования нам будет необходимо увеличивать частоту запросов и уменьшать длительность задержек. Не лишним будет по логу работы драйвера убедится, что выбранный нами способ организации задержек работает корректно. На рис 4.1 показан один из участков лога.