RTOS vendors have moved quickly to gain a piece of any of these potentially lucrative markets for computer-like consumer devices. Integrated Systems Inc. (Sunnyvale, Calif.) is already shipping its pSOS operating system in car-navigation systems, digital cameras, phones and Sony’s satellite set-top box. Wind River Systems Inc. (Alameda, Calif.) is shipping its VxWorks in satellite set-tops and digital cameras, and is working with Nortel on Internet-connected phones. The RTOS from QNX Software Systems Ltd. (Kanata, Ont.), which senior technical analyst Mal Raddalgoda compares with Windows CE in his article later in this section, is finding use in set-tops, DVD players, VCRs and telephones.
VRTX from the Microtec division of Mentor Graphics Corp. (Wilsonville, Ore.) is targeted at many of the same applications. Set-top-box maker General Instrument (Horsham, Pa.) is using it in its new DCT-1000. Jack Birnbaum, manager of digital technical software development at General Instrument, discusses the multimedia system later in this section. Scientific Atlanta (Norcross, Ga.) uses PowerTV’s PowerOS in its digital set-top, and the OS is also being implemented in TVs, network computers and DVD devices.
Microsoft Corp. has seen the main market for its operating systems-the desktop PC-flatten in terms of market penetration. While its Windows NT has made significant inroads into servers, the volumes in neither market match those of the emerging consumer-computing arena. So, it comes as no surprise that the Redmond, Wash., company is looking for new worlds to conquer.
After its first foray into computing for consumer electronics, Windows CE 1.0, met with yawns from the embedded community, Microsoft rolled a second spin. A third spin, Windows CE 3.0, is due out in the third quarter of next year.
WinCE 2.0 comes closer than 1.0 to its RTOS competitors in terms of memory space, interrupt response and determinism. And although it is still a far cry from the capabilities of many RTOSes, CE 2.0 packs more than enough of a punch for first-generation consumer computer applications such as handheld and palm-sized PCs, where companies such as Casio, Everex, Hewlett-Packard, LG Electronics, Philips and Sharp have already pressed it into service. CE is even sturdy enough for WebTV, which sits alongside the TV set accessing the Internet at 28.8 to 56 kbits/second over existing analog phone lines.
The big question remains: Does CE have sufficient interrupt response and determinism for use in tomorrow’s all-digital TVs and set-top boxes, which will be linked to the Internet by all-digital ADSL phone connections and cable mo- dems with data rates ranging from 2 to 30 Mbits/s? A number of embedded designers who have looked at the OS in terms of its applicability to hard real-time applications suggest it does not.
One reservation voiced by several designers interviewed about WinCE 2.0 concerned threads and thread priority, and the way the OS manages them. For one thing, while CE is preemptive and multitasking, it is limited to supporting only 32 processes simultaneously. That’s enough for small systems, but this limitation can be a problem in larger systems like those found in the telecom/datacom or office-automation markets.
With the current implementation, Microsoft’s documentation says there are eight priority levels available. But only seven of them are really useful, designers said. The lower levels are idle and barely usable by applications and threads, since they can execute only after all other priorities are complete. This makes CE a solution for soft real-time applications only, and then only if an engineer is very careful in the way he or she writes the code or implements the hardware.
By way of contrast, most RTOSes have as many as 256 levels, all of which can be used in any hard or soft real-time situation. In addition, having only eight priority levels requires that multiple threads share a single priority level, managed by a round-robin scheduler. This scheduling technique is hard on system performance and makes the system determinism extremely difficult to evaluate.
Also, according to Microsoft specs, levels 2, 3 and 4 are dedicated to kernel threads and normal applications. But what the documentation does not say is that appli-cations cannot be prioritized against each other or against kernel threads. Since there are only eight priority levels, the number of threads per level will usually be bigger than the number of priorities.
This situation will make the time-slice scheduler predominant over the priority-based scheduler. Consequently, the overall system will act more like a time-slice-based scheduler rather than a priority-based system, limiting its effectiveness even in soft real-time applications.
By comparison, with an exclusively priority-based scheduler the only requirement is the need to establish priority between threads. Once established the scheduler will use these priorities to run the threads. Since thread completion (by blocking or dying) is requested before switching to another one, no additional context switches are needed.
Engineers targeting real-time Net-centric applications in the near future should also be concerned about the way WinCE 2.0 handles interrupts. The OS lacks nested interrupts, which are almost de rigueur in embedded systems. The upshot: an interrupt cannot be serviced while a previous interrupt is being processed. So, when an interrupt is raised in WinCE 2.0 while the kernel is within an interrupt service routine (ISR), execution continues to the end of that ISR before starting the ISR for a new IRQ (interrupt request line). This can introduce latencies, or delays, between the time of the hardware interrupt and the start of the ISR.
The bottom line, according to several developers, is that no matter what improvements Microsoft makes to the underlying kernel, WinCE 2.0 generally does not handle interrupts efficiently and the model is not well-suited for real-time. For one thing, interrupt prioritization is not respected. Interrupts are taken and processed by the kernel in the order of arrival. Once the kernel accepts an interrupt, this interrupt cannot be preempted by one arriving later.
The only time an interrupt can preempt another is when one interrupt service thread (IST) has a higher priority. But since WinCE 2.0 provides only two levels for IST priority, high and low, this feature is something of a blunt instrument. For systems with more than two devices generating interrupts, ISTs will have to share priority levels, and priority between devices cannot be guaranteed.
A second problem is context switches that are needed to process an interrupt. Once an interrupt is generated, the kernel performs at least three context switches: one when the processor receives the interrupt, a second when the IST is started and a third when the thread processing the data is activated. For a system with a low interrupt rate, this kernel will work perfectly. But once the rate rises, the system will completely fall down.
Intent on being a player in the real-time world, Micro- soft has vowed to improve Windows CE 3.0, adding faster thread switching, nested interrupts and more priority levels. The 3.0 kernel will require no more than 50 microseconds when switching between high-priority threads, Microsoft said. The ability to nest interrupts will make it possible to respond to higher-priority interrupts while servicing lower-priority ones. The new kernel will also support more than WinCE 2.0′s eight priority levels.