Шины.PCI,.USB.и.FireWire

программно$управляемую подачу управляющих воздействий на устройство с вре$ менным разрешением порядка единиц микросекунд. Если при формировании воз$ действий не требуется анализ ответа устройства, то программно можно форми$ ровать и более быстрые управляющие сигналы (доли микросекунды). Однако большие объемы данных таким способом передавать не рекомендуется — слиш$ ком велика будет загрузка и шины, и процессора. Для интенсивных передач вы$ годно использовать DMA, для чего устройство должно быть мастером шины. При использовании DMA программные действия (инициализация сеансов обмена) те$ ряют жесткую синхронизацию с физическим обменом с устройством.

Реализация интерфейса USB

Интерфейс USB, несмотря на довольно сложный протокол обмена, вполне досту$ пен для периферийных устройств собственной разработки. Рядом фирм выпуска$ ется широкий ассортимент микросхем, со стороны USB различающихся скоростя$ ми обмена (LS, FS или HS), числом и возможностями конечных точек (тип передач, размер буфера). Реализация интерфейса USB в периферийном устройстве может быть различной, но во всем многообразии можно выделить два основных подхода:

микроконтроллер (или программируемая логическая матрица), на котором ре$ ализованы основные прикладные функции устройства, имеет встроенный порт USB. Выбор микросхемы для такого решения определяется требованиями при$ кладной части устройства к производительности процессора, необходимой пери$ ферией (аналоговые и дискретные порты ввода$вывода, таймеры, допол$ нительные интерфейсы) и, наконец, возможностями USB$порта (скорость и характеристики конечных точек). В этом случае разработчику устройства при$ ходится кроме прикладной части заниматься и вопросами взаимодействия по шине USB. Эти вопросы включают как программированием микроконтролле$ ра, так и разработку USB$драйверов устройства на хост$компьютере;

для организации интерфейса USB используется отдельная микросхема (про$ граммируемый микроконтроллер или микросхема с фиксированными функци$ ями), соединяемая с прикладной частью устройства, как правило, параллель$ ной шиной. В этом случае микросхема с USB выполняет сугубо транспортные функции: потоки, посылаемые через конечные точки USB, направляет в при$ кладную часть устройства (или из нее). В этом случае можно обойти вопросы интерфейса USB (микропрограмму и драйверы), воспользовавшись готовым транспортным решением. Для этого выпускаются микросхемы с фиксирован$ ными функциями преобразования интерфейсов, например USB–ATA (вклю$ чая и режимы UltraDMA), USB–RS$232, USB–Centronics, USB–ECP и другие.

С портом USB выпускаются микроконтроллеры на ядре MCS51, M68HC05, M68HC11 или RISC$архитектуры; они различаются объемом памяти (оператив$ ной и энергонезависимой), производительностью, питанием, потреблением. Мик$ роконтроллеры могут иметь встроенные устройства АЦП/ЦАП, дискретные ли$

нии ввода/вывода общего назначения, последовательные и параллельные порты различных типов. Из этого ассортимента можно выбрать подходящую микросхе$ му, на базе которой разрабатываемое устройство будет реализовано с минималь$ ным числом дополнительных элементов. К микроконтроллерам прилагаются и средства разработки их встроенного ПО (firmware) — самой сложной части та$ кого устройства.

Есть микроконтроллеры с USB, способные работать без программирования энер$ гонезависимой памяти. Так, например, микроконтроллеры серии EzUSB фирмы Cypress Semiconductor позволяют использовать EEPROM малого размера, чтобы хранить в нем только идентификаторы. По включении питания прикладного мик$ ропрограммного обеспечения в устройстве нет, и до его загрузки с к компьютера устройство остается функционально «мертвым». Однако при подключении к шине USB устройство предоставляет дескрипторы со своими идентификаторами (VID, PID), по которым с ними связываются специализированные драйверы. Кроме того, устройство «умеет» по специфическому запросу от хоста (Firmware_Load) загружать по шине USB микропрограмму из хост$компьютера в свое ОЗУ и запускать ис$ полнение этой программы. В процессе исполнения загруженной микропрограммы устройство может «обрасти» новыми свойствами и дескрипторами. Чтобы хост воспринял устройство в его новом качестве, выполняется так называемая ренуме рация (ReNumeration™): микропрограмма отключает, а потом снова включает порт USB. Хост это воспринимает как подключение нового устройства, считывает его новые дескрипторы и конфигурирует устройство. Конечно, такая гибкость нужна не всегда, но это особенно удобно при разработке и совместной отладке всех аппа$ ратных и программных компонентов устройства, включая и его микропрограмм$ ную поддержку.

Есть и периферийные микросхемы USB — порты USB, подключаемые к микрокон$ троллерам параллельной 8/16$битной шиной данных с обычным набором управ$ ляющих сигналов (CS#, RD#, WR#...), линией запроса прерывания и, возможно, сиг$ налами каналов DMA.

Есть и микросхемы USB, сочетающие в себе и USB$функции, и хабы. Все вариан$ ты не перечислить, тем более что все время появляются новые микросхемы. Ин$ формацию о них можно найти в Сети (www.cypress.com, www.devasys.com, www.iged. com, www.microchip.com, www.netchip.com, www.motorola.com, www.semiconductor.philips. com, www.ti.com, www.natsemi.com, www.intel.com, www.ftdichip.com, www.gigatechnology. com).

Немаловажная часть разработки собственных устройств — программное обеспе$ чение для хост$компьютера, которое доносит до пользователя всю функциональ$ ность устройства. В ряде случаев удается воспользоваться готовыми драйверами (например, драйвером виртуального COM$порта для преобразователя интерфей$ са). В других случаях ПО приходится писать самостоятельно, и хорошо, когда изго$ товитель микросхем с USB заботится о предоставлении инструментальных

средств разработки всех частей ПО. Так, например, фирма Cypress для своих микро$ схем с USB (микроконтроллеров и периферийных ИС) поставляет универсаль$ ный драйвер, поддерживающий обращения к конечным точкам всех типов (управ$ ление по EP0, точки для передачи массивов, изохронных обменов и прерывания). При установке этого драйвера в реестре Windows автоматически прописываются предопределенный список кодов производителя и устройства (VID и PID), с ко$ торыми будет связан данный драйвер. В дескрипторе устройства его разработчик должен поместить один из вариантов сочетаний идентификаторов, и по подклю$ чении данного устройства к шине USB ОС автоматически загрузит его драйвер. Прикладное ПО, связанное с данным устройством, должно обращаться к этому драйверу (напрямую или через промежуточные библиотечные функции). Если разработчик позаботился о создании строкового дескриптора устройства, ОС ото$ бразит его содержимое по подключении данного устройства.

Подключение через USB имеет свою специфику, обусловленную природой USB — хост$центрической шины, подключающей множество устройств через один кон$ троллер. Устройство с интерфейсом USB всегда сугубо подчиненно, всем обменом управляет программа, исполняемая центральным процессором. При этом момен$ ты физического обмена данными с устройством (реального управления устрой$ ством) отделены от моментов формирования этих данных программой (то есть подачи управляющих воздействий). Интервал времени между этими событиями — неопределенный и весьма ощутимый: драйвер USB не может (и не будет) мгно$ венно отдать хост$контроллеру в работу свежепоступивший запрос на передачу (IRP). Во$первых, драйверу приходится должным образом оформлять запрос в виде дескриптора передачи (а для контроллера UHC его требуется еще и разбить на транзакции), на что уходит время. Во$вторых, драйвер должен согласовывать мо$ мент времени, в который он вводит новый дескриптор, с циклом работы контрол$ лера, привязанным к кадрам шины USB. В$третьих, запрос попадает в очередь, которая к этому моменту может быть и не пустой — когда именно контроллер до$ берется до данной передачи, заранее не известно. Таким образом, задержка от мо$ мента формирования выводимых данных до их поступления в устройство может в лучшем случае исчисляться единицами$десятками миллисекунд, а в худшем (при большой загрузке шины и процессора) — и того больше. Если программное взаи$ модействие с устройством требует двунаправленного обмена информацией, то надо принимать во внимание и взаимную несинхронизированность обменов с разными конечными точками устройства (см. главу 9). Синхронизацию ввода и вывода обес$ печивают только конечные точки типа Control, но они не обеспечивают высокой скорости обмена и не всегда достаются разработчику для прикладного использо$ вания. Пример$подсказка решения задачи синхронизации — протокол Bulk Only Transport для устройств хранения — описан в главе13. Синхронизация изохрон$ ных конечных точек — несколько иная и довольно сложная тема.

Уже из этого поверхностного описания особенностей подключения по USB стано$ вится ясно, что программно$управляемые интерфейсы (аналогичные, например,

программной реализации протокола Centronics для параллельного порта) будут работать слишком медленно. Если очередной шаг протокола интерфейса (вывод) выполняется по результату ввода текущего состояния устройства, то разрешение порядка единиц миллисекунд — это слишком оптимистичная оценка его быстро$ действия, даже для устройств HS (USB 2.0). Для диалогов, критичных к времени, можно использовать конечные точки типов Interrupt IN и Interrupt OUT, что и де$ лается, например, в HID$устройствах. Однако пропускная способность этих точек высока только на HS в USB 2.0. Шина USB предоставляет довольно высокую про$ пускную способность для потоковых обменов, что и следует учитывать, разраба$ тывая концепцию взаимодействия с устройством. Взаимодействие будет эффек$ тивным, если оно ведется пакетами, а не одиночными операциями чтения$записи байтов. Для взаимодействия с регистро$ориентированными устройствами удобно использовать точки типа Control.

Прерывания от устройств USB, как это ни парадоксально звучит, планируются хостом: в дескрипторе передачи устанавливается специальный бит$признак, за$ ставляющий хост$контроллер выработать запрос прерывания по ее выполнении. При этом хост$контроллер может быть запрограммирован на некоторую задержку подачи запроса прерывания, что позволяет сократить число прерываний процес$ сора: один запрос от контроллера может сигнализировать прерывания от несколь$ ких устройств.

Передача данных по прерываниям от устройства (через точки типа Interrupt) опять$ таки планируются хостом. В соответствии с параметрами точки (периодом обслу$ живания) хост циклически пытается выполнить передачу (ввод или вывод дан$ ных). Реально передача происходит по готовности устройства. При этом генерация прерывания процессору может быть как разрешена, так и запрещена. Отметим, что по прерываниям можно как вводить данные (через точки Interrupt IN), так и выво$ дить (через точки Interrupt OUT). О возможности вывода по прерываниям порой забывают.

Изохронные передачи на USB возможны только между памятью хоста и пери$ ферийным устройством; ими управляет только хост$контроллер. Непосред$ ственная изохронная передача между устройствами (как в FireWire) на USB невозможна.

Реализация интерфейса FireWire

Разработка собственных устройств с интерфейсом FireWire может оказаться не$ сколько сложнее, чем с интерфейсами PCI или USB. Этому есть несколько при$ чин: круг производителей микросхем FireWire и их ассортимент у же, чем USB; многие спецификации, связанные с FireWire, не являются общедоступными; иде$ ология взаимодействия по шине FireWire существенно отличается от других ин$ терфейсов. Последний тезис развернем подробнее.

Та же фирма выпускает контроллер аудиоустройств OXFW970, в котором имеет$ ся интегрированный интерфейс 1394a/b (LINK и PHY S800) и 4 последователь$ ных выходных аудиоинтерфейса, каждый из которых может передавать данные пары каналов. К этим интерфейсам подключаются ЦАП’ы разрядностью 16/24/32 бит; микросхема поддерживает частоты выборок 32, 44,1 и 48 кГц. Микросхема под$ держивает форматы аудиопотоков в соответствии со стандартом 61883$6 (см. гла$ ву 24).

Микросхемы для FireWire выпускаются и другими фирмами, их можно найти в Сети, например, по ключевым словам «1394 LINK chip».