FAQ: Application Development

1. In terms of the 7 OSI layers, what are the locations of the HAVi software elements and interoperability API?
   
   
2. What benefits does HAVi bring to developers who are currently using AV/C?
   
   
3. Which buses/protocols is the Communication Media Manager (CMM) implemented on?
   
   
4. Is there any HAVi API that can be used to send (i.e. broadcast) one message simultaneously to multiple devices/software-elements?
   
   
5. Are designers required to use predefined button layouts, or are they free to design their own?
   
   
6. How may text, menus, EPGs, etc. be displayed on HAVi devices (such as DTVs)?
   
   
7. How much memory does an FAV device require to upload a DCM from a newly connected device?
   
   
8. When a user removes a device from the network, does the DCM of that device continue to consume memory?
   
   
9. How does HAVi handle interrupt processing and RTOS in a 1394 network?

The software elements support the OSI application level. The HAVi interoperability API lies essentially at the application level. Perhaps some portions (like the DDI GUI description) could be considered at the presentation level and some (Message System open/close) at the session level.

AV/C offers payload only. Developers using AV/C have to write programs that access 1394 device drivers. When hardware (product board, CPU, etc.) changes, 1394 device drivers change too, forcing developers to rewrite their applications.

In HAVi, since the APIs are independent of 1394 device drivers, developers need not rewrite their applications. Other advantages include:

• Point-to-point connection will become easier using HAVi's Stream Manager.
• Programmers can relieve themselves from bus-reset related programming by using HAVi's Event Manager.
• Programming will become easier by using HAVi features such as global registry, resource management, scheduled actions, web access, etc.

Currently only IEEE-1394.

At the HAVi API level, it is possible to send simultaneously using a SEID list. Specifically, the API used is MsgSend. Note: At a lower level (e.g. Messaging System), it need not necessarily translate into a broadcast.

While some basic display fields such as text-name for buttons are mandated in the HAVi GUI, developers have freedom to design their own GUI for other elements such as button position, shape, etc.

HAVi provides several mechanisms for dealing with UI issues:

• DDI (Data-Driven Interaction) defines a declarative widget- and action-based UI representation. The DDI description allows the UI designer to make "suggestions" for layout and other aspects of rendering that the portion of an application responsible for UI (the DDI- Controller) may or may not be used in making a best-effort attempt to render the UI and respond to user input. Having to specify the detailed capabilities of display and input devices was intentionally avoided to allow implementers greater flexibility.
• Display FCM.
• Users may add FCMs for their new devices.
• Level 2 GUI.

The memory requirement depends on the extent of functionalities of the DCM. HAVi provides profile information inside the SDD to prevent an FAV device from uploading a DCM whose memory consumption would be more than what the FAV device can offer. Before the FAV device uploads the DCM, the FAV must check the profile of the DCM by reading the HAVi_DCM_Profile_field in the SDD of the newly connected device to determine whether or not it can upload the DCM.

No. The moment a device is removed from the network, a 1394 bus reset event occurs and information is generated about the removal of the device. This prompts the DCM Manager to uninstall the DCM of the removed device.

This depends on the response of the IEEE-1394 hardware, the 1394 device driver on top of the OS, and the interrupt handling capacity of the OS.