Драйвер клавиатуры реализующий функции музыкального синтезатора на клавиатуре для Windows NT 5 (стр. 1 из 8)
Факультет информатики и систем управления
Кафедра ПО ЭВМ и информационные технологии
РАСЧЕТНО-ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к курсовой работе на тему:
Драйвер клавиатуры, реализующий функции музыкального синтезатора на клавиатуре для Windows NT 5
Содержание
1. Введение
2. Конструкторский раздел
2.1 Постановка задачи
2.2 Архитектура Windows NT 5
2.3 Драйверная модель WDM
2.3.1 Функции загрузки/выгрузки драйвера
2.3.2 Функции обработки запросов/прерываний
2.4 Приоритеты выполнения программного кода
2.5 Стек клавиатуры
2.6 Kernel Streaming
2.7 Описание формата MIDI-данных
2.8 Выбор структуры программного обеспечения
2.8.1 Драйвер-фильтр
2.8.2 Получение доступа к аудиоустройству
2.8.3 Взаимодействие компонент программного обеспечения
2.9 Алгоритм работы драйвера-фильтра
2.9.1 Функции загрузки/выгрузки драйвера
2.9.2 Функции обработки пакетов IRP
2.9.3 Функции работы с аудио-устройством
2.9.4 Схема хранения музыкальных параметров клавиш
2.9.5 Разделение задачи на потоки
3. Технологический раздел
3.1 Выбор средств разработки программного обеспечения
3.2 Установка драйвера в системе
3.3 Сборка программного обеспечения
3.4 Использование библиотеки DirectKS
3.5 Отправление запросов из приложения в драйвер
3.6 Описание интерфейса пользователя
3.7 Тестирование программного обеспечения
4. Заключение
5. Список литературы
6. Приложения
6.1 Функции установки драйвера в системе
6.2 Изменения в библиотеке DirectKS
1. Введение
В современных вычислительных системах важнейшую роль играет подсистема ввода/вывода. Известно, что примерно 80% инструкций программы связаны с этой подсистемой. В связи с этим в настоящее время возрастает актуальность разработки программных систем, осуществляющих взаимодействие с периферийными устройствами посредством подсистемы ввода/вывода.
Данное программное обеспечение позволяет организовать настраиваемое звуковое сопровождение нажатий клавиш на клавиатуре. Существует множество вариантов его применения, среди которых можно выделить следующие:
Упрощение работы с компьютером людям со слабым зрением.
Создание MIDI-синтезатора на клавиатуре.
Создание системы звуковой сигнализации.
В стандартную поставку ОС Microsoft Windows XP Professional входят компоненты, обеспечивающие специальные возможности операционной системы для пользователей с различными отклонениями в здоровье. Среди этих компонент следует отметить:
«Экранную клавиатуру», с помощью которой, в частности, можно озвучить выбор клавиш мышью.
Возможность озвучивания нажатий клавиш Num, Caps и Scroll Lock.
Характерной особенностью вышеперечисленных компонент является подача сигнала одной частоты независимо от нажатой клавиши и невозможность настройки параметров звучания. В этой связи представляется целесообразной разработка нового программного обеспечения, позволяющего организовать звуковое сопровождение клавиатуры в более полном объеме, в частности, настраивать выборочное озвучивание клавиш.
2. Конструкторский раздел
2.1 Постановка задачи
В соответствии с заданием на курсовую работу необходимо разработать программное обеспечение для решения следующих задач:
Вывод музыкальных нот с заданными параметрами при нажатии клавиш.
Возможность настройки пользователем параметров звучания клавиш.
Программное обеспечение состоит из двух взаимодействующих частей:
Драйвер-фильтр, реализующий первую задачу.
Программа настройки, реализующая вторую задачу.
Требования к программному обеспечению:
Драйвер-фильтр должен отслеживать нажатия всех клавиш клавиатуры PS/2 и генерировать музыкальные ноты с соответствующими клавише параметрами.
Программа настройки должна позволять пользователю редактировать параметры звучания клавиш, предоставляя удобный интерфейс.
В качестве устройства для вывода музыкальных нот используется синтезатор MIDI, встроенный в звуковую карту Sound Blaster.
Приоритетным критерием при разработке продукта является производительность для драйвера-фильтра и удобство пользователя для программы настройки.
Программное обеспечение ориентировано на работу в ОС Windows NT 5. Функционирование программного обеспечения не должно влиять на работу других драйверов системы.
2.2 Архитектура Windows NT 5
Архитектура Windows NT 5 соответствует классическим представлениям о проектировании операционных систем. Наиболее распространены реализации данной ОС для платформы Intel x86 в одно- или многопроцессорных конфигурациях, однако существуют также версии для DEC Alpha и MIPS. Windows NT 5 использует защищённый режим центрального процессора, реализует механизмы виртуальной памяти и многозадачности.
Исполняемый код в Windows NT 5 имеет два уровня привилегий: код пользовательского режима и код режима ядра. Уровень привилегий накладывает определённые ограничения: в пользовательском режиме не могут выполняться привилегированные инструкции процессора, не разрешено обращение к защищённым страницам памяти. Эти ограничения накладываются для обеспечения безопасности работы системы. Пользовательское приложение не должно иметь возможность в результате ошибки или преднамеренно вносить изменения в критические таблицы операционной системы или в память других приложений. В частности, такие ограничения запрещают пользовательскому приложению напрямую управлять внешними устройствами, потому что каждое из них является разделяемым ресурсом.
В Windows NT 5 обеспечение обмена данными и управление доступом к внешнему устройству как к разделяемому ресурсу возлагается на его драйвер. Ввод и вывод в драйверах осуществляется посредством IRP-пакетов (Input/Output Request Packet). Запросы на ввод/вывод, посылаемые приложениями или другими драйверами, обрабатываются драйвером, после чего запрашивающей программе в том же пакете посылается статус завершения операции. Общий принцип взаимодействия проиллюстрирован на рис. 2.1.
Рис.2.1. Архитектура ввода/вывода Windows NT 5
Управление внешним устройством в общем случае сводится к заполнению его регистров необходимыми данными. Монопольный доступ драйвера к этим регистрам гарантируется операционной системой. Очевидно, что при данных обстоятельствах требуется, чтобы драйвер устройства выполнялся в режиме ядра.
Обобщённая классификация драйверов Windows NT 5 может быть представлена следующим образом:
Драйверы режима ядра:
Унаследованные драйверы
Драйверы файловой системы
Видеодрайверы
Драйверы PnP (Plug And Play):
Драйверы WDM
Драйверы пользовательского режима:
Драйверы виртуальных устройств
2.3 Драйверная модель WDM
Windows Driver Model (WDM) — это стандартная спецификация Microsoft для разработчиков драйверов устройств. Она поддерживается в операционных системах Windows 98/Me/2000/XP. Компания Microsoft требует, чтобы все новые драйверы под эти операционные системы создавались по этой спецификации. Для этого от них требуется чёткое следование структуре WDM, поддержка Plug and Play и управления электропитанием.
Драйверная модель WDM построена на организации и манипулировании слоями объектов физических устройств (PDO, Physical Device Object) и объектов функциональных устройств (FDO, Functional Device Object).
Объект PDO создается для каждого физически идентифицируемого элемента аппаратуры, подключенного к шине данных, и подразумевает ответственность за низкоуровневый контроль, достаточно общий для набора функций реализуемых этим аппаратным элементом. Объект PDO – это особая структура данных, создаваемая системой для взаимодействия программного и аппаратного обеспечения.
Объекты FDO подразумевает единицу логической функциональности устройства.
Объектам FDO устройств разрешается окружать себя Объектами Фильтрами (FiDO, Filter Device objects) как показано на рис. 2.2. Соответственно, каждому FiDO объекту сопоставлен драйвер, который выполняет определенную работу. Объекты фильтры подразделяются на фильтры нижнего уровня и фильтры верхнего уровня. И тех и других может существовать произвольное количество. Они модифицируют процесс обработки запросов ввода/вывода. Объекты FDO и FiDO отличаются только в смысловом отношении. FDO объект и его драйвер считаются главными. Они обычно обеспечивают управление устройством, а объекты FiDO являются вспомогательными.
Рис. 2.2. Стек устройств
Все объекты FDO и FiDO позиционируют себя в стеке устройств. Порядок объектов в стеке определяет порядок обработки запросов ввода-вывода. Если необходимо перехватить и обработать запрос, непосредственно идущий от пользователя, то нужно устанавливать верхний фильтр. Если же нужно отслеживать обращение к портам ввода вывода, обрабатывать прерывания, то нужен нижний фильтр. Данная модель позволяет драйверу устанавливать callback процедуры. Когда запрос начинает обрабатываться, то он обрабатывается последовательно всеми драйверами стека устройства ( исключая ситуацию, когда какой-либо драйвер сам завершит обработку запроса ). После этого диспетчер ввода-вывода передает запрос callback процедуре каждого драйвера стека. Сначала запрос передается callback процедуре последнего драйвера который в стеке, потом процедуре предпоследнего драйвера и т.д. Callback процедуры нужны для того, чтобы обработать прочитанную из устройства информацию. Если фильтр обрабатывает запросы на чтение, то когда этот запрос поступит в драйвер информация еще не будет считана. Поэтому драйверу необходимо установить callback функцию. При ее вызове запрос уже будет содержать считанные данные.
Драйвер имеет следующие точки входа: