Stfw.Ru8bit 0x01 I 24bit VendorlD
Формат общего вида содержит заголовок, корневую директорию и поддиректории. Пример того, как правильно прочитать и расшифровать содержимое Configuration ROM, можно найти в документации по видеокамере Sony, которая обсуждается ниже в этой главе.
Кроме того, устройство может быть составным и содержать в себе несколько единиц (unit) в этом случае Configuration ROM, содержит отдельные директории с информацией о каждой единице.
Структура ROM общего формата состоит из ряда блоков (включая директории), длина которых кратна октету (32 бита). Заголовок этой структуры состоит из следующих полей: infolength (8 бит), crclength (8 бит), romcrc (16 бит). Поле infolength позволяет программам отличать ROM минимального формата от ROM общего формата. Для минимального формата первые 8 бит содержат число 1. В свою очередь crclength указывает общую длину памяти, покрытой CRC.
Вслед за заголовком находится состоящий из четырех октетов businfoblock, Первый его октет содержит ASCII представление названия шины ("1394"). Второй октет содержит информацию о способностях устройства по отношению ка работе шины, для 1394а формат является расширением такового для 1394-1995:
Регистр Длина (бит)
irmc 1 Флаг способности устройства быть менеджером изохронных ресурсов
cmc 1 Флаг способности выполнять роль Cycle master
isc 1 Флаг поддержки изохронной передачи
bmc 1 Флаг способности быть менеджером шины
pmc 1 Флаг способности выполнять роль Power manager (1394a)
reserved 4
cyc_clk_acc 8 Для устройств с установленным cmc содержит значение точности тактов часов в единицах миллионных долей секунды (допустимые значения от 0 до двоичного 100), для прочих устройств заполнен единицами.
max rec 4 Задает значение максимальной длины асинхронного пакета с которым может работать данное устройство. Длина вычисляется как 2 в степени единица плюс значение данного регистра. В настоящее время используются значения от 0 до 10,
reserved 4
gen 2 Флаг, указывающий изменялось ли содержимое Configuration ROM со времени предыдущего bus reset(1394a)
reserved 3
linkspeed 3 (1394а)
И наконец последние два октета, содержат nodevendorid 24 бит и вслед за ним 40 бит chipid. Эти 64 бита должны однозначно идентифицировать данное устройство. То же самое значение содержится в директориях в структуре Nodeuniqueid leaf.
Следом за businfoblock располагается структура директорий, начинающаяся с Rootdirectory. В корневой директории ROM общего формата должны обязательно присутствовать следующие поддиректории: ModuleVendorld, NodeCapabilities, NodeUniqueld. Директория NodeUniqueld в версии стандарта 1394а более не является обязательной так как составляющие NodeVendorlD и ChipID доступны в businfoblock.
Директории и файлы имеют следующий формат: 2 бита тип ключа, 6 бит значение ключа, 24 бита содержимое. Тип ключа определяет как же собственно найти объект, возможны следующие варианты: 0 означает что далее следует непосредственно значение, 1 указывает на то, что далее идет значение смещения (от начала Initial Registers Space) где находится параметр, 2 означает что далее идет ссылка на файл и наконец 3 означает ссылку на директорию. Значение ключа определяет назначение и тип объекта, возможные значения приведены в таблице.
Значение ключа
0x03 Modul eVendorld
ОхОС Node_Capabilities
OxOD NodeUni queld
0x02 Bus Dependant Info (директория или файл)
0x04 Modul eHardwareVer si on
0x05 ModuleSpecId
0x06 Modul e_S oftware_Ver si on
0x07 Module Dependent Info (директория или файл)
0x08 Node_Vendor_Id
0x09 NodeHardwareVersi on
ОхОА Node_Spec_Id
0x0В Node_S oftware_Versi on
0x10 Node Dependent Info (директория или файл)
0x11 Unit Directory (одна для каждого входящего в состав unit-a)
Длполноты изложения в таблице ниже приводятся так же битовые флажки NodeCapabilities (каждый флажок имеет длину 1 бит и первый флажок начинается в позиции 9, т.е. Первые 8 бит не используются), их назначение здесь не обсуждается:
Флажок в Node_Capabilitie
s Описание
spt Поддержка Split timeout
ms Реализованы регистры Messaging_passing
int Реализованы регистры Interrupt target и Interrupt mask
ext Реализованы регистры Argument
bas Реализованы регистры Test start и Test status
Флажок в Node_Capabilitie
s Описание
prv Данный Node реализует private space
64 Используется 64 разрядная адресация
fix Используется фиксированная адресация (всегда установлен)
1st Реализован Lostbit в Stateclear и Stateset
drq Реализован Disablerequest в Stateclear и Stateset
r Зарезервирован
elo Реализован регистр Error log и соответствующий бит в в State clear и State_set
atn Реализован бит Attention в Stateclear и Stateset
off Реализован бит Off в State clear и State set
ded Поддерживается режим dead state
init Поддерживается режим initializing state
Структура NodeUniqueld следующая: соответствующий файл содержит в своем заголовке смещение, указывающее на содержимое состоящее из 16 битового значения 0x0002, CRC16 бит (покрывающее оставшиеся поля), 24 ,bn Nodevendorid, 40 бит Chipid.
Из описания регистров CSR (Control and Setup Registers) видно, что реализация всего этого набора со стороны устройства может оказаться не таким уж простым делом по сравнению с с USB и даже PCI устройством. Задачу может несколько упростить наличие стандарта на реализации чипов FireWire уровней PHY и LINK, называемого OHCI-1394 (Open Host Controller Interface). Тем не менее с этой задачей в настоящее время весьма успешно справляются некоторые отечественный производители электронного оборудования, такие как например "Инструментальные Системы" (www.insys.ru). "Инструментальные Системы"предлагают специализированные системы сбора данных, некоторые из которых используют FireWire для связи с компьютером.
Рассмотрим как все это может использоваться на примере цифровых видеокамер Sony XCD-SX900 и XCD-X700, подробное описание протоколы работы которых можно найти на сайте производителя в файлах GXCDSX900E.pdf и GDFWV500E.pdf.
Для того, чтобы видеокамера начала передачу изображения необходимо определить какое из подключенных к шине устройств является камерой и проинициализировать ее после этого камере необходимо сообщить желаемые настройки: частоту кадров и формат передачи изображения. Камере так же необходимо указать какую из двух доступных скоростей передачи следует использовать (200Mbit/sec или 400Mbit/sec ). Разумеется выбранная скорость передачи должна быть достаточна для передачи требуемого числа кадров в секунду в выбранном формате. После этого необходимо создать изохронный канал нужной пропускной способности, (более подробно процедура описана ранее), и сообщить его номер камере с тем чтобы она начала передачу. После этого остается в цикле принимать пакеты с изображением!
Обычно процедура создания канала начинается с определения адреса устройства менеджера изохронных ресурсов. Этот адрес можно прочесть в регистрах устройства менеджера шины. Обычно API предоставляет возможность узнать эти адреса. Для создания
канала необходимо прочесть и модифицировать при помощи функции lock регистры BANDWIDTHAVAILABLE и CHANNELSAVAILABLE в менеджере изохронных ресурсов с тем чтобы часть свободной полосы отвести под вновь создаваемый канал.
Возможно все это кажется несколько сложным, однако если не считать расчета величины на которую следует изменить BANDWIDTHAVAILABLE, все остальное сводится к вызову несколько раз функций read/write/lock.
Для того чтобы "обнаружить" камеру нужно получить при помощи API список всех устройств и прочитав VendorlD и ProductID из Configuration ROM каждого из них запомнить адрес устройства найденной камеры. Если единственным подключенным устройством является камера, эту процедуру можно пропустить. Дальнейшее, согласно описанию протокола приводимому производителем, сводится примерно к следующей последовательности команд:
1. Записать в регистры камеры по адресу OxFFFF'FOFO'0000 значение 0х8000'0000 и тем самым проинициализировать камеру.
2. Выбрать количество кадров изображения в секунду (например 7.5) записав по адресу OxFFFF'FOFO'0600 значение 0х4000'0000
3. Выбрать разрешение картинки, скажем 1024x768 (запись по адресу OxFFFF'FOFO'0604 значения ОхАООО'0000 )
4. Установить допустимый для выбранного разрешения формат передачи OxFFFF'FOFO'0608 значение 0х2000'0000
5. Сообщить камере номер созданного ранее изохронного канала и скорость передачи (запись по адресу 0xFFFF'F0F0'060C значение OxNlOOO'0000 или 0xN2000'0000, в зависимости от выбранной скорости, где N - номер канала от 0x0 до OxF)
6. И наконец включить передачу изображения записав по адресу OxFFFF'FOFO'0614 значение 0х8000'0000
В принципе ничего сложного! Во всяком случае не сложнее передачи через последовательный порт RS232 с использованием программного управления потоком :)
Разумеется на практике для того, чтобы при передаче изображения не происходило его потерь, нам потребуется приемный буффер достаточно болшого размера, обработка ошибочных ситуаций и тому подобное, но суть дела это не меняет. Теперь мы представляем себе как работать с Fire Wire устройствами. Подсистема Fire Wire нашей ОС при приеме данных от устройства через изохронный канал просто будет вызывать нашу функцию и передавать в нее пришедшие данные, наша забота теперь только успевать их обрабатывать!
Изохронная передача работает примерно так же (примеры можно найти в исходных текстах ОС Linux), однако все может быть достаточно гладко до тех пор пока принимающее устройство является достаточно интеллектуальным чтобы правильно использовать принимаемый поток данных на своей стороне. Речь идет во о чем, например при получении изображения если это изображение требуется показывать на экране принимающий компьютер может определять какой кадр видео и когда когда следует начать и закончить показывать чтобы изображение не дергалось и не замирало, вобщем вело себя адекватно. Однако в качестве принимающего устройства могут попасться существенно менее интеллектуальные камкордеры, которые показывают каждый кадр изображения ровно тогда когда ими этот кадр получен. И что же в результате? Камкордер, использующий телевизионный формат NTSC для внутреннего представления изображения для правильной работы должен получать 29.97 видеокадров в секунду. Изображение передается внутри пакетов протокола CIP (Common Isochronous Packets). Размер кадров составляет 480x250, соответственно один кадр занимает 120000 байт. Таким образом NTSC требует скорости передачи 29.97*120000=3596400 байт в секунду. Изохронные пакеты IEEE1394 передаются с частотой 8КГц и если выбрать для канала наиболее близкую к требуемой скорость передачи, то с учетом всех полей заголовка CIP пакета окажется что один такой пакет будет передавать 480 байт изображения. Но для того, чтобы достичь скорости передачи 29.97 кадров в секунду потребовалось бы в одном пакете передавать 3596400/8000=449.55 байт в секунду! Простые устройства не могут преобразовывать потоки видео с одной частотой кадров в потоки видео
с другой частотой. Но к счастью CIP допускает другое решение этой проблемы: примерно 1 из 15 CIP пакетов должен содержать внутри себя указание что он не несет в себе байтов данных изображения, такие пакеты игнорируются устройством. Более подробную информацию о передаче изображения можно найти в документации и исходных текстах Linux.
