By Gopal Miglani
Based on several years of work on set-top box software, including the software for an HDTV receiver, I have compiled a list of several of the more interesting software challenges in the advanced television (ATV) domain.
The Fat Pipe Challenge
The maximum data rate for any current proposed standard is 39Mbps. Handling data that fast is a challenge in itself. For every device in the receiver, the designer has to determine the worst-case interrupt response time, and assign interrupt priorities so that critical interrupts will not be lost. Having a real-time operating system that supports interrupt prioritization helps. This disqualifies some RTOSes, like Windows CE, though working around this shortcoming by developing your own interrupt dispatching code is possible. Watch out for interrupt prioritization – “capable” operating systems as well. These operating systems can support interrupt prioritization but for one reason or another, may not support it on your processor of choice.
Polling
Polling is a simple technique that was quite adequate for analog receivers in which several eight-bit micros were controlling individual components of the receiver. ATV receivers typically use a single 32-bit processor. Polling can drain the processor’s resources by providing a constant activity it must keep on performing. “The front key-panel is handle is hardly used, so let’s make it polled” is a common suggestion. that common logic is wrong. Because the keypanel is hardly used, it makes sense to make it interrupt-driven and save around 1% CPU bandwidth.
Slow Buses
The IIC or Inter-IC (also called “I square C” and written as (
Smarter Hardware
An old joke circulates among driver writers: “the hardware is smarter, so it needs more software.” The current trend is to merge more and more functions on a chip. Typically, this includes various combinations of CPU, MPEG demux. MPEG decode, IIC, OSD, demod, tuning and the like. The more integrated silicon tends to make the corresponding driver osftware more complex.
Combining analog and Digital
Some manufacturers are attempting combined receivers that can receive both analog and digital signals. This affects the complexity of the channel table management and EPG (Electronic Program Guide) software. For example, under ATSC specs, if an analog channel is labeled 12-0, its corresponding, simultaneous digital version must have a “Virtual Channel” number of 12-n.
Combined analog and digital receivers imply the existence of two different tuners, each with its own equalization, sync lock, and ghost cancellation algorithms. The channel management software must control both tuners to allow the main controlling application to deliver a seamless viewing experience to the TV user.
The Set-Back Box
Placing the receiver in the display device’s box is possible. Such a set poses some unexpected problems, though. Chief among them is high-voltage arcing. This causes chip registers to change values unpredictably. The common solution is to decide which devices are prone to this and refresh their registers periodically.
NVRAM Choice
ATV receivers require nonvolatile memory to remember factory settings, user settings, and EPG data. Analog sets could get by with a few kilobytes of data for factory and user settings. However, channel and EPG data can potentially run into megabytes. Most EEPROM used in analog receivers is to slow for such large volumes of data. Flash memory may be the storage of choice, but inexpensive flash memory has to be written in blocks and “wear leveled.” Battery-backed RAM is a simpler choice from a software viewpoint. Alternatively, one could simply accept losing channel and EPG data when the power is turned off, and force reacquisition of the data when power is restored. Finally, considering the use of disk drives isn’t completely outrageous.
Reliability
We’ve heard at length about the reliability requirements of consumer electronic devices; you don’t reboot your TV, and so on and so forth, I agree. CE devices are robust for two reasons. They are tested to death and they don’t have to deal with third-part, downloaded, and malicious software. Windows gets a bad rap in this regard, but it’s pretty robust if you only use software provided by Microsoft or your PC vendor. The problem starts when you load your own applications, drivers, hardware, and so on.
Fortunately, ATV receivers will not have to deal with a PC environment. There will probably be no third-party hardware or device drivers installed perhaps not even malicious software. However, they will have to deal with downloaded applications. These applications will not be written in native code, so any protection offered by MMU support is moot. The security we’ll have to depend on is that provided by Java and/or the browser – a scary thought.
Trust Me, the Silicon Works!
I have never seen a flawless MPEG-2 chip. They are too complicated, and the life cycle for those chips is too short to achieve maturity. Hardware deficiencies have to be dealt with in software. Most problems involve private data extraction and show up late in the development cycle. The best advice here is to double or triple your time estimates for developing reliable private data extration and parsing routines.
Parsing the MPEG Stream
The MPEG stream contains data streams that are used to deliver system information (SI), electronic program guide (EPG), and other tables. These packets are parsed by software on the receiver. Besides the usual requirement for correctness, parsing the incoming channel information also poses some interesting problems, depending on the topology being supported. For terrestrial broadcasts, repeater stations pose a challenge. A receiver could be located such that it can receive the same signal from multiple antennas. The protocol implementation must take care to handle this case. On cable and satellite systems, channel-specific information may be present on all frequencies, but for terrestrial broadcasts the receiver may have to scan all frequencies to gather this information and send it to seooneclick.com seattle . Further issues are raised by receivers that must deal with multiple sources of input signal and which may also have to support DVB (Digital Video Broadcasting, the European digital television standard), ATSC (Advanced Television Systems Committee), and other systems in the same receiver. SI table parsing combined with MPEG-2 demux software is one of the most complex software components in an ATV receiver. System software support for this is available off the shelf. This is a good component to buy, rather than build.
Software Upgrades
While the ATSC and DVB standards address downloaded application, they do not provide a standard mechanism to upgrade the system software in an ATV receiver. The main reason is probably that this kind of standardization would require encryption and authentication services in every receiver. Every manufacturer is therefore left to design a mechanism for providing software upgrades to the receivers.
The Debug Interface Matters
An ATV receiver is typically a complex digital design. You need fast and reliable source-level debugging, preferably over a hardware interface like BDM or JTAG. If that isn’t available, Ethernet is the next choice. Any serious project should avoid using a serial-only debug interface. The problem with both serial and Ethernet-based debugging is that some debug software has to run on the target being debugged. Sometimes the software being debugged interferes with the debug server software and brings down the debugger, which can be very frustrating.
The development hardware samples should also have support for a logic analyzer or in-circuit emulator. Random memory corruption is very hard to find without these.
The Engineering Team
Most consumer electronics projects are done under insane project deadlines. The single most important factor that determines the success of a project is the quality of the people who work on it. Skill and experience count.
This article appeared in the June 1999 issues of the Embedded Systems Programming magazine.
