Print this article

Comment

1 July 2005

One size fits all

Real-time operating system and Windows can work together.

By Gerd Lammers

The idea of running a desktop operating system, such as Windows, concurrently with a real-time operating system (RTOS) on a single CPU can be a very attractive proposition. It eliminates the need for a second CPU while still providing the Windows interface for the RTOS.

That arrangement lets the user monitor and interact with the real-time processes via a familiar interface. In addition, a desktop Windows environment provides a vast array of tools for data logging, analysis, storage, and networking and provides a straightforward link between the factory floor and the executive suite, with stops along the way at marketing, sales, inventory, and all other aspects of the enterprise.

Naturally, there must be no compromise of the real-time performance and stability of the RTOS environment. The desktop Windows environment cannot affect the RTOS. The occasional application crash or operating system exception, while annoying, is seldom an actual disaster in the office environment. That, however, is not true in a world that is trying to manage moving robot arms, high-temperature processes, and critical sensors. Any failure there could endanger human safety or cause important data to be lost.

Add to these considerations the need to keep system complexity, size, and cost to a minimum, and you face the requirement of essentially running Windows and an RTOS on the same CPU. Running them on separate processors introduces unacceptable overhead for communication as well as added hardware costs. There is a way to run both OSs on the same CPU while completely isolating them from each other, allowing non-disruptive communication between the two, and not compromising the system monitoring real-time performance. You can do this without modifying the source code of either operating system.

The solutions lie in application of drivers, low-level configuration code for interrupts, and context switching, virtual networking, and strict memory protection. It is necessary to ensure the two operating systems run in separate memory spaces with no possibility that either one can write into the space of the other. This starts by first configuring Windows XP's awareness of its memory resources, and then adding the RTOS image and code extensions needed for dual operation.

Separate memory

The memory separation occurs by modifying the setup of XP's boot initialization. If the system has 512 Mbytes of physical memory, you can configure XP so it is only aware of 412 Mbytes. On subsequent boots it will not even be aware that the other 100 Mbytes exist. It is into this space, you can load the operating system image of the RTOS.

You can create the RTOS image with the standard tools available. For Windows CE, it would be Platform Builder and if you operate VxWorks, the RTOS image would come together in the Tornado environment. This includes all the components, drivers and board support appropriate to the application, plus several elements such as virtual networking needed to run in the dual OS arrangement. On the XP side, certain custom drivers and low-level extension code install at boot-up. This extension code looks like a driver to Windows XP but allows low-level configuration and monitoring of interrupts.

A special uploader, running as a Win32 application under XP, loads the RTOS image from disk into the fixed memory area, boots the RTOS, and then terminates. At this point, both operating systems load into memory, and the RTOS is in a fixed space separated by the memory management unit (MMU) and totally protected and stable. Windows XP is completely unaware of its existence. The next requirements are for the two OSs to be able to communicate and for the RTOS to be able to respond to priority real-time interrupts with no interference or overhead from XP.

Running on a single x86 CPU, Windows XP embedded and a commercial RTOS occupy separate and protected memory address spaces and communicate through shared memory via networking protocols. Real-time applications run separately, at a higher priority.

A virtual network

Communications occur when you set up an area of shared memory in the fixed and protected RTOS space. However, due to protection, the system will not permit direct reads and writes to this shared memory. Rather, the two OSs communicate over a virtual network via TCP/IP. Each OS has its own TCP/IP stack dedicated to this virtual network. Windows XP runs the standard Microsoft NDIS network driver.

This gives the RTOS and XP the ability to notify each other of events that take place on their respective sides as if they were communicating over a network. For example, XP might signal the RTOS that some user input had occurred that requires action on the part of the RTOS. On occasion, XP might signal the RTOS that it has crashed.

Thanks to the strict separation of the memory domains, a "blue screen" on the XP side will generate an event to the RTOS side via a shared memory signal notifying it of the crash. The RTOS will receive this event like any other. Otherwise it will be completely unaffected by the XP crash. At that point, the application developer is free to create the most appropriate strategy.

Such a strategy might dictate the RTOS move all the machinery, such as robot arms, into safe positions and perform an orderly shutdown of operations so you can reboot the system. In another scenario, one that requires little or no user interaction, for example, the system might continue to operate until the end of a shift or some other convenient point where someone can perform maintenance. That strategy is a part of the RTOS's application and becomes triggered by the crash event notification from XP.

In addition to the virtual network over which the two OSs communicate, each can also connect to other networks. You could connect XP to the enterprise network or to the Internet, while the RTOS could connect to a field bus such as Profibus or CAN. The only restriction is they cannot share the same network interface card (NIC). Each OS gets its own network interfaces, which protect themselves from each other. The same holds true for memory domains.

Often it is also necessary for the needs of the enterprise to gather data from real-time operations for analysis or use by the other operating system. A large block of data generated by the real-time processes, such as a graphics frame, might be tedious to transfer via TCP/IP. Therefore, it is possible to allocate an additional area of memory separated from the RTOS and Windows. Either OS is able to read from and write to the shared memory via pointers. This memory can be arbitrarily large in size according to the judgment of the developer.

Thus, the RTOS can deposit data as it generates and Windows XP can retrieve it and store it to disk for later use by desktop tools such as Excel or more specialized data analysis applications. That data then becomes available to the enterprise.

In this dual-OS scenario, Windows XP and the RTOS execute on a single x86 CPU. However, they are completely separate and unaware of each other. That means because of this strict separation, unlike some other approaches, Windows XP is not the lowest priority task of the RTOS. Thus, Windows does not run under the RTOS, and the RTOS does not run under Windows.

XP only runs when all RTOS tasks are idle. Any real-time interrupt that occurs while XP is running will invoke the RTOS, and all real-time tasks will execute before any XP task. All interrupts enabled for the RTOS have a higher priority than anything in Windows XP including Windows interrupts. In order to achieve this, a certain amount of real-time extension code undergoes implementation at the hardware abstraction layer (HAL). This code loads when XP boots up.

Two roles

The real-time extension code has two major responsibilities. First, it monitors all interrupts before either OS to determine if it is for XP or for the RTOS. Second, it permits the developer configuring the system to alter the interrupt tables. If XP is running and a real-time interrupt occurs, this extension code performs a context switch to run the RTOS and immediately sends the interrupt to the RTOS. While there is some slight overhead associated with this initial context switch (approximately five microseconds on an 800 MHz Pentium), all real-time interrupt service routines after that handle exactly as they would be if the RTOS were running standalone.

When Windows XP boots, it does so as it would do normally—it detects all the hardware and installs. After uploading the RTOS image, the developer can go in by means of the real-time extension code and reassign slots and interrupt lines to the RTOS. For instance, to assign a PCI card to a real-time interrupt, XP loses the card, and it gets reassigned. At the same time, it installs a dummy driver to "keep XP happy" even though it no longer has access to that card because the RTOS now owns it.

Interrupts for both operating systems occur as usual by the programmable interrupt controller. However, the extension code monitors the interrupts and decides which are for XP and which are for the RTOS. It is not itself an RTOS, but more like a driver that loads upon Windows XP installation. When any real-time task is running and a Windows interrupt occurs, it is queued according to priority until the last real-time task has completed and the RTOS is idle. At that point, another context switch lets XP start running.

This technique represents a software solution for running Windows XP Embedded along with a commercial real-time operating system on a single x86 CPU. Any additional coding does not involve modification of the code of either operating system. In the case of the RTOS, additional code incorporates as operating system library components or drivers at the time you build the RTOS image, or as parts of the real-time application. In the case of XP, code is included as drivers that boot with the OS and provide the ability to configure lower-level code at the hardware abstraction layer. The result is a real-time system that runs without compromise and also connects to all the networking and management needs of the enterprise without the cost and overhead of additional hardware.

Setting up the dual operating system scheme involves first booting Windows XP and defining a separate, protected memory domain for the RTOS. The previously configured RTOS image, in this case Windows CE, then loads from disk into the protected memory area, and a "shared" area is set up for communication via a virtual network and TCP/IP.

This state diagram shows how the RTOS is invoked when a real-time interrupt occurs. As long as any RTOS task is active, control of the CPU remains with the RTOS. Only when all real-time tasks have completed does Windows run again.

Behind the Byline

Gerd Lammers is director of worldwide sales and marketing for real-time products at KUKA Controls GmbH in Weingarten, Germany, a hardware and software developer. Lammers completed his degree in Electrical Engineering at the University of Applied Science, Ravensburg-Weingarten, Germany.