|
AVOIDING COMMON PROBLEMS IN 1394 DEVICE INTEROPERABILITY
This document provides brief advice about common interoperability
problems among
1394 consumer electronics devices, and how to help avoid them. Much more
detailed
information is available in the IEEE and 1394 TA specifications, and within
the 1394 TA
working groups.
1394 Bus-level (PHY and Link) issues
- Do not generate a 1394 bus reset as an error-recovery mechanism when
something
unexpected or unsupported happens. If two or more devices do this on
one bus, the result
can be endless bus resets.
- do not assume your device will be root, IRM, or Bus Manager. Test
with larger bus
configurations, and test with large and small "gap count"
values (on appropriate
topologies). Make sure to reset your root hold off bit if you are the
only node in the
network. Gap Count table E-6 in 1394-1995 and E-1 in 1394a-2000 specifications
no
longer work in the presence of 1394b nodes. You are better off to either
leave the gap
count as 63 if 1394b is present or implement Performance optimization
as explained in
section E-1 of 1394a-2000 specification.
- Do not assume that PHYs reporting a speed code of 3 (1394b) are s100
devices.
Either implement 1394b-style speed checking, or use a simple "probe"
method to select
your packet speed. The "probe" method is: Send a packet at
your fastest speed, and if
there is no acknowledgment, try again at the second fastest speed, repeating
until you
reach s100 or get an acknowledgment. Then use this speed until the next
bus reset.
Preferably use 1394b-style speed checking. Probing might take a considerable
amount of
CPU time (at the peak bus reset time when it is most critical) to complete,
as at the most
3 packets have to be sent per node to determine the correct speed. The
probe method is
not an efficient method, especially considering the OS and driver delays
involved with it and the device's responsiveness after a bus reset may
be affected. Care must be taken so that the device does not busy out
or delay incoming requests just because it is busy probing to find out
the max. speed.
Connection-level issues
- Do not assume that the configuration ROM on another device is static.
Look for new Unit Directories in the device after any potential change, such as a
bus reset. To save time, check the Config ROM generation (1394a) to see if the ROM has
changed. For AVC devices, check for new AVC Subunits even if the Config ROM has not
changed.
- Be careful establishing and releasing 61883 "CMP" connections.
Unless your device allocated isochronous bandwidth and a channel number,
clean up and stop transmission when your point-to-point connection count
drops to zero.
- Be careful to wait after a bus reset so that existing connections
can be re-established before new allocation requests are made.
- Be sure to implement and test the AVC Plug Signal-Format command for
any plugs you support, even if your particular device does not rely on this command.
Application layer issues:
- Be careful about "single-threading" your firmware or software
support. Many things can happen at the same time on 1394. Especially after a bus reset, be
sure your device can deal with multiple requests. For example, your device might send
an AVC command to another device. Before the AVC response is received, your device
might receive a different AVC command from a third device. You must not reject this
new command just because you are busy with your own command. Similarly, you may
receive requests at any time to read your configuration ROM, or plug registers, or to
access other services. These requests should not stall due to unrelated activity.
- Your device could be exposed to a rich mixture of MPEG video and
audio formats. Find a way to test as many of these as possible. For example, use the
Sony and JVC HD camcorders in addition to the many TVs now on the market.
- If your device has a tuner capability, make the tuner available
on 1394 so that other devices can select your device as a content source.
For more information, contact:
Richard Mourn
Chairman, Compliance and Interoperability Working Group
rmourn@quantumparametrics.com
Dave Thompson
Chairman, Quality Review Board
dave.thompson@lsi.com
|
HELPFUL LINKS
Design Guide
Events
Calendar
White
Papers
Presentations For Developers
|
|
