July 17, 1997

Windows CE at the center of a juggling act

MARKUS LEVY, TECHNICAL EDITOR

Microsoft's Windows CE operating system has been relatively successful in handheld PCs. Now, the company is trying to take the OS into more embedded applications. Find out if WinCE has what it takes to compete with the traditional embedded OSs.

Last September, Microsoft Windows CE (WinCE) made its debut as the Win95-like operating system for handheld PCs. It had a fairly positive beginning as OEMs quickly designed the new operating system into seven handheld PCs, and that number continues to grow. But now Microsoft wants to open the doors for WinCE to land in a variety of embedded applications, including terminals, industrial controllers, wireless communication devices, digital-video-disk (DVD) players, set-top boxes, and Internet Web phones.

WinCE's primary attributes are the familiar Windows GUI and support for the Win32 application-programming interface (API). These attributes enable developers with Windows-based software experience to develop for the handheld-PC platform without adapting to new environments. Although Microsoft has touted WinCE's being built from scratch with modularity in mind, the company has provided no details describing WinCE's hard, real-time responsiveness. Furthermore, most of the media attention has focused on the seamless exchange of information between WinCE-powered handheld PCs and desktop or mobile PCs. What lies behind the GUI front end is still a mystery, as is WinCE's performance compared with the traditional embedded OSs. Furthermore, a GUI alone does not constitute an OS.

Like Windows NT, WinCE is a multitasking, multithreaded operating sys tem with pre-emptive, priority-based scheduling. It can run multiple processes, and each process can have multiple threads, each with its own priority. Similar to WinNT and Win95, WinCE uses the standard Win32 APIs, providing an interface that is familiar to a large programmer base. One difference, however, is that WinCE supports only slightly more than 500 Win32 APIs, a subset of the 1000-plus Win32 APIs that WinNT and 95 support.

Although Microsoft selected the 500 APIs that would best serve the WinCE applications, this limitation does mean that WinCE may be unable to run all WinNT and 95 applications. If you want to port a WinNT or 95 application to run under WinCE, you have to check the API calls that the WinNT or 95 application makes and modify the calls to unsupported APIs. However, many embedded-system developers clearly feel most comfortable in a Win32 development environment using the Win32 APIs. The fact that traditional RTOS vendors, such as QNX and Wind River, are adding a Win32 API layer to their kernels confirms this preference. The Win32 API layer translates Win32 calls into native RTOS calls.

The major software elements of WinCE include the kernel, graphics system, windowing system, device drivers, file systems, registry interface, OEM abstraction layer (OAL), various shells, Internet Explorer-CE, and communications suite (sockets, transmission-control protocol/Internet protocol (TCP/IP), Infrared Data Association (IrDA), point-to-point protocol (PPP), Network Driver Interface Specification (NDIS), WinInet, etc) (Figure 1). Unlike WinNT and 95, WinCE is a modular operating system, allowing you to pick the pieces you need for your application, which is essential for applications with code-size constraints. You can build a WinCE device with just the kernel, the OAL, and some device drivers, and not even use the graphics system, for example. In the smallest configuration, WinCE can fit into 128 kbytes of ROM and 32 kbytes of RAM. However, this simple system could run only one thread and would lack a user interface and communication software. Nevertheless, WinCE's code size is incredibly smaller than that of WinNT or 95. But WinCE is much larger than Integrated System Inc's (ISI's) pSOS+ or Microtec's VRTX kernels, which start at less than 2 kbytes of ROM and 600 bytes of RAM. WinCE is also larger than Wind River's VxWorks, which ranges from as small as 5 kbytes of ROM for the deterministic, stand-alone Wind microkernel to more than 1 Mbyte with Java, graphics, a Web browser, and networking support.

A full-blown Windows CE implementation using all of the components and shells to build a handheld PC consumes about 2 Mbytes of ROM and 1 Mbyte of DRAM. And if you bundle in a few applications, memory requirements could easily exceed 4 Mbytes of ROM and 2 Mbytes of RAM. You could also build a WinCE-based cellular phone that would fit into about 512 kbytes of ROM and 512 kbytes of RAM. This phone would support an alphanumeric display, an address book, and Internet connectivity for functions such as directory services and stock quotes.

The flexibility of WinCE's modules also allows you to replace components. For example, if you don't like the IrDA component contained within Microsoft's communication stacks, you can replace it with a third party's infrared driver, such as the PicoRay from Phoenix Technologies' PicoPAL product line.

One of Microsoft's goals for Windows CE is to help the company make the transition from desktop PCs to consumer and industrial devices; the handheld PC is the first incarnation of this transition. For the most part, the capabilities of WinCE seem to match up well to this application. But how does this OS stack up in applications that are not as PC-like as the handheld PC? Furthermore, how does WinCE compare with other embedded operating systems?

Mission-critical functions

PC users have grown accustomed to using the three-fingered salute of the infamous ALT-CTRL-DEL key se-quence. Misbehaved applications are more the norm than the exception in PCs. But misbehaved applications are unacceptable in time-critical devices or consumer appliances. ("Excuse me while I reboot my television!") WinCE uses the virtual-memory system of the processor to protect against bad applications' crashing the entire system. Theoretically, this approach would prevent an application from accessing another application's memory space and from directly writing into the OS's memory space. Furthermore, you can write applications and drivers that can detect and respond to many fatal software defects.

For those defects that software cannot catch directly, embedded applications typically use watchdog timers to detect and initiate recovery. WinCE-based applications or applications that use RTOSs--such as QNX, Wind River's VxWorks, or ISI's pSOS+--also use this approach. A watchdog timer allows a system to restart without the user's intervention. The best way to ensure that a watchdog interrupt will run when a system malfunctions is to process the interrupt as a nonmaskable (or at least the highest priority) interrupt. You can write such interrupt handlers using Microsoft's OEM Adaptation Kit (OAK) for WinCE. Alternatively, third-party developers, such as VenturCom, are providing such handlers as part of their WinCE extensions. VenturCom's and Radisys' real-time extensions (RTXs) contain APIs for notifying hard, real-time processes that a system failure has occurred. But, although these extensions notify the system of a failure, the user must usually issue a physical hardware reboot.

A software watchdog, which QNX uses, is another approach to detecting process crashes. When a process crashes abnormally (for example, with an errant pointer), the OS notifies the software watchdog. The software watchdog then analyzes the fault and restarts the errant process, a related group of processes, or all the processes. This procedure may allow system recovery without the need for a hardware reboot.

In certain applications, it may be necessary to detect if a system reset has occurred. Some OSs, such as pSOS+ and VRTX, can detect a system reset when the system is using a CPU that has registers that indicate why a reset has occurred. For example, Motorola's 68340 can inform the user application that a watchdog time-out or a double-bus fault generated a system reset. According to Microsoft, WinCE can detect a system reset or power on/off and record that information. You may be able to obtain more detailed information, such as whether a double-bus fault, an external interrupt, or a power glitch caused the reset, depending on the processor.

Handling application crashes is one important feature of any operating system. Another is the ability to schedule the CPU's processing of prioritized events. Events include hardware interrupts, timer triggers, window messages that the system generates in response to user input, and interprocess messaging. A typical WinCE device contains many processes. Each process comprises one or more threads, the actual units of execution. The application developer assigns each thread one of seven priority levels. Theoretically, in WinCE, the two highest priority levels could be for interrupt-level code, and the lowest level could be for idle-time tasks. However, in reality, all processes belong to the normal priority class; WinCE does not support the idle, high, and real-time priority classes.

Among the normal-priority processes, the thread with the highest priority level (from among all the processes) runs until it blocks (perhaps while waiting for input or some other system service) or completes. At that point, the scheduler runs the next highest priority thread. Higher priority processes may pre-empt those with a lower priority. Also, in WinCE devices, the scheduler time-slices threads of the same priority level; the user can set the length of the time slice.

RTOSs such as VxWorks, pSOS+, VRTX, QNX, LynxOS, and Microware's OS-9 support multitasking in a similar manner to WinCE. One difference, although it may be insignificant, is that the RTOSs support 256 levels of task priority. Another difference is that the developer has the option to schedule pre-emptively, in a round-robin manner, or a combination of the two. VxWorks also has the flexibility to allow you to plug in your own scheduling algorithms or dynamically control scheduling time slices and task priorities.

OS-9 uses a combination of round-robin and real-time priority-based scheduling. Its scheduler ages processes and re-evaluates priorities at each system tick. The scheduler first gives resources to the highest priority, nonblocked, real-time tasks and then applies round-robin scheduling for tasks not executing in real-time. This combination is configurable and under the user's control.

Re-entrancy is important in a multitasking system in which multiple processes can "simultaneously" access a function. Similar to most RTOSs, both WinCE and VenturCom's RTXs to CE support re-entrancy and provide pre-emptable critical-section management that prevents unbounded priority inversion. A higher priority thread can pre-empt a thread holding a critical section. If the higher priority thread tries to enter the critical region occupied by a lower priority thread, the scheduler temporarily boosts the priority of the lower priority thread to that of the higher priority thread waiting to enter the critical section. This priority boosting, or priority inheritance, allows the lower priority thread to get through the critical section and relinquish control to the waiting threads. This method results in minimal pre-emption latency without the chance of deadlock.

When an interrupt occurs in a WinCE system, the OS masks all other interrupts regardless of priority while the interrupt-service routine (ISR) runs. The ISR must interrogate the hardware to determine which interrupt has occurred. The ISR then runs the interrupt-service thread that the OS has designated to service that interrupt. This approach, which some RTOSs take, allows low interrupt latency but may increase the latency in the system processing the interrupt as a thread. However, this approach leads to proper prioritization of interrupt processing, because the OS schedules the interrupt processing just as it does other application threads. Microsoft claims that ISRs typically run for 4 to 5 µsec on a 32-MHz µP, so, depending on the application, the interrupt may not have a noticeable effect on response time.

RTOSs such as those mentioned typically allow higher priority interrupts to interrupt currently executing interrupts, but this approach is processor-dependent. RISC µPs often have only one usable interrupt and a nonmaskable interrupt. ISI's pSOS+ handles the RISC µPs by setting up a software vector system. When the interrupt fires, execution is interrupted. The ISR then polls hardware to figure out which interrupt has fired and calls the relevant handler. ISRs can run with or without pSOS+'s being aware that the interrupt has fired. If pSOS+ is aware, then it recalculates priorities based on the fact that the ISR may have posted data to a queue or changed a semaphore that a task may have been blocked on. In this way, pSOS+ achieves fast ISR-to-task response times. CISC µPs work in a similar way, but usually the hardware handles the interrupt priorities, and the µP can interrupt an interrupt.

Applications' "forgetting" to free allocated objects causes memory leaks. Memory leaks may result in a system that has slower response, that stops performing certain functions, or that hangs. Windows CE automatically cleans up allocated objects when an application terminates but only when that application is well-behaved. WinCE's memory management can track memory leaks to the process that is at fault, but it is ultimately the developer's responsibility to identify the leak. Development packages are available to Win32 developers to help find memory leaks; these packages should become available for WinCE developers as well. In response to low memory, WinCE sends WM_HIBERNATE messages to applications, asking the applications to take a snapshot of their state and free as many resources as possible. In most embedded systems, the developer typically understands the applications' use of memory, so a crash shouldn't occur. In addition, the developer may preallocate memory to help achieve determinism.

WinCE relies on the developer to plug any memory leaks during application development. As process-based systems, several RTOSs, such as OS-9 and LynxOS, keep track of all memory resources that the kernel allocates and deallocates from processes. Upon termination of the process, the kernel returns any memory consumed to the system pool whether the termination is normal or fatal.

Memory-leak control is particularly important for browsers that continuously allocate and free up memory for images and HTML (Hypertext Markup Language) pages. Unlike WinCE, QNX has implemented a shared memory buffer for images so that allocation/free sequences don't occur and fragment memory, thereby eliminating memory leakage.

Developing WinCE devices

Although it is a relatively new product, WinCE is already heavily backed by a variety of development support. Part of the reason for this early adoption is the familiarity of the Win32 API, which has made it easy for independent software vendors to make the transition from PC applications. Additionally, µP vendors relish the thought that this Microsoft OS supports much more than the usual x86 CPU. So, these vendors are eagerly funding development-tool support. Furthermore, many third-party tool companies are speculating that if Microsoft is successful with WinCE, the payoff will be big.

Besides the expected support in the form of applications for handheld PCs, WinCE support includes Microsoft's OAK, development boards, custom drivers, training, and product testing for WinCE-logo approval. Regarding the logo approval, before you purchase support products for your WinCE design, check to see that Microsoft has officially approved the product. If you have questions about approval, contact Microsoft or Veritest (www.microsoft.com/windows/thirdparty.htm or www.veritest.com/microsoft.htm). Veritest is a Microsoft-approved, independent testing laboratory.

If you're designing a WinCE platform, one of the components that you have to develop is the OAL. Unlike the more traditional Windows platform, a WinCE device doesn't need a BIOS. In the PC, the BIOS provides an abstraction of the hardware platform that predates the hardware-abstraction layer (HAL) of NT and the OAL of CE (Figure 1). The OAL contains some BIOS-like functions, such as booting the OS from the restart interrupt and initializing a µP's registers. But a WinCE system uses separate drivers to access the system's peripherals, such as the keyboard, screen, audio, and COM ports.

Microsoft's OAK includes sample source code for the OAL created for a handheld PC running Hitachi's SH-3 µP. You can also get sample OALs from each of the µP vendors that support WinCE. Alternatively, third-party companies, such as Eclipse International, will help you develop custom OALs for any platform that contains a WinCE-supported CPU.

Once you have written the code for the OAL or any other WinCE application, use Microsoft's cross-compilation package for Visual C++ running under NT 4.0 on an x86 system. As a matter of fact, you can do most of your WinCE software development on a Windows NT PC with the same interactive development environment (IDE) and programming model you use to develop all other Windows applications. With the Windows environment, you can generate the appropriate binary by pulling down a menu item, selecting the processor target, and clicking the compile button.

Besides the OAL source code, Microsoft's OAK contains WinCE object code, reference materials and source-code examples for creating platform-specific files that interact with the OAL, and tools for building a ROMable image. This image contains WinCE, the OAL, platform-specific files, and the user's applications. You get the OAK free when you sign up to purchase WinCE licenses. The cost of a license varies depending on where you purchase it; for example, Annasoft expects to sell each WinCE license for around $65 for quantities less than 20,000, but this price varies by distributor.

The cross-compiler for Visual C++ is available as a Windows CE add-on for $199; you must also purchase Micro-soft's Visual C++ 5.0. In the future, Microsoft will also provide Visual Basic and Visual J++ for WinCE. Microsoft's software developer's kit (SDK), available through the Web, includes an assembler, a debugger, a remote memory viewer (RMV), and other tools. The RMV lets you view information about the processes, threads, and dynamic-link libraries (DLLs) that are running on your WinCE device. Microsoft tool support includes an x86 emulator, which allows development and debugging on the desktop PC without target hardware. Microsoft also provides a device-driver kit (DDK) to help you debug device drivers.

Metrowerks Inc also provides compiler support for WinCE developers. Metrowerks is known for its CodeWarrior suite of software-development tools that run on WinNT, Win95, or Mac OS. The tools include C, C++, and Java cross-platform compilers for x86, MIPS, and PowerPC µPs. CodeWarrior for PowerPC embedded systems, scheduled for release this year, will cost $699.

Another useful product for WinCE development is from VenturCom. The company will provide Component Integrator (CI), a GUI-based configuration tool that runs on Windows NT and allows engineers to select WinCE components from the tool's database to include in an embedded configuration. The tool also checks dependencies among components and builds target configurations. VenturCom is also developing RTXs for Windows CE. RTXs provide a real-time API with 128 priority levels.

In a sense, Microsoft has been in the embedded business for many years, if you count ROM DOS, ROM Windows, and even WinNT. But WinCE brings a new challenge for the company. WinCE implies custom applications that revolve around this operating system. WinCE also implies big support issues, and Microsoft still has many details to iron out for third-party support. Microsoft also has strict quality control, and it doesn't want a bunch of junky WinCE systems ruining the image.

Even at this early stage, it seems likely that Windows CE will play an important role in embedded applications because increasing application complexity is shifting many application areas to 32 bits. WinCE will also be important because the embedded systems are shifting toward commercial operating systems. A recent study conducted by Embedded Systems Research (Corvallis, OR) concluded that within two years, the use of proprietary OSs will drop to only 26%, with the balance using commercial OSs. There is also a growing demand for a standard GUI in embedded applications, specifically with the Win32 API. Furthermore, to ensure the success of WinCE, Microsoft is building an infrastructure that includes technical distributors and system integrators, as well as partnerships with key embedded independent hardware vendors.

Acknowledgments

I'd like to thank the folks at QNX and Radisys for their helpful insight.

| EDN Access | Feedback | Table of Contents |