MX2007006186A - 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

MESSAGE FORMAT OF DIGITAL DATA INTERFACE DEVICE FIELD OF THE INVENTION The present invention relates generally to data communications. Very particularly, the invention relates to a digital data interface device message format.

BACKGROUND OF THE INVENTION Computers, mobile phones, mobile phone cameras and video capture devices, personal data assistants, products related to electronic games and various video technologies (for example, DVD and high definition VCR) have advanced significantly in recent years to provide the capture and presentation of static images, video, video-on-demand, and graphics of increasing resolution. The combination of such visual images with high-quality audio data, such as CD-type, DVD-type sound reproduction, and other devices that have associated audio signal outputs, creates a true multimedia experience, with richer or more realistic content for an end user. In addition, high-quality, highly mobile music and sound system transport mechanisms, such as MP3 players, have been developed for audio-only presentations to users. The explosion of high-quality data presentation leads to the need to establish specialized interfaces that could transfer data at high data rates, so that the quality of the data is not degraded or invalid. Said interface is a Mobile Screen Digital Interface (MDDI), used, for example, to exchange high-speed data between the upper and lower folding parts of a cell phone that has a camera. MDDI is a low-power, cost-effective transfer mechanism that allows very high-speed data transfer over a short-range communication link between a guest and a customer. MDDI requires a minimum of just four cables plus power for bidirectional data transfer that delivers a maximum bandwidth of up to 3.2 Gbits per second. In one application, MDDI increases reliability and decreases power consumption in collapsible cell phones by significantly reducing the number of cables running through a computer hinge to interconnect the digital baseband controller with a LCD screen and / or a camera. This reduction of cables also allows equipment manufacturers to reduce development costs by simplifying the designs of folding or sliding equipment. Although MDDI and other data interfaces can be used to effectively provide high data rates through the interfaces, interface systems that exchange data received over an MDDI or other data interface link are often slow and are not optimized for a particular application, such as, for example, processing of camera images and control data to be exchanged between the upper and lower collapsible portions of a cellular telephone. What is needed is a digital data device interface to provide efficient processing of data collected and exchanged over an MDDI or other high-speed link. Commonly owned, the co-pending EÜA Patent Application Number (with attorney's file number 1549.2350001), entitled Digital Data Interface Device, filed on November 23, 2005, describes said device. The present application describes a message format that can be used within a digital data interface device.

SUMMARY OF THE INVENTION The present invention provides a digital data interface device message format 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 interpretation module receives and interprets commands from, and generates response messages through the communication link for a system controller, interprets the messages, and guides the information content of the commands to an appropriate module within the device of digital data interface. The content module receives data from a peripheral device, stores the data and transfers the data to the system controller via the communication link. The control module receives information from the message interpreter, and guides the information to a control block of the peripheral device. In one example, the digital data interface device includes an MDDI link controller. The digital data interface device can be used to control a peripheral device, such as a camera, bar code reader, image scanner, audio device or other sensor. In a particular example, a cell phone having a camera with an MDDI link and a digital data device interface is provided. The message format of the digital data interface device includes a transaction identification field, a counting field, a command identification field and a status field. Optionally, the message format may include a data field. When an MDDI link is used, a digital data interface device message may be included in an MDDI registry access packet. Additional embodiments, features and advantages of the invention, as well as the structure and operation of the various embodiments of the invention, are described in detail below with reference to the appended figures.

BRIEF DESCRIPTION OF THE FIGURES The invention is described with reference to the appended figures. In the figures, similar reference numbers indicate functionally similar elements or identical The figure where an element appears first is indicated by the digit to the left in the corresponding reference number. Figure 1 is a diagram of a digital data device interface coupled to a digital device and a peripheral device. Figure 2 is a diagram of a message interpretation module. Figure 3 is a diagram of a content module. Figure 4 is a diagram of a control module. Figure 5 is a diagram of a cell phone having upper and lower collapsible sections using an MDDI interface to provide high-speed data communications between electronic circuits located in the upper and lower collapsible portions. Figure 6 is a diagram of the upper collapsible portion of a cell phone having a camera using an MDDI interface. Figure 7 is a diagram of a digital data interface device message format. Figure 8 is a diagram of a registration access packet that includes a reverse encapsulation message that contains an interface device message of digital data.

DETAILED DESCRIPTION OF THE INVENTION The present disclosure shows one or more embodiments that incorporate characteristics of the invention. The described embodiments simply exemplify the invention. The scope of the invention is not limited to the described modalities. The invention is defined by the appended claims thereto. The described modalities, and references in the description to "one modality", "an exemplary embodiment", etc., indicate that the described modalities may include a particular characteristic, structure or feature but each modality does not necessarily include the particular feature, structure or feature. In addition, such phrases do not necessarily refer to the same modality. Even when a particular feature, structure or feature is described in relation to a modality, it is understood that it is within the knowledge of one skilled in the art to effect said characteristic, structure or feature in connection with other modalities whether or not they are explicitly described. The embodiments of the invention can be executed in hardware, wired microprogramming, software or any combination thereof. The embodiments of the invention can also be executed as instructions stored in a machine-readable medium, which can be read and executed through one or more processors. A machine readable medium can include any mechanism for storing or transmitting information in a machine readable form (e.g., a computing device). For example, a machine-readable medium may include read-only memory (ROM); random access memory (RAM); magnetic disk storage medium; optical storage medium; fast memory devices; electrical, optical, acoustic or other forms of propagated signals (for example, carrier waves, infrared signals, digital signals, etc.), and others. In addition, wired microprogramming, software, routines, instructions can be described in the present invention as performing some actions. However, it should be appreciated that such descriptions are simply for convenience and that said actions are in fact the result of computing devices, processors, controllers, or other devices that perform wired microprogramming, software, routines, instructions, etc. Figure 1 is a diagram of a digital data device interface 100 coupled to a device digital 150 and a peripheral device 180. Digital device 150 may include, but is not limited to, a cell phone, a personal data assistant, a smartphone or a personal computer. In general, the digital device 150 may include digital devices that serve as a processing unit for digital instructions and the processing of digital presentation data. The digital device 150 includes a system controller 160 and a link controller 170. The peripheral device 180 may include, but is not limited to, a camera, a bar code reader, an image scanner, an audio device, and a sensor. In general, the peripheral 180 may include audio, video or image capture and display devices where the digital display data is exchanged between a peripheral and a processing unit. The peripheral device 180 includes control blocks 190. When the peripheral 180 is a camera, for example, the control blocks 190 may include, but are not limited to, lens control, white or intermittent LED control and shutter control. The digital presentation data may include digital data representing audio, images and multimedia data. The digital data interface device 100 it transfers digital presentation data at a high speed over a communication link 105. In one example, an MDDI communication link can be used which supports bidirectional data transfer with a maximum bandwidth of 3.2 Gbits per second. Other high data transfer rates that are higher or lower than this exemplary speed can be supported, depending on the communication link. The digital data interface device 100 includes a message interpretation module 110, a content module 120, a control module 130 and a link controller 140. The link controller 140, which is located within the interface of digital data 100, and link controller 170, which is located within digital device 150, establish communication link 105. Link controller 140 and link controller 170 may be MDDI link controllers. The MDDI standard of the Electronic Video Standards Association ("VESA") describes the requirements of a high-speed digital packet interface that allows portable devices to transport digital images from small portable devices to larger external displays. MDDI applies a miniature connector system and thin flexible cable ideal for linking computing devices, communications and entertainment to emerging products, such as supportable micro-screens. It also includes information on how to simplify connections between guest processors and a display device to reduce the cost and increase the reliability of these connections. The link controllers 140 and 170 establish a communication path 105 based on the VESA MDDI Standard. U.S. Patent No. 6,760,772, entitled "Generation and Implementation of a Communication Protocol and Interface for High-Speed Signal Data Transfer," issued to Zou et al. July 6, 2004 ("patent? 772") discloses a data interface for transferring digital data between a guest and a customer in a communication path using linked packet structures to form a communication protocol for presentation data . The embodiments of the invention shown in the "772 Patent" focus on an MDDI interface. The signal protocol is used by link controllers, such as link controllers 140 and 170, configured to generate, transmit and receive packets that form the communications protocol, and to form digital data in one or more types of data packets, at least one resident on the guest device and coupled to the client through a path of communications, such as communications path 105. The interface provides a high-speed, bidirectional, low power, and cost effective data transfer mechanism over a short-range "serial" data link, which leads to the execution with miniature connectors and thin flexible cables. One embodiment of the link controllers 140 and 170 establishes the communication path 105 based on the teachings of the 772 patent. The 772 patent is incorporated herein by reference in its entirety. In addition, the guest includes one of several types of devices that can benefit from the use of the present invention. For example, a guest could be a portable computer in the form of a handheld computer, personal computer, or similar mobile computing device, as shown in a digital device 150. It could also be a Personal Data Assistant (PDA), a localization device, or one of many wireless telephones or modems. Alternatively, a host device could be a portable display or entertainment device, such as a portable DVD or CD player, or a gaming device. The host can reside as a host device or control element in a variety of products commercially used or planned for which a high-speed communication link with a customer is desired. For example, a guest could be used to transfer data at high speeds from a video recording device to a storage-based client for improved response, or to a larger high-resolution display screen. An appliance such as a refrigerator that incorporates an on-board computer or inventory system and / or Bluetooth connections to other devices in the home, may have enhanced screen capabilities when operated in Bluetooth or Internet connected mode, or have reduced cabling needs for in-the-door screens (a client) and keyboards or scanner (client) while the electronic computer or control systems (guest) reside in some other part of the cabinet. In general, those skilled in the art will appreciate the wide variety of modern electronic devices and devices that can benefit from the use of this interface, as well as the ability to feed back older devices with superior data rate information transport using limited numbers. of available conductors in recently added or existing connectors or cables. At the same time, a client could understand a variety of useful devices to present information to an end user, or present information from a user to the host. For example, a micro-screen incorporated in glasses or lenses, a projection device incorporated in a hat or helmet, a small screen or even a holographic element incorporated in a vehicle, such as in a window or windshield, or several loudspeaker systems , hearing aids or sound to present high quality sound or music. Other display devices include projectors or projection devices used to present information at meetings, or for films and television images. Another example would be the use of touch pads or touch-sensitive devices, speech recognition input devices, security scanners, and so on, which can be used to transfer a significant amount of information from a user of a device or system. with little real "input" different to the touch or sound of the user. In addition, assembly stations for computers and equipment of carts or desktops and fasteners for cordless telephones can act as interface devices for end users or other devices and equipment, and can employ clients (input or output devices such as a mouse ) or guests to assist in the transfer of data, especially when high-speed networks are involved.

However, those skilled in the art will readily recognize that the present invention is not limited to those devices, there being many other devices on the market, and proposed for use, which are intended to provide end users with high quality images and sound, either in terms of storage and transport or in terms of presentation in reproduction. The present invention is useful for increasing the performance of the data among various elements or devices to allow the high data rates necessary to obtain the desired user experience. The inventive MDDI and the communication signal protocol can be used to simplify the interconnection between a host processor, controller or circuit component (for example), and a screen within a device or device or structure housing (referred to as a mode). internal) to reduce the cost or complexity and associated power and control requirements or restrictions of these connections, and to improve reliability, not only for connection to or for external elements, devices or equipment (referred to as an external mode). The wireless communication devices each have or comprise devices such as, but not limited to, a wireless telephone or equipment, a telephone cellular, a data transceiver, or a position or location determination receiver, and may be manual or portable as vehicle mounted (including, cars, trucks, boats, trains and aircraft) as desired. However, although wireless communication devices are generally viewed as mobile, it is also understood that the teachings of the invention can be applied to "fixed" units in some configurations. In addition, the teachings of the invention can be applied to wireless devices such as one or more data modules or modems which can be used to transfer data and / or voice traffic, and can communicate with other devices using cables or other Links or known wireless connections, for example, to transfer information, commands, or audio signals. In addition, commands should be used to cause modems or modules to work in a predetermined coordinated or associated manner to transfer information over multiple communication channels. Wireless communication devices are sometimes also referred to as user terminals, mobile stations, mobile units, subscriber units, radios or mobile radiotelephones, wireless units, or simply as "users" and "mobile" in some communication systems, depending on of preference.

In the context of wireless devices, the present invention can be used with wireless devices that use a variety of industry standards, such as, but not limited to, "Advanced Analogue Mobile (AMPS) Cellular System, and the following digital cellular systems. : Division of Code Multiple Access (CDMA) wide-spread spectrum systems, Time Division Multiple Access (TDMA) systems, and newer digital hybrid communication systems using TDMA and CDMA technologies A CDMA cellular system is described in The Telecommunications Industry Association / Electronic Industries Association (TIA / EIA) IS-95 Standard, combined AMPS and CDMA systems are described in the TIA / EIA IS-98 Standard, and other communication systems are described in the International Mobile Telecommunications 2000 / Universal Mobile Telecommunications System or IMT-2000 / UM standards, covering what It is commonly mastered as CDMA broadband (CDMA), cdma2000 (such as cdma2000 lx-rxtt cdm2000 lx, 3x, or MC standards, for example) or TD-SCDMA.

Satellite-based communication systems also use these similar known standards or standards. In other modalities, the link controllers 140 and 170 may be a USB link controller or both may include a combination of controllers, such as for example, an MDDI link controller and another type of link controller, such as, for example, a USB link controller. Alternatively, the link controllers 140 and 170 may include a combination of controllers, such as an MDDI link controller and a single link for exchanging recognition message between the digital data interface device 100 and a digital device 150. link 140 and 170 can additionally support other types of interfaces, such as an Ethernet or RS-232 serial port interface. Additional interfaces can be supported, as will be known to those skilled in the art, based on the teachings shown herein. Within the digital data interface device 100, the message interpretation module 110 receives commands from, and generates response messages through the communication link 105 for the system controller 160, interprets the command messages, and guides the content • information of the commands to an appropriate module within the digital data interface device 100. Figure 2 shows details of the architecture and function of the message interpretation module 110. Specifically, referring to Figure 2, the module of interpretation of messages 110 includes a message interpretation controller 210, a response buffer 220 and a command buffer 230. The message interpretation controller 210 reads and interprets the input messages, generates logging access and generates response messages. The input messages, for example, include instructions of the digital device 150 for the control peripheral 180. The response messages may include acknowledgment messages back to the digital device 150 that an instruction was executed or not. The response messages may also include requests for reading peripheral data 180 and unsolicited control commands to the digital device 150. The response buffer 220 is coupled to the message interpretation controller 210 and buffer the response messages. A response buffer controller 225 may be coupled between the response buffer 220 and the link controller 140 to regulate the flow of output response messages to the link controller 140. The command buffer 230 is also coupled to the message interpretation controller 210 and buffer the messages of entry command. A command buffer 235 may be coupled between the command buffer 230 and a link controller 140 which regulates the flow of input command messages received from the link controller 140. The command buffer 235 it also identifies a valid command message and detects a new transaction within the valid command message. The command buffer 235 includes an error detection mechanism that examines a predefined unique identifier associated with a command message to detect one or more missing parts within a particular command message or within a set of command messages . In an exemplary execution, the predefined unique identifier includes a single bit at the start of a command message. Referring again to Figure 1, the content module 120 receives data from the peripheral device 180, stores the data and transfers the data to the system controller 160 through the communication link 105. Figure 3 shows additional details of the architecture and function of the content module 120. Referring to Figure 3, the content module 120 includes a content buffer 310, a read control module 320, a write control and synchronization module 330 and a block of register 340. The content buffer 310 stores data that has been received from the peripheral device 180. The read control module 320 manages the transfer of data from the content buffer 310 to the link controller 140. For example, the Read control module 320 may receive a request for data from digital device 150 on e-nlace controller 140. Read control module 320 may provide messages to digital device 150 indicating the size of the data and if the data is ready to be sent. When the data is available, the data can be transferred directly from the content buffer 310 or directly through the read control module 320. The write control and synchronization module 330 manages the data flow of the peripheral device 180 to the content buffer 310. The write control and synchronization module 330 includes a means for selectively writing some or all of the data received from the peripheral device 180 for the content buffer 310. The write control and synchronization module 330 also includes a means to examine the synchronization pulses contained within the received data to determine one or more data limits in order to distinguish the content. Additionally, the write and synchronization module 330 may include a means for inserting timing information into data. The register block 340 stores operating parameters that affect the behavior of at least one content buffer 310, the read control module 320 and the write control and synchronization module 330. The register block 340 can also be coupled to the message interpretation module 110 to receive operational parameters. For example, the register block 340 may store masks of video data that can be used for decimation of a video or frame signal when the peripheral device 180 is a camera. Similarly, the operating parameters may include instructions for sub-sampling within the frames and lines of a video signal, as well as instructions used to determine the edges of a video signal. The parameters may also include pixels per line and window width and height information which is then used to dictate the behavior of the write control and synchronization module 330 and the read control module 320. Referring again to FIG. 1, the control module 130 receives information from the interpreter of messages 130 and routes the information to control blocks 190 of the peripheral device 180. The control module 130 can also receive information from the control blocks 190 and guide the information to the message interpretation module 110. Figure 4 shows additional details of the architecture and function of the control module 130. Referring to Figure 4, the control module 130 includes a control register block 410 and a peripheral control block 420. The control register block 410 contains registers that provide the control instructions for the peripheral control block 420. The control register block 410 is coupled between the message interpretation module 110 and the peripheral control block 420. The peripheral control block 420 gathers the peripheral control information of the block control register 410 and uses that information to control the peripheral device 180. For example, when or the peripheral device 180 is a camera, the peripheral control block 420 may include control blocks for white or flash LED control, exposure and shutter control, lens control and master control of the camera. Figure 5 is a block diagram of a cell phone 500 having upper and lower collapsible sections using an MDDI interface to provide High speed data communications between components located in the upper and lower folding parts. The following analysis which relates to a cellular phone 500 provides an illustrative example which further shows the utility of the digital data interface device 100 and provides additional details related to its execution and use. Based on this analysis, the use of a personal digital interface device 100 with other devices, for example, a personal digital assistant and other types of mobile telephones, will be apparent and are within the spirit and scope of the invention. Referring to Figure 5, a lower folding section 502 of a cellular telephone 500 includes a Mobile Station Modem (MSM) baseband chip 504. The MSM 104 is a digital baseband controller. The invention is not limited to use with MSM 504 baseband chip. In other embodiments, the MSM 504 baseband chip could be any other type of baseband processor, digital programmable signal processors (DSP), or controllers A top folding section 514 of the cell phone 500 includes a Liquid Crystal Display module (LCD) 516 and a camera module 518. Both collapsible sections, the lower section 502 and the upper folding section 514 are encased in plastic as is typically used with cell phones. The hinges 550 and 552 mechanically connect the lower folding section 502 and the upper folding section 514. The flexible coupling 554 provides electrical coupling between the lower folding section 502 and the upper folding section 514. The link IDD 510 connects the camera module 518 to the MSM 504. An MDDI link controller can be provided for each of the camera module 518 and MSM 504. Within the cell phone 500, for example, a MDDI guest 522 is integrated into the interface system 530 which is coupled to the module camera 518, while a MDDI Client 506 resides on the MSM side of the MDDI link 510. In one embodiment, the MDDI guest is the master controller of the MDDI link. In the cell phone 500 the pixel data of the camera module 518 is received and formatted in MDDI- packets by means of the interface system 530 using the MDDI guest 522 before being transmitted in the MDDI link 510. The MDDI client 506 receives the MDDI packets and re-converts them into pixel data of the same format as generated by the camera module 518. The pixel data is sent to an appropriate block in MSM 504 for processing. Similarly, the MDDI 512 link connects the LCD module 516 to the MSM 504. The MDDI 512 link interconnects an MDDI Guest 508, integrated in the MSM 504, and a MDDI Client 520 integrated in the interface system 532 which is coupled to the LCD module 516. The display data generated by an MSM 504 graphics controller is received and formatted in MDDI packets by means of a MDDI Guest 508 before being transmitted in the MDDI link 512. The MDDI client 520 receives the MDDI packets and re-converts them into the deployment data and processes the deployment data through an interface system 532 for use by the LCD module 516. The interface systems 530 and 532 represent different modes of the interface of the digital data device 100. In the case of the interface system 530, the interface elements of the digital data device 100 are will execute to support data transfer of camera images and camera control functions for a camera. In the case of the Interface 532 system, the interface elements of the digital data device 100 will be executed to support data display for an LCD and control functions for the LCD. The interface system 530 is further explained to illustrate a mode of the interface of the digital data device 100 when used in a cell phone with a camera, such as cell phone 500 with camera module 518.

The relationship between the devices in Figure 1 and the cell phone 500 is as follows. The interface of the digital data device 100 is represented by the interface system 530. The link controller 140 is represented by an MDDI Guest 522. The peripheral 180 is represented by a camera module 518. The system controller 160 is represented by an MSM 504 and the link controller 170 is represented by the MDDI Client 506. Figure 6 is a diagram of the upper folding portion 514 and provides additional details related to the interface system 530 to highlight the exemplary mode of the device interface. Digital data 100 as used inside a cell phone with a camera. The interface system 530 includes the MDDI guest 522, camera message interpreter 602, camera video interface 604, master I2C 606, motor control 608 and white / flash LED timer 610. The I2C link is a control link commonly used that provides a communication link between the circuits. The I2C link was developed by Philips Electronics N.V. in the 80s. Remember that the interface system 530 corresponds to the interface of the digital data device 100. The components of the interface system 530 correspond to the components of the interface of the Digital data device 100 in the following way. The camera message interpreter 602 corresponds to the message interpreter module 100. The camera video interface 604 corresponds to the content module 120. Collectively, the master I2C 606, the motor control 608 and the white / flash LED timer 610 corresponds to the control module 130. The camera message interpreter 602 receives commands and generates response messages through the MDDI guest 522. to the MSM 504. The camera message interpreter 602 interprets the messages and guides the information content to the block appropriate within the interface system 530, which can be referred to as an MDDI camera interface device. The camera video interface • 604 receives image data from the camera 620, stores the image data, and transfers the image data to the MDDI 522 host. Collectively, the I2C master 606, the motor control 608 and the LED timer white / flash 610 form a camera control block. In this case, I2C master 606 provides controls for operating camera 620, motor control 608 provides controls for handling lenses 622 (for example lens zooming functions), and timer white LED / flash 610 provides controls for handling LEDs white / flash 624 (for example brightness and duration).

Figure 7 shows a message format of the digital data interface device 700. The message format of the digital data interface device 700 can be used, for example, to format the messages exchanging information and commands between the interface device. digital data 100 and digital device 150. Message format 700 includes a transaction identifier field 710, a count field 720, a command identification field 730, a status field 740, and a data field 750 In one example, the transaction identifier field 710, the count field 720, the command identification field 730, and the state field 740 each have one byte. The data field 750 is an optional field that may or may not be present. When present, the data field 750 has four or eight bytes. In other examples, the field sizes may have other lengths, depending on the specific message delivery needs. The field size uses an 8-bit format for each byte. In other examples, the bit format may include other formats, such as, for example, a 4-bit or 16-bit format. Using the message formats above, you can format the command and response messages. There are two types of command messages: a write command and a read command. A writing command is a message to execute a command, and a read command is a message to read information from one or more records. There are three types of response messages: a handwriting recognition, a read response and an unsolicited message. A handwriting recognition is a response message that indicates successful logging access. A read response message contains information that was read from one or more records. In some cases, a read response message may contain status indicators or signals that were not stored in a record. An unsolicited message is generated by, for example, the digital data interface device 100 without a request by the system controller 160. When the communication link 105 is an MDDI link, the interface messages of the digital data device they can be encapsulated within MDDI registry access packets. The registry access packages are defined within the VDI MDDI standard. Figure 8 shows the log access packet format 800. The log access packet format 800 includes a packet length field 810, a packet type field 820, a client ID field 830, a field of read / write indicator 840, a register address field 850, a revision field of cyclic parameter redundancy ("CRC") 860, a record data list field 870 and a CRC field of record data 880. With the exception of the record address field 850 and the record data list field 870 , each field has two bytes. The register address field 850 has four bytes and the register data list field 870 is a multiple of four bytes. An interface message of the digital data device that conforms to the interface message format of the digital data device 700 can be encapsulated in the record data list field 870. The specific uses of the other fields are not redundant for the present invention, and are described more fully in the VESA MDDI standard. In general, the digital data interface device 100 receives commands from the system controller 160 through MDDI reverse encapsulation packets. The command IDs are incorporated into the packet and are decoded by the message interpretation module 110. The content of the commands is then sent to the appropriate block within the digital data interface device 100. Similarly, the interpretation module of messages 110 is also responsible for constructing the response messages for the system controller 160. These messages are a response to a specific command of the system controller 160, or a message not requested generated by the digital data interface device 100 or peripheral device 180. The use of an MDDI message to encapsulate an interface message of the digital data device is intended to provide an example of the way in which the interface messages of the device Digital data can be encapsulated in other types of existing messages, and is not intended to limit the invention. Based on the teachings shown here, experts in the relevant technique will be able to determine the way in which it is. encapsulate the messages of the digital data interface device in other types of messages. Referring again to Figure 7, the transaction ID field 710 is used to identify messages. The transaction ID field 710 can also be used to associate a command message with a corresponding response message. Additionally, the transaction ID field 710 may include a byte containing a unique value which specifies an unsolicited response message. Referring to Figure 1, the system controller 160 allocates a transaction identifier that is used to populate this field and uses the transaction ID field 710 to recognize the response to a specific command. The counting field 720 is used to determine the length of a message. The count field 720 can also be used to determine the number of bytes of data field and status in a message. The command identification field 730 identifies the type of command to be executed. Each specific command ID is the value of the registration base address for the specific section of the digital data interface device 100. When the peripheral device 180 is a camera, as shown in FIG. 6, an example configuration of Command ID is as follows: The 740 state field is used to determine if it is read from, or written to a block of record. The status field 740 can also be used to request an acknowledgment indicating whether a command has been executed. Similarly, state field 740 can be used to specify whether a command has been successfully executed. In an example, bit 0 is used to identify whether the message is a read or write command. Bit 1 is used to indicate if recognition is required. Bit 3 is used to provide a recognition status. When a message is a written command, the data field 750 includes data to be written for one or more records. In this case, the data is guided to a register block based on a value in the command identification field 730. When a message is a response message, the data field 750 includes data that was read from one or more records. For a reply message no. As requested, the data field 750 includes 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 the peripheral device 180 is a camera, as shown in Figure 6. The formats for the command messages sent by the system controller 160 to the interface of the digital data device 100 for the registration control of the interface of the digital data device 100 are as follows: A message using the above format can contain all the setting information / registration settings necessary for the interface of the digital data device 100. The command ID indicates the start registration address in the interface of the digital data device 100 which is going to address. The interface of the digital data device 100 will automatically increment the registration address for each consecutive byte until all bytes of record value in the message have been consumed. The count indicates the number of logging accesses in the packet (including the read / write byte). The following table lists exemplary record sets (and the corresponding command ID value) in the interface of digital data device 100 that can be configured using messages that conform to the previous format.

The following two tables provide examples examples illustrating the manner in which command messages can be formatted to support a peripheral device, such as a camera. The format for an I2C command message is as follows: The format for a flash control command message (for example, using a white LED) is as follows: As discussed above, commands received from system controller 160 may require the recognition or a return value response from the interface of the digital data device 100. This is defined by setting the required bit ACK in byte 3 of a command message. The three types of response messages are a recognition response message, which indicates successful access to a control register within the digital data interface device 100, a read response message, which carries information read from a peripheral device and an unsolicited message, which is generated by the digital data interface device 100 without a request from the system controller 160. The format for a recognition response message is as follows: The format for a read response message is as follows: The format for an unsolicited response message is as follows: The above message formats were intended to provide illustrative examples, and are not limited to the scope of the invention. Based on the teachings here shown, those skilled in the art will be able to develop additional message formats depending on the specific application and peripherals being used.

Conclusion Exemplary embodiments of the present invention have been presented. The invention is not limited to these examples. These examples are presented here for purposes of illustration and not limitation. The alternatives (including equivalents, extensions, variations, deviations, etc., of those described here) will be apparent to experts in the relevant techniques based on the teachings contained herein. These alternatives fall within the scope and spirit of the invention. All publications, patents and patent applications mentioned in this description are indicative of the skill level of those skilled in the art to which this invention pertains, and are hereby incorporated by reference to the same extent as if each individual publication, patent or application of patent was specifically and individually indicated to be incorporated by reference.

Claims (17)

NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following is claimed as a priority: CLAIMS

1. - A digital data interface device message format, comprising: a transaction identification field; a counting field; a command identification field; and a state field.

2. - The message format of the digital data interface device according to claim 1, characterized in that each of the fields comprises an 8-bit format.

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

4. The message format of the digital data interface device according to claim 3, characterized in that the data field includes four or eight bytes.

5. - The message format of the digital data interface device according to claim 3, characterized in that for a write command, the data field includes data to be written in one or more registers; and where for response messages, the data field includes data that was read from one or more records.

6. The message format of the digital data interface device according to claim 3, characterized in that for an unsolicited response message, the data field includes data related to the event that caused the unsolicited response to be sent .

7. The message format of the digital data interface device according to claim 3, characterized in that the data field contains data that is guided to a register block based on a value of the command ID field.

8. The message format of the digital data interface device according to claim 1, characterized in that the transaction ID field comprises a byte that is used to identify a message. 9.- The message format of the digital data interface device in accordance with the claim 8, characterized in that the transaction ID field comprises a byte that associates a command message with a corresponding response message. 10. The message format of the digital data interface device according to claim 8, characterized in that the transaction ID field comprises a byte containing a value specifying an unsolicited response message; and where the value of the byte is unique. 11. The message format of the digital data interface device according to claim 3, characterized in that the counting field comprises a byte that is used to determine the length of a message. 12. The message format of the digital data interface device according to claim 3, characterized in that the counting field comprises a byte that is used to determine the state number and bytes of the data field in a message. 13. The message format of the digital data interface device according to claim 1, characterized in that the state field comprises a byte used to determine whether it is read from or written to a register block. 14.- The message format of the device digital data interface according to claim 1, characterized in that the state field comprises a byte used to request an acknowledgment as to whether a command has been executed. 15. The message format of the digital data interface device according to claim 1, characterized in that the status field comprises a byte used to specify whether a command has been executed successfully. 16. A digital data interface device for transferring digital presentation data at a high speed between a guest device and a client device over a communication link, comprising: a message interpretation module that receives commands from, and generates response messages through the communication link for a system controller, interprets the messages, and guides the information content of the commands to an appropriate module within the digital data interface device; a content module that receives data from a peripheral device, stores the data and transfers the data to the system controller via the communication link; a control module that receives information from message interpreter, and guide the 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 according to claim 16, characterized in that the set of messages includes messages to control a peripheral device.