Firewire is an onion...
I've spent about a week pouring over Firewire documents. There are a few. I've summarized the important specs and tech data below.
The first document is commonly known as CSR although it is formally known by ANSI/IEEE 1212-2001 or by ISO/IEC 13213:1994. CSR stands for Control and Status Register and describes a method for devices to communicate via a shared memory address (64 bits). The basic operations are read/write a quadlet (a 32 bit value), read/write an octlet (a 64-bit value), read/write a block (arbitrary size) and lock. The commands are completed asynchronously (i.e. non-blocking) but a software abstraction layer can create the illusion of synchronous calls. CSR describes how a bus can work but is not tied to any particular implementation.
The next document is known as IEEE 1394-1995 or 1394a-2000 or 1394b-2002 High Speed Serial Bus. It is an implementation of CSR. It describes a hot-pluggable bus that can provide power as well as data transmission, typically at 400Mbps (the most common) but can go faster (3200Mbps) or slower (100Mbps) with the newer "b" spec. The bus creates a tree topology with a "root" having possibly multiple children. This tree can contain up to 63 nodes but due to bandwidth reasons there is usually far fewer (eg 1 or 2) devices. Unlike the popular USB2.0 spec, this bus is equally at home connecting computer to device, device to device or computer to computer. This allows it to be equally at home connecting consumer A/V equipment or connecting two (or more) computers. It does have a weakness, however. It's enumeration mechanism does not handle circular connections well. In other words, there can only be one path along the tree from one device to any other.
Another key capability of this bus is isochronous communications. This allows you to pre-allocate bandwidth so that time based data (audio/video) will be guaranteed to have the bandwidth available. Asynchronous communications have to use the remaining unallocated bandwith. There is a minimum amount of bandwidth reserved for asynchronous so that other devices are not starved out (typically 20%). This means that the maximum isochronous bandwidth a S400 device can allocate is about 320Mbps.
Due to it's "hot pluggable" nature, every time a device is plugged in or unplugged, the bus is reset and re-enumerated. The devices that were transmitting isochronously get a chance to reallocate their bandwidth. This can cause a "blip" in the data stream. Software can be notified of a bus reset and take appropriate action. Since the node address can change with a reset, each device has a unique ID available known as an EUI-64. This ID is formed from a 24 bit Vendor ID (assigned by a central authority) as well as a 40 bit serial number assigned by the vendor. Two otherwise identical devices will have distinct EUI-64's.
Every Firewire device must implement a minimum amount of CSR registers. This allows the enumeration mechanism to work as well as determine what protocols the device understands. It also determines the bus capabilites of the device. A device can be a cycle master (it can generate the bus start of cycle packets), an isochronous manager (isoch. bandwidth and channel allocation mechanism), or bus manager (supply and manage power, bus optimization and root determination). The bus can operate without a bus manager but both devices must supply their own power. A device does not need to be any of the above.
The CSR's form directories with offsets pointing to where to find other directories. This allows for a generic tree configuration. The Bus Info Block is first and is always located at offset 0x400. Immediately following is the Root Directory that describes the device and contains offsets to unit directories. A device can support multiple protocols and multiple versions of the same protocol. Each unit dependant directory lists a protocol by Protocol ID and spec version # and the offset where to find the CSR's that control the device using that protocol and version #.
The next spec to read up on is the IIDC 1394-based Digital Camera specification version 1.30, 1.20 or 1.04 (also known as DCAM). It is a defined by the 1394 Trade Association Instrumentation and Industrial Control Working Group, Digital Camera Sub Working group (II-WG DC-SWG). It's purpose is to define a command set for digital cameras that use the firewire bus. This is a completely separate group from the DV group which comprise a whole laundry list of specs. More importantly, it defines uncompressed digital camera operations. DV cameras use a lossy MPEG2 video compression variant to transmit data.
The spec provides several inquiry registers that allow you to determine what data formats, frame rates, image sizes, etc. are available. This allows software to choose a configuration that it can deal with and ignore the others if it wants. There are 5 standard formats each with standard image sizes and frame rates available for compatibility purposes as well as a fixed image format (for still cameras) and a flexible format where you can configure your camera's options known as Format 7. This is by far the most flexible format and allows you to change every aspect of your image data.
The spec also defines standard image controls (Brightness, Auto-expose, Sharpness, White Balance, Hue, Saturation, Gamma, Shutter, Gain, Iris, Focus, Temperature, Trigger, Zoom, Pan, Tilt, Optical Filter) as well as the level of support for each of these capabilities (not present, read only, read-write, auto-mode, one-push mode, disable mode, valid range). Format 7 also allows you to specify the Region of Interest within the image as well as the valid sizes available. Finally, you can choose your data format (YUV4:2:2, YUV4:1:1, RGB8, Y8, Y16, etc). Additional, camera specific, controls can be added in an advanced CSR controls directory but additional info is required from the manufacturer in order to identify and translate these CSR's into camera features. The most important of these is binning options. Finally, once you have set up your camera, you can tell it to acquire one image (one-shot) a series of images (multi-shot) or a stream of images (stream). Of course, if your camera is a still camera, isoch stream will not be available.
In general, the specs work together as a protocol stack to cover and define a very wide range of objects. There is a spec for Hard Disks, printers, keyboard, mice, generic masss storage (media keys), CD/DVD drives known as SBP-2 and more recently SBP-3. As mentioned before, consumer DV video falls under many specs such as AV/C and HAVi. RFC 2734 defines how to layer the IP network protocol on the 1394 bus. Peruse these at your leisure the next time you get insomnia. Oh, and by the way, the official PDF of the specs are all sold online for about $100 a pop. Happy reading.
The first document is commonly known as CSR although it is formally known by ANSI/IEEE 1212-2001 or by ISO/IEC 13213:1994. CSR stands for Control and Status Register and describes a method for devices to communicate via a shared memory address (64 bits). The basic operations are read/write a quadlet (a 32 bit value), read/write an octlet (a 64-bit value), read/write a block (arbitrary size) and lock. The commands are completed asynchronously (i.e. non-blocking) but a software abstraction layer can create the illusion of synchronous calls. CSR describes how a bus can work but is not tied to any particular implementation.
The next document is known as IEEE 1394-1995 or 1394a-2000 or 1394b-2002 High Speed Serial Bus. It is an implementation of CSR. It describes a hot-pluggable bus that can provide power as well as data transmission, typically at 400Mbps (the most common) but can go faster (3200Mbps) or slower (100Mbps) with the newer "b" spec. The bus creates a tree topology with a "root" having possibly multiple children. This tree can contain up to 63 nodes but due to bandwidth reasons there is usually far fewer (eg 1 or 2) devices. Unlike the popular USB2.0 spec, this bus is equally at home connecting computer to device, device to device or computer to computer. This allows it to be equally at home connecting consumer A/V equipment or connecting two (or more) computers. It does have a weakness, however. It's enumeration mechanism does not handle circular connections well. In other words, there can only be one path along the tree from one device to any other.
Another key capability of this bus is isochronous communications. This allows you to pre-allocate bandwidth so that time based data (audio/video) will be guaranteed to have the bandwidth available. Asynchronous communications have to use the remaining unallocated bandwith. There is a minimum amount of bandwidth reserved for asynchronous so that other devices are not starved out (typically 20%). This means that the maximum isochronous bandwidth a S400 device can allocate is about 320Mbps.
Due to it's "hot pluggable" nature, every time a device is plugged in or unplugged, the bus is reset and re-enumerated. The devices that were transmitting isochronously get a chance to reallocate their bandwidth. This can cause a "blip" in the data stream. Software can be notified of a bus reset and take appropriate action. Since the node address can change with a reset, each device has a unique ID available known as an EUI-64. This ID is formed from a 24 bit Vendor ID (assigned by a central authority) as well as a 40 bit serial number assigned by the vendor. Two otherwise identical devices will have distinct EUI-64's.
Every Firewire device must implement a minimum amount of CSR registers. This allows the enumeration mechanism to work as well as determine what protocols the device understands. It also determines the bus capabilites of the device. A device can be a cycle master (it can generate the bus start of cycle packets), an isochronous manager (isoch. bandwidth and channel allocation mechanism), or bus manager (supply and manage power, bus optimization and root determination). The bus can operate without a bus manager but both devices must supply their own power. A device does not need to be any of the above.
The CSR's form directories with offsets pointing to where to find other directories. This allows for a generic tree configuration. The Bus Info Block is first and is always located at offset 0x400. Immediately following is the Root Directory that describes the device and contains offsets to unit directories. A device can support multiple protocols and multiple versions of the same protocol. Each unit dependant directory lists a protocol by Protocol ID and spec version # and the offset where to find the CSR's that control the device using that protocol and version #.
The next spec to read up on is the IIDC 1394-based Digital Camera specification version 1.30, 1.20 or 1.04 (also known as DCAM). It is a defined by the 1394 Trade Association Instrumentation and Industrial Control Working Group, Digital Camera Sub Working group (II-WG DC-SWG). It's purpose is to define a command set for digital cameras that use the firewire bus. This is a completely separate group from the DV group which comprise a whole laundry list of specs. More importantly, it defines uncompressed digital camera operations. DV cameras use a lossy MPEG2 video compression variant to transmit data.
The spec provides several inquiry registers that allow you to determine what data formats, frame rates, image sizes, etc. are available. This allows software to choose a configuration that it can deal with and ignore the others if it wants. There are 5 standard formats each with standard image sizes and frame rates available for compatibility purposes as well as a fixed image format (for still cameras) and a flexible format where you can configure your camera's options known as Format 7. This is by far the most flexible format and allows you to change every aspect of your image data.
The spec also defines standard image controls (Brightness, Auto-expose, Sharpness, White Balance, Hue, Saturation, Gamma, Shutter, Gain, Iris, Focus, Temperature, Trigger, Zoom, Pan, Tilt, Optical Filter) as well as the level of support for each of these capabilities (not present, read only, read-write, auto-mode, one-push mode, disable mode, valid range). Format 7 also allows you to specify the Region of Interest within the image as well as the valid sizes available. Finally, you can choose your data format (YUV4:2:2, YUV4:1:1, RGB8, Y8, Y16, etc). Additional, camera specific, controls can be added in an advanced CSR controls directory but additional info is required from the manufacturer in order to identify and translate these CSR's into camera features. The most important of these is binning options. Finally, once you have set up your camera, you can tell it to acquire one image (one-shot) a series of images (multi-shot) or a stream of images (stream). Of course, if your camera is a still camera, isoch stream will not be available.
In general, the specs work together as a protocol stack to cover and define a very wide range of objects. There is a spec for Hard Disks, printers, keyboard, mice, generic masss storage (media keys), CD/DVD drives known as SBP-2 and more recently SBP-3. As mentioned before, consumer DV video falls under many specs such as AV/C and HAVi. RFC 2734 defines how to layer the IP network protocol on the 1394 bus. Peruse these at your leisure the next time you get insomnia. Oh, and by the way, the official PDF of the specs are all sold online for about $100 a pop. Happy reading.
posted by Oscar Papel at
11:23 PM
0 Comments:
Post a Comment
<< Home