Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

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

.pdf
Скачиваний:
59
Добавлен:
19.03.2016
Размер:
6 Mб
Скачать

по основному каналу сообщений — устройство в фазе завершения может отве$ тить пакетом STALL, что будет означать отвергнутую команду. Уточнить состо$ яние можно, послав соответствующую команду, предполагающую получение состояния в фазе данных через точку Bulk IN;

по каналу передачи данных: обнаружив ошибку в процессе выполнения коман$ ды, устройство на очередную транзакцию Bulk IN/OUT ответит пакетом STALL. Уточнить состояние можно будет, послав следующий командный блок (пред$ варительно разблокировав точки запросом Clear_EP_Halt).

Данные передаются пакетами через точки Bulk IN и Bulk OUT, укороченный пакет служит признаком конца блока данных. Хост и устройство отслеживают соответ$ ствие объема передаваемых данных запрошенному в команде. В случае обнаруже$ ния несоответствия устройство может сигнализировать об этом передачей состоя$ ния через точку Interrupt IN или через ответ STALL в транзакциях передачи данных.

Сброс устройства можно выполнить, послав в запросе ADSC специальный команд$ ный блок с содержимым 1D, 04, FF, FF, FF... По этой команде устройство предпри$ мет попытку безопасного прекращения текущей операции, очистит все буферы и очереди. После этого хост должен выполнить запросы Clear_EP_Halt, чтобы раз$ блокировать точки и привести в исходное состояние переключатели Toggle Bit. Сброс через порт USB (по запросу к хабу) во время исполнения команды чреват потерей данных.

Прерывания (точка Interrupt IN) используются только для протокола 00. На каж$ дый посланный ADSC хост ждет прерывание; если устройство ответит на ADSC условием STALL, то для этой команды прерывание уже не ожидается. Если у уст$ ройства есть непереданный запрос прерывания, а хост посылает уже следующий ADSC, то прежний запрос прерывания устройство аннулирует.

Устройства человеко машинного интерфейса (HID устройства)

К классу HID (Human Interface Device) относятся устройства, обеспечивающие интерфейс между человеком и компьютером:

клавиатура, мышь, шар, другие устройства$указатели, джойстик;

органы управления на лицевой панели компьютера — кнопки, переключатели, регуляторы и т. п.;

органы управления, присущие пультам дистанционного управления аудио$ и ви$ деотехникой, телефонам, различным игровым симуляторам (рули, педали, штур$ валы и т. п.).

Для этих устройств характерен небольшой объем передаваемых данных, возника$ ющих для компьютера спонтанно (асинхронно), и умеренные требования к задерж$ ке обслуживания. К данному классу относятся и иные устройства с похожим ха$ рактером данных (считыватели штрихкода, термометры, вольтметры и т. п.). Подробно данный класс описан в документе Device Class Definition for Human

Interface Devices (HID), в 2001 году вышла его версия 1.11. Класс HID допускает работу устройств на любой скорости шины USB.

Деление на подклассы учитывает только необходимость поддержки данного уст$ ройства на этапе загрузки. Специальный код протокола выделяет только клавиа$ туру и мышь — стандартные устройства ввода.

С HID$устройствами хост обменивается сообщениями$рапортами (report), кото$ рые могут быть трех типов (Report Type):

тип 1 — ввод (Input) от устройства;

тип 2 — вывод (Output) в устройство;

тип 3 — управление свойствами (Feature).

Если устройство способно обмениваться разнообразными (не по типу, а по назна$ чению) рапортами, то каждый рапорт начинается с байта идентификатора рапор та (Reprt ID). Например, комбинация клавиатуры с указателем может давать как рапорты нажатий клавиш, так и рапорты устройства$указателя.

Интерфейс HID устройства обеспечивает двунаправленный обмен рапортами между устройством и драйвером. В нем имеется:

обязательный двунаправленный канал (через EP0) для вывода рапортов и вво$ да по опросу (полинг);

обязательный однонаправленный канал асинхронного ввода рапортов по пре$ рываниям (от устройства к его драйверу через точку Interrupt IN);

необязательный канал вывода по прерываниям; если у устройства имеется точ$ ка Interrupt OUT, то выводные рапорты передаются по ней.

HID$устройства имеют специальный классовый HID дескриптор, ссылающийся на дескриптор рапортов и набор физических дескрипторов (указываются тип и дли$ на этих дескрипторов, что позволяет получить их по запросу Get_Descriptor).

Дескриптор рапорта представляет собой сложную структуру, описывающую пе$ редаваемые данные: назначение (ввод, вывод или управление свойствами), исполь$ зование, диапазон допустимых значений, размер… Эта информация нужна драй$ веру HID$устройств, разбирающему (и собирающему) рапорты. Драйвер содержит модуль Item Parser, разбирающий, какому приложению следует передать тот или иной рапорт. Без должного дескриптора рапорта приложение рапорт ни принять, ни послать не сможет.

Набор физических дескрипторов описывает, какой частью тела1 человек воздей$ ствует на тот или иной орган управления. Эти дескрипторы необязательны и сооб$ щаются не многими устройствами; они вносят дополнительные сложности в опи$ сание, хотя позволяют приложениям точнее использовать те или иные органы.

HID$устройства поддерживают все стандартные запросы к устройствам и специ фические запросы, приведенные в табл. 16.3.

1Кроме привычных клавиатур, мышей и джойстиков существуют и более сложные. Например, «ки$ берперчатка» имеет множество датчиков положения, связанных с разными частями кисти оператора. Физические дескрипторы и позволяют связывать передаваемые параметры с действиями оператора.

Таблица 16.3. Классовые запросы к HID устройствам

Запрос

bmRequestType

bRequest

Get_Report

10100001

01

Get_Idle

10100001

02

Get_Protocol

10100001

03

Set_Report

00100001

09

Set_Idle

00100001

0A

Set_Protocol

00100001

0B

 

 

 

Запросы Get_Report и Set_Report служат для приема и передачи рапортов через EP0. Здесь в поле wValue старший байт задает тип рапорта, младший — его иденти$ фикатор. В поле wIndex задается номер интерфейса, поле wLength задает длину рапорта, который передается в фазе данных.

Запрос Set_Idle позволяет управлять подачей рапортов по каналу прерываний в случае отсутствия изменений состояния рапортуемых величин. Здесь в поле wValue старший байт задает длительность молчания в покое (idle duration), младший — идентификатор рапорта. В поле wIndex задается номер интерфейса, поле wLength = = 0 (фаза данных отсутствует). Если задана нулевая длительность, то устройство будет передавать рапорты только в случае изменений состояния (что требуется, например, для клавиатуры). Ненулевое значение трактуется как длительность интервала (в 4$миллисекундных единицах), в течение которого точка Interrupt IN отвечает на опросы NAK’ами, если нет изменений состояния. Так, например, можно уменьшить поток «пустых» данных опроса устройств$указателей (мыши или джойстика), не теряя быстроты реакции на события (задаваемая длительность и bInterval, задающий частоту опроса точки Interrupt IN, независимы).

Запрос Get_Idle позволяет считать текущее значение длительности для рапорта, идентификатор которого задан в младшем байте поля wValue. В поле wIndex зада$ ется номер интерфейса, поле wLength = 1 (принимается один байт данных).

Запрос Set_Protocol (только для устройств, участвующих в начальной загрузке) позволяет переключать протокол работы устройства. Тип протокола задается в поле wValue: 0 — протокол (упрощенный), используемый при загрузке (Boot Protocol); 1 — нормальный протокол рапортов (Report Protocol). В поле wIndex задается но$ мер интерфейса, поле wLength = 0.

Запрос Get_Protocol позволяет определить текущий протокол. В поле wIndex зада$ ется номер интерфейса, поле wLength=1 (принимается один байт данных).

Аудиоустройства

Аудиоустройства с точки зрения USB представляют собой, как правило, компо$ зитные устройства, содержащие набор независимых интерфейсов. Путь любого аудиосигнала в аудиоустройстве начинается с входного терминала (Input Terminal) и заканчивается на выходном терминале (Output Terminal). Между терминалами

могут находиться различные модули (Unit), осуществляющие какие$то преобра$ зования и соединения.

Терминалы могут быть различных типов:

USB терминал — подключение к шине USB, с помощью которого через конеч$ ные точки (как правило, изохронные) осуществляется доставка потоков аудио$ данных от хоста к устройству (входной терминал) или от устройства к хосту (выходной терминал)1. Для интерфейсов USB$терминалов определен подкласс 02 — AUDIOSTREAMING со своими специфическими дескрипторами, описы$ вающими способ доставки (и синхронизации) и формат потока;

входные (оконечные) терминалы: устройства для записи звуков — встроенные в устройства или внешне подключаемые микрофоны различных типов, наборы микрофонов для пространственной записи (каждой разновидности назначен свой код типа);

выходные (оконечные) терминалы: устройства для воспроизведения звуков — колонки разных типов, наушники;

двунаправленные (оконечные) терминалы: телефонные трубки и головные теле$ фонные гарнитуры, без эхоподавления и с ним;

телефонные терминалы: устройства подключения к телефонной сети и мини$ АТС;

внешние терминалы: аналоговые и цифровые входы и выходы различных стан$ дартов и форматов, включая интерфейсы S/PDIF и потоки аудиоданных, пере$ даваемые по шине IEEE 1394;

встроенные терминалы: проигрыватели грампластинок, CD, DVD, звуковое сопровождение TV и видеомагнитофонов, приемники (радио, телевизионные, спутниковые), устройства аналоговой и цифровой звукозаписи, радиопередат$ чики, синтезаторы, измерительные генераторы сигналов.

Всеми этими терминалами требуется управлять по шине USB; для них имеются дескрипторы, описывающие их управляемые свойства.

Модули (units), которые располагаются пути аудиосигнала, могут выполнять са$ мые разнообразные функции: коммутация, регулировка уровня, микширование, панорамирование, фильтрация, реверберация и все возможные эффекты, которые стали легко реализуемыми с применением цифровой формы обработки сигналов. Для этих модулей введен подкласс 01 — AUDIOCONTROL, тоже со своими специ$ фическими дескрипторами и запросами.

С аудиоустройствами тесно связаны и MIDI устройства, являющиеся приемни$ ками или источниками потоков MIDI$сообщений2. Для них введен подкласс 03 — MIDISTREAMING со своими специфическими дескрипторами и запросами. MIDI$ устройство USB может выступать как в роли простого конвертора интерфейсов (выполнять доставку сообщений между хостом и MIDI$разъемами на устройстве), так и MIDI$синтезатора, преобразующего MIDI$сообщения в аудиопотоки. При этом обрабатываться могут сообщения как с внешних разъемов, так и с шины USB.

1 Здесь вход и выход рассматриваются с точки зрения аудиоустройства, а не хоста. 2 Это команды для синтезаторов, но не собственно аудиоданные.

Синтезатор MIDI с точки зрения аудиоустройства является встроенным входным терминалом. Он поставляет аудиопоток, дальнейший путь которого определяется аудиоустройством (через интерфейсы подклассов 01 и 02).

Разрешение проблем при подключении устройств

Все спецификации USB разрабатывались (и разрабатываются) в расчете на пол$ ную поддержку Plug and Play и «горячего» подключения$отключения устройств. При этом в идеальном варианте с пользователя снимаются все заботы по конфигу$ рированию подключаемых устройств и установке его программного обеспечения. Однако на практике процесс подключения нового устройства происходит не все$ гда в таком «безоблачном» варианте. Проблемы, с которыми сталкиваются пользо$ ватели готовых устройств, как правило, сводятся к поиску подходящих драйверов и прикладного ПО. Конечно же, не надо забывать и о таких простых неполадках, как случайное отключение (опциями CMOS Setup) контроллера USB, находящегося на системной плате, а также ошибок подключения дополнительных разъемов USB.

В ОС Windows каждое подключенное устройство USB отображается в Диспетчере устройств (Device Manager). Для наглядности удобно в меню Вид выбрать опцию Устройства по подключению, тогда устройства будут отображаться в виде деревьев, «растущих» из шины PCI. Каждое дерево начинается со своего хост$контроллера, к которому подключен корневой концентратор (Root Hub). Заметим, что для каж$ дого дерева (то есть для каждого хост$контроллера) адреса устройств USB назна$ чаются независимо. К сожалению (но для удобства пользователя), диспетчер уст$ ройств Windows отображает только подключенные устройства и не отображает свободных портов хабов. Это усложняет понимание организации портов и кон$ троллеров. Более информативна утилита USB View (от Microsoft), которая под$ робнее отображает дерево устройств (хост$контроллеры, корневые хабы, проме$ жуточные хабы и конечные устройства). Для каждого элемента отображаются дескрипторы устройств, их конечных точек, а также состояние подключения:

номер выбранной конфигурации (Current Config Value);

скорость работы (Device Bus Speed);

адрес устройства (Device Address);

число открытых каналов (Open Pipes, не считая основного канала сообщений);

cостояние подключения (ConnectionStatus).

Для хабов в дереве отображаются ветки, соответствующие всем имеющимся его портам. Это позволяет определить внутреннюю структуру хост$части системы. Так, например, можно увидеть в компьютере с шестью портами USB и провозглашен$ ной поддержкой USB 2.0 «Расширенный хост$контроллер USB 2.0» (EHC) c шести$ портовым корневым хабом и три «Универсальных хост$контроллера USB», у каж$ дого из которых имеется по двухпортовому корневому хабу. В этом случае HS$ устройство можно подключать к любому порту и оно маршрутизирующей логикой

(см. главу 15) будет связано с контроллером EHC. Для устройств FS и LS каждая пара портов подключается к своему контроллеру$компаньону (UHC). В такой си$ стеме можно говорить о суммарной пропускной способности шины USB, равной 480 + 3×12 = 516 Мбит/с. Правда, из этого следует вычесть накладные расходы (см. главу 11) и не забывать о возможных ограничениях со стороны шины PCI, к которой подключены хост$контроллеры, и со стороны контроллера системной па$ мяти, которой контроллеры пользуются очень активно. Если бы мы в шестипорто$ вой системе увидели расширенный контроллер с четырехпортовым корневым хабом, это означало бы, что поддержка USB 2.0 имеется только на четырех портах из шести.

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

Для облегчения отладки собственных устройств полезно как$нибудь отображать информацию о текущем состоянии его интерфейсной части (блока SIE, см гла$ ву 13). Это отображение должно быть автономным (индикация на самом устрой$ стве, а не средствами хост$компьютера). На начальном этапе отладки достаточно индицировать четыре состояния:

«Запитано» (Powered State);

«Дежурное» состояние (Default State);

«Адресовано» (Addressed State);

«Сконфигурировано» (Configured State).

Устройство, подключаемое к шине USB, должно последовательно пройти от со$ стояния «запитано» до «сконфигурировано». По тому, в каком состоянии «застре$ вает» подключаемое устройство, можно судить о событиях, происшедших в систе$ ме, и найти неполадки.

Если устройство при подключении «зависает» в состоянии «запитано», это может быть вызвано рядом причин:

хост не получает сигнала о подключении устройства. Следует проверить нали$ чие высокого логического уровня на линии D+ (для FS/HS$устройства) или D$ (для LS$устройства), который должно обеспечить устройство. Этот сигнал мо$ жет не дойти до хоста при неплотном соединении разъема USB (в нем сигналь$ ные цепи замыкаются позже питающих);

хост не реагирует на сигнал подключения. Нормально хост реагирует посылкой сигнала шинного сброса — занулением линии D+ или D на 10–20 мс, этот им$ пульс легко можно увидеть с помощью осциллографа. «Заснувший» хост мо$ жет и не реагировать на подключение (не посылать сигнал сброса). Доводилось наблюдать, как хост с ОС UNIX перестает реагировать на подключение LS$уст$ ройства (даже стандартной мыши) после многократных (с интервалом в несколь$ ко секунд) подключений/отключений его к одному и тому же порту корневого хаба. После этого подключение того же устройства к другому порту восприни$ мается нормально. Более того, последующее подключение этого устройства к порту, на котором реакция на подключение прекращалась, снова восприни$ мается нормально;

устройство не реагирует на сигнал шинного сброса. Нормально устройство долж$ но по сигналу шинного сброса перейти в «дежурное» состояние.

Если устройство «зависает» в «дежурном» состоянии, это означает его неспособ$ ность сообщить дескрипторы и исполнить запрос назначения уникального адреса. Здесь определить неисправность несколько сложнее, поскольку требуется просмо$ треть пакеты запросов, принимаемые и передаваемые устройством. Причины не$ корректного обмена пакетами могут быть как в электронике, так и в микропро$ граммном обеспечении (firmware). В электронной части, например, может быть неправильная частота генератора, синхронизирующего SIE контроллера устрой$ ства USB, или неисправности в сигнальных цепях. В микропрограммном обеспе$ чении следует проверить дескрипторы, сообщаемые устройством.

Зависание в состоянии «адресовано» может означать, что подключенным устрой$ ством никто в системе не заинтересовался и не пытается сконфигурировать. Это происходит, например, когда ОС не может связать с обнаруженным устройством подходящий драйвер. Обнаруженное устройство идентифицируется кодами VID (код производителя) и PID (код продукта) в своих дескрипторах (см. главу 13). Также это может происходить в случае подключения HS$устройства, критичного к скорости передачи, к FS$порту.

В поддержке устройств USB, по крайней мере в ОС Windows, наблюдается стран$ ность (с точки зрения автора) в учете устройств. Каждое вновь подключенное уст$ ройство после установки его ПО поддержки оставляет в реестре Windows запись, в которой некоторый идентификатор устройства связывается с именами модулей ПО, его поддерживающих. Странность заключается в том, что вместе с такими бес$ спорными идентификаторами устройства, как VID и PID, в реестре фиксируется и номер порта. Если то же устройство переключить в другой порт, то ОС это вос$ примет как подключение нового(!) устройства и снова начнет установку ПО под$ держки, создавая и новую запись в реестре. Отключение устройства не вызывает удаления записи из реестра, так что реестр будет «обрастать» лишними записями. Само по себе это не так уж важно (вопрос о компактности записей, похоже, давно уже решен в пользу лени), но ПО некоторых устройств отказывается загружаться (или работать), когда в реестре прописан его двойник с другим адресом. В этой ситуации приходится либо возвращать устройство в порт первоначального под$ ключения (что не всегда удобно), либо вручную чистить реестр (что не к лицу ря$ довому пользователю). Вероятная причина этой странности — упрощение иден$ тификации нескольких однотипных устройств, одновременно подключенных к компьютеру. Использование номера порта, который является сравнительно слу$ чайным (пользователь подключает устройство в первый попавшийся разъем), для идентификации устройства следовало бы заменить на уникальный идентифика$ тор конкретного экземпляра устройства. Для этого спецификацией USB в деск$ рипторах устройства определены все необходимые элементы, включая строковый дескриптор с серийным номером. «Глубина залегания» этой странности — типо$ вые драйверы устройств (подвластные их разработчикам) или системный драйвер USBD (за него отвечает разработчик ОС), на момент написания книги автором не выяснена.

Шина IEEE 1394 — FireWire

Высокопроизводительная последовательная шина (High Performance Serial Bus) IEEE 1394 — FireWire создавалась как более дешевая и удобная альтернатива па$ раллельным шинам (SCSI) для соединения равноранговых устройств. Шина по$ зволяет связать до 63 устройств без применения дополнительной аппаратуры (ха$ бов). Устройства бытовой электроники — цифровые камкордеры (записывающие видеокамеры), камеры для видеоконференций, фотокамеры, приемники кабель$ ного и спутникового телевидения, цифровые видеоплееры (CD и DVD), акусти$ ческие системы, цифровые музыкальные инструменты, а также периферийные устройства компьютеров (принтеры, сканеры, устройства хранения данных) и сами компьютеры могут объединяться в единую сеть. Шина не требует управления со стороны компьютера. Шина поддерживает динамическое реконфигурирование — возможность «горячего» подключения и отключения устройств. События подклю$ чения/отключения вызывают сброс и реинициализацию: определение структуры шины (дерева), назначение физических адресов всем узлам и, если требуется, вы$ боры мастера циклов, диспетчера изохронных ресурсов и контроллера шины. Че$ рез доли секунды после сброса все ресурсы становятся доступными для последую$ щего использования, и каждое устройство имеет полное представление обо всех подключенных устройствах и их возможностях. Благодаря наличию линий пита$ ния, интерфейсная часть устройства может оставаться подключенной к шине даже при отключении питания функциональной части устройства.

По инициативе VESA шина позиционируется как основа «домашней сети», объ$ единяющей всю бытовую и компьютерную технику в единый комплекс. Эта сеть является одноранговой (peer$to$peer), чем существенно отличается от USB.

Основные свойства шины FireWire перечислены далее.

Равноранговость. Шина позволяет любым своим абонентам обмениваться дан$ ными друг с другом. Для организации обменов не требуется хост$компьютер (и его ресурсы — память и процессор), который мог бы стать «бутылочным гор$ лом» при интенсивных обменах.

Универсальность. Шина обеспечивает передачу как асинхронного, так и изо$ хронного трафика. Это позволяет объединять в единую сеть компьютеры, их пе$ риферийные устройства (принтеры, сканеры, устройства хранения) и цифро$ вую аудио$видеотехнику.

Надежность. Шина обеспечивает контроль достоверности передачи, обработ$ ку и исправление ошибок.

Легкость установки и использования. Для начала работы достаточно соединить устройства, соблюдая несложные топологические правила.

Большое число соединяемых устройств. Одна шина может объединять до 63 уст$ ройств (узлов). Возможно объединение в единую сеть нескольких шин (фор$ мально — до 1024) с помощью мостов или коммутаторов.

Свободная топология. Устройства могут иметь один или несколько портов. По$ средством унифицированных кабелей устройства соединяются произвольным образом, исключая лишь петлевые соединения. Ограничение — между любой парой конечных узлов должно быть не более 16 промежуточных узлов.

Большая протяженность. Длина одного кабельного сегмента, соединяющего пару устройств, может достигать 4,5 м. Ограничение — суммарная длина кабе$ ля в одной шине не должна превышать 72 м.

Полная поддержка PnP с динамическим конфигурированием:

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

поддержка «горячего» подключения отключения. Любое событие подключе$ ния/отключения вызывает реинициализацию шины, после которой форми$ руются новое дерево и новая нумерация узлов. Во время реинициализации «полезный» обмен данными прерывается, но время реконфигурирования невелико — менее 400 мс в старой шине и менее 200 мкс для 1394a.

Сосуществование на одной шине устройств с различными скоростями обмена. Для шины определен ряд стандартных скоростей: S100, S200, S400; в IEEE 1394b (2002 год) определены новые скорости: S800, S1600 и S3200. При обменах вы$ бирается скорость, доступная узлам, вовлеченным в передачу.

Высокая скорость обмена и изохронные передачи. Даже на начальном уровне S100 (около 100 Мбит/с) по шине можно передавать одновременно два канала видео вещательного качества (30 кадров в секунду) и аудиосигнал с качеством CD (стерео).

Питание от шины. Шина обеспечивает питание устройств постоянным током до 1,5 А с напряжением 8–40 В.

Малое число цепей. В шине используются две экранированные витые пары для передачи сигналов и дополнительно пара проводов для питания от шины.

Возможность гальванической развязки. Компоненты физического уровня, элек$ трически связанные с коннекторами и кабелями, могут быть развязаны по по$ стоянному току от остальных компонентов устройства. В новых вариантах сре$ ды передачи IEEE 1394b возможна полная гальваническая развязка узла от кабеля и применение оптоволоконной связи.

Низкая цена компонентов и кабеля (по сравнению со SCSI).

Организация и топология шины

Стандарт IEEE 1394 описывает шину с последовательным интерфейсом, по кото$ рой информация передается пакетами. Источник пакетов должен получить право передачи пакета, используя механизм арбитража, в котором задействуются все устройства, подключенные к шине. Арбитраж предоставляет узлам право доступа в соответствии с запрошенным типом передачи. Для асинхронных транзакций ар$ битраж обеспечивает справедливое распределение полосы пропускания, для изо$ хронных передач — гарантированную (предварительно согласованную) полосу про$ пускания для каждого канала. Коллизии (столкновения пакетов от нескольких устройств) в исправной шине отсутствуют.

Все устройства соединяются друг с другом кабелями на основе любой топологии (древовидной, цепочечной, звездообразной). Каждое устройство (узел сети) обычно имеет несколько равноправных соединительных разъемов, представляющих его порты. Некоторые устройства имеют только один разъем, что ограничивает воз$ можные варианты их месторасположения. В современной редакции стандарт до$ пускает до 16 портов (разъемов) на одном устройстве, чаще встречаются 1–4$пор$ товые устройства. Многопортовые узлы позволяют соединять множество узлов IEEE 1394 без использования вспомогательного оборудования (хабов). Внутри многопортового узла имеется повторитель, транслирующий пакеты и управляю$ щие сигналы между портами.

Устройства на шине могут передавать данные на разных скоростях. Базовой скоро стью, поддерживаемой любым устройством, является S100. На этой общедоступ$ ной скорости передаются все служебные пакеты, в том числе и пакеты самоиден$ тификации. Если устройство поддерживает высокую скорость (например, S400), то оно обязано поддерживать и все более низкие скорости вплоть до базовой. Па$ кеты транзакций могут передаваться на любой скорости, доступной узлам, связан$ ным кабельным сегментом. При этом перед посылкой пакета на скорости, отлич$ ной от базовой (S100), передающий узел посылает сигнал выбранной скорости (см. главу 22). Пакет, приходящий на один порт устройства на высокой скорости, узел не будет транслировать на порт, для которого установлена более низкая ско$ рость. Таким образом, скорость, на которой возможно прохождение пакета между произвольной парой узлов, зависит от скоростных возможностей этих узлов и про$ межуточных узлов, лежащих на пути между ними. Отсутствие ответа на пакет, по$ сланный на высокой скорости, служит поводом для повторной попытки посылки на более низкой скорости. Заранее узнать доступную скорость можно по карте ско$ ростей — двухмерной матрице, в которой для каждой пары узлов шины указывает$ ся максимальная возможная скорость передачи. Эта карта доступна только при наличии диспетчера шины (см. главу 21).

Кабельная шина допускает большую свободу выбора топологии физических соеди нений при соблюдении следующих ограничений:

на шине может быть не более 63 узлов;

между любой парой узлов может быть не более 16 кабельных сегментов (в 1394a допускается до 24 сегментов);