|
FireWire, also known as IEEE 1394, may pave the way for a true convergence of consumer electronics and computers. Thomas presents a fully functional Win32 console application that takes a snapshot from the CCM-DS250 digital camera, converts it from a YUV format to a 24-bit device independent bitmap (DIB), and writes the DIB to a file.
September 01, 1997
URL:http://www.drdobbs.com/architecture-and-design/firewire-the-ieee-1394-serial-bus/184410277
Thomas is a software engineer for Sequoia Advanced Technologies, a supplier of SCSI and IEEE-1394 system software. He can be reached at [email protected] or http://www.seqadvtech.com/.
It is rare these days to enter a consumer electronics store and not hear salespeople talking about "digital" devices. Digital audio tape (DAT), digital cameras, digital camcorders, digital versatile disk (DVD), digital satellite systems, digital VCRs, and (coming soon) digital televisions are all being pitched to us as "must have" devices. But what features do digital devices offer that their analog cousins don't?
An obvious answer is that a digital device should connect to your computer. Digital cameras, for instance, don't have film. You must download pictures into your computer so that you can view, print, or e-mail them to your mother (after doctoring the digital pictures a bit to make you appear a few pounds lighter, of course).
Soon, the best way to connect a digital device to your computer will be through a digital data port called FireWire.
FireWire, also known as IEEE 1394, is a high-speed serial bus. As of December 12, 1995, it is an official industry standard. With the 1394, a true convergence of consumer electronics and computers is possible. Although there are currently only a few 1394 digital devices and adapter cards available, many more are on the way.
The features of the 1394 that make it compelling to the computer industry include:
Low cost. After a little more than one year of being an official standard, 1394 has a price point close to that of SCSI. New 1394 chipsets will soon be available from several manufacturers, driving the price down further, and before long, computer manufacturers will start putting 1394 directly on motherboards.
High speed. IEEE 1394 is an extremely high-performance serial bus, currently operating at 100 or 200 Mbits/sec. At this writing, 400 Mbits/sec versions of 1394 are becoming available, and 800 Mbits/sec and 1.2 Gbits/sec versions of 1394 will be available within a year or two. (By comparison, the Universal Serial Bus (USB) operates at 12 Mbits/sec.) Even at its lowest speed of 100 Mbits/sec, 1394 supports two simultaneous channels of full motion (30 frames per second), high-quality video, and stereo audio, with enough bandwidth left over to issue commands to control the digital devices transmitting the audio and video.
True plug-and-play. IEEE 1394 devices can be connected to the computer or to one another at any time, with the power on or off. In some cases, 1394 devices can even power themselves from the 1394 bus. The 1394 connector was derived from Nintendo's Gameboy, so it is kid tested and engineer approved (meaning it's rugged). Unlike SCSI, terminators aren't needed for 1394 devices. The 1394 cables consist of two pairs of wires for data transport, and one pair for device power.
Easy networking. IEEE 1394 devices can be connected via branching or daisy chaining. This means that it is very easy for consumers to connect 1394 devices. 1394 supports peer-to-peer data paths, allowing 1394 devices to communicate directly with one another. For example, a digital camera can easily send pictures directly to a digital printer without a computer in the middle. In addition, up to 63 IEEE1394 devices can be connected together. With bus-bridging technology, up to 64,000 IEEE1394 devices can be connected.
Isochronous support. IEEE 1394 supports a guaranteed data path bandwidth called "isochronous data transfers" and allows for real-time transmission of data to/from 1394 devices. This is important for audio and video applications such as MPEG and DVC. Isochronous data transfers operate in a broadcast manner, where one or many 1394 devices can "listen" to the data being transmitted. The emphasis of isochronous data transfers is placed on guaranteed data timing rather than guaranteed delivery. Multiple channels (up to 63) of isochronous data can be transferred simultaneously on the 1394 bus. Since isochronous transfers can only take up a maximum of 80 percent of the 1394 bus bandwidth, there is enough bandwidth left over for additional asynchronous transfers.
Asynchronous support. IEEE 1394 supports asynchronous data transmission, which includes receipt datagrams that indicate that the data was transmitted reliably to the 1394 device. Asynchronous data transfers place emphasis on delivery rather than timing. The data transmission is guaranteed, and retries are supported.
Traditional computer devices support IEEE1394. Soon there will be 1394 fixed-disk drives, 1394 printers, 1394 scanners, and 1394 CD-ROM/DVD devices. Consequently, a computer with a 1394 port will be able to connect to a potentially huge number of 1394 computer devices, as well as to all of the available 1394 consumer electronics devices.
Microsoft has designed a complete 1394 software architecture and intends to release it in the next version of Windows, code named "Memphis." Currently, however, Memphis and the subsequent 1394 DDK/SDK aren't generally available. However, Texas Instruments (TI) has developed a software solution for Windows 95 for its 1394 PCI host adapters that closely mirrors the Memphis 1394 solution. Figure 1 illustrates the TI software architecture. We took one of TI's 1394 PCI host adapters (called a PCI Lynx), installed it in our PC, connected a 1394 digital camera, and proceeded to develop 1394 Win32 applications. TI provides a VxD/ DLL combination that can be used to write 1394 applications. Since the TI approach closely mirrors the Memphis solution, it should be straightforward to port any Win32-1394 applications written to TI's DLL over to the final Memphis 1394 software architecture.
The camera we selected for our initial development was a Sony CCM-DS250 that supports isochronous video data transfers and can be controlled via a series of registers that can be accessed via asynchronous writes and reads. It also conforms to the 1394 digital-camera specification, available from the 1394 Trade Association at http://www.1394ta.org/. (This web site provides a wealth of information about 1394 and key 1394 links and should be one of your first stops if you are serious about 1394 software development.)
To illustrate what's involved in initiating isochronous data transfer and control of a 1394 device, I'll present a fully functional Win32 console application that takes a snapshot from the CCM-DS250 digital camera, converts it from a YUV format to a 24-bit device-independent bitmap (DIB), and writes the DIB to a file. (The source code and related files for this application are available electronically; see "Availability," page 3.) The file can then be viewed with the Windows 95 Paint program or any graphic utility that supports DIBs. The snapshot application provides a good overview of isochronous data transfer, and 1394 device control via asynchronous data writes to the camera's control registers.
The sequence for starting an isochronous data transmission from a 1394 device begins with a call to cls1394Initialize, which performs needed initialization of the 1394 bus software. cls1394Initialize forces the 1394 bus to be reset, which causes all 1394 devices on the bus to start transmitting their self-ID packets. At this point, the bus manager, usually the 1394 host adapter in the PC, builds its device speed and topology maps. This information allows the DLL to direct your subsequent 1394 requests to the correct device. The 1394 device's Configuration Info Blocks are then interrogated to gather World Wide User IDs (WWUIDs), which are used to identify the specific 1394 device with which you wish to communicate.
For example, the WWUID for the Sony CCM-DS250 is 0x08004602. At this writing, there is no general catalog of WWUIDs available that I know of. However, this information will surely be made available on the 1394 Trade Association web site in the near future. For now, just know the WWUID of the device for which you wish to write 1394 software.
Next, the function cls1394CreateFile returns a handle to the 1394 device that is to start transmitting isochronous data and that is specified by its WWUID, which is passed in as an argument. Also passed as an argument is an index (one based) that specifies with which instance of the device you wish to talk. For example, if there is more than one CCM-DS250 connected to the 1394 bus, this index specifies the CCM-DS250 for which you wish to obtain a handle.
The 1394 is a read/write memory architecture bus (as opposed to an I/O bus) that follows the IEEE 1212 Control and Status Register standard for 64-bit fixed addressing. The upper 10 bits of the 1394 address specify the bus number, which ranges from 0 to 1023. The next 6 bits of the address specify the device number (properly referred to as a "node number"), which ranges from 0 to 63. The next 48 bits specify the address of the register space within the 1394 device that is being addressed. With 48 bits of register space, a 1394 device can have up to 256 terabytes of addressable space; see Figure 2.
With the Win32 1394 API, once you have acquired a handle to a 1394 device, you simply use the 48-bit register address to access registers within the device. The bus and node number are automatically generated by the API from the passed-in device handle.
Isochronous data transactions do not use 1394 addresses. Instead, they use "channels" -- a relationship between a 1394 device (a "talker") that is transmitting the isochronous data, and one or more 1394 devices ("listeners") that simply receive the isochronous data. Channel numbers are assigned using the isochronous resource management (IRM) facilities. From Win32, this mechanism suggests a function call to allocate a channel for isochronous data transmission. And indeed, there is one.
For an isochronous data transfer to take place on the 1394 bus, one of the 1394 devices must serve as an IRM. Before starting an isochronous data transfer, the 1394 device initiating the transfer must communicate with registers provided by the IRM to allocate an isochronous channel and isochronous bandwidth. In this manner, all 1394 devices can interrogate the common registers in the IRM and determine what resources are left to be used on the 1394 bus.
Luckily, this process is handled automatically by the 1394 API. You need only make the cls1394IsochAllocateChannel and cls1394IsochAllocateBandwidth function calls, and the proper registers in the IRM are accessed and written, indicating the resources that you are claiming for your isochronous data transfer. As the names imply, cls1394IsochAllocateChannel allocates an isochronous channel for data transmission, while cls1394IsochAllocateBandwidth allocates isochronous bandwidth to be used for the data transmission.
You can either request a specific channel number from cls1394IsochAllocateChannel or you can have it return a channel number to you. The example snapshot utility simply instructs cls1394IsochAllocateChannel to allocate a channel to the application, since you don't really care what the specific channel number is.
The CCM-DS250 supports various video modes. The mode I selected for the snapshot utility was a 320×240 YUV (4:2:2) mode, which works out to 16 bits per pixel. Since you are instructing the camera to transmit at 30 frames per second, that indicates that you will be receiving 320 pixels per packet. At 320 pixels per packet, that works out to 640 bytes per packet, so this will be our isochronous packet size. When you work through the math, this will amount to 153,600 bits/sec or 153.6 Kbits/sec. This data rate is low enough that you can quite safely use a 100 Mbits/sec channel.
You then allocate 100 Mbits/sec with a packet size of 640 bytes from the IRM. Upon calling this function, the 1394 DLL will write to the proper IRM registers to allocate the bandwidth from the 1394 system. A handle will be returned, which is used to release the bandwidth back to the 1394 system once you have completed your tasks.
A call to cls1394IsochAllocateResources, which allocates hardware/software resources for isochronous data transmission, then directs the 1394 DLL to allocate certain hardware and software resources for a subsequent isochronous data transfer. In this function, specify whether you are listening to an isochronous channel or talking on an isochronous channel. Since you are bringing a frame of video data in from the camera, you are clearly a listener.
Next, the cls1394IsochAttachBuffers function attaches one or more user buffers to a specific isochronous channel. Once isochronous data starts being transmitted on the specified channel, the user buffers specified in this function call are filled with the isochronous data. The way the user buffers are utilized is controlled via the structure in Example 1, in which one structure is filled out for each buffer that is to be assigned to the isochronous channel. In Example 1:
Next, the function cls1394IsochListen instructs the 1394 DLL to start listening for isochronous data on the specified channel. The data will be placed in the buffers specified by clsIsochAttachBuffers().
Finally, cls1394WriteQuadlet, which is used to setup the 1394 device to start transmitting isochronous data, allows you to write asynchronous data directly into the camera's control registers (per the camera's 1394 specification). For example, at camera register 0x0FFFFF0F00610, you instruct the camera to power up. You then set the frame rate, video mode, video format, isochronous channel, and speed. Next, you instruct the camera to start sending video data on the isochronous channel. (The source code provides more information about these functions.)
The process of setting these registers is, of course, quite device specific. However, there are several cameras that conform to the 1394-base Digital Camera Specification from the Trade Association.
The sequence of terminating the isochronous data flow is basically the reverse of the sequence for starting an isochronous data transfer, shown by way of example in the source code. Here's a quick overview of the required sequence of function calls:
1. cls1394WriteQuadlet stops the isochronous data transmission from the 1394 device.
2. cls1394IsochStop stops all isochronous operations on the given channel.
3. cls1394IsochDetachBuffers releases the specified user buffer and any associated resources.
4. cls1394IsochFreeResources releases previously allocated hardware and software resources.
5. cls1394IsochFreeBandwidth frees previously allocated isochronous bandwidth back to the 1394 system.
6. cls1394IsochFreeChannel frees the previously allocated isochronous channel back to the 1394 system.
7. cls1394CloseHandle closes a previously allocated handle to a 1394 device.
8. cls1394Terminate instructs the 1394 software subsystem to release all allocated resources back to the operating system.
Using the sequences presented here as a framework and the source code as a specific example, you should have little problem in developing custom FireWire Win32 applications. I have examined several FireWire API implementations on both the MacOS and Win32 platforms that are similar to the aforementioned outline in most respects. In fact, porting the snapshot utility to these other implementations should be fairly straightforward. I hope you find the sample code I provided useful in this process.
1394 is such a compelling technology that it is likely to be instrumental in changing the way computers are used, much as automated tellers have changed banking. Virtually every major computer manufacturer, consumer electronics manufacturer, and multimedia IC manufacturer has endorsed IEEE 1394 as the future digital data port. Apple, which pioneered the FireWire effort, has announced full 1394 support in its new MacOS, and Microsoft is strongly backing 1394 technology from a software standpoint.
For more information, check out http://www.fujitsumicro.com/products/network/1394.html.
DDJ
Dr. Dobb's Journal September 1997
Dr. Dobb's Journal September 1997
Dr. Dobb's Journal September 1997
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.