MXPA00000776A - Ieee set top box device driver - Google Patents

Abstract

A device interface for use in a receiver/decoder (2020) for a broadcast digital television system in which received signals are passed through a receiver to the receiver/decoder and thence to a television set (2022). The receiver/decoder decodes a compressed MPEG-type signal, and is controlled by a remote controller handset (2026), through an interface in the receiver/decoder. The operation of the receiver/decoder is controlled by a virtual machine (VM) which includes a run time engine (RTE) (4008). The receiver/decoder includes a plurality of interfaces to external units. The device interface enables an application run by the RTE to access an IEEE 1394 interface.

Description

IEEE SUPERIOR BOX DEVICE CONTROLLER The present invention relates to the interconnection of application programs to physical devices (peripherals), particularly, but not exclusively, in the context of receivers / decoders for digital television systems. The advent of digital transmission systems has opened the possibility of using these systems for other purposes. One of these is to provide interactivity with the end user. As used herein, the term "digital transmission system" includes any transmission system for transmitting or broadcasting, for example, primarily digital audio or multi-media data. Although the present invention can be applied particularly to a digitally transmitted television system, the invention can also be applied to a fixed telecommunications network for multi-media internet applications, to a closed circuit television, and so on. As used herein, the term "digital television system" includes, for example, any satellite, terrestrial, cable and other systems. The present invention finds specific application in a digital television system transmitted in which the received signals are passed through a receiver to a receiver / decoder and thence to a television set. The term "receiver / decoder" as used herein may involve a receiver for receiving signals either encoded, or uncoded, for example, television and / or radio signals, which may be broadcast or transmitted by some other means. The term may also involve a decoder for decoding the received signals. The modes of those receivers / decoders may include an integral decoder with the receiver for decoding the received signals, for example, in a "top box", that decoder operating in combination with a physically separate receiver, or that decoder including additional functions, such as as a Web browser, a video recorder, or a television. The receiver / decoder decodes a signal type MPEG in a television signal for the television set. This is controlled by means of a combined remote controller handset, through an interface in the receiver / decoder, also known as a top box or STB. The term MPEG refers to the standards of data transmission developed by the working group "Group of Experts in Moving Images" of the International Standards Organization, and in particular but not exclusively the MPEG-2 standard developed for digital television applications , and outlined in documents ISO 13818-1, ISO 13818-2, ISO 13818-3 and ISO 13818-4. In the context of the present patent application, the term includes all variants, modifications or developments of the MPEG formats applicable to the field of digital data transmission. One way to provide the interactivity described above is to execute an application in the receiver / decoder through which the television signal is received. It is desirable to enable a variety of applications to communicate with a variety of physical devices in a transparent manner. Our co-pending applications PCT / EP97 / 02115 and PCT / EP97 / 02116 describe systems in which one or more applications can be downloaded by means of a receiver / decoder, and communicate with the physical devices in the receiver / decoder such as the interfaces in parallel and serial, and smart card readers by means of a device driver for each device and a global device manager. As used herein, the term "smart card" includes, but is not limited to, any chip-based card device, or similar function and performance object that it possesses., for example, a microprocessor and / or memory storage. Included in this term are devices that have alternative physical forms to a card, for example, key-shaped devices, such as those frequently used in TV decoder systems. According to the present invention, it has been proposed to provide the capability for a receiver / decoder to communicate with other audio-visual equipment, for example, a digital video recorder through a high-speed digital interface. The newly developed IEEE 1394 standard provides a promising and flexible interface protocol that provides serial communication speeds of 100 Mbps or more. A problem with the use of the IEEE 1394 interface is that the busbar of the interface can be reset, or the parameters can be altered by means of a device connected to the busbar, apart from the receiver / decoder, and this can cause problems for an application. This can lead to a requirement for more memory and processing power to execute more complex applications, capable of dealing with the interface. This would add to the cost of each receiver / decoder as well as the cost of developing and debugging applications. The aspects of the invention attempt to alleviate the problems of interconnecting applications to those interfaces. Although the invention offers most of the advantages for interconnecting a receiver / decoder to an IEEE 1394 or a similar interface, it will be noted that the invention can be applied to interconnect other applications to interfaces whose parameters may change outside the control of the application. In a first aspect, the invention provides a method for communicating data, by means of a device driver, between an application and an interface having at least one characteristic to which the interface identifier is assigned, the or each interface identifier. being subject to change after at least one event, the method comprising, for at least one of the characteristics, storing a corresponding logical identifier, providing the logical identifier to the application to direct the communication associated with the corresponding feature between the device driver and the application, and maintain correspondence between the, or each logical identifier, and the, or each characteristic independently of the interface identifier assigned to, or to each characteristic, in such a way that communication between the application and the device driver, directed using a given logical identifier, perman ece associated with the corresponding given characteristic, after a change in the assignment of the interface identifier corresponding to the characteristic. In this way, although the association of interface identifiers and features may change from time to time, those changes can be made substantially transparent to the application, which can consequently be simpler. Communication between the interface and the device driver is preferably directed based on, or to, each interface identifier; this facilitates communication with the interface. Logical identifiers can only be assigned to features that are specified by one or more applications. This can reduce the number of logical identifiers required. Alternatively, the device driver may be configured to collect a list of logical identifiers and corresponding interface identifiers for all features, or for all features that satisfy previously determined criteria, and preferably to update this list each time it is added or removes or alters a feature, or if any interface identifier is changed. Although the method removes the need for the application to know the interface identifier, the device driver is preferably configured to communicate the interface identifier assigned to the logical identifier with the application on request. It is found that this facilitates the testing of a system in a remarkable manner, since it is possible for a high-level application to determine whether the interface and the associated device driver are functioning as desired. Preferably, the device driver is configured to accept requests from an application to define connections between physical devices connected to the bus, using at least one logical identifier instead of an interface identifier. This can make it easier to manage connections through an application. The application is preferably configured to communicate with the device driver by means of the device manager element. The provision of the device manager element allows global communication control to be carried out, so that multiple applications can communicate with multiple devices without conflicts. In a first preferred implementation, at least one of the characteristics of the interface comprises a peripheral connected to the interface, and the corresponding interface identifier comprises the physical address (sometimes also known as a node address) assigned to that peripheral, the logical identifier comprising a logical address (which may also be called a logical peripheral identifier) assigned to the peripheral. In this way, an application that uses a given logical address can continue to communicate with a given peripheral (for example, a digital video recorder), even if it changes the physical address of the peripheral (for example, after connecting another peripheral). to the busbar and the subsequent restart of the busbar). In this case, correspondence maintenance preferably includes interrogating each peripheral to which a logical address is assigned, in order to determine the physical address assigned to the peripheral after the, or each event, for example, a restart of the busbar. This allows assignments to be updated after any probable change in the physical address. Also in that case, it is particularly convenient if communication of the interface identifier for a given peripheral comprises communicating the physical address (or node) of the peripheral, and also includes communicating an additional identifier of the peripheral, eg, a unique node identifier that contain additional information that identifies the peripheral. The unique node identifier can identify the manufacturer and / or the vendor and / or the model number of the peripheral, and can include a serial number. The unique node identifier is preferably 4 bytes, and most preferably 8 bytes long. According to a second preferred implementation, at least one of the characteristics of the interface comprises a channel of defined parameters available through the interface, and the corresponding interface identifier comprises the channel number of the interface (or the so-called interface identifier). channel), the logical identifier comprising a logical channel identifier. In this way, it is not necessary for the application to maintain the sequence of channel numbers of the interface, which could change. The channels are preferably isochronous channels having a defined bandwidth. Preferably the device driver is configured to receive a request from an application to allocate a defined parameter channel (e.g., a channel having a defined maximum bandwidth), and to return a logical channel identifier if the allocation is successful Although the application does not need to know the interface channel number, it is preferable if the device driver is configured to accept a preferred interface channel number, and to assign the preferred interface channel if available, and to assign a channel Free if the preferred interface channel is not available or if no preferred interface channel is specified. The provision of the capability to specify appropriate interface channels can facilitate the control and testing of the interface by means of an appropriate application, without requiring all applications to recognize the channel numbers of the interface. Preferably the device driver is configured to receive an identifier of a preferred interface channel, and to recognize a previously determined key in place of a valid interface channel number, such as not specifying any preferred interface channel, and to report a error to the application, if other invalid interface channel numbers are specified; this can help in debugging applications. It is also preferable that the device driver is configured to communicate the interface identifier of the interface to the application, and preferably also other parameters, preferably including at least one of the maximum speed assigned to the channel, the speed available at that time , the number of connections (if any) used by the channel, and the identifiers of each connection used by the channel. This enables sophisticated administration of communications through an appropriate application, without requiring all applications to deal with those parameters to use the interface. More preferably, the first and second preferred implementations are used together, the device controller being configured to accept requests from an application to define one or more connections between the peripherals attached to the interface, by reference to the logical addresses and the logical channel identifiers. The combination of the two implementations in this way provides the synergistic benefit of an application being able to establish connections without having to maintain the succession of any detail of the physical address of the peripherals concerned, nor of the interface channel through which the connection is established. Preferably, the device driver is configured to establish at least one of the point-to-point connections between specific peripherals and broadcast connections. During an event, such as a bus reboot, in which the parameters of the interface are liable to change, communication may be interrupted. Although the device driver can handle certain events without requiring input from the application, it is preferable that the device driver is configured to signal one or more events to an application (if the application requires it), including events, preferably when minus one of the restart of the busbar (preferably separate events signaling the start and end of the restart), a change in the topology of the bus, or the channel or connection parameters. In a second aspect, the invention provides a device driver for performing communication between an application and an interface having at least one feature to which an interface identifier is assigned, the, or each interface identifier being exposed to change afterwards. of at least one event, the device controller comprising elements for storing at least one logical identifier corresponding to a respective interface identifier, elements for providing the logical identifier to the application to direct the communication associated with the corresponding characteristic between the controller device and the application, and elements to maintain correspondence between the, or each logical identifier and the, or each characteristic independently of the interface identifier assigned to the, or to each characteristic, in such a way that the communication between the application and the device controller Directed logic using a given logical identifier may remain associated with the corresponding given characteristic after a change in the interface identifier assignment corresponding to the characteristic. The device driver can be implemented in the hardware, for example, in a dedicated integrated circuit; this may allow the improved speed of the operation, more preferably, however, the device driver is implemented at least partially in the software, preferably executed by means of processing elements executing the application; this allows for greater flexibility, requires fewer components, and allows the device driver to update more quickly.

In a third aspect, the invention provides a data processing system comprising a runtime machine element for executing an application, an interface element for connection to at least one device, the interface having at least one feature to the which interface identifier is assigned, the, or each interface identifier being exposed to change after at least one event, and a device controller element comprising elements to store at least one logical identifier corresponding to an interface identifier respective, an element to provide the logical identifier to the application, to direct the communication associated with the corresponding characteristic between the, or each logical identifier and the, or each characteristic independently of the interface identifier assigned to, or to each characteristic, such way that communication between the apli tion and the directed device driver using a given logical identifier, may remain associated with the corresponding given characteristic, after a change in the interface identifier assignment corresponding to the characteristic. The preferred features of the first aspect can be applied to the second and third aspects. The data processing system is preferably implemented in a receiver / decoder (eg, a top box) that includes an element for receiving broadcast data (via satellite or cable), the interface being preferably configured for connection to a digital video recorder, or to a digital visual display device, or to a computer for the visual display or storage of at least a portion of the received data. The device controller element is preferably configured to cooperate with the device element to modify the received data stream, to produce a modified data stream to pass it to the interface. The interface conforms preferably to the IEEE 1394 standard or a modification, refinement or variation thereof. The data can be transported in accordance with the IEEE 1883 standard. The application is preferably executed in an interpreted language, and preferably the device driver is collected. The invention is most preferably employed in a receiver / decoder to enable an application to communicate with, for example, a digital video recorder through an IEEE 1394 bus. The device driver can be configured to transmit commands to control the digital video recorder from the application and / or to receive data regarding the information stored in the digital video recorder; in this way an interactive application that is running on the receiver / decoder can control the recording and playback of programs or other data. The data to be communicated are preferably data in MPEG format (by which is meant any variant or development of the basic MPEG format), but other formats can be used. The preferred features of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: - Figure 1 is a schematic diagram of the interfaces of a receiver / decoder. Figure 2 is a functional block diagram of the receiver / decoder. Figure 3 shows certain components of the virtual machine and the runtime machine in more detail. Figure 4 is a schematic diagram for explaining the flow of communication between an application and a remote peripheral by means of the device driver. Figure 5 is a schematic diagram illustrating some components of the device driver.

B SICKS OF THE RECEIVER / DECODER Before describing a device driver encompassing the invention, the basic characteristics of the preferred platform, a digital satellite receiver / decoder, will be briefly explained. Referring to Figure 1, a receiver / decoder 2020 or upper box for use in a digital interactive television system in which an attempt is made to install the mode device driver is illustrated schematically. Details of an appropriate digital interactive television system can be found in our co-pending applications PCT / EP97 / 02106-02117, to which reference should be made, and whose descriptions are incorporated herein by reference. For ease of reference, the parts described in more detail in the specifications mentioned above are generally designated by the reference numbers used in those specifications. The basic configuration of the receiver / decoder will be summarized below to help understand the function of the device driver. As described in more detail in the specifications mentioned above, referring to Figure 1, the receiver / decoder 2020 includes many interfaces; specifically, a 4028 tuner for MPEG signal flow, a serial 4030 interface, a parallel 4032 interface, and two 4036 card readers, one for a smart card that is part of the system, and one for bank cards or other smart cards (used to make payments, bank at home, etc.). The receiver / decoder also includes a 4034 interface to a modulated-demodulated return channel 4002 to the producer of the television signal, such that the user can indicate preferences, etc., back to the producer of the television signal (program). . The receiver also comprises an Execution Time Machine 4008, a Device Manager 4068 and a plurality of Devices 4062 for executing one or more 4056 applications. For the purposes of this specification, an application is a piece of computer code for controlling functions high-level preference of the receiver / decoder 2020. For example, when the end-user places the focus of a remote controller on a button object that is seen on the screen of the television set 2022, and presses a validation key, it is executes the sequence of instructions associated with the button. An interactive application proposes menus and executes commands on the end user's request, and provides data related to the purpose of the application. The applications can be either resident applications, that is, stored in the ROM (or FLASH or other non-volatile memory) of the receiver / decoder 2020, or broadcast and downloaded into the RAM or FLASH of the receiver / decoder 2020. Some examples of applications, described in more detail in the applications mentioned above are: - • An Initiation Application that is an adaptive collection of modules that enable the receiver / decoder 2020 to be immediately operational in the MPEG-2 environment. • A Startup Application that allows any application, whether downloaded or resident, to run on the receiver / decoder 2020. • A Program Guide that is an interactive application that gives complete information about programming. • A Pay Per View application that is an interactive service available on each Pay Per View channel of the digital TV bouquet, to enable the end user to purchase the ongoing event. • A PC Download application that enables an end user to download computer software using the PC download application * A Magazine Browser application that includes a cyclic video broadcast of images with end user navigation via on-screen buttons . • A TV Shopping application that allows goods to be transmitted for sale to the receiver / decoder 2020, and that are visually displayed on television 2022, and that allows the user to select a particular item to buy it. The applications are stored in memory locations in the receiver / decoder 2020 and are represented as resource files. The resource files comprise graphic object description unit files, variable block unit files, instruction sequence files, application files and data files, as described in more detail in the specifications mentioned above. In the MPEG data stream, each module comprises a group of MPEG tables. Each MPEG table can be formatted as a number of sections. In the MPEG data stream, each section has a "size" of up to 4 kbytes. For the data transfer through the serial and parallel port, for example, the modules are divided in a similar way into tables and sections, the size of the section varying with the means of transport. The modules are transported in the data stream MPEG in the form of data packets of typically 188 bytes within respective types of data streams, for example, video data streams, audio data streams and teletext data streams. Each packet is preceded by a 13-bit packet identifier (PID), a PID for each packet transported in the MPEG data stream. A table of program maps (PMT table) contains a list of the different data streams, and defines the contents of each data stream, in accordance with the respective PID. A PID can alert a device to the presence of applications in the data stream, the PID being identified using the PMT table. The decoder contains the memory divided into a RAM volume, a FLASH volume and a ROM volume, but this physical organization is different from the logical organization. The memory can also be divided into memory volumes associated with the different interfaces. From one point of view, memory can be seen as part of the hardware; from another point of view, the memory can be seen as supporting or containing the entire system that is shown apart from the hardware. The system can be viewed as centered on a runtime machine 4008 that is part of a virtual machine 4007. This is coupled to applications on the one hand (the "high level" side) and, on the other side (the "low level" side), by means of different intermediate logic units described below, to the 4061 hardware of the receiver / decoder . The hardware of the receiver / decoder can be viewed as including the different ports or interfaces that were described above (the interface 2030 for the combined handset 2026, the 4028 interface of the MPEG stream, the serial interface 4030, the parallel 4032 interface, the interfaces to the 4036 card readers, and the 4034 interface to the modulated-demodulated return channel 4002). With reference to Figure 2, different applications 4056 are coupled to unit 4007; some of the most commonly used applications may be more or less resident in the system, as indicated in 4057, while others will be downloaded into the system, for example, from the MPEG data stream or from other ports as required. The unit 4007 includes, in addition to the runtime machine 4008, some resident library functions 4006 include a toolbox 4058. The library contains miscellaneous functions in the C language used by the machine 4008. These include data manipulation. such as compression, expansion or comparison of data structures, line drawing, and so on. The library 4006 also includes information about the 4061 hardware in the receiver / decoder 2020, such as the hardware and software version numbers and the available space in RAM, and a function that is used when a new 4062 device is downloaded. Functions can be downloaded into the library, and stored in Flash or RAM memory. The runtime machine 4008 is coupled to a device manager 4068 that is coupled to a set of devices 4062, which are coupled to the device drivers 4060, which in turn are coupled to the ports or interfaces. In broad terms, a device driver can be contemplated as defining a logical interface, such that two different device drivers can be coupled to a common physical port. A device will normally be coupled to more than one device driver; if a device is coupled to a single device driver, the device will typically be designed to incorporate all the functionality required for communication, so as to counteract the need for a separate device driver. Certain devices can communicate with each other. As will be described later, there are 3 forms of communication from the 4062 devices to the runtime machine: by means of variables, buffer zones, and events that are passed to a set of linear lists of events. Each function of the receiver / decoder 2020 is represented as a device 4062. The devices can be either local or remote. Local 4064 devices include smart cards, SCART connector signals, modems, serial and parallel interfaces, an MPEG audio and video player, and an MPEG section and table extractor. Remote 4066 devices, executed at a remote location, differ from the local devices in which a port and procedure must be defined by the authority or the system designer, rather than by means of a device and device driver provided and designed by the receiver / decoder manufacturer. When a new 4062 device is created, it can be installed on existing receivers / decoders 2020, by downloading the relevant application 4056 from the broadcast center. This download is made in the receiver / decoder 2020 by means of an application 4056 that verifies the hardware and software versions and, if they are correct, loads the software module representing the new device 4062 and requests a procedure from the library 4006 to install the code of the new device inside the fixed memory (in Flash memory). This can provide a flexible and secure installation of new functions inside the receiver / decoder 2020, without affecting the rest of the software. The device manager 4068 is a common software interface between the application 4056 and the specific functions of the receiver / decoder 2020. The device manager 4068 controls access to the devices 4062, declares the reception of an unexpected event, and manages the memory shared. The runtime machine 4008 operates under the control of the microprocessor and a common application programming interface. These are installed in every receiver / decoder 2020, in such a way that all the receivers / decoders 2020 are identical from the point of view of the application. The machine 4008 executes the applications 4056 in the receiver / decoder 2020. It executes the interactive 4056 applications and receives events from outside the receiver / decoder 2020, visually displays graphics and text, calls devices for services and uses functions of the library 4006 connected to the 4008 machine for specific computing. The runtime machine 4008 is an executable code installed on each receiver / decoder 2020, and includes an interpreter for interpreting and executing applications. The 4008 machine can be adapted to any operating system, including a single-task operating system (such as MS-DOS). The machine 4008 is based on process sequence units (which take different events such as a key pressure, to perform different actions), and contains its own scheduler to manage the linear lists of events from the different hardware interfaces. It also handles the visual display of graphics and text. A process sequencing unit comprises a set of action groups. Each event causes the process sequencer unit to move from its current action group to another action group, depending on the character of the event, and to execute the actions of the new action group. The machine 4008 comprises a code loader for loading and unloading applications 4056 within the memory 2028 of the receiver / decoder. Only the necessary code is loaded into the RAM or Flash memory, in order to ensure its optimal use. The downloaded data is verified by means of an authentication mechanism to avoid any modification of an application 4056, or the execution of any unauthorized application. The machine 4008 also comprises a decompressor. Since the application code (a form of intermediate code) is compressed to save space and quickly download from the MPEG-2 transport stream or by means of a built-in receiver / decoder mode, the code must be decompressed before loading it inside the RAM. The machine 4008 also comprises an interpreter to interpret the code of the application, to update the different variable values and determine the changes of state, and an error verifier. Before using the services of any 4062 device, a program (such as a sequence of application instructions) must be declared as a "client", that is, a logical path to the 4062 device or 4068 device manager . The administrator gives the client a customer number that is referenced in all accesses to the device. A 4062 device can have many clients, the number of clients for each device 4062 being specified depending on the type of device 4062. A client is introduced to the device 4062 by means of a procedure "Device_Opening Channel". This procedure assigns a customer number to the customer. A client can be removed from the client list of the device administrator 4068 by means of a procedure "Device_Close Channel". Access to the devices 4062 provided by the device manager 4068 can be either synchronized or unsynchronized. For synchronized access, a "Device: Call" procedure is used. This is a means to access data that is immediately available, or a functionality that does not involve waiting for the desired response. For unsynchronized access, a "Device: I / O" procedure is used. This is a means of accessing data that involves waiting for a response, for example, exploring frequencies of the tuner to find a multiplexer or retrieving a table from the MPEG stream. When the requested result is available, an event is placed in the linear list of the machine to signal its arrival. Another procedure "Device: Event" provides a means to manage unexpected events. As noted above, the main cycle of the runtime machine is coupled to a variety of process sequencing units, and when the main cycle encounters an appropriate event, the control is temporarily transferred to one of the process sequencing units. Referring to Figure 3, the device manager includes a linear list 100 within which the events of the devices for temporary storage are passed. At suitable intervals, the virtual machine sends a signal to this linear list to extract the first article from it. This event article is moved to a linear list structure 101 in the virtual machine. Depending on the priority level of the event article, it is inserted into the appropriate one of the 5 linear lists 0 to 4. The articles of the event are extracted from the linear list structure 101 by means of a linear list selecting unit 102, under the control of the runtime machine. When an event of the linear list structure 101 is selected, it is passed to a process sequencer unit machine 104, which consists of a process sequencer unit controller 105 and a set of process sequencing units 106. Each process sequencing unit is a set of action groups linked together, such that each step from an action group to the next action group is, in general, dependent on the current action group, and the nature of the event . Different process sequencing units have different sizes and complexities, including one in which the "next" action group, that is, the action group to which the system passes in response to an event, depends solely on the nature of the event, but is independent of the action group in progress. Furthermore, as shown on the right-hand side of the block of process sequencing units, there may be many copies of a process sequencing unit, i.e., many identical process sequence units, to deal, for example, with many streams of Separate data, using identical protocols through a single port. When an event is selected, it is passed to the appropriate process sequencer unit. It selects the appropriate output from the current action group in the process sequencer unit. This results in the selection of the next appropriate action group, and the actions in that action group to be performed, involving, for example, the sending of a message to the device manager, or the execution of a sequence of instructions. The action groups in the process sequencing unit can also send event messages to other process sequencing units. If a sequence of instructions is selected, the identification of the instruction sequence is sent to an instruction sequence selector 107. This obtains the desired instruction sequence from an instruction sequence memory 108, and passes it to an instruction sequence interpreter 109, which executes the sequence of instructions. The system also includes a filter 110, which is loaded with types of events, for example, from the process sequencing units 106. When an event article is passed from the linear list 100 in the device manager, to the linear list structure 101 in the virtual machine, its type or character is compared against the list in the filter 110, and if it is from a type that is not recognized, this is rejected. This ensures that if the device manager or keyboard generates events of a type with which the virtual machine can not handle, those events are not passed to the linear list structure 101. (If the events of this class were passed to the structure 101 of the linear list, or these would accumulate in that linear list structure or these could cause malfunctioning of the process sequencer unit machine 104). Therefore, it can be seen that our basic receiver / decoder platform provides considerable flexibility to allow an application to communicate with a variety of devices.

DEVICE CONTROLLER FOR IEEE 1394 COLLAR BAR Referring to Figure 4, it can be seen that the IEEE 1394 bus controller operates in accordance with the scheme described above to facilitate communication between an application and a peripheral such as a video recorder digitally connected to the IEEE 1394 busbar. For high-speed data communication, for example for real-time MPEG data storage, conventional serial and parallel interfaces, which are relatively easy to control via an application, may not be fast enough The device driver described below incorporates a number of novel features that allow an application to efficiently access the IEEE 1394 bus, and can enable control of, for example, a digital video recorder connected to the busbar by means of a relatively unsophisticated application. The device driver can be considered as comprising a number of functional units that are separately accessible by means of an application, hereinafter referred to as commands, Each command is interconnected with an application by means of a device 4062 executed under the control of the device. device administrator 4068, by means of one of three standard procedures mentioned above, which are common to other devices. The information can be passed between an application and the device driver by means of parameter tables. For ease of reference, the three basic procedures are briefly summarized below: -1) Device: Call. An application can use this command to perform synchronized commands or data transfer. The execution of the application is suspended until the control is returned when the device driver has completed the operation; this allows operations that must be performed in strict sequence to be controlled reliably. 2) Device: 1/0. This command allows unsynchronized operation. That is, an application can send a request for a data transfer or a particular function will perform the device driver, and the execution of the application can continue as long as the device driver performs data transfer or function. 3) Device: Event. This event capture function allows the device driver to signal events to an application, and for the application to take particular action in response to the event, regardless of whether the application code is running at the time the event is signaled. event; the application is interrupted effectively. Events can be prioritized. Events can be used to signal events that occur at the interface, such as a bus reboot. The commands that are provided in a device controller encompassing the invention will now be described. Each command can be accessed by means of an application, by passing a command identifier as a parameter, by means of the problems either Device: Call or Device: 10. It is not necessary to provide all the commands described later, and they can alter the functions of the commands. Although commands can be provided or altered independently, as will be noted, certain synergistic benefits are increased by the combined functionality provided by the commands described. The commands will be described in terms of the features and functions provided by each command, as an application sees it, along with optional and preferred features. With the information given and the specifications provided, the actual implementation of these features should be easy for a person skilled in the art, and the precise details are left to the one who implements them. As an example, each command can be implemented in the software, preferably written in the programming language C, and preferably collected to run on the processor that is used to run the application; however, the device driver can be run on a separate processor, and some or all of the commands can be implemented by means of dedicated hardware. Using the Call or 10 commands, the device driver can signal information, or pass parameters back to an application, by setting values in a parameter table stored in memory, whose address is passed to the device driver. It will be noted that the functionality described below for the commands implies that the device driver implements certain underlying functions, for example, to deal with the identifiers of logical peripherals and logical channel identifiers, the device driver incorporates means to maintain respective tables of identifiers. of logical peripherals and logical channel identifiers, enabling them to correlate with their corresponding interface characteristics (physical address or channel number of the interface respectively). In addition, in the case of an occurrence such as a bus reboot, the device driver is configured to find out the new physical addresses and channel numbers, and to update the tables in such a way that the transition is relatively clean according to an application sees it In addition, of course, the device driver includes elements to actually effect communication with the interface, and to perform the necessary maintenance tasks such as allocation and memory deallocation. Some of these functions are illustrated schematically in Figure 5. Details of these will depend on the specific physical hardware used, but they will be easy for an expert in the art to implement, based on the guidance presented in this specification, and with reference to the appropriate portions of the documentation of the IEEE 1394 standards (the description of which is incorporated herein by reference), so they will not be described herein.

Command: Bus 1394 Set This command allows an application to set the basic interface parameters, preferably the size of a buffer area of data reception to be assigned, and the number of communication retries that will be used when unsynchronized commands are sent through the 'interface. These parameters can be previously set and omit the command, but the provision of this command allows communications to be optimized for different applications. Although these parameters can very well be set asynchronously, it is preferable to access this command by means of the Call method, in such a way that the commands of the subsequent application are executed only after the parameters of the device have been established. The preference command signals an error to the application if the device driver is in the process of receiving data from a peripheral.

Command: Bus 1394 Info This command returns the basic information regarding the topology of the busbar to an application. Because it is less critical for time, it is preferably accessed asynchronously by means of command 10. Preferably this, and in fact all or at least some of the unsynchronized commands are configured to pass a maximum time ( for example in minutes) required for response (or a code, for example, zero meaning no maximum time); this may allow the device driver to prioritize requests. Preferably the command returns information concerning the maximum data transfer speed that the busbar manages, the data transfer speed available at the time of the call (that is, taking into account the connections already active in the busbar) , the number of peripherals physically connected to the busbar and their corresponding logical identifiers (which will also be described later), and which logical channels are available at the time of the call. With the IEEE 1394 busbar, each peripheral connected to the busbar is assigned a physical address that can change from time to time. It will be noted that, although the specific provision of this command is optional, it is desirable for the device driver to maintain a table of logical addresses (also called logical peripheral identifiers) that are constant for each peripheral (for a given session for a given application). the logical addresses can change if the receiver / decoder is reset), so that in each execution, an application can use a single logical address to uniquely and unequivocally identify a corresponding peripheral. The channel numbers assigned to the channels may also vary, so that the device driver also maintains a table of numbers of logical channels. The device driver can then respond to a request for information simply by searching for data from the appropriate table. Preferably, the information concerning the availability of channels is passed in binary form, such as a bitmap, preferably 8 bytes of information in which each bit encodes the availability of one of the 64 logical channels (for example a "0"). "meaning that the channel is already assigned, and a" 1"meaning that the channel is available for use).

Command: Bus 1394 Periph Info This command is configured to receive a parameter indicating a logical peripheral identifier, and to return a two-byte physical address (also known as a node ID) that corresponds to the physical address assigned to the peripheral in the interface, and preferably also to return a unique node identifier of 8 bytes, preferably only identifying the peripheral globally, or at least identifying the vendor or the model number of the peripheral. This provides the ability for an appropriately sophisticated application to determine, for example, the special capabilities of the equipment based on the information that identifies the specific peripherals. The command is preferably configured to signal an error if the interface is not physically connected to a functional IEEE 1394 bus, or if the logical peripheral identifier is invalid (eg, greater than a previously determined maximum, preferably 63), and also to signal a restart of the pending busbar, an error if the specified logical peripheral identifier is not known, or if the device fails to respond within a specified time. The command is preferably accessed asynchronously, by means of the procedure Device: 1/0, a signal indicating the termination or the fault that is being passed through a parameter block.

Command: Bus 1394 Alloc Channel This command is configured to receive a request to assign a channel, preferably specifying the desired communication speed, and also preferably the desired interface channel to be used. A previously determined code (eg OFFh) can be used to signify that there is no particular interface channel, in which case, or in the case of the interface channel being occupied, the device driver allocates an available channel. The command returns an assigned logical channel identifier if successful, and preferably indicates an error in the applicable cases described above for the Bus__1394_Info_Periph command, or if no channel is available or if the requested data rate is greater than the maximum available rate .

In simplified implementations of the device driver, for example using a very limited number of channels, this command can be omitted, and the two related commands described later, at the expense of some flexibility. The command is preferably accessed asynchronously, by means of the Device: 1/0 procedure, a signal indicating the termination or failure that is being passed through a parameter block.

Command: Bus 1394 Info Channel This command is configured to return information concerning the characteristics of a specified logical channel to an application. The command returns preferably the maximum speed assigned to the channel (in Kbit / second), the available speed through the channel at the time of the call, the actual channel identifier (that is, the one assigned by means of the interface instead by means of the device driver), the number of connections using the channel and the logical identifiers of each connection used by the channel. The preference command signals an error if the specified channel number is not assigned, in the case of an invalid identifier, in the case of a pending busbar restart, or if the interface is not physically connected.

The command is preferably accessed asynchronously, by means of the Device: I / O procedure, a signal indicating the termination or failure that is being passed through a parameter block.

Command: Bus 1394 Free Channel This command releases a channel for communication by breaking the connections for a logical channel specified as a parameter (but preferably not by unassigning the connection identifiers). The command operates preferably asynchronously and indicates that communications are still pending on the selected channel by means of an event.

Command: Bus 1394 Open Connect This command is configured to receive a request indicating a logical channel identifier, and preferably also a connection type, and to initiate a point-to-point connection between two devices or a broadcast connection in or outside, depending on the type of connection specified. Where the point-to-point connection is specified, the logical peripheral identifiers of the two peripherals must also be passed to the device driver. Although the variants of this command can operate using the actual physical addresses and channel numbers of the interface, the operation on the basis of the logical parameters offers the advantages of the simplified application operation mentioned above. The command returns a logical connection identifier if successful. Simplified implementations may omit the ability for defined point-to-point connections to be specified; in typical applications, there may be only a single device such as a digital video recorder connected to the busbar, so that broadcast connections may be sufficient. In some implementations of the device driver, the opening of a particular connection may also automatically trigger the rerouting of other signal paths within the receiver / decoder. For example, the opening of an in-line broadcast can cause automatic disconnection of the front end from the demultiplexer input, in such a way that the demultiplexer is available to process the incoming data received through the IEEE 1394 bus. This command indicates preferably an error when the maximum number of connections is reached, or in the other applicable cases mentioned above in relation to other commands. The command is preferably accessed asynchronously, through the procedure Device: I / O, a signal that indicates the termination or failure that is happening through an event.

Command: Bus 1394 Cióse Connect This command receives a logical connection identifier and stops the communication on that connection, after which it releases the connection identifier to be used again. If the signals inside the receiver / decoder are automatically redirected after the connections are opened, the device preferably restores the connections to their previous state after the connection is closed, or after the closing of the last relevant connection.

For example, the demultiplexer input can be reconnected to the front end after the closing of the last broadcast in the connection. The command is preferably accessed asynchronously, through the procedure Device: I / O, a signal that indicates the termination or failure that is happening through an event.

Command: Bus 1394 List Connect This command returns a list of active connections, only those that involve the same decoder, available at the time of the call, preferably in the form of a list that includes the number of connections, or for each connection a logical connection identifier and a flag indicating the type of connection (point-to-point, broadcast in, broadcast out). This and / or the command described below can be omitted in simple implementations of the device, if only simple connections are provided. However, the provision of these commands allows an application to monitor not only the connections it has established itself, but also to monitor connections established by other applications, if more than one application is able to use the device driver at any time , and to monitor if any connections have been closed unexpectedly. The command is preferably accessed synchronously, through the procedure Device: Call, since the connections are exposed to changing frequently, and otherwise an application could try to control communications based on outdated information, or require the grouping the response of the device driver.

Command: Bus 1394 Info Connect This command accepts a logical connection identifier and returns the logical channel number through which the connection is established. The command also preferably returns an indication of the type of connection, and, in the case of a point-to-point connection, returns the logical addresses of the wrapped peripherals. As with the List_Connect command, this command is preferably accessed synchronously.

Command: Bus 1394 Reset This command initiates a bus reboot procedure, or returns an error if a cholester bus restart is already pending. The somando can be used to allow an application to take control of the IEEE 1394 bus immediately after a restart, and is preferably accessed synchronously. The device driver preferably signals termination of the busbar restart by means of an event, described later in an additional manner.

Command: Bus 1394 Send FCP This particular command can be omitted or implemented differently. The following description is of an example of a configuration for sending data asynchronously through the IEEE 1394 bus. This command receives a parameter block containing a message that is to be sent asynchronously as a command or response to a peripheral in the IEEE 1394 busbar. The parameter block preferably contains an indication of the type of message, the size of the buffer area to be allocated for a response, the peripheral peripheral identifier of the destination peripheral, the length of the message and the message itself. The command indicates preferably successful delivery, or reports an error if the shipment was unsuccessful within a previously determined number of retries, or in the applicable cases described above for the Info_Periph command. Since large amounts of data can potentially be transferred, the command is preferably accessed asynchronously, to allow the application to continue execution while the transmission continues. Preferably, the command is configured to broadcast a message to all peripherals if a previously defined logical peripheral identifier is specified, for example 63. In simplified implementations of the device driver, this command can be restricted to the transmission of messages from fixed length, for example 32 bytes, which is sufficient for the transmission of a command to a digital video recorder. Preferably, the device driver is capable of receiving and transmitting multiple requests almost simultaneously, and of reporting multiple responses. However, simplified implementations can only provide capacity for individual sequential requests. In addition to the commands, which allow an application to send commands to the device driver, the device driver is configured to signal events to an application, through the device manager event that handles the functions. The device driver implements the following events: - Ev Bus 1394 FCP Rev This event signals the reception of an FCP frame from a peripheral, and provides a block of parameters containing the logical address of the source peripheral, the type, length and content of the message.

Ev Bus 1394 Channel This event indicates the allocation and unassignment of the channel, and passes a list that indicates which channels are assigned, preferably coded in binary form as described above in relation to the Info command.

Ev Bus 1394 Trust This event signals the peripheral connection or disconnection, and provides a list that contains the number of connected peripherals and their logical addresses. It will be noted that the device driver must monitor the changes in the interface in relation to it and the Channel event described previously, in order to maintain the mapping table between the updated interface and logical identifiers, even if the device driver does not point those events to an application.

Ev Bus 1394 Connect This event is used to signal a connection break, and provides a logical identifier to the application of the broken connection, and preferably also a list containing more information concerning the broken connection in a format similar to that described above. for the Info Connection command.

Ev Bus 1394 Lo Events This event can signal one or more low-level interface errors, for example, peripherals that keep the bus for longer than allowed, data or CRC errors, unexpected transactions, channel numbers or transaction codes unknown, and similar. This event is mainly useful for debugging, and can be omitted in simplified implementations of the device driver.

Ev Bus 1394 Hi Events This event can signal one or more high-level bus conditions, including at least one (and preferably both) of a start and end of the bus restart, and also events such as a fault of cable power, detection of a cycle in the busbar, or a fatal error whereby the device driver can not recover on its own after multiple retries.

Ev Bus 1394 Off As an additional event, this event can be used to signal internal errors to the device driver, such as not having an available buffer zone in which to store a received message. The above commands and events are merely illustrative, and the invention can be implemented in a variety of ways, and, in particular, some commands can be combined with others performing similar functions, or some can be omitted in simplified implementations. You can freely mix the hardware and software implementations of each of the functions, both between commands and within a single command; Hardware implementations can operate faster and free up processing power, while software deployments can be updated more quickly. It will be readily understood that the functions performed by the hardware, the computer software, and the like, are performed in, or using, electrical signals and the like. Software implementations can be stored in the ROM or FLASH, or they can be patched in the FLASH. It will be understood that the present invention has been described above only by way of example, and modifications of details within the scope of the invention can be made. Each feature described in the description, and (where appropriate) in the claims and drawings may be provided independently or in any appropriate combination.

Claims (46)

1. A method for communicating data, by means of a device driver, between an application and an interface having at least one characteristic to which a corresponding interface identifier is assigned, assigning the interface identifier to the characteristic being susceptible to change after at least one event, the method comprising: for at least one of the characteristics, storing a corresponding logical identifier; provide the logical identifier to the application to 'direct the communication associated with the corresponding feature between the device driver and the application; and maintain correspondence between the, or each logical identifier, and the, or each characteristic independently of the interface identifier assigned to, or to each characteristic, such that communication between the application and the device driver, addressed using a logical identifier Given, remain associated with the corresponding given characteristic, after a change in the assignment of the interface identifier corresponding to the characteristic.

2. The method according to claim 1, wherein the communication between the interface and the device driver is directed based on, or to, each interface identifier.

3. A method according to any of the preceding claims, which includes collecting a list of logical identifiers and corresponding interface identifiers for all features that meet the previously determined criteria.

4. A method according to any of the preceding claims, wherein the device driver is configured to communicate the assigned interface identifier to the logical identifier, with the application on request.

5. A method according to any of the preceding claims, wherein the device driver is configured to accept requests from an application to define connections between physical devices connected to the bus, using at least one logical identifier instead of an identifier of interface.

6. A method according to any of the preceding claims, wherein the application is preferably configured to communicate with the device driver by means of the device manager element.

A method according to any one of the preceding claims, wherein at least one of said interface characteristics comprises a peripheral connected to the interface, and the corresponding interface identifier comprises the physical address assigned to that peripheral, the logical identifier comprising a logical address assigned to the peripheral.

8. A method according to claim 7, wherein the correspondence maintenance includes interrogating each peripheral to which a logical address is assigned, to determine the physical address assigned to the peripheral after a restart of the busbar.

A method according to Claim 4 and Claim 7 or Claim 8, wherein the communication of the interface identifier for a given peripheral comprises communicating the physical address of the peripheral, and also includes communicating a unique node identifier containing Additional information that identifies the peripheral.

A method according to any of the preceding claims, wherein at least one of the characteristics of the interface comprises a channel of defined parameters available through the interface, and the corresponding interface identifier comprises the channel number of the interface, the logical identifier comprising a logical channel identifier.

11. A method according to Claim 10, wherein the device driver is configured to receive a request from an application to allocate a channel of defined parameters, and to return a logical channel identifier if the assignment is successful.

12. A method according to the claim 10 or 11, wherein the device driver is configured to accept a preferred interface channel number, and to allocate the preferred interface channel if available, and to assign a free channel if the preferred interface channel is not available or if no preferred interface channel is specified.

A method according to Claim 10, 11 or 12, wherein the device driver is configured to receive an identifier of a preferred interface channel, to recognize a previously determined key instead of a valid interface channel number. , as indicating that no preferred interface channel was specified, and to report an error to the application, if other invalid interface channel numbers are specified.

14. A method according to the claim 10, 11, 12 or 13, wherein the device driver is configured to communicate the channel number of the interface to the application, and at least one other parameter selected from: maximum speed assigned to the channel; the speed available at that moment; the number of connections (if any) that the channel uses; and the identifiers of each connection that the channel uses.

15. A method according to any of the preceding claims, wherein the device driver is configured to accept requests from an application to define one or more connections between the peripherals attached to the interface, by reference to the logical addresses and identifiers of logical channels.

16. A method according to any of the preceding claims, wherein the device driver is configured to establish at least one broadcast connection.

17. A method according to any of the preceding claims, wherein the device driver is configured to signal one or more events to an application, the events including preferably the restart of the bus (preferably the start and end) of the restart), and a change in the topology of the busbar, or the channel or connection parameters.

18. A device driver for performing communication between an application and an interface having at least one feature to which an interface identifier is assigned, the, or each interface identifier being exposed to change after at least one event, the device controller comprising: elements for storing at least one logical identifier corresponding to a respective interface identifier; elements for providing the logical identifier to the application to direct the communication associated with the corresponding feature between the device driver and the application; and elements to maintain correspondence between the, or each logical identifier and the, or each characteristic independently of the interface identifier assigned to the, or to each characteristic, in such a way that the communication between the application and the directed device controller using a logical identifier Given, it may remain associated with the corresponding given characteristic after a change in the assignment of the interface identifier corresponding to the characteristic.

19. A device driver according to Claim 18, wherein the device driver is implemented in the software, preferably executable by means of processing elements executing the, or each application.

20. A device driver according to any of Claims 18 to 19, wherein the device driver is configured to collect a list of logical identifiers and corresponding interface identifiers for all features that meet predetermined criteria.

21. A device driver according to any of Claims 18 to 20, which includes elements to communicate to the interface identifier assigned to the logical identifier, with the application on request.

22. A device driver according to any of Claims 18 to 21, including elements for accepting an application request to define connections between physical devices connected to the bus, using at least one logical identifier instead of an identifier of interface.

A device controller according to any of Claims 18 to 22, wherein at least one of said interface characteristics comprises a peripheral connected to the interface, and the corresponding interface identifier comprises the physical address assigned to that peripheral. , the logical identifier comprising a logical address assigned to the peripheral.

24. A device controller according to Claim 23, configured to interrogate each peripheral to which a logical address is assigned, to determine the physical address assigned to the peripheral after a bus reboot.

25. A device controller according to Claim 21 and Claim 23 or 24, wherein the elements for communicating the interface identifier for a given peripheral comprise elements for communicating the physical address of the peripheral, and also include elements for communicating a peripheral. unique node identifier that cons additional information that identifies the peripheral.

26. A device controller according to any of Claims 18 to 25, wherein at least one of the characteristics of the interface comprises a channel of defined parameters available through the interface, and the corresponding interface identifier comprises the number of the interface channel, the logical identifier comprising a logical channel identifier.

27. A device driver according to Claim 26, which includes channel assignment elements configured to receive a request from an application to allocate a channel of defined parameters, and to return a logical channel identifier if the assignment is successful.

28. A device driver according to Claim 27, wherein the channel allocation element is configured to accept a preferred interface channel number, and to allocate the preferred interface channel if available, and to allocate a channel. Free if the preferred interface channel is not available or if no preferred interface channel is specified.

29. A device driver according to Claim 27 or Claim 28, wherein the channel allocation element is configured to receive an identifier of a preferred interface channel, to recognize a previously determined key instead of a channel number of a channel. valid interface, as indicating that no preferred interface channel was specified, and to report an error to the application, if other invalid interface channel numbers are specified.

30. A device controller according to claim 26, 27, 28 or 29, which includes elements for communicating the channel number of the interface to the application, and at least one other parameter selected from: maximum speed assigned to the channel; the speed available at that moment; the number of connections (if any) that the channel uses; and the identifiers of each connection that the channel uses.

A device controller according to any of Claims 18 to 30, which includes elements configured to accept requests from an application to define one or more connections between the physical devices attached to the interface, by reference to the logical channel identifiers. and, in the case of a request to define a point-to-point connection, by reference to the logical addresses of the peripherals.

32. A device driver according to any of Claims 18 to 31, which includes elements configured to establish at least one broadcast connection after the request by an application.

33. A device driver according to any of Claims 18 to 31, which includes elements for signaling one or more events to an application, the events including preferably the bus restart (preferably the start and end of the bus). restart), and a change in the topology of the busbar, or the channel or connection parameters.

34. A data processing system comprising: a runtime machine element for executing an application; an interface element for connection to at least one device, the interface having at least one feature to which the interface identifier is assigned, the, or each interface identifier being exposed to change after at least one event, and one element device controller according to any of Claims 18 to 33.

35. A data processing system according to Claim 34, implemented in a receiver / decoder, including an element for receiving broadcast data, the interface being configured for connection to a digital video recorder, or to a digital visual display device, or to a computer for visual display or storage of at least a portion of the data received.

36. A receiver / decoder according to claim 35, wherein the device driver element is configured to cooperate with another device driver element to modify the received data stream, to produce a modified data stream to pass it to said interface.

37. A receiver / decoder according to Claim 35 or 36, wherein the interface complies with the IEEE 1394 standard or a variant thereof.

38. A receiver / decoder according to Claim 35, 36 or 37, wherein the application is executed in an interpreted language, and the device driver is collected.

39. A receiver / decoder in accordance with the Claim 35, 36, 37 or 38, wherein the device driver is configured to transmit commands to control a digital video recorder from the application and / or to receive data concerning the information stored in the digital video recorder.

40. A receiver / decoder in accordance with Claim 39, where the data to be communicated includes data in the MPEG format.

41. A device driver for use in a receiver / decoder, having a runtime machine element for executing an application, and a 1394 interface to which at least one peripheral, the, or each capable peripheral can be connected having a respective physical address assigned to it, the interface being capable of providing at least one communication channel, the, or each channel having a respective actual channel identifier assigned thereto, the actual channel identifier assigned to each channel, and the address assigned to each peripheral being exposed to change after a restart of the busbar, the device driver being configured to facilitate communication between the application and the IEEE 1394 interface, the device driver comprising: an element to store at least a logical address corresponding to a respective peripheral, and to store at least one identi logical channel chip corresponding to a respective real channel; an element to provide the logical address to the application to direct communication between the device driver and the application; a channel allocation element to receive a request from an application to allocate a communication channel, and, if an appropriate communication channel is available, to allocate the appropriate communication channel available and provide a logical channel identifier to the application, to direct communication between the device driver and the application; a connection allocation element for receiving a request from an application for assigning a connection between peripherals attached to the interface, using a channel identified by said logical channel identifier, and assigning a connection if possible, wherein, in the case of a request for a point-to-point connection between peripherals, the peripherals are identified using the logical addresses; a peripheral identity element configured to receive a request from an application to identify a peripheral that corresponds to a given logical address and, in response to it, to communicate the physical address of the corresponding peripheral and to communicate a unique node identifier that contain additional information that identifies the peripheral; an event signaling element for signaling to the application one of a plurality of events, including a restart of the interface bus; and a channel identity element configured to receive a request from an application to identify a channel corresponding to a given logical channel identifier and, in response to it, to communicate the channel identifier of the corresponding channel interface, and to communicate at least one additional parameter of the channel, indicating at least one of the maximum assigned channel bandwidth and channel bandwidth available at that time; wherein the channel allocation element is configured to receive an identifier of a preferred real channel, and to assign the preferred real channel if available, and to assign a free channel if the preferred real channel is not available, or if the identifier preferred real channel comprises a previously determined key in place of a valid real channel identifier, and to report an error to the application if the preferred channel identifier corresponds to an invalid real channel identifier apart from the previously determined key.

42. A receiver / decoder comprising an element for receiving broadcast data; a runtime machine element to execute at least one application; an IEEE 1394 interface element for connection to at least one peripheral device; and a device controller element according to Claim 41, for interconnecting the or each application to the IEEE 1394 interface element, and an element for transporting the received data to the IEEE 1394 interface.

43. A method for communicating data substantially as it was described herein with reference to, and as illustrated in the accompanying drawings.

44. A device driver substantially as described herein with reference to the accompanying drawings.

45. A data processing system substantially as described herein with reference to the accompanying drawings.

46. A receiver / decoder substantially as described herein with reference to the accompanying drawings.