Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
  • G06F13/10—Program control for peripheral devices
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
  • G06F13/10—Program control for peripheral devices
  • G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver

Definitions

• the present invention relates to the field of digital set-top software/firmware for use, e.g., in a cable or satellite television subscriber network.
• an abstract interface model is provided for device drivers in a set-top terminal.
• subscriber television networks such as cable/satellite television networks.
• Such terminals can support increased levels of programming services and a variety of software-based applications and functions, such as an electronic program guide, stock or weather banners, shop and bank at home services, games, and the like.
• this trend is expected to continue with the convergence of telephone, television and computer networks, and the rise of in- home computer networks.
• Each terminal includes different hardware devices, for example, tuners, demodulators, MPEG-2 Decoders (e.g., audio, video, and data), video encoders, audio mixers, and so forth, which are controlled by respective drivers.
• MPEG-2 Decoders e.g., audio, video, and data
• video encoders e.g., video, and data
• audio mixers e.g., audio mixers, and so forth, which are controlled by respective drivers.
• each terminal uses an operating system (OS) platform for controlling the functions of the terminal .
• the OS has a hierarchical structure wherein functions are separated according to their level of abstraction. At the bottom of the structure, the least abstract level or layer is the hardware device level . The next higher level is the device driver level . At the top of the structure, the most abstract level is typically the client level.
• each level manages a set of objects, which can be hardware or software objects, and defines operations that can be carried out on the objects.
• a device driver it is necessary for a device driver to be implemented separately for each operating system platform, e.g., for different set-top manufacturers, or different set-top models from the same manufacturer.
• a single hardware platform may be required to support different OS platforms. It is even possible for different terminals in the same network to have different operating systems .
• device drivers for a particular OS are tightly bundled to the OS, which means each driver contains OS-specific details throughout the driver's implementation, so a full development cycle is required to develop drivers for each OS platform.
• the interface should allow a device driver to be implemented only once while being usable under several operating systems and set-top platforms.
• One such suitable platform is the DCT5000 series terminals, manufactured by General Instrument Corporation, the assignee hereof.
• the interface should allow two-way communication between the device driver and a client.
• the interface should ensure that the hardware device appears the same to the terminal's client (e.g., whatever application or other entity is communicating with the device) regardless of the OS under which the hardware device operates. Similarly, the client should appear the same to the actual device driver regardless of the operating system.
• the interface should allow the sharing of architecture and code across both OS platforms and hardware platforms .
• the interface should be usable with operating systems that have, or do not have, a dedicated (operating system-specific) device driver interface.
• the interface should be implementable using object-oriented or procedure-oriented programming languages .
• the present invention provides a device driver abstract interface model having the above and other advantages .
• the present invention relates to an abstract interface model for device drivers in a set-top terminal .
• the invention allows the development of driver core logic only once.
• the core still needs to be compiled separately for each OS platform.
• a method for allowing communication between a client and a device driver in a terminal, where the terminal has an associated specific operating system under which the device driver operates .
• the method includes the step of providing a first abstract interface for converting a service request from the client that has a format that is operating system-independent into a call to the device driver that has a format that is compatible with the specific operating system.
• the first abstract interface is adapted to provide the call to the device driver in any one of a plurality of different formats that are compatible with a corresponding plurality of different operating systems .
• the device driver interface When a dedicated (OS-specific) device driver interface is present, the device driver interface is adapted to receive a second call directly from another client that has a format that is compatible with the specific operating system. The second call does not pass through the first abstract interface. Moreover, the device driver interface provides the second call to the device driver via a second abstract interface.
• a related method for allowing communication between a client and a device driver in a terminal, where the terminal has an associated specific operating system under which the device driver operates includes the step of providing a first abstract interface for converting a message from the device driver that is in the format of the specific operating system to a corresponding message in an operating system- independent format for use by the client.
• the first abstract interface is adapted to convert the message from any one of a plurality of different formats that are compatible with a corresponding plurality of different operating systems into the operating system- independent format for use by the client.
• FIG. 1 illustrates a device driver abstract interface model for use with an operating system that has a dedicated device driver interface in accordance with the present invention.
• FIG. 2 illustrates a device driver abstract interface model for use with an operating system that does not have a dedicated device driver interface in accordance with the present invention.
• the present invention relates to an abstract interface model for device drivers in a set-top terminal .
• Known object-oriented design techniques provide a method for abstractly creating objects. Mainly, the designer can create an object that provides an abstract interface without directly knowing the details of the instantiation of the object. This occurs dynamically, at the run time of the software.
• the invention extends or modifies this idea as follows. Only a single driver interface is created for all operating systems. This is done at the time the source code is compiled, and only happens once (statically) .
• the device driver core control resides immediately above the hardware device level, and communicates with the hardware device either directly, or with the assistance of the OS-specific driver support subsystem.
• the core control includes the majority of all the code in this architecture.
• the device driver core control implements the logic defined in the device driver abstract interface. This interface defines what services the driver must provide.
• the core control includes all code required to provide those services .
• FIG. 1 illustrates a device driver abstract interface model for use with an OS that has a dedicated device driver interface in accordance with the present invention.
• the dedicated device driver interface 130 may be, e.g., Windows CE from Microsoft (tm) .
• a layered device driver model 100 includes a number of levels 110, 120, 130, 140, 150 and 160. Typically, the OS requires just a driver implemented to its interface, in one level.
• a bottom level 160 which is the least abstract level, includes the hardware device itself 162 in the set-top terminal.
• the next abstract level 150 includes a second device driver abstract interface 152, a device driver core control 154, and an OS-specific driver support 156.
• the next abstract level 140 includes an OS- specific device driver implementation 142.
• the next abstract level 130 includes an OS device driver interface 132.
• the next abstract level 120 includes the first device driver abstract interface 122, and a device driver proxy 124.
• the next abstract level 110 which is the highest level, includes a client 112 that is using the device driver abstract interface 122, and a client 114 that is using the OS device driver interface 132. Note that while only one device is shown, the invention is suitable for use with any number of devices in a set-top.
• the OS-specific device driver 142 controls or drives the device driver core control 154 using the second device driver abstract interface 152.
• this level 140 with the OS-specific device driver 142 converts or transforms OS-specific device driver calls (tied specifically to an OS) into abstract device driver calls that are defined by the device driver abstract interface 152.
• the OS itself invokes services within the OS- specific device driver 142 through the operating system's defined driver interface 132.
• the OS may be
• Microsoft (tm) Windows CE for example.
• This OS invokes calls having the format "xxx_IOCTL" within a Windows CE Device Driver, where "xxx" represents the Windows CE names of the device.
• Windows CE represents an example where a proxy would invoke a "DeviceloControl" call to passing the Win CE name of the device.
• the device driver proxy 124 represents the device driver 154 to the client 112 using the abstract interface 122, which is functionally the same as the device driver abstract interface 152 that is implemented by the device driver core control 154.
• These clients can include, e.g., middleware and applications. Hence, it appears as if the client is interfacing directly to the driver core itself.
• the proxy 124 converts or transforms interface service requests from the client 112 into their associated OS-specific system device.
• the abstract interfaces 122, 152 handle data that is communicated from the driver to the client, which can be synchronous or asynchronous.
• the driver 154 With synchronous communication, the driver 154 only provides data to the client 110, 114 when asked. The data is transferred across the OS driver boundary as described in connection with the client to driver communication.
• Asynchronous communication occurs when a driver wishes to send a client data (e.g., a message) without the client asking for it. Note that the driver can only inform the client that it has data, and the client must then synchronously retrieve the data. This is summarized by the following steps:
• the driver signals the client asynchronously through an event .
• Client issues a synchronous operation to retrieve or read the data.
• the device driver proxy 124 converts abstract interface requests from a client 110 into OS- specific device driver system calls.
• the OS invokes OS-specific driver entry points.
• the OS- specific driver 142 converts the request back into a driver abstract interface request, which is the same interface call that the client originally performed. This request is executed in the device driver core 154.
• external clients can chose two interface paths when accessing drivers.
• the abstract interface 122, 152 can be used in the manner the internal clients (e.g., clients developed by the set- top manufacturer) use it, such as the client 112 is doing in FIG. 1.
• the OS driver interface can be directly used, as the client 114 is doing in FIG 1.
• An external client is external to the set-top manufacturer.
• External clients include any entity that needs to use the manufacturer's driver including, e.g., a middleware developer such as Liberate Technologies (tm) , San Carlos, California, USA, or an OS developer such as Microsoft.
• FIG. 2 illustrates a device driver abstract interface model for use with an operating system that does not have a dedicated device driver interface in accordance with the present invention.
• the hierarchical model 200 includes levels 210,
• the bottom level 260 includes the hardware device 262.
• the next abstract level 250 includes a device driver abstract interface 252, a device driver core control 254, and an OS-specific driver support 256.
• the next level 210 includes the client 212 that is using the abstract interface 252.
• FIG. 2 refers to a set-top system containing an OS without a device driver interface.
• An example of such an OS is VRTX from Mentor Graphics Corporation, Wilsonville, Oregon, USA.
• This layered architecture compresses (e.g., fewer layers are required) when the OS does not require the use of a dedicated OS-specific interface.
• the client 212 again, views the device driver 254 using the device driver abstract interface 252. But, the client directly connects to the driver core 254. Only the abstract interface 252 is available under the OS without dedicated driver interfaces.
• the device driver 254 views the client via the interface 252 to allow two-way communication. Accordingly, it can be seen that the present invention provides an abstract interface model for device drivers in a set -top terminal.
• the device driver To clients using the abstract interface, the device driver always appears the same. The client does not need to be redeveloped for each operating system. Also, the client cannot tell or see the difference between the two very different OS implementations (see FIGs 1 and 2) . The driver appears the same. A key point is that the device drivers support an abstract interface allowing clients to be developed once, and utilized across operating systems.
• the driver core control sub-system is implemented in a OS-independent manner. Typically, this sub-system requires a great amount of effort to develop (e.g., up to 90% of all driver development man-hours) . However, since the driver core control sub-system of the invention only needs to be developed once, and can then be utilized across different OS platforms, the abstract device driver model can greatly improve the time to market for new set-top products.
• LANs local area networks
• MANs metropolitan area networks
• WANs wide area networks
• internets intranets
• intranets and the Internet, or combinations thereof, may be used.
• the invention may be implemented using any known hardware, firmware and/or software techniques.

Applications Claiming Priority (3)

Publications (1)

Family

ID=23858234

Family Applications (1)

Country Status (7)

Cited By (1)

Families Citing this family (14)

Family Cites Families (1)

• 2000
  • 2000-12-06 JP JP2001547266A patent/JP2003521027A/ja active Pending
  • 2000-12-06 AU AU43100/01A patent/AU4310001A/en not_active Abandoned
  • 2000-12-06 EP EP00992393A patent/EP1287436A2/de not_active Withdrawn
  • 2000-12-06 WO PCT/US2000/042614 patent/WO2001046819A2/en not_active Application Discontinuation
  • 2000-12-06 CN CN00819068A patent/CN1434942A/zh active Pending
  • 2000-12-06 KR KR1020027007954A patent/KR20020073481A/ko not_active Application Discontinuation
  • 2000-12-06 CA CA002395468A patent/CA2395468A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events