Предшествующие реализации.

Ни смотря на то, что в настоящее время USB устройства являются достсточно распространенными, поддержка их различными ОС несколько отставала от успехов производителей соответствующего "железа". Так, например, если возможность работать напрямую с собственным устройством, подключенным к последовательному порту RS232 при помощи стандартного компонента из программы Visual Basic или Delphi является весьма обычным делом, то это вряд ли можно сказать про USB, а тем более Fire Wire.
Существуют два осовных способа работы прикладной программы с USB/FireWire устройствами: первый - обращение к специализированным API драйверов верхнего уровня, которые обеспечивают доступ к абстрактному устройству (сканеру, принтеру, диску и.т.п.), скрывая при этом от программы детали, связанные с работой последовательной шины и второй способ, когда используется API нижнего уровня, предоставляющее доступ непосредственно к шине на уровне пакетов, каналов передачи, регистров CSR и.т.п.

Аппаратные интерфейсы шины ШЕЕ 1394 в отличие от USB не разделяются на хосты и устройства, однако существуют комплекты микросхем предназначенные для сложных полнофункциональных устройств, таких как например компьютеры, и для более узкоспециализированных, например видеокамер.

Производители электронных компонентов выпускают специализированные микросхемы, реализующие протоколы USB хоста и устройства. С использованием этих микросхем можно реализовать собственные аппаратные решения для шины USB. Кроме того, для реализации каких-либо дополнительных возможностей не предусмотренных производителями можно воспользоваться микросхемами программируемой логики (PLIS), в качеств отправной точки для этого можно воспользоваться например VHDL прошивками USB драйверов доступными на сайте www.opencores.org. Последнее может быть интересно так же с точки зрения изучения электрического протокола шины.

Для регистров Configuration ROM предусмотрен минимальный формат, который содержит только 24 битовый VendorlD и общий формат, представляющий собой набор директорий, содержащих специфическую информацию. Минимальный формат имеет следующий вид

Регистры PHY обеспечивают низкоуровневый интерфейс к шине, они могут быть прочитаны другими устройствами, желающими получит информацию о числе портов, максимальной скорости передачи, версии поддерживаемого стандарта IEEE 1394 и.т.п., поддерживаемых данным устройством. Некоторые из этих регистров могут быть изменены при помощи посылки пакетов PHY Configuration. Например можно дать устройству комнаду задержать свое участие в процедуре Tree Identification на 167 микросекунд, с тем чобы оно не смогло получить роль менеджера шины.

Начиная со смещения 0x800 от начала Initial Units Registers располагаются регистры Unit
registers, наиболее важными из которых являются
TOPOLOGYMAP (диапазон адресов 0xl000-0xl3FC)
SPEEDMAP (диапазон адресов 0x2000 - 0x2FFC)
Устройство, которое оказывается менеджером шины, запоминает первые 4 байта из SelflD
пакетов, в том порядке в котором их посылают устройства во время процедуры Self
Identification.
На основании этой информации любое устойство, которому это потребуется может
восстановить топологию шины.
Формат TOPOLOGYMAP следующий:
16 бит длина всей таблицы.
16 6HTCRC.
32 бит generationnumber - количество раз, которое менеджер шины генерировал карту
топологии шины.
16 бит число подключенных устройств
16 бит selfidcount - общее число SelflD пакетов, посланных устройствами.
Дальше сдедуют 4 байтовые фрагменты SelflD пакетов в количестве selfidcount.
Регистр SPEEDMAP содержит от 0 до 4029 чисел, определяющих максимальную скорость. передачи между каждой парой устройств. Заголовок такой же в регистре TOPOLOGYMAP, в след за которым размещены однобайтовые элементы (симметричной) матрицы скоростей.

Устройства, использующие изохронную передачу обязаны иметь эти регистры. Содержимое регисттров обновляется с частотой 24.576МГц, отчитывая 125 микросекундные интервалы (тайм слоты).

Взаимодействие ПО с шиной происходит как на уровне транзакций (Transaction layer) так и на уровне связи (Link layer) для чего определены понятия программных интерфейсов FireWire: интерфейс асинхронных транзакций, интерфейс изохронной передачи, минующий уровень транзакций и обращающийся напрямую к Link layer, а так же интерфейс управления шиной (Bus management interface). Каждый из этих программных интерфейсов как правило обеспечивается отдельным драйверов ядре ОС. Эти интерфейсы используют прикладные драйверы устройств, например таких как внешний накопитель FireWire.

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

Потребители очевидно имеют 6 контактные разъемы и POWERCLASS равный 4,6 или 7. Для поддержания уровня PHY активным таким устройствам требуется не более 3 ватт, После получения PHY пакета link-on, такие устройства могут потреблять дополнительную энергию для работы уровня LINK. Если требования устройству к потреблению питания не укладываются полностью ни в один POWERCLASS, то директории Configuration ROM содержат дополлнительную информацию.

В отличие от USB, устройства Fire Wire могут не только иметь собственный источник питания, но и поставлять питающе напряжение через шину другим устройствам. Стандарт ШЕЕ 1394 определяет целую систему упреждающего оповещения о возможной потере тем или иным устройством способности поставлять питающее напряжение в шину.

Для классификации USB устройств по отношению к питающему напряжению вводится единица нагрузки по току величиной в 100 миллиампер (в зависимоти от условий питающее напряжение в разных частях шины может окахываться в диапазоне от 4.40 до 5.25 вольт).

Для передачи битов данных USB использует NRZI кодирование (для сравнения FireWire использует NRZ), смысл использования таких кодировок состоит в упрощении синхронизации передающих и приемных цепей устройств друг с другом. Подобные кодировки обеспечивают повышенное количество переходов между уровнями логического нуля и единицы по сравнению с непосредственной передачей битовой последовательности.

Спецификация FireWrare определяет для протокола обмена данными следующие уровни

Хост передает устройству IN/OUT token пакет и вслед за ним принимает пакет данных isochron. Никакого handshake, никакой повторной передачи. Доставка данных не гарантирована, однако хост инициирует передачу пакетов с достаточной частотой и регулярностью, что каждый изохронный канал получает определенную (заявленную устройством) полосу пропускания для передачи. При этом максимальная латентность при передаче определяется только длительностью таймслота, которая составляет 1 миллисекунда для USB1.0 и 125 микросекунд для USB2.0.