3.1.3 Разработка usb драйвера
Работа программиста, создающего драйвер внешнего (не находящегося на материнской плате) USB устройства сводится к тому, чтобы воспользоваться программным интерфейсом системных драйверов шины USB, общение с которым происходит при помощи пакетов, называемых URB (USB Request Block) пакетами [3.3]. Работа с регистрами USB контроллеров на материнской плате теперь стала уделом узкого круга специалистов – разработчиков материнских плат и операционных систем. Всем остальным разработчикам USB‑устройств в операционной системе Windows предлагается достаточно развитый программный интерфейс WDM‑драйверов, которые берут на себя все аппаратно-ориентированные операции. Структура USB драйвера приведен ниже (рис. 3.3).
Рисунок 3.3 – Структура USB драйвера
3.2 Технология отладки драйверов в операционных системах семейства Windows
Никакой сложный фрагмент программного кода не может считаться безошибочным. В среде профессионалов бытует мнение, что если в программе нет ошибок, то ошибка в компиляторе, поэтому он не выявил всех ошибок в программе.
Ошибки нельзя уничтожить совсем, их можно только ограничить. Все это становится наиболее очевидным, когда программное обеспечение начинает взаимодействовать с программами и аппаратурой других поставщиков, зачастую представляющими черный ящик.
Традиционно, тестирование разделяется на два этапа. Первый — достаточно сумбурный этап первоначального эмпирического накопления данных о поведении сложившейся конфигурации аппаратуры и программного обеспечения. Разумеется, у опытных разработчиков этот этап короче и проходит рациональнее. Второй этап обязан обобщить полученные на первом этапе сведения, простроить приемлемую модель возникновения проблем и провести их поэтапную ликвидацию. Если второй этап не справляется с такой постановкой вопроса и превращается в первый, то вcя работа превращается в беспорядочные метания [3.4].
Разумеется, поэтапное тестирование значительно эффективнее, нежели тестирование по окончании разработки системы целиком. Хотя такой подход требует большего набора фрагментарных тестов, эффективность данного подхода неоспорима. Хотя бы по той простой причине, что дата завершения тестирования при таком подходе более предсказуема, нежели для продукта, который ни разу не тестировался по частям [3.4].
В литературе, посвященной тестированию, различают «прирастающее» тестирование (с постепенным усложнением) и более формальное регрессивное тестирование (когда происходит откат на предыдущий шаг в случае неудачи) [3.5]. По мере расширения проекта, эти сохраненные предшествующие тесты позволят удостовериться, что изменения не внесли ошибок в прежде разработанные фрагменты.
Зачастую аппаратура разрабатывается параллельно программному обеспечению (самому драйверу и сопутствующему ПО). При раннем частичном тестировании дефекты в аппаратуре выявляются раньше и, соответственно, остается больше времени на исправление ошибок ее проектирования. В противном случае неожиданное осознание того, что следует закупить другие микросхемы, сделать еще одну итерацию печатной платы или заказной интегральной схемы – окажется «настоящей встряской» для разработчиков и руководителей проекта [3.5].
Немногие фирмы могут позволить себе иметь отдельные команды разработчиков и испытателей. Таким образом, разработчик драйвера должен зачастую параллельно разрабатывать драйвер и поэтапные тесты для него. Преимуществом такого «унитарного» подхода является то, что разработчик остается в курсе предельных параметров драйвера и устройства. Недостаток состоит в том, что разработчик может заранее не запланировать тесты на некоторые редко встречающиеся ошибочные ситуации, что впоследствии может оказаться серьезной проблемой для разрабатываемого ПО [3.5].
Разумеется, должна быть установлена хорошая дисциплина для обеспечения достаточного времени и для разработки, и для тестирования. Сокращение стадии тестирования для ускорения общего графика разработки драйвера – «относительно» плохая перспектива для любого разрабатываемого ПО (не только драйвера).