HK1111278A - Digital data interface device message format - Google Patents

Abstract

The present invention provides a digital data interface device message format (Fig. 7) that describes command and response messages to be exchanged between a digital device having a system controller and a digital data interface device. The digital data interface includes a message interpreter, content module and a control module. The digital data interface device may include an MDDI link controller. The digital data interface device can be used by a cellular telephone to control a peripheral device such as a camera, bar code reader, image scanner, audio device or other sensor. The digital data interface device message format includes a transaction identification field (710), a count field (720), a command identification field (730) and a status field (740). Optionally, the message format can include a data field (750). When an MDDI link is used, a digital data interface device message can be included in an MDDI register access packet.

Description

Digital data interface device message format

Technical Field

The present invention relates generally to data communications. More particularly, the present invention relates to a digital data interface device message format.

Background

In the past few years, computers, mobile phones, mobile phone cameras and video capture devices, personal data assistants, electronic game related products, and various video technologies (e.g., DVD and high definition VCR) have advanced significantly to provide capture and presentation of still, video-on-demand, and graphical images of increasingly higher resolution. These visual images are combined with high quality video data (e.g., CD-type sound reproduction, DVDs, and other devices with associated audio signal outputs) to create a more realistic, content-rich, or realistic multimedia experience for the end user. In addition, highly mobile, high quality sound systems and music delivery mechanisms (e.g., MP3 players) have been developed to provide users with only audio presentations.

The development of high quality data presentation has forced the need to establish a dedicated interface that can transfer data at high data rates so that the data quality is not degraded or impaired. One such interface is the Mobile Display Digital Interface (MDDI), which is used to exchange high speed data, for example, between the lower flip (lower) and upper flip (upper) of a cellular telephone with a camera. MDDI is a cost-effective, low-power-consumption delivery mechanism that enables very high-speed data transfer between a host and a client over a short-range communication link. MDDI requires a minimum of only four leads plus power for bi-directional data transfer delivering a maximum bandwidth of up to 3.2 gigabits per second.

In one application, MDDI increases reliability and reduces power consumption of flip cellular phones by significantly reducing the number of leads that pass through the hinge of the handset to interconnect the digital baseband controller with the LCD display and/or camera. This reduction in leads also allows handset manufacturers to reduce development costs by simplifying flip or slide handset designs.

While MDDI and other data interfaces can be used to effectively provide high speed data rates on the interface, interface systems that exchange data received over the MDDI or other data interface link are typically slower and less than optimal for particular applications, such as, for example, processing camera images and control data to be exchanged between the lower and upper clamshell portions of a cellular telephone.

There is a need for a digital data device interface that provides efficient processing of data collected and exchanged via an MDDI or other high speed link. Commonly owned co-pending U.S. patent application No. (attorney docket No. 1549.2350001) entitled "Digital Data Interface Device", filed on 23/11/2005 describes such a Device.

The present application describes a message format that may be used within a digital data interface device.

Disclosure of Invention

A digital data interface device message format is provided that describes command and response messages to be exchanged between a digital device having a system controller and a digital data interface device. The digital data interface device includes a message interpreter, a content module, and a control module. The message interpreter module receives and interprets commands from the system controller and generates response messages to the system controller over the communication link, interprets the messages, and routes the information content of the commands to the appropriate module within the digital data interface device. The content module receives data from the peripheral device, stores the data, and communicates the data to the system controller via the communication link. The control module receives information from the message interpreter and routes the information to the control block of the peripheral device.

In one example, the digital data interface device includes an MDDI link controller. The digital data interface device may be used to control peripheral devices such as cameras, bar code readers, image scanners, audio devices, or other sensors. In one particular example, a cellular telephone is provided having a camera with an MDDI link and a digital data device interface.

The digital data interface device message format includes a transaction identification field, a count field, a command identification field, and a status field. Optionally, the message format may include a data field. When an MDDI link is used, the digital data interface device message may be included in an MDDI register access packet.

Further embodiments, features, and advantages of the present inventions, as well as the structure and operation of the various embodiments of the present invention, are described in detail below with reference to the accompanying drawings.

Drawings

The invention is described with reference to the accompanying drawings. In the drawings, like reference numbers can indicate identical or functionally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

FIG. 1 is a diagram of a digital data device interface coupled to a digital device and a peripheral device.

Fig. 2 is a diagram of a message interpreter module.

FIG. 3 is a diagram of a content module.

FIG. 4 is a diagram of a control module.

Fig. 5 is a diagram of a cellular telephone having an upper clamshell section and a lower clamshell section that uses an MDDI interface to provide high speed data communications between electronic devices located in the upper and lower clamshell.

Fig. 6 is a diagram of a flip-up lid of a cellular telephone having a camera using an MDDI interface.

Fig. 7 is a diagram of a digital data interface device message format.

FIG. 8 is a diagram of a register access packet including a reverse encapsulation message containing a digital data interface device message.

Detailed Description

This specification discloses one or more embodiments that incorporate the features of this invention. The disclosed embodiments are merely illustrative of the invention. The scope of the invention is not limited to the disclosed embodiments. The invention is defined by the appended claims.

References in the described embodiments and specification to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

Embodiments of the invention may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include Read Only Memory (ROM); random Access Memory (RAM); a magnetic disk storage medium; an optical storage medium; a flash memory device; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. It should be understood, however, that such descriptions are merely for convenience and that such actions in fact come from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.

FIG. 1 is a diagram of a digital data device interface 100 coupled to a digital device 150 and a peripheral device 180. Digital device 150 may include, but is not limited to, a cellular telephone, a personal data assistant, a smart phone, or a personal computer. In general, digital device 150 may comprise a digital device that acts as a processing unit for digital instructions and processing digital presentation data (digital presentation data). Digital device 150 includes a system controller 160 and a link controller 170.

Peripheral devices 180 may include, but are not limited to, cameras, barcode readers, image scanners, audio devices, and sensors. In general, peripheral device 180 may include an audio, video, or image capture and display device, with digital presentation data exchanged between the peripheral device and the processing unit. Peripheral device 180 includes a control block 190. For example, when peripheral 180 is a camera, control block 190 may include, but is not limited to, lens control, flash or white LED control, and shutter control.

Digital presentation data may include digital data representing audio, image, and multimedia data.

Digital data interface device 100 communicates digital presentation data at a high rate via communication link 105. In one example, an MDDI communication link may be used that supports bi-directional data transfer with a maximum bandwidth of 3.2 gigabits per second. Other high rates of data transfer, higher or lower than this exemplary rate, may be supported depending on the communication link. Digital data interface device 100 includes a message interpreter module 110, a content module 120, a control module 130, and a link controller 140.

Link controller 140, located within digital data interface 100, and link controller 170, located within digital device 150, establish communication link 105. Link controller 140 and link controller 170 may be MDDI link controllers.

The video electronics standards association ("VESA") MDDI standard describes the requirements of a high-speed digital packet interface that allows a portable device to transfer digital images from a small portable device to a larger external display. MDDI employs miniature connector systems and thin flexible cables that are ideal for linking portable computing, communication and entertainment devices to emerging products such as wearable microdisplays. It also contains information on how to simplify the connections between the host processor and the display device in order to reduce the cost and increase the reliability of these connections. Link controllers 140 and 170 establish communication path 105 based on the VESA MDDI standard.

U.S. patent No. 6,760,772 (' 772 patent), entitled "Generating and optimizing a communication protocol and Interface for High Data Rate Signal Transfer," issued to zuu et al, 7/6, 2004, describes a Data Interface that uses packet structures to communicate digital Data between a host and a client over a communication path, where the packet structures are linked together to form a communication protocol for presentation Data. Embodiments of the present invention taught in the' 772 patent are directed to an MDDI interface. Link controllers (e.g., link controllers 140 and 170) use signal protocols that are configured to generate, transmit, and receive packets that form a communication protocol, and to form digital data into one or more types of data packets, where at least one type of data packet resides in a host device and is coupled to a client via a communication path (e.g., communication path 105). The interface provides a cost-effective, low-power, bi-directional, high-speed data transfer mechanism over a short-range "serial" type data link, which is suitable for implementation with miniature connectors and thin flexible cables. Embodiments of link controllers 140 and 170 establish communication path 105 based on the teachings of the' 772 patent. The' 772 patent is incorporated herein by reference in its entirety.

Further, the host includes one of several types of devices that may benefit from using the present invention. For example, the host may be a portable computer in the form of a handheld, laptop, or similar mobile computing device, such as depicted as digital device 150. The host may also be a Personal Data Assistant (PDA), a paging device, or one of a number of wireless telephones or modems. Alternatively, the host device may be a portable entertainment or presentation device, such as a portable DVD or CD player or a gaming device.

The host may reside as a host device or control element in a variety of other widely used or planned commercially available products that require a high speed communication link with the client. For example, a host may be used to transfer data from a video recording device to a storage-based client at a high rate for improved response, or to a large screen of high definition for presentation. Appliances such as refrigerators that incorporate an on board inventory (on board inventory) or computing system and/or bluetooth connections to other home devices may have improved display capabilities when operating in the internet or bluetooth connection mode, or reduced wiring requirements for in-room displays (clients) and keypads or scanners (clients) when the electronic computer or control system (host) resides elsewhere in the enclosure. In general, those skilled in the art will appreciate the wide variety of modern electronic devices and appliances that may benefit from the use of such an interface, as well as the ability to retrofit older devices with higher data rates of information transfer with a limited number of conductors available in newly added or existing connectors or cables.

Also, a client may include a variety of devices that may be used to provide information to an end user or to provide information from a user to a host. For example, microdisplays incorporated in goggles or glasses, projection devices built into hats or helmets, small screens or even holographic elements built into vehicles (e.g., in a viewing window or windshield), or various speakers, headphones, or sound systems for presenting high quality sound or music. Other presentation devices include projectors or projection devices for presenting information for meetings or movies and television images. Another example would be the use of touch pads or sensitive devices, voice recognition input devices, security scanners, etc., which can be invoked to pass large amounts of information from a device or system user with little actual "input" other than touch or sound from the user. In addition, docking stations (docking stations) and car kits (car kits) or desktop kits (desk-top kits) for computers and holders for wireless telephones may act as interface devices to end users or to other devices and equipment, and use clients (output or input devices such as mice) or hosts to assist in transferring data, especially where high speed networks are involved.

However, the person skilled in the art will readily appreciate that the present invention is not limited to these devices, and there are many other devices on the market that are proposed for use that are intended to provide high quality images and sounds for the end user in terms of storage and transmission or in terms of playback presentation. The present invention may be used to increase the amount of data processing between various elements or devices to accommodate the high data rates required to achieve a desired user experience.

The present MDDI and communication signal protocols can be used to simplify the interconnection between a host processor, controller or circuit component, for example, and a display within a device or device housing or structure (referred to as an internal mode) in order to reduce cost or complexity and associated power and control requirements or constraints on these connections and improve reliability not only for connections to or for external elements, devices or equipment (referred to as an external mode).

The wireless communication devices each have or include apparatus such as, but not limited to, a wireless handset or telephone, a cellular telephone, a data transceiver, or a paging or positioning receiver, and may be hand-held or portable as desired, as installed in vehicles, including cars, vans, boats, trains, and planes. However, while wireless communication devices are generally considered to be mobile, it should also be understood that the teachings of this disclosure are applicable to "fixed" units in some configurations. Additionally, the teachings of this disclosure are applicable to wireless devices such as one or more data modules or modems that may be used to transfer data and/or voice traffic, and may communicate with other devices using, for example, cables or other known wireless links or connections to transfer information, commands, or audio signals. Additionally, commands may be used to cause modems or modules to work in a predetermined coordinated or associated manner to communicate information over multiple communication channels. Wireless communication devices are also sometimes referred to as user terminals, mobile stations, mobile units, subscriber units, mobile radios or radiotelephones, wireless units, or simply as "users" and "mobile devices" depending on preference in some communication systems.

In the context of wireless devices, the present invention may be used with wireless devices using a variety of industry standards, such as, but not limited to, cellular analog Advanced Mobile Phone System (AMPS), and the following digital cellular systems: code Division Multiple Access (CDMA) spread spectrum systems; time Division Multiple Access (TDMA) systems; and newer hybrid digital communication systems using TDMA and CDMA techniques. CDMA cellular systems are described in the telecommunications industry association/electronic industries association (TIA/EIA) standard IS-95. A combined AMPS & CDMA system IS described in TIA/EIA Standard IS-98. Other communication systems are described in the international mobile telecommunications system 2000/global system for mobile telecommunications or IMT-2000/UM standard (covering what is commonly referred to as wideband cdma (wcdma), cdma2000 (e.g., cdma 20001 x-rxtt cdma 20001 x, 3x or MC standard) or TD-SCDMA). Satellite-based communication systems also utilize these or similar known standards.

In other embodiments, both link controllers 140 and 170 may be USB link controllers, or both may comprise a combination of controllers, such as, for example, an MDDI link controller and another type of link controller (e.g., a USB link controller, for example). Alternatively, link controllers 140 and 170 may comprise a combination of controllers, such as an MDDI link controller and a single link for exchanging acknowledgement messages between digital data interface device 100 and digital device 150. Link controllers 140 and 170 additionally may support other types of interfaces such as ethernet or RS-232 serial port interfaces. Additional interfaces may be supported as will be appreciated by those skilled in the relevant art based on the teachings herein.

Within digital data interface device 100, message interpreter module 110 receives commands from system controller 160 and generates response messages to system controller 160 via communication link 105, interprets the command messages, and routes the information content of the commands to the appropriate module within digital data interface device 100. Fig. 2 shows details of the structure and function of message interpreter module 110.

In particular, referring to FIG. 2, message interpreter module 110 includes a message interpreter controller 210, a response buffer 220, and a command buffer 230.

Message interpreter controller 210 reads and interprets incoming messages, generates register accesses, and generates response messages. The incoming message, for example, includes instructions from digital device 150 for controlling peripheral device 180. The response message may include an acknowledgement message back to digital device 150 as to whether the instruction was executed. The response message may also include a request to read data from peripheral device 180, and an unsolicited control command to digital device 150.

Response buffer 220 is coupled to message interpreter controller 210 and buffers the response message. Response buffer controller 225 may be coupled between response buffer 220 and link controller 140 to regulate the flow of outgoing response messages to link controller 140.

Command buffer 230 is also coupled to message interpreter controller 210 and buffers incoming command messages. Command buffer controller 235 may be coupled between command buffer 230 and link controller 140 and regulate the flow of incoming command messages received from link controller 140. Command buffer controller 235 also identifies valid command messages and detects new transactions within valid command messages. Command buffer controller 235 includes an error detection mechanism that examines a predefined unique identifier associated with a command message to detect one or more missing portions within a particular command message or within a set of command messages. In an exemplary implementation, the predefined unique identifier comprises a single bit at the beginning of the command message.

Referring back to fig. 1, content module 120 receives data from peripheral device 180, stores the data, and communicates the data to system controller 160 via communication link 105. Fig. 3 shows more details of the structure and function of the content module 120.

Referring to fig. 3, the content module 120 includes a content buffer 310, a read control module 320, a write and synchronization control module 330, and a register block 340. Content buffer 310 stores data that has been received from peripheral device 180.

Read control module 320 manages the transfer of data from content buffer 310 to link controller 140. For example, the read control module 320 may receive a request for data from the digital device 150 via the link controller 140. Read control module 320 may provide a message to digital device 150 indicating the size of the data and whether the data is ready to be sent. When data is available, the data may then be passed directly from the content buffer 310 or directly via the read control module 320.

Write and sync control module 330 manages the flow of data from peripheral device 180 to content buffer 310. Write and sync control module 330 includes a means for selectively writing some or all of the data received from peripheral device 180 to content buffer 310. Write and sync control module 330 also includes means for examining sync pulses included within the received data to determine one or more data boundaries for distinguishing content. In addition, the write and synchronization module 330 may include means for inserting timing information into the data.

Register block 340 stores operating parameters that affect the behavior of at least one of content buffer 310, read control module 320, and write and sync control module 330. Register block 340 may also be coupled to message interpreter module 110 in order to receive operating parameters. For example, register block 340 may store a video data mask (video data mask) that may be used to decimate video signals or frames when peripheral device 180 is a camera. Similarly, the operating parameters may include instructions for sub-sampling within frames and lines of the video signal, as well as instructions for determining edges of the video signal. The parameters may also include pixels per line, and window height and width information, which is then used to indicate the behavior of the write and sync control module 330 and the read control module 320.

Referring back to fig. 1, control module 130 receives information from message interpreter 130 and routes the information to control block 190 of peripheral 180. Control module 130 may also receive information from control block 190 and route the information to message interpreter module 110. Fig. 4 shows more details of the structure and function of the control module 130.

Referring to fig. 4, control module 130 includes a control register block 410 and a peripheral control block 420. Control register block 410 includes registers that provide control instructions for peripheral control block 420. Control register block 410 is coupled between message interpreter module 110 and peripheral control block 420. Peripheral control block 420 collects peripheral control information from control register block 410 and uses that information to control peripheral device 180. For example, when peripheral device 180 is a camera, peripheral control blocks 420 may include control blocks for flash or white LED control, shutter and exposure control, lens control, and master control of the camera.

Fig. 5 is a block diagram of a cellular telephone 500 having an upper clamshell section and a lower clamshell section, the cellular telephone 500 using an MDDI interface to provide high speed data communications between components located in the upper and lower clamshell. The following discussion regarding cellular telephone 500 provides an illustrative example that further shows the utility of digital data interface device 100 and provides additional details regarding its implementation and use. Based on the discussion herein, it will be apparent that the digital data interface device 100 is used with other devices, such as personal digital assistants and other types of mobile telephones, and is within the spirit and scope of the present invention.

Referring to fig. 5, a lower clamshell section 502 of a cellular telephone 500 includes a Mobile Station Modem (MSM) baseband chip 504. MSM 104 is a digital baseband controller. The present invention is not limited to use with the MSM baseband chip 504. In other embodiments, MSM baseband chip 504 may be another type of baseband processor, a programmable Digital Signal Processor (DSP), or a controller. The upper clamshell section 514 of the cellular telephone 500 includes a Liquid Crystal Display (LCD) module 516 and a camera module 518. Both lower clamshell section 502 and upper clamshell section 514 are enclosed in plastic, as is the case with typical cellular telephones. Hinges 550 and 552 mechanically connect lower clamshell 502 to upper clamshell 514. Flexible coupling 554 provides electrical coupling between lower clamshell 502 and upper clamshell 514.

MDDI link 510 connects camera module 518 to MSM 504. An MDDI link controller may be provided for each of camera module 518 and MSM 504. Within cellular telephone 500, for example, MDDI host 522 is integrated into interface system 530 that is coupled to camera module 518, while MDDI client 506 resides on the MSM side of MDDI link 510. In one embodiment, the MDDI host is the host controller for the MDDI link.

In cellular telephone 500, pixel data from camera module 518 is received and formatted into MDDI packets by interface system 530 using MDDI host 522 before being transmitted onto MDDI link 510. MDDI client 506 receives the MDDI packets and re-converts them into pixel data in the same format as the pixel data generated by camera module 518. The pixel data is then sent to the appropriate block in MSM 504 for processing.

Similarly, MDDI link 512 connects LCD module 516 to MSM 504. MDDI link 512 interconnects MDDI host 508 integrated into MSM 504 with MDDI client 520 integrated into interface system 532 coupled to LCD module 516. Display data generated by a graphics controller of MSM 504 is received and formatted into MDDI packets by MDDI host 508 before being transmitted onto MDDI link 512. MDDI client 520 receives and re-converts the MDDI packets into display data and processes the display data through interface system 532 for use by LCD module 516.

Interface systems 530 and 532 represent different embodiments of digital data device interface 100. In the case of interface system 530, the digital data device interface 100 elements will be implemented to support data transfer of camera images and camera control functions of the camera. In the case of interface system 532, digital data device interface 100 elements will be implemented to support the display of data to and control functions of the LCD. Interface system 530 is further explained to illustrate an embodiment of digital data device interface 100 when used in a cellular telephone with a camera (e.g., cellular telephone 500 with camera module 518).

The relationship between the device in fig. 1 and the cellular phone 500 is as follows. Digital data device interface 100 is represented by interface system 530. Link controller 140 is represented by MDDI host 522. Peripheral 180 is represented by camera module 518. System controller 160 is represented by MSM 504 and link controller 170 is represented by MDDI client 506.

Fig. 6 is a diagram of flip-top cover 514 and provides more detail regarding interface system 530 to highlight an exemplary embodiment of digital data device interface 100 as used within a cellular telephone with a camera. Interface system 530 includes MDDI host 522, camera message interpreter 602, camera video interface 604, I2C master 606, motor control 608, and flash/white LED timer 610. The I2C bus is a commonly used control bus that provides a communication link between circuits. The I2C bus was developed by Philips Electronics n.v. in the 80's of the 20 th century.

Recall that interface system 530 corresponds to digital data device interface 100. The components of interface system 530 correspond to the components of digital data device interface 100 in the following manner. Camera message interpreter 602 corresponds to message interpreter module 100. The camera video interface 604 corresponds to the content module 120. Collectively, I2C master 606, motor control 608, and flash/white LED timer 610 correspond to control module 130.

Camera message interpreter 602 receives the command and generates a response message to MSM 504 via MDDI host 522. Camera message interpreter 602 interprets the message and routes the information content to the appropriate block within interface system 530, which may be referred to as an MDDI camera interface device. Camera video interface 604 receives image data from camera 620, stores the image data, and passes the image data to MDDI host 522. Together, I2C master 606, motor control 608, and flash/white LED timer 610 form a camera control block. In this case, I2C master 606 provides control of the management of camera 620, motor control 608 provides control of the management of lens 622 (e.g., lens zoom function), and flash/white LED timer 610 provides control of the management of flash/white LED 624 (e.g., flash brightness and duration).

Fig. 7 shows a digital data interface device message format 700. Digital data interface device message format 700 may be used, for example, to format messages that exchange information and commands between digital data interface device 100 and digital device 150. Message format 700 contains transaction identifier field 710, count field 720, command identification field 730, status field 740, and data field 750. In one example, the transaction identifier field 710, count field 720, command identification field 730, and status field 740 are each one byte. Data field 750 is an optional field that may or may not be present. When present, the data field 750 is four or eight bytes. In other examples, the field size may be other lengths depending on the particular messaging needs. The field size uses an 8-bit format per byte. In other examples, the bit format may include other formats, such as, for example, a 4-bit or 16-bit format.

Command and response messages may be formatted using the message formats described above. There are two types of command messages: a write command and a read command. A write command is a message that executes a command, and a read command is a message that reads information from one or more registers. There are three types of response messages: write acknowledgements, read responses, and unsolicited messages. The write acknowledge is a response message indicating a successful register access. The read response message includes information read from one or more registers. In some cases, the read response message may include a status indicator or signal that is not stored in the register. The unsolicited message is generated by, for example, digital data interface device 100 if not requested by system controller 160.

When communication link 105 is an MDDI link, digital data device interface messages may be encapsulated within MDDI register access packets. Register access packets are defined within the VESAMDDI standard.

FIG. 8 shows a register access packet format 800. Register access packet format 800 includes a packet length field 810, a packet type field 820, a client ID field 830, a read/write flag field 840, a register address field 850, a parameter cyclic redundancy check ("CRC") field 860, a register data list field 870, and a register data CRC field 880. Each field is two bytes except for a register address field 850 and a register data list field 870. The register address field 850 is four bytes and the register data list field 870 is a multiple of four bytes. A digital data device interface message conforming to digital data device interface message format 700 may be encapsulated in register data list field 870. The specific use of the other fields is not germane to the present invention and is more fully described in the VESA MDDI standard.

In general, digital data interface device 100 receives commands from system controller 160 via an MDDI reverse encapsulation packet. The command ID is embedded in the packet and decoded by message interpreter module 110. The contents of the command are then sent to the appropriate block within the digital data interface device 100. Similarly, message interpreter module 110 is also responsible for building response messages to system controller 160. These messages are responses to specific commands of the system controller 160 or unsolicited messages generated by the digital data interface device 100 or the peripheral device 180.

The use of MDDI messages to encapsulate digital data device interface messages is intended to provide an example of how digital data device interface messages may be encapsulated in other existing message types, and is not intended to limit the present invention. Based on the teachings herein, one of ordinary skill in the relevant art will be able to determine how to encapsulate digital data interface device messages into other types of messages.

Referring back to fig. 7, the transaction ID field 710 is used to identify the message. The transaction ID field 710 may also be used to associate command messages with corresponding response messages. Additionally, the transaction ID field 710 may include bytes containing a unique value that specifies an unsolicited response message. Referring to fig. 1, the system controller 160 assigns a transaction identifier to populate this field and uses the transaction ID field 710 to recognize the response to a particular command.

Count field 720 is used to determine the length of the message. The count field 720 may also be used to determine the number of status and data field bytes in the message.

The command identification field 730 identifies the type of command to be executed. Each particular command ID is a value of a register base address of a particular portion of the digital data interface device 100. When peripheral 180 is a camera (such as depicted in fig. 6), an exemplary set of command IDs is as follows:

command ID	Description of the invention
		0x00	Digital device configuration commands
0x40	Camera interface control commands
		0x60	Lens control command
0x80	I2C Command
		0x90	Shutter control command
0xA0	Flash control command
		0xB0	Three-wire serial interface control command
0xC0	Phase Locked Loop (PLL) control commands
		0xD0-0xFF	Reservation commands

The status field 740 is used to determine whether to read from or write to the register block. The status field 740 may also be used to request confirmation indicating whether the command has been executed. Similarly, status field 740 may be used to specify whether the command has been successfully executed. In one example, bit 0 is used to identify whether the message is a read command or a write command. Bit 1 is used to indicate whether an acknowledgement is required. Bit 3 is used to provide acknowledgement status.

When the message is a write command, the data field 750 includes data to be written to one or more registers. In this case, data is routed to the register block based on the value in the command identification field 730. When the message is a response message, data field 750 includes data read from one or more registers. For unsolicited response messages, the data field 750 contains data related to the event that caused the unsolicited response to be sent.

The following message encodings are provided as illustrative examples of possible encodings when peripheral 180 is a camera, as depicted in fig. 6.

The format of the command message sent by system controller 160 to digital data device interface 100 for register control of digital data device interface 100 is as follows:

	name (R)	Number of bits	Description of the invention
				Byte 0	Transaction ID	8	Transaction ID assigned by system controller 160
Byte 1	Counting	8	Total number of bytes in the message
				Byte 2	Command ID	8	The digital data interface device 100 commands the ID. This value differs based on the block within the digital data interface device 100 being addressed.
Byte 3	Status of state	8	Bit 0-read/write: write 0, read bit 1-acknowledge request: 0-no request, 1-request bit 2-acknowledge state: 0-fail/error, 1-pass/success bit 3-7-reserve
				Byte 4	Register value	8	Data content
Byte 5	Register value	8	Data content
				...	Register value	8	Data content
Byte 11	Register value	8	Data content

Messages using the above format may include all register setting/configuration information required by digital data device interface 100. The command ID indicates the starting register address to be addressed in the digital data device interface 100. The digital data device interface 100 will automatically increment the register address for each successive byte until all register value bytes in the message are consumed. The count indicates the number of register accesses (including read/write bytes) in the packet. The following table lists exemplary register settings (and corresponding command ID values) in digital data device interface 100 that may be configured using messages conforming to the above format:

command ID	Description of the invention
		0x0000	Null value
0x0100	The transmit link closes the packet and waits to be reset to a clear state after transmitting the packet.
		0x0200	Powering up: enabling a clock
0x03XX	Dormancy (hibernate): this command informs the communication link 105 whether to transmit a filler packet or power down when no more packets can be sent. This will occur after a certain number of subframes, which include only padding packets, subframe headers, periodic reverse encapsulation packets, or periodic round trip measurement packets. This number is passed as the low order byte of this command. 0x # #: the number of empty subframes that need to wait before entering the sleep state. This may be a value between 1 and 225. The zero value disables automatic sleep.
		0x0400	Resetting link controller 140

0x050X	Display ignore/listen: this command tells link controller 140 whether to listen to link controller 170. 0x 00: listen to link controller 170 — default settings to allow remote wakeup.
		0x06XX	Sending reverse encapsulation: this sends a reverse encapsulation packet requesting a display capability packet. The lower byte is passed as a flag field of the reverse encapsulation packet. This allows requesting a client capability package or status package.
0x0700	Sending a round trip measurement packet: this command tells the digital data interface device 100 to send a reverse timing packet at the next available time.

The following two tables provide illustrative examples showing how a command message may be formatted in order to support a peripheral device, such as a camera. The format of the I2C command message is as follows:

	name (R)	Number of bits	Description of the invention
				Byte 0	Transaction ID	8	Transaction ID assigned by system controller 160
Byte 1	Counting	8	Total number of bytes in this message
				Byte 2	Command ID	8	I2C Command ID
Byte 3	Status of state	8	Bit 0-read/write: write 0, read bit 1-acknowledge request: 0-no request, 1-request bit 2-acknowledge state: 0-fail/error, 1-pass/success bit 3-7-reserve
				Byte 4	Camera module slave address	8	Using the least significant bit as a read/write bit
Byte 5	Camera module register address	8	Address of register in camera module
				Byte 6	Register value	8	Data content
...	Register value	8	Data content
				Byte 11	Register value	8	Data content

The format of the flash control (e.g., using white LEDs) command message is as follows:

	name (R)	Number of bits	Description of the invention
				Byte 0	Transaction ID	8	Transaction ID assigned by system controller 160
Byte 1	Counting	8	Total number of bytes in this message
				Byte 2	Command ID	8	Flash control command ID
Byte 3	Status of state	8	Bit 0-read/write: write 0, read bit 1-acknowledge request: 0-no request, 1-request bit 2-acknowledge state: 0-fail/error, 1-pass/success bit 3-7-reserve
					Intensity of white LED	8	0x00：20mA0x01：40mA

			0x02：60mA...0x18：500mA
				Byte 4	Red eye reduction mode pulse	8	The red eye reduces the number of pulses before the full discharge pulse. For a full discharge pulse, this parameter should be set to 0x 01.
Byte 5	Duration of pulse	8	Duration of the flash/strobe pulse in the clock unit.
				Byte 6	White LED duration	8	0x 00: no change is made; the state of the LED does not change. 0x 01: LED on for 1 frame time.. 0 xFF: LED on for 256 frame time
Byte 7	Red-eye reduction pulse interval	8	Time intervals between red-eye reduction mode pulses in a clock unit
				Byte 8	White LED turn-on	8	0x 00: white LED off 0x 01: white LED on 0x 02: flash/strobe full discharge 0x 04: flash/gated red eye reduction
Bytes 9-11	Retention	8

As described above, the command received from system controller 160 may require an acknowledgement or return value response from digital data device interface 100. This is defined by setting the ACK required bit in byte 3 of the command message. Three types of response messages are: an acknowledge response message indicating successful access to a control register within digital data interface device 100; a read response message carrying information read from the peripheral device; and unsolicited messages generated by the digital data interface device 100 without coming from the system controller 160.

The format of the acknowledgement response message is as follows:

	name (R)	Number of bits	Description of the invention
				Byte 0	Transaction ID	8	Transaction ID assigned by system controller 160
Byte 1	Counting	8	Total number of bytes in this message
				Byte 2	Command ID	8	Specific orderOrder ID (corresponding to the initial message sent by the system controller 160)
Byte 3	Status of state	8	Bit 0-read/write: write 0, read bit 1-acknowledge request: 0-no request, 1-request bit 2-acknowledge state: 0-fail/error, 1-pass/success bit 3-7-reserve

The format of the read response message is as follows:

	name (R)	Number of bits	Description of the invention
				Byte 0	Transaction ID	8	Transaction ID assigned by system controller 160
Byte 1	Counting	8	Total number of bytes in this message
				Byte 2	Command ID	8	Specific command ID (corresponding to the initial message sent by the system controller 160)
Byte 3	Status of state	8	Bit 0- (N/A) bit 1- (N/A) bit 2-acknowledge state, (N/A) bit 3-7-reserve
				Byte 4	Register value	8	A value read from the digital data interface device 100 or a peripheral register.
Byte 5	Register value	8	A value read from the digital data interface device 100 or a peripheral register.
				...	Register value	8	A value read from the digital data interface device 100 or a peripheral register.
Byte 11	Register value	8	A value read from the digital data interface device 100 or a peripheral register.

The format of the unsolicited response message is as follows:

	name (R)	Number of bits	Description of the invention
				Byte 0	Transaction ID	8	Transaction ID assigned by system controller 160
Byte 1	Counting	8	Total number of bytes in this message
				Byte 2	Command ID	8	N/A-0X00
Byte 3	Status of state	8	Bit 0- (N/A) bit 1- (N/A) bit 2-acknowledge state, (N/A) bit 3-7-reserve
				Byte 4	Interrupt state	8	The status of interrupts in the digital data interface device-depending on the design.
Byte 5	Link controller 140 state	8	The state of link controller 140-depending on the design.
				Byte 6	Shutter/flash execution completion	8	Command execution complete 0x 01-shutter execution Command complete 0x 02-gated execution Command complete
Byte 7	Message content	8	A value read from the digital data interface device 100 or a peripheral register.
				...	Message content	8	A value read from the digital data interface device 100 or a peripheral register.
				Byte 11	Message content	8	A value read from the digital data interface device 100 or a peripheral register.

The above message formats are intended to provide illustrative examples and are not intended to limit the scope of the present invention. Based on the teachings herein, one of ordinary skill in the relevant art will be able to develop additional message formats depending on the particular application and peripheral device used.

Conclusion

Exemplary embodiments of the present invention have been provided. The present invention is not limited to these examples. These examples are provided herein for the purpose of illustration and not limitation. Alternatives (including equivalents, extensions, variations, deviations, etc., of what is described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives are within the scope and spirit of the invention.

All publications, patents, and patent applications mentioned in this specification are indicative of the level of skill of those skilled in the art to which this invention pertains and are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference.

Claims (17)

1. A digital data interface device message format, comprising:

a transaction identification field;

a count field;

a command identification field; and

a status field.

2. The digital data interface device message format of claim 1, wherein each of the fields comprises an 8-bit format.

3. The digital data interface device message format of claim 1, further comprising a data field.

4. A digital data interface device message format according to claim 3, wherein the data field comprises four or eight bytes.

5. The digital data interface device message format according to claim 3, wherein for a write command, the data field includes data to be written to one or more registers; and wherein for a response message, the data field includes data read from one or more registers.

6. A digital data interface device message format according to claim 3, wherein for unsolicited response messages, the data field contains data relating to an event that caused the unsolicited response to be sent.

7. A digital data interface device message format according to claim 3, wherein the data field includes data routed to a block of registers based on a value of the command ID field.

8. A digital data interface device message format according to claim 1, wherein the transaction ID field includes bytes for identifying a message.

9. A digital data interface device message format according to claim 8, wherein the transaction ID field comprises bytes associating a command message with a corresponding response message.

10. A digital data interface device message format according to claim 8, wherein the transaction ID field comprises a byte containing a value specifying an unsolicited response message; and wherein the byte values are unique.

11. A digital data interface device message format according to claim 3, wherein the count field comprises bytes for determining a message length.

12. A digital data interface device message format according to claim 3, wherein the count field includes bytes for determining the number of status and data field bytes in the message.

13. A digital data interface device message format according to claim 1, wherein the status field comprises a byte used to determine whether to read from or write to a block of registers.

14. A digital data interface device message format according to claim 1, wherein the status field includes a byte for requesting confirmation whether a command has been executed.

15. A digital data interface device message format according to claim 1, wherein the status field includes a byte for specifying whether a command has been successfully executed.

16. A digital data interface device for communicating digital presentation data at a high rate between a host device and a client device over a communication link, the device comprising:

a message interpreter module that receives commands from a system controller and generates response messages to the system controller via the communication link, interprets the messages and routes the informational content of the commands to the appropriate module within the digital data interface device;

a content module that receives data from a peripheral device, stores the data, and communicates the data to the system controller via the communication link;

a control module that receives information from the message interpreter and routes information to a control block of the peripheral device; and

a set of messages, wherein each message comprises a transaction ID field, a count field, a command ID field, a status field, and a data field.

17. The digital data interface device of claim 16, wherein the set of messages includes messages for controlling a peripheral device.