Драйвер USB устройства URC220 для OS QNX (1037661), страница 4
Текст из файла (страница 4)
После этого посылает устройствусигнал сброса, чтобы после этого устройство стало находиться в известномсостоянии. В этом состоянии оно откликается по начальному нулевому адресу.Хост сбрасывает только одно устройство в один момент времени, поэтому неможет появиться двух устройств, отвечающих по нулевому адресу.Далее хост отправляет запрос на endpoint 0 устройства 0, чтобы выяснитьмаксимальный размер пакета, который устройство может принимать и отправлять.Хост выясняет это с помощью команды “Get Descriptor” (Device).Обычно хост (например, Windows) опять сбрасывает устройство, далее отправляетзапрос “Set Address” с уникальным адресом устройства на адрес 0, после чегоустройство принимает новый адрес, и с этого момента хост может сбросить другоенедавно подключённое устройство.На данном этапе устройство имеет адрес, но не сконфигурировано и отвечаеттолько на стандартные запросы, которые можно передавать только с помощьюControl Transfer, а единственной доступной конечной точкой являетсядвунаправленная нулевая конечная точка.Как правило, хост теперь начинает опрашивать устройство, чтобы определить всюнеобходимую информацию об этом устройстве.
Среди этих запросов такие как:- Get Device Descriptor- Get Configuration Descriptor- Get String DescriptorКогда компьютер узнаёт достаточно информации об устройстве, он загружаетсоответствующий драйвер. Этот драйвер затем выберет нужную конфигурацию,отправив запрос “Set Configuration”.После этого устройство становится сконфигурированным и может выполнять тефункции, для которых было разработано, отвечая при этом как на специальныезапросы драйвера, так и на стандартные запросы.5.6.2 Дескрипторы (Descriptors)Устройство содержит множество дескрипторов, которые помогают определить,какое устройство было подключено, а также возможности этого устройства.
Какбыло сказано выше, хост отправляет запросы “Get Device Descriptor”, “GetConfigurationDescriptor” и “GetStringDescriptor” дляопределениясоответствующих дескрипторов.Устройство имеет один Device Descriptor, который хранит информацию опроизводителе - Vendor Identification Number (VID), устройстве - Part Identification22Number(PID),максимальномразмерепакета,атакжеоколичествеConfigurationдескрипторов - bNumConfigurations.Зная VID и PID, операционнаясистема загружает необходимыйдрайвер.Далеепроисходитсчитываниепервогоконфигурационногодескриптора, при этом данныепередаютсявопределённомпорядке (см.
рис. 5.10): сначала самConfiguration дескриптор, затем,первый Interface Descriptor, а затемуже все Endpoint дескрипторы (двана рисунке слева). Далее идёт ещёодин Interface Descriptor, а затемопять все Endpoint дескрипторы.Т.е. считывание данных происходиттак, как показано на рисунке, т.е.сверху вниз. После этого, еслиbNumConfigurations больше одного,происходит считывание следующейконфигурации устройства (“OtherConfiguration Descriptors”).Драйвер при этом должен выбратьодну из конфигураций, для которойзаданыдескрипторы(тоестьРис.5.10 Порядок передачи дескрипторовописание) того, какие конечныеточки использует устройство, какой способ передачи данных и т.д.
Как правило,выбирается первая конфигурация.После этого устройство начинает нормально функционировать, выполняянеобходимые функции и используя все конечные точки для обмена информациеймежду устройством и драйвером.Ознакомиться со спецификацией USB можно на официальном сайте:www.usb.orgИнтересный ресурс об устройстве и использовании USB:www.usbmadesimple.co.uk236. Реализация ПО для управления URC220Для управления устройством URC220, то есть для обмена данными с ним, былареализована архитектура клиент-сервер. При запуске сервер следит заподключением и отключением устройств, реализует передачу данных междусервером и каждым устройством, а также передачу данных между сервером иклиентами.
Таким образом, клиентские программы работают с устройствами черезсервер (см. рис. 6.1). Клиент-сервер взаимодействие через общую оперативнуюпамять.Рис.6.1 Cхема работы ПО6.1 Алгоритм работы сервераСервер представляет собой консольное приложение для QNX, разработанное всреде Momentics. Исходный код программы реализован в 4-х файлах.
В файлах“Main.cpp” и “Main.h” расположены основные функции для работы сервера, афайлы “urcpipe.cpp” и “urcpipe.h” являются USB драйвером для обеспеченияобмена данными между сервером и устройствами.Общая схема работы сервера показана на рисунке 6.2. Рассмотрим назначениеосновных функций.main() – стартовая функция, с которой начинает выполнять работу программа,здесь происходит инициализация программы, ожидание во время работы сервера,а затем завершение работы.shmem_create() – функция для создания общей памяти, то есть памяти, которуюмогут использовать несколько процессов, запущенных в системе: сервер и24клиентские программы. Функция сначала создаёт объект для работы с памятью,далее выделяет необходимый объём памяти и очищает память.Рис.6.2 Общая схема работы сервераshmem_delete() – функция для удаления общей памяти, вызывается в самомконце, перед окончанием выполнения программы.usb_connect() – выполняет подключение к USB стеку QNX, то есть к средствамработы с USB.
Сообщает ОС различные параметры, среди которых PID и VIDустройства, с которым планируется работать, а также функции в программе(callback_* - см. далее), которые необходимо вызывать при возникновенииразличных событий.usb_disconnect() – отключение от USB стека.callback_insertion() – вызывается операционной сразу после того, какустройство было подключено к одному из USB портов, причём только для тогоустройства с указанным ранее PID и VID. Функция выводит о нём информацию,далее производит поиск свободного номера, который сопоставляет с этимустройством, а далее вызывает функцию dev_open() для подключения и настройкиустройства.callback_removal() – вызывается тогда, когда устройство отключили от USB.Функция сначала определяет ранее присвоенный этому устройству номер, а затемвызывает функцию dev_close() для завершения работы с устройством.Итак, после запуска, основной поток (функция main()) программы производитподключение к USB стеку и инициализирует общую память, после чего зависает,ожидая нажатия на клавишу.
В это время, при подключении и отключении25устройств, ОС вызывает функции callback_insertion() и callback_removal() дляобработки этих событий. Эти функции производят нумерацию устройств ивызывают функции dev_open() и dev_close() для начала и окончания работы сустройством.После нажатия на клавишу, основной поток закрывает все устройства, завершаетработу с USB и удаляет общую память, после чего программа завершается.Рассмотрим подробнее устройство функций dev_open() и dev_close().
Алгоритмработы этих функций показан на рисунке 6.3.Рис.6.3 Работа функций dev_open() и dev_close()Объект dev представляет собой массив, элементами которого являются структурыURC_PARAMETERS, содержащие два поля:1) pipe – объект класса CURCPIPE (реализован в файле “urcpipe.cpp”) дляработы с USB: подключение/отключение от устройства и передача данных;2) thread – идентификатор потока в QNX.Объект shmem – это общая память, представляющая собой массив структурURC_SHARED_MEM, содержащие поля для обмена данными, в том числе объектmutex, служащий для синхронизации доступа к памяти между несколькимипроцессами: сервером и клиентскими программами.Функция dev_open() сначала вызывает функцию open() соответствующего объектаpipe для подключения к устройству, далее инициализирует объект mutex. Послеэтого создаёт поток, в котором начинает выполняться функция dev_thread().Функция dev_close() выполняет операции, обратные операциям dev_open().Функция dev_thread() представляет собой бесконечный цикл, где постоянно идётпроверка: нужно ли передать данные от клиента к устройству или наоборот.
Приэтом обращение к данным как функцией dev_thread(), так и клиентскими26программами, осуществляется синхронно, так как используется mutex. Один изпотоков первым переводит mutex в состояние locked. Далее, когда другой потокпытается обратиться к данным, он зависает до тех пор, пока первый поток невыполнит все операции с данными и не переведёт mutex в состояние unlocked,чтобы к данным мог получить другой поток, который также установит mutex всостояние locked, и так далее. То есть с данными в один момент времени работаеттолько один поток. Для каждого устройства имеется свой mutex и поток, гдевыполняется dev_thread().Таким образом, во время работы сервера работают сразу несколько потоков:главный (функция main()) в состоянии ожидания плюс по одному потоку накаждое подключенное к компьютеру устройство.Алгоритм работы функции dev_thread() показан на рисунке 6.4.Рис.6.4 Алгоритм работы функции dev_thread()Для обмена данными с устройством используются функции write() и read() объектаpipe.
Таким образом, класс CURCPIPE, кроме конструктора и деструктора состоитиз следующих функций.27CURCPIPE::open() - функция открывает устройство,конфигурацию, в случае ошибки возвращает 0.ипроизводитегоCURCPIPE::close() – отключает от устройства.CURCPIPE::bulk_cbf() – функция вызывается операционной системой дляобработки различных событий во время передачи данных.CURCPIPE::wait_io() – после вызова функция ожидает окончания операцииприёма или отправки данных до их завершения или до возникновения ошибки.CURCPIPE::write() – отправляет данные по USB в устройство, вызывает в своёмкоде функцию wait_io(), поэтому функция write() является синхронной функциейотправки данных.CURCPIPE::read() – принимает данные по USB от устройства, вызывает в своёмкоде функцию wait_io(), поэтому функция read() является синхронной функциейприёма данных.6.2 Алгоритм работы клиентских программАлгоритм работы той части клиентских программ, которая отвечает завзаимодействие с устройствами, во многом похож на алгоритм работы функцииdev_thread() и показан на рисунке 6.5Рис.6.5 Алгоритм работы клиентских программ28Здесь сначала идёт подключение к программе внешней памяти, чтобы иметьдоступ к полям массива структур.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
