CC BY
19Управление исполнительными устройствами по USB в режиме реального времени
Колкер А.Б. Горбунов Н.О. Новосибирский государственный Технический Университет(НГТУ)
Аннотация: Шина USB является в настоящее время одним из наиболее популярных универсальных периферийных интерфейсов, предназначенных для высокоскоростного потокового обмена данными. Большинство микропроцессорных систем средней сложности оборудованы USB интерфейсом и способны обмениваться данными с его помощью. В настоящее время набор стандартов USB представлен тремя обратно совместимыми поколениями протоколов. Целью данной статьи является определить рамки применимости стандартного интерфейса для управления исполнительными устройствами и подачи управляющих команд в режиме реального времени, а также выбрать наиболее удобный режим его работы для решения поставленной задачи.
Ключевые слова: управление
исполнительными устройствами,
мехатроника, интерфейс USB, операционная система Linux, микропроцессорная техника, микроконтроллеры
ВВЕДЕНИЕ
Интерфейс USB (Universal Serial Bus, универсальная последовательная шина) был представлен в 1996 году с целью создания одного универсального интерфейса для подключения различной периферии к персональному компьютеру. На тот момент персональные компьютеры были оснащены большим числом периферийных интерфейсов, но имеющих один общий недостаток - для каждого из них требовался свой специальный разъем и очень часто выделенное аппаратное прерывание (IRQ, Interrupt ReQuest).
Первая спецификации USB 1.0 была опубликована в начале 1996 года, а уже осенью 1998 года появилась спецификация USB 1.1, исправлявшая проблемы, обнаруженные в первой спецификации. Весной 2000 года была опубликована версия 2.0, которая предусматривала повышение пропускной способности шины USB практически в сорок раз. [1] Интерфейсом USB версий 1.x поддерживается два возможных режима скорости передачи данных. Режим Full speed или полноскоростной режим, позволяющий осуществлять передачу
данных со скоростью до 12 Мбит/с, а также режим Low speed или низкоскоростной со скоростью передачи данных до 1,5 Мбит/с. Стандарт USB 2.0, который на данный момент господствует на рынке, включает в себя режим High speed или высокоскоростной, который поднимает предел скорости передачи данных до 480 Мбит/с. Наиболее современный стандарт USB 3.0,который в настоящее время еще не получил такого широкого распространения, как его предшественники, имеет теоретическую скорость передачи данных 4.8 Гбит/с. В настоящий момент USB3.0, в основном, применяется для сопряжения с твердотельными накопителями и внешними сетевыми устройствами и практически не встречается в практике проектирования микроконтроллерной техники.
Вследствие вышесказанного, рассмотрим стандарт USB2.0 , как наиболее востребованный популярный при создании микропроцессорной техники.
СТРУКТУРА USB СТАНДАРТА 2.0
Интерфейс Universal Serial Bus - это последовательный полудуплексный протокол, который позволяет вести обмен данными между ведущим устройством и большим числом периферийных устройств. Подключенные периферийные устройства разделяют полосу пропускания USB между собой, используя планируемый хостом протокол на основе посылки маркеров. Интерфейс USB предоставляет возможность подключения, конфигурирования, использования и отключения периферийного устройства, в то время как хост и другие периферийные устройства задействованы в каких-либо операциях. Спецификацией USB 2.0 определяется несколько основных составляющих шины USB: хост-контроллер, порт, концентратор, USB устройство, корневой концентратор, функция и логическое устройство.
Хост-контроллер (USB host controller) - это устройство, которое осуществляет управление питанием и конфигурацию USB устройств, подключенных к шине, распределяет её полосу пропускания между устройствами и является инициатором всех транзакций на ней. Изначально интерфейс USB не поддерживал каких-либо форм мультихостинга, то есть наличия нескольких
хостов на одной шине. Однако в спецификации One-To-Go, представленной в USB 2.0, был введен протокол Host Negotiation Protocol, позволяющий договориться двум устройствам USB о том, которое из них будет выступать в качестве хоста. Данный протокол предназначен только для одиночных соединений типа «точка-точка», например мобильный телефон -персональный органайзер, и не распространяется на концентраторы и конфигурации компьютеров. Таким образом, для использования микроконтроллерной системы в качестве «ведущей», она должна быть оборудована аппаратурой хост-контроллера. Будем считать, что в качестве микроконтроллера используется одноплатный компьютер или контроллер с установленной Linux-подобной операционной системой. На рынке представлен широкий набор промышленных устройств, обладающих такими свойствами, например, популярный
промышленный микроконтроллер Segnenics SMH 2GI,
Концентратор или хаб (Hub) является ключевым элементом архитектуры USB. Точки подключения называются портами
концентратора. Концентратор преобразует одну точку подключения в их множество, архитектура USB допускает соединение нескольких концентраторов между собой. У каждого концентратора есть один восходящий порт (Upstream port), предназначенный для подключения к хосту или концентратору верхнего уровня. Все остальные порты являются нисходящими (Downstream port),
предназначенными для подключения функций или концентраторов нижнего уровня. Концентратор может детектировать подключение или отключение устройств на своих портах, управлять подачей питания на нисходящие порты, а также возможна установка ограничения на ток, потребляемым каждым из портов. Каждый из портов может быть разрешен или запрещен к использованию, а также сконфигурирован на режимы скорости обмена данными с устройством. Концентратор обеспечивает изоляцию низкоскоростных сегментов (Low Speed и Full Speed) от высокоскоростных (High speed).
Функция (Function) - это периферийное устройство или отдельный блок периферийного устройства, позволяющий передавать и принимать информацию по шине USB. Каждая функция предоставляет информацию о своей конфигурации, описывающую тип и возможности периферийного устройства, а также ресурсные требования, например информация о потребляемом токе. Перед использованием функция должна быть сконфигурирована хостом, то есть ей должна быть выделена полоса пропускания в канале связи и выбраны опции конфигурации. Устройство (Device) может представлять собой концентратор, функцию или их комбинацию, которая называется составным
устройством (Compound device). Для хоста составное устройство выглядит как концентратор с постоянно подключенными функциями. Обычно USB устройство представляет собой функцию с портом для подключения.
Важной логической частью USB функции является конечная точка (Endpoint). Конечная точка- часть устройства, которая имеет уникальный идентификатор и является получателем или отправителем информации, передаваемой по USB. С аппаратной стороны конечная точка может представлять собой блок данных в памяти или регистр микроконтроллера. Хост также имеет буфер для приема и передачи данных, однако хост не может иметь конечных точек. Конечная точка имеет ряд основных параметров:
o частота доступа к шине; o допустимая величина задержки обслуживания;
o требуемая ширина полосы пропускания; o номер конечной точки; o способ обработки ошибок; o максимальный размер пакета, который конечная точка может отправлять или принимать;
o тип посылок, используемый конечной точкой;
o направление передачи данных. Стандартом USB определяется одно и только устройство, которое является ведущим - это хост-контроллер. Устройства USB могут только отвечать на запросы хост-контроллера, они не могут посылать информацию по собственной инициативе. Однако, имеется один случай, когда устройство отправляет информацию по шине по собственной инициативе - после помещения устройства в спящий режим, устройство может послать сигнал хост-контроллеру о своем пробуждении. Данная концепция обусловлена тем, что устройства, поддерживающие протокол USB, должны быть дешевыми и максимально простыми, поэтому вся нагрузка по управлению шиной ложится на хост-контроллер.
Таким образом, ведущий микроконтроллер должен исполнять роль хост-контроллера, а каждое исполнительное устройство должно иметь возможность получать команды, как оконечная точка.
Физическое соединение устройств осуществляется по топологии многоярусной звезды (tiered star). Центром каждой звезды является концентратор, каждый кабельный сегмент соединяет две точки - концентратор с другим концентратором или функцией. Вершиной пирамиды устройств является хост-контроллер с интегрированным в него концентратором, называемым корневым (Root hub) и
предоставляющим одну или несколько точек подключения.
Рисунок 1. Топология интерфейса USB 2.0
Спецификацией USB 2.0 допускается возможность использования до семи ярусов пирамиды устройств USB, включая хост-контроллер. Следует отметить, что составное устройство занимает два яруса пирамиды устройств, поэтому не может быть расположено на седьмом ярусе.
БАЗОВЫЕ ТИПЫ ПЕРЕДАЧИ ДАННЫХ ПРОТОКОЛА USB
Спецификация интерфейса USB определяет четыре базовых типа передач данных (Transfer Type): управляющие передачи, передачи массивов данных, передачи по прерываниям и изохронные передачи. Рассмотрим, какие из базовых типов наиболее удобны задачи управления
исполнительными устройствами.
Управляющие передачи (Control Transfers) применяются для конфигурирования устройства во время его подключения, управления устройством и получения информации о его статусе в процессе работы. Протоколом USB обеспечивается гарантированная доставка таких посылок. Длина поля данных посылки такого типа не может превышать 64 байт в режиме Full Speed и High Speed и 8 байт в режиме Low Speed. Управляющим передачам гарантированно выделяется 10% полосы пропускания. Может быть использовано для передачи коротких команд управления в режиме реального времени.
Передачи массивов данных (Bulk Data Transfers) используются в том случае, если необходимо обеспечить гарантированную доставку данных от хоста к функции или в обратном направлении в режиме High Speed и Full Speed, однако время доставки таких передач не ограничено. Передачи массивов данных занимают всю доступную полосу пропускания шины и имеют поле данных размером 8, 16, 32 или 64 байт. Приоритет у таких передач наиболее низкий, при высокой загрузке шины они могут быть приостановлены, следовательно, данный режим не подходит для управления устройствами в режиме реального времени.
Передачи по прерываниям (Interrupt Transfers)
используются случае, когда требуется передавать одиночные пакеты данных небольшого размера, требующие ограниченного времени доставки. Передачи такого типа носят спонтанный характер и имеют требования по времени обслуживания, которые предъявляются устройством. Размер поля данных может содержать до 64 байт в режиме Full Speed и High Speed и до 8 байт в режиме Low Speed. Предел времени обслуживания устанавливается в диапазоне от 1 до 255 мс для режима Full Speed, от 10 до 255 мс для Low Speed и 125 мкс для High Speed. Наиболее подходящий режим обмена данными «с гарантией доставки» для управления устройствами.
Изохронные передачи (Isochronous Transfers) используются для обмена данными в режиме "реального времени". Доставка таких пакетов не гарантируется протоколом USB, так как передача ведется без повторений и допускается потеря. Пропускная способность шины и задержка доставки для таких передач предварительно согласовывается. Изохронные передачи разделяются по способу синхронизации конечных точек с системой. Спецификацией USB определяются асинхронный, синхронный и адаптивный классы устройств, каждому из которых соответствует свой тип канала USB. Может быть использован для управления устройствами если гарантия доставки пакета не требуется.
МЕХАНИЗМ ПЕРЕДАЧИ ДАННЫХ ИНТЕРФЕЙСА ТОБ
Передача данных по интерфейсу USB осуществляется асинхронно при помощи отдельных блоков, которые называются USB кадрами. Передача одного блока данных осуществляется за фиксированный временной интервал равный 1 ± 0,0005 мс. [2,5]. Следовательно, теоретическое время доставки пакета не может быть меньше данной величины. Обмен данными инициируется и организуется хостом согласно его плану распределения ресурсов. Загрузка кадров планируется так, чтобы в них находилось место для наиболее приоритетных типов передач, в свою очередь свободное место в USB кадре занимается низкоприоритетными передачами.
Рисунок 2. Кадр USB
Началом каждого кадра определяется отправкой хостом маркера SOF (Start Of Frame), выступающим в роли синхронизирующего сигнала для всех ведомых устройств на шине
50
USB. В конце каждого кадра хост выделяет временной интервал EOF (End Of Frame), во время которого концентраторами запрещаются все передачи по восходящим портам в сторону хоста. В случае обнаружения концентратором передачи данных с какого-либо порта во время EOF данный порт немедленно отключается.
У каждого кадра имеется свой номер. Для нумерации кадров хост-контроллер оперирует 32-битным счетчиком, однако в маркере SOF передаются только младшие 11 бит номера кадра. Инкремент счетчика кадров производится во время EOF. Один кадр может содержать несколько транзакций, число которых зависит от скорости передачи данных, длины поля каждой транзакции, а также задержек, которые вносятся соединительными кабелями, устройствами и концентраторами. Все транзакции должны быть завершены до момента времени EOF. Спецификацией USB позволяется занимать под периодические транзакции до 90% пропускной способности шины.
Стандарт USB реализует оперирование командами и блоками данных при помощи логической абстракции, которая называется каналом. С этой стороны, любое устройство USB рассматривается как логическое устройство, то есть представляется набором конечных точек. Таким образом, канал является связующим звеном между хостом и конечными точками устройства.
Конечная точка п
Конечная точка
Конечная точка ?
USB Потек кадров USB Хост
Канал, Канал 1
Канал2 Канал 2
Информация по шине передается в виде пакетов. Каждый пакет начинается с поля синхронизации SYNC (SYNChronization), после которого следует идентификатор пакета PID (Packet IDentifier). Идентификатор пакета состоит из четырехразрядного кода типа пакета и четырехразрядного контрольного поля Check, каждый разряд которого является инверсией соответствующего разряда поля PID. Пакет заканчивается полем EOP.
| SYNC | PID I Check \ Данные пакета j EOP | Рисунок 4. Пакет USB
Таким образом, можно сформировать следующую обобщенную схему:
o каждый кадр состоит из наиболее приоритетных посылок;
o каждая передача состоит из одной или нескольких транзакций;
o каждая транзакция состоит из пакетов; o каждый пакет состоит из идентификатора пакета, данных (если они есть) и контрольной суммы.
Система USB разделяется на три логических уровня с определенными правилами взаимодействия между собой. Устройство USB разделяется интерфейсную, логическую и функциональную части, каждая из которых отвечает только за определенный круг задач. Аналогично, хост также разделяется на три части - интерфейсную, системную и прикладную.
Рисунок 3. Схема логической абстракции USB
Рисунок 5. Обобщенная схема блоков данных протокола USB
Рисунок 6. Логические уровни протокола USB
Согласно этому разделению, операции обмена данными между прикладным программным обеспечением и интерфейсом ШВ осуществляются путем передачи буферов памяти через эти три уровня уровни.
На функциональном уровне клиентское программное обеспечение в хосте, представляемое драйвером USB устройства, обеспечивает взаимодействие пользователя с операционной системой и системным драйвером. На этом уровне определяется тип передачи данных, который необходим для выполнения требуемой пользовательским программным обеспечением операции, после чего на логический уровень системному программному обеспечению передается буфер памяти и пакет запроса на ввод/вывод (IRP, Input/output Request Packet), в котором указывается тип необходимой операции. В IRP пакете содержатся только сведения о запросе, то есть адрес и длина буфера в оперативной памяти. Обработкой запроса
занимается непосредственно системный драйвер USB.
На логическом уровне, системное программное обеспечение USB в хосте (USBD, Universal Serial Bus Driver) осуществляет управление устройствами на шине USB, адресацией , распределением пропускной способности шины, питанием устройств и осуществляет обработку IRP запросов пользовательских драйверов. Планирование транзакций также осуществляется на уровне системного драйвера USB.
На уровне шины хост-контроллером USB (HCD, Host Controller Driver) IRP запросы преобразуются в структуры данных, на основе которых и выполняются физические транзакции. Хост-контроллером интерфейса шины формируются кадры, которые передаются последовательной передачей бит,
закодированных методом NRZI.
Клиентское IR Р Драйвер Транзакции Драйзер хост-ноктроппера Транзакции Хост-^оитроллер Квдрь; ш KRZI
ПО USB интерфейса шины ÜSB il
Формирует IRP-aa проси
Формируа! перечень гранэакций
Планирует выполнение 1ранэакцнй
Формирует Кадры
Рисунок 7. Иллюстрации последовательности работы уровней USB
Битовая передача
Все транзакции интерфейса USB состоят из трех пакетов. Каждая транзакция начинается с посылки хост-контроллером специального маркера-пакета типа Token. Этот пакет описывает тип, направление передачи, адрес устройства USB и номер конечной точки. В каждой транзакции возможен обмен только между конечной точкой
устройства и хостом. Устройство, распознав свой адрес, содержащийся в пакете-маркере типа Token и передает пакет данных или уведомление об отсутствии данных. После успешного приема пакета приемник данных посылает пакет подтверждения (пакет типа Handshake).
А Б
Рисунок 8. А - передача данных от хоста, Б - передача данных хосту
Спецификацией USB определяется несколько возможных классов устройств. Процедура определения класса USB устройства осуществляется хостом после обнаружения этого устройства на шине. Устройство отправляет хосту свой код класса (Class Code), на основе которого хост загружает драйвер необходимый для работы с данными типами устройств. Такой подход позволяет унифицировать работу с однотипными устройствами разных производителей. Одно устройство может поддерживать несколько классов, число которых определяется числом конечных точек устройства.
Спецификация USB определяет класс HID устройств, как устройства для взаимодействия с пользователем, например устройства ввода, однако класс HID позволяет реализовать низкоскоростной обмен данными с устройством даже не попадающим под жесткое определение устройства ввода. [3] Так как в большинстве операционный систем присутствует стандартный драйвер HID, то необходимость в трудоемкой работе по разработке драйвера отпадает. С точки зрения разработчика программного обеспечения самого устройства требуется обеспечить поддержку специальных структур, описывающих HID-интерфейс. [1]. Принципиальным ограничением является скорость передачи данных, которая не может быть выше 64 Кбит/с, однако для многих приложений этого оказывается достаточно.
Информация о устройстве содержится в сегментах его .ROM-памяти. Эти сегменты называются дескрипторами (descriptor) устройства. Данные содержащиеся в дескрипторе сообщают хосту, что подключенное устройство принадлежит к определенному классу устройств. Помимо этого устройство может сообщить хосту о режиме скорости передачи данных, производителе устройства, информацию о конечных точках, которые использует устройство.
Стандартом USB определяется ряд дескрипторов, которые являются общими для всех классов устройств. Считывание дескрипторов осуществляется запросом GetDescriptor, в качестве которого используется код дескриптора. Устройство может обладать несколькими описаниями одного типа. Так, обязательными дескрипторами устройства являются DEIVCE, CONFIGURATION, INTERFACE, ENDPIONT. [3]
Таблица 1. Структура дескриптора DEVICE
Номер поля Название поля Раз-мер, байт Значение Описание
1 bLenght 1 18 Размер дескриптора в байтах
2 bDesriptorType 1 1 Тип дескриптора, в данном случае DEVICE
3 bcdUSB 2 BCD Номер спецификации USB, поддерживаемый устройством
4 bDeviceClass 1 Class Код класса
5 bDeviceSubclass 1 Subclass Код подкласса
6 bDeviceProtocol 1 Protocol Код протокола
7 bMaxPacketSizeG 1 Число Максимальный размер пакета для контрольной точки. Допустимые значения: 8, 16, 32, 64
8 idVendor 2 VID Идентификационный код производителя
9 idProduct 2 PID Идентификационный код продукта
10 bcdDevice 2 BCD Номер версии устройства в двоично-десятичном представлении
11 iManufacturer 1 Число Индекс строки, описывающей производителя
12 iProduct 1 Число Индекс строки, описывающей продукт
13 iSerialNumber 1 Число Индекс строки, описывающей серийный номер устройства
14 bNumConfiguration 1 Число Количество конфигураций, поддерживаемых устройством
Дескриптор DEIVCE или дескриптор устройства, содержащий в себе общее описание USB устройства. Данный дескриптор у устройства один и только один и имеет размер равный 18 байт. [3] На основе дескриптора устройства хост может определить такую информацию о
устройстве как:
o спецификация USB, поддерживаемая устройством;
o класс, к которому относится устройство; o стандартизированный протокол,
используемый при работе;
o производителе и модели устройства.
Следует отметить, что такие значения как PID, VID, Class, Subclass и Protocol распределяются организацией USB-IF.
В дескриптор CONFIGURATION или дескриптор конфигурации отражается
информация только о конфигурации устройства, при запросе которого устройство выдает описание запрошенной конфигурации и всех входящих в неё интерфейсов и конечных точек. [З] Получение отдельных описаний интерфейсов и конечных точек спецификацией USB не предусмотрено. Общая длина этого списка указывается в поле wTotalLength. Количество интерфейсов для данной конфигурации содержится в поле bNumInterfaces, по значению в данном поле можно судить, сколько описаний
интерфейсов следует далее. Поле bConfigurationValue содержит номер текущей конфигурации, это значение используется стандартным требованием
SETCONFIGURATION и должно быть больше 0. Поле bmAttributes отражает атрибуты, присущие данной конфигурации, а именно: наличие собственного источника питания устройства и возможность сообщения устройством о выходе из режима «сна» при внешнем воздействии. В поле bMaxPower указывается максимальный потребляемый ток при использовании в качестве источника внутреннего питания шины USB.
Таблица 2. Структура дескриптора CONFIGURATION
Номер поля Название поля Размер, байт Значение Описание
1 bLenght 1 9 Размер дескриптора в байтах
2 bDesriptorType 1 2 Тип дескриптора, в данном случае CONFIGURATION
З wTotalLength 2 Число Полный размер описания конфигурации, включая описание всех интерфейсов и конечных точек
4 bNumInterfaces 1 Число Количество интерфейсов в данной конфигурации
5 bConfiguration Value 1 Число Номер данной конфигурации. Используется запросом Set configuration
б iConfiguration 1 Число Индекс строки, описывающий данную конфигурацию
Т bmAttributes 1 Bitmap Битовое поле, характеризующее конфигурацию
S bMaxPower 1 Число Значение максимального тока, которое потребляет устройство от шины USB. Значение указывается в единицах unit, равное 2 мА.
Дескриптор INTERFACE или дескриптор интерфейса описывает все интерфейсы устройства. [3] Дескриптор ENDPIONT или дескриптор конечной точки описывает конечные точки. Устройство может иметь несколько дескрипторов этих типов. Стандарт USB не предполагает явного запроса этих дескрипторов, они запрашиваются совместно с дескриптором конфигурации. Необязательным дескриптором является STRING. При запросе данного описания дополнительно передаются номер дескриптора и идентификатор языка возвращаемой строки. При отсутствии дескрипторов подобного типа все поля, содержащие указатели на строковые описания, должны быть установлены в 0.
Для класса HID спецификацией USB был введен особый тип дескрипторов, называемый HID дескрипторами, при помощи которых устройство может сообщить хосту о структуре и характере передаваемых им данных. HID-устройством может являться любое устройство, которое удовлетворяет следующим правилам:
o устройство может устанавливать частоту своего опроса с целью выяснения наличия у устройства данных для пересылки;
o обмен данными с HID-устройством происходит при помощи специальной структуры, называемой репортом (Report). Репорт может содержать до 65535 байт данных. Структура репорта очень гибка, что позволяет описывать любое устройство и любой формат передачи данных;
o HID-устройство имеет конечную точку типа Interrupt IN для отправки данных, также оно может дополнительно иметь конечную точку типа Interrupt OUT для приема данных от хоста;
o HID-устройство должно поддерживать специфичные запросы Getreport, а также дополнительно Setreport.
Принадлежность устройства к классу HID определяется содержимым в поля bInterfaceClass дескриптора интерфейса, таким образом, после запроса дескриптора конфигурации хост определяет, что подключенное устройство является HID.
HID дескриптор - это специальных классовый
дескриптор, который ссылается на физический дескриптор и дескриптор репорта. В нем содержится информация о типе и длине этих дескрипторов.
Дескриптор репорта отличается от всех остальных дескрипторов тем, что он не является просто таблицей значений. Его длина и содержание варьируется в зависимости от количества полей данных, необходимых для обмена данными с устройством. Дескриптор репорта состоит из элементов, которые содержат некоторую информацию об устройстве. Первая часть элемента содержит три поля: тип элемента, его тэг и размер. Существует три типа элементов Main, Global и Local. Для элементов типа Main на данный момент существует пять тэгов: Input, Output, Feature, Collection и End Collection.
Тэги Input и Output относятся к данным, которые передаются от хоста к устройству и в обратном направлении. Тэг Feature также относится к данным, участвующих в обмене данными между хостом и устройством, но эти данные не предназначаются для получения конечным пользовательским программным обеспечением и имеют служебный характер. Тэги Collection и End Collection используются для смысловой группировки элементов Input, Output, Feature по критерию выполняемой функции.
Обмен данными между хостом и HID-устройством может осуществляться при помощи трех различных видов репортов. Репорты типа Output и Input используются для приема и передачи периодических данных, примером которых может послужить нажатие клавиш на клавиатуре. Репорты типа Feature используются в тех случаях, когда очень критично время доставки, например для установки параметров устройства.
Рисунок 9. Каналы обмена данными H/D-устройсва и HD-драйвера
Обмен данными между устройством и HID-драйвером хоста производится либо через двунаправленный канал нулевой конечной точки, либо по каналу прерываний. Канал нулевой точки используется для приема и передачи управляющих посылок, запрос Getdescriptor и приема данных, отправленных хост-контроллером. Канал прерываний используется для передачи асинхронных данных, которые не запрашиваются хостом. Данные с конечной точки типа Interrupt считываются только в том случае, если устройство подтверждает наличие новых данных и необходимость их передачи.
ЭКСПЕРИМЕНТАЛЬНЫЙ СТЕНД
В процессе эксперимента был создан стенд состоящий из:
• Компьютера под управлением операционной системы Linux (Ubuntu 12.04 LTS)
• Модуля сопряжения - микроконтроллер AT90USB162, имеющий на борту аппаратный модуль взаимодействия с интерфейсами USB и PS/2.
Свойства системы тестировались при помощи задачи формирования ШИМ
последовательностей, управляемых командами, поступающими по шине USB.
Выбор микроконтроллера AT90USB162 обусловлен наличием полной поддержки спецификации USB 2.0. Встроенный аппаратный модуль USB имеет четыре программируемые конечные точки с размером пакета принимаемого пакета до б4 байт, поддержку режима низкого энергопотребления с выходом из него по прерыванию от хоста. Для разработки и отладки программного обеспечения использовалась отладочная плата AVR-USB162.
Для выполнения поставленной задачи целесообразно использовать устройство класса HID, что обусловлено тем, что для исполнительного устройства не требуется высокой скорости передачи данных от хоста к устройству, однако критична своевременность доставки данных. Использование точек доступа типа Interrupt и Control устройством для обмена данными позволяет добиться фиксированного интервала времени обслуживания даже при загруженной шине USB. Со стороны одноплатного компьютера необходимо разработать программный модуль, позволяющий осуществлять обмен данными с
микроконтроллером, используя протокол USB. Для обмена данными с микроконтроллером предлагается использование библиотеки HID API для взаимодействия со стандартным драйвером USB HID в операционной системе Linux. [8]
В настоящее время существует как минимум три проекта, которые позволяют создать USB устройство на основе микроконтроллера архитектуры AVR, не нарушающих требований комитета USB-IF к наличию у устройства уникальной пары PID и VID. Один из проектов, под названием V-USB, позволяет эмулировать протокол USB на контроллерах AVR, не имеющей аппаратной поддержки интерфейса. Данный проект распространяется по лицензии GPL и предоставляет официально зарегистрированную пару PID и VID, однако он не способен полностью реализовать интерфейс USB и допускает некоторые его упрощения и работает только в режиме USB 1.1. Основным недостатком проекта V-USB является тот факт, что вся нагрузка по работе с протоколом USB ложится на центральное процессорное устройства микроконтроллера, а не на отдельный аппаратный
модуль. Таким образом, сфера применения этого проекта достаточно ограниченна и не может быть использована для скоростного обмена данными.
Следует отметить, что фирма Atmel предоставляет свой стек протокола USB для контроллеров с аппаратным модулем USB, однако на данный момент он практически не поддерживается разработчиками. Преемником стека USB Atmel считается библиотека LUFA, которая активно поддерживается сообществом и предоставляется по лицензии MIT. [Т] На данный момент фирма Atmel передала свои уникальные идентификаторы PID и VID разработчикам библиотеки LUFA. Помимо этого данная библиотека очень хорошо документирована, активно поддерживается сообществом разработчиков и предоставляет очень удобный API для работы с ней. Она позволяет реализовать полностью функции USB устройства, а также функции хоста. Следует отметить, что исходные коды, разработанные с помощью библиотеки LUFA, можно перенести на любой микроконтроллер фирмы Atmel без изменений, что обеспечивает возможность разработки на более дешевом контроллере с последующим переносом на микроконтроллер более высокого класса. Всё это делает библиотеку LUFA наиболее удачным инструментом для разработки программного обеспечения USB устройств на основе микроконтроллеров архитектуры AVR с аппаратной поддержкой протокола USB.
Проектирование программного обеспечения микроконтроллера следует логически разделить на проектирование двух подсистем: подсистемы, обеспечивающей обмен данными с одноплатным компьютером средствами протокола USB, и подсистемы, обеспечивающей работу аппаратного модуля с тестовым исполнительным устройством.
Подсистема обмена данными средствами протокола USB должна обеспечивать обработку всех специфичных для данного интерфейса запросов, посылаемых хостом, обеспечивать работу с буферными регистрами контрольных точек аппаратного модуля USB
микроконтроллера, а также обработку прерываний аппаратного модуля USB микроконтроллера. В одном из случаев на вход подсистемы обмена данных поступают данные, которые отправляет хост, которые далее передаются подсистеме работы с тестовым устройством. В другом случае, на вход данной подсистемы поступают данные, полученные от подсистемы работы с тестовым устройством, которые должны передаться хосту.
Подсистема работы с тестовым устройством осуществляет обработку полученных данных и на основе их формирует управляющее воздействие на тестовое устройство. В случае если управляющее воздействие представляет собой ШИМ последовательность, данная подсистема должна обеспечивать работу с аппаратным
таймером микроконтроллера, то есть инициализацию, настройку таймера, обработку его прерываний. Помимо этого подсистема должна обрабатывать данные, полученные от тестового исполнительного устройства, а точнее данные с драйверов обеспечивающих согласование электрических уровней на выходе микроконтроллере и на входе тестового исполнительного устройства
Алгоритм работы тела цикла микроконтроллера показан на рисунке 10.
Начало
V
I Конфигурация периферии микроконтроллера
а
Разрешение прерываний
й
Рисунок 10. Диаграмма деятельности, отражающая алгоритм работы микроконтроллера
Для обмена данными с микроконтроллером, выступающим в роли USB HID устройства, проектируемая система должна осуществлять взаимодействие с драйвером USB HID в операционной системе Linux. Данные, которые необходимо передать, передаются в систему от стороннего программного модуля, который в нотации UML является актером системы. Помимо актера «Сторонний программный модуль» в системе присутствует актер «HID-драйвер», которому передаются и от которого принимаются данные.
о о °
Сформировать HID реп орт
Открыть USB Поиск устройства |
устройств нашине ^ < < include> >
л << include> > <<include>> I
-f- аУЧ _ _>rS
/Ч <<extern>>
Обмен данными Сторонний программный с микроконтроллером модуль
Передать данные микроконтроллеру
Ф
< < extern> >
Получить данные от микроконтроллера
Рисунок 11. Диаграмма прецедентов для программного модуля со стороны одноплатного компьютера
HID - драйвер
Именно актер «H/D-драйвер» осуществляет обмен данными с микроконтроллером по запросу системы, однако он не может инициировать каких-либо прецедентов в системе. Диаграмма прецедентов для программного модуля обмена данными представлена на рис. 11.
Актер «Сторонний программный модуль» является инициатором только прецедента «Обмен данными с микроконтроллером». Прецедент «Обмен данными с микроконтроллером» описывается следующим потоком событий.
Предусловия: устройство было корректно подключено к шине USB.
Основной поток событий:
1. Сторонний программный модуль передает системе данные, необходимые для передачи микроконтроллеру, а так же информацию о типе канала, по которому должен осуществляться обмен данными.
2. Система проверяет соответствие количества входных аргументов. В случае несоответствия выполняется альтернативный поток А1.
3. Система формирует HID-репорт на основе данных, полученных от стороннего модуля.
4. Система начинает поиск устройства, которому необходимо передать данные, на основе дескриптора устройства, а именно пары PID, VID и строкового дескриптора, описывающего производителя устройства. В случае, если устройство найдено выполняется альтернативный поток А2.
5. Система открывает найденное устройство и сообщает о том, что устройство было открыто. В случае неудачи выполняется альтернативный поток А3.
6. На основе полученного аргумента система определяет тип канала, по которому следует передавать данные. В случае, если аргумент означает использование канала управляющих передач выполняется альтернативный поток А4. В случае канал прерываний - альтернативный поток А5.
Альтернативный поток А1:
Система сообщает о неверном количестве аргументов.
Альтернативный поток А2:
Система сообщает о том, что она смогла найти необходимое устройство на шине USB.
Альтернативный поток А3:
Система сообщает о том, что ей не удалось открыть устройство.
Альтернативный поток А4:
1. Система отправляет сформированный репорт типа FEATURE HID - драйверу
2. Система сообщает о количестве переданных байт и их содержимом.
3. Система запрашивает у устройства данные, использую HID - драйвер, после чего их получает.
4. В случае успеха получения данных система сообщает о содержимом полученной информации от устройства, в случае неудачи - причину.
Альтернативный поток А5:
1. Система отправляет сформированный репорт типа OUT HID - драйверу
2. Система сообщает о количестве переданных байт и их содержимом.
3. Система запрашивает у устройства репорта типа IN, использую HID - драйвер, после чего их получает.
4. В случае успеха получения данных система сообщает о количестве полученных байт и их содержимом.
Под задачей тестирования работы модуля сопряжения подразумевается оценка нагрузочной способности разработанного программного модуля обмена данными со стороны одноплатного компьютера, а также измерение времени задержки между моментом отправки одноплатным компьютером данных для формирования управляющего воздействия и выводом на порт GPIO микроконтроллера заданного управляющего воздействия в виде ШИМ последовательности. Согласно
требованиям технического задания
спроектированный модуль должен иметь высокую нагрузочную способности, что подразумевает осуществление обмена данными одноплатного компьютера с микроконтроллером при любой загрузке центрального процессорного устройства одноплатного компьютера.
Оценка нагрузочной способности
программного модуля обмена данными со стороны одноплатного компьютера произведена по нижеприведенной методике. Тестирования возможности обмена данными проводилось при наихудшем варианте, то есть при стопроцентной загрузке центрального процессора одноплатного компьютера. По результатам тестирования отправка данных микроконтроллеру и их получение программным модулем со стороны одноплатного компьютера осуществляется при любой загрузки процессора на тестируемом компьютере.
В ходе тестирования была выявлена максимальная частота операций отправки и приема данных, осуществляемых одноплатным компьютером, при которой возможна стабильный обмен данными между спроектированным USB устройством и компьютером. Максимальный период операций обмена данными позволяющий осуществлять стабильный обмен данными представляет собой величину порядка 10 мс. При более частой отправки пакетов SETUP или IN/OUT, с которых начинаются все транзакции по протоколу USB, в нулевую конечную точку и следующих за ними передаваемых данных возникает переполнение конечной точки и
устройство перестает отвечать на запросы хоста. После обработки данных из нулевой конечной точки устройство может опять осуществлять обмен данными с хостом. Следует отметить, что в данном приложении использования аппаратно-программного модуля требуется по осуществлять передачу данных значительно реже.
2
Рисунок 12 Осциллограмма измерения времени задержки для передач типа Interrupt (1 - выход микроконтроллера, 2 - выход LPT порта). Развертка - 2 В/дел, 2 мс/дел
Измерение времени задержки между моментом отправки одноплатным компьютером данных для формирования управляющего воздействия и выводом на порт GPIO микроконтроллера заданного управляющего воздействия осуществлено по следующей методике: перед вызовом функции отправки данных микроконтроллеру осуществляется вызов низкоуровневой функции 2 становки высокого уровня напряжения LPT порта. После окончания работы функции отправки данных USB HID драйвера вызывается функция установки низкого уровня напряжения на выходе LPT порта. Таким образом, на выходе LPT порта появляется импульс, передний фронт которого соответствует временному моменту вызова функции отправки данных по протоколу USB.
Для проведения эксперимента подсистема работы с исполнительным устройством было несколько модифицирована - было изменено время формирования ШИМ последовательности на выходах порта GPIO. ШИМ последовательность формировалась ровно один период отсчета таймера/счетчика0, тем самым на
выходе GPIO микроконтроллера появлялся одиночный импульс. Отправка сообщений микроконтроллеру осуществлялась циклически, таким образом, согласно разработанному алгоритму формирования импульсов на выходах портов GPIO микроконтроллера, время появление сигнала, соответствующего текущему
отправленному хостом сообщения, соответствует заднему фронту предыдущего сигнала.
Рисунок 13. Осциллограмма измерения времени задержки для передач типа Соп1то1 (1 -выход микроконтроллера, 2 - выход LPT порта, инвертирован). Развертка - 2 В/дел, 2 мс/дел
Измерение времени задержки проведено для двух возможных типов передач по интерфейсу USB, а именно контрольных передач и передач по прерываниям. Для передач прерыванию задержка составила величину порядка 2 мс, для управляющих передач - 4 мс. Осциллограммы, полученные при проведении экспериментов представлены на рис. 12 - 13. Полученные результаты объясняются спецификой передач, передачи по прерываниям имеют фиксированный интервал времени обслуживания. Под управляющие передачи хост выделяет 10% полосы пропускания шины, однако нет гарантии, что полосу пропускания, которую требует программный модуль со стороны одноплатного компьютера не займут управляющие передачи от других приложений и процессов, запущенных в системе.
На основании этого можно сделать вывод, что в случае если от модуля сопряжения требуется малое время передачи данных для формирования управляющего воздействия, то целесообразнее использовать передачи по прерываниям.
ЗАКЛЮЧЕНИЕ
В статье приводится пути построения устройств сопряжения и исполнительных устройств, которые могут управляться при помощи интерфейса USB 2.0. В результате анализа данных можно сделать следующие выводы.
• Для реализации системы управления выгодно использовать HID режим устройства, который позволяет передавать данные со скоростью до 64 Кбит
• На практике максимальный период операций обмена данными позволяющий осуществлять стабильный обмен данными представляет собой величину порядка 10 мс.
• Модуль сопряжения (оконечное устройство) целесообразно строить на базе однокристального микроконтроллера с поддержкой USB.
• Библиотека LUFA, распространяемая по лицензии MIT, предоставляет удобный API для работы с аппаратным модулем USB микроконтроллеров Atmel.
• Для передач прерыванию задержка
выполнения команд составляет величину порядка
2 мс, для управляющих передач - 4 мс.
ЛИТЕРАТУРА
[1] П. В. Агуров Практика программирования USB. -Спб.: БХВ Петербург 2006 - 624 с.
[2] Universal Serial Bus Revision 2.0 specification. [Электронный ресурс] // USB-IF. - Режим доступа: http://www.usb.org/developers/docs/usb 20 040413.zi p - Загл. с ссылки.
[3] Device Class Definition for HID 1.11. [Электронный ресурс] // USB-IF. - Режим доступа: http://www.usb.org/developers/devclass deocs/HID1 1 1.pdf - Загл. с ссылки.
[4] AT90USB82/162 Datasheet. [Электронный ресурс] //Atmel. Режим доступа: http://ww.atmel.com/Images/doc7707.pdf - Загл. с ссылки.
[5] USB in NutShell. [Электронный ресурс] // Beyond Logic. - Режим доступа: http://www.beyondlogic.org/usbnutshell/usb1.html -Загл. с экрана.
[6] USB. [Электронный ресурс] // Википедия. - Режим доступа: http://ru.wikipedia.org/wiki/USB - Загл. с экрана.
[7] LUFA Library. [Электронный ресурс] // Режим доступа:
http://www.fourwalledcubicle.com/files/LUFA/Doc/13 0303/html/ - Загл. с экрана.
[8] HID API for Linux, Mac OS X, and Windows. [Электронный ресурс] // Режим доступа: http://www.signal11.us/oss/hidapi - Загл. с экрана.
[9] TrilithIC Data Sheer BTS781GP. [Электронный ресурс] // Режим доступа: http://www.datasheetcatalog.org/datasheet/infineon/1-BTS781GP 28-06-2002.pdf- Загл. с ссылки
Колкер Алексей Борисович - доцент кафедры автоматики НГТУ, к.т.н. E-mail fiery77@ya.ru
Горбунов Никита Олегович -магистрант кафедры автоматики НГТУ, E-mail n.o.gorbunov@mail.ru
