A few days ago I posted an article from Cots Journal Online which discussed some of the shortcomings of Linux use in embedded systems. Based on some of the comments posted back to the blog it would appear that Linux is used because of the community which surrounds it rather than for the technical merits of the operating system and tools – for someone that’s lived in the embedded space before working at Microsoft I find this somewhat surprising – I based my choice of processor, components, and (if needed) operating system on the technical merits of the operating system and tools.
Let me ask this question If you are starting an embedded system development project next month and you’ve been asked by your manager to select the appropriate processor, reference board, and operating system – do you choose Linux because it’s considered to be hip/trendy or do you make the decision based on the technical merits of the processor, silicon vendor, system integrators, reference hardware, and operating system technologies and tools ? – do you consider using non-Linux operating systems in any of your embedded designs, and if so, why (and why not).
ok, so let’s examine the COTS Journal Online article and walk through each of the items and see how Windows Embedded operating systems stack up – I mentioned in a comment to the original post that I don’t want this to turn into a “Linx is better than Windows is better than Linux” discussion, no throwing of mud or Fud – let’s try to stick to the facts and consider both operating systems for their technical merits, after all, that’s what really matters, right ?
<snip>By definition, a real-time system is one in which an event (for example, an interrupt from an important peri-pheral device) must be handled within a bounded (and typically short) amount of time; failure to respond causes a failure in the embedded system. Many embedded systems have real-time requirements; desktop systems do not. Along with context switch time, interrupt latency is the most often analyzed and benchmarked measurement for embedded real-time systems. Operating system architecture is the most significant factor for determining interrupt latency and thread response times in an embedded system. </snip>
Microsoft has two embedded operating systems (three if you also count SPOT), Windows CE and Windows XP Embedded.
Windows XP Embedded is not a real-time operating system, this is a desktop operating system which has been componentized (approx 12,000 components, 9,000 of which are drivers, 3,000 are operating system components), although Windows XP Embedded is not a real-time operating system it’s possible to add real-time response from 3rd party real-time extensions from companies such as Venturcom and Tenasys – check out the Interrupt Latency technical paper on the Tenasys web site (needs registration), Interrupt latencies were consistently measured as being < 20uS on a Pentium 133MHz with 32MB Ram.
Why would someone consider using Windows XP Embedded with a real-time extension ? – surely it makes sense to choose a real-time operating system from the get-go, right? – Windows XP Embedded runs on the x86 processor and contains all the same operating system technologies as the Windows XP Professional operating system, this means that you can quickly configure and build an operating system that supports a wide range of hardware components, ranging from USB2.0/1394 external hard drives, USB WebCam’s, high-end video cards, TV recording cards – and also has embedded enabling features for booting from the network, from flash, CD-Rom, headless, and other interesting features – there’s a ton of existing programs and drivers that work with Windows 2000 or Windows XP, these can be used without any changes on Windows XP Embedded – so you get the best of both worlds, broad hardware support, quick and easy operating system configuration, and support for Hard-Real-Time extensions.
ok, so what about Windows CE ? – Windows CE is a hard-real-time operating system out of the box (originally the operating system was considered to be soft-real-time, but we made changes to the kernel for the Windows CE 3.0 release which made the operating system hard-real-time – let me know if you would like a discussion about the changes and I will follow up in another blog post). What do we mean by “hard-real-time”, take a look at the definition of Hard-Real-Time from Nat Framptons realtimeonline site, let’s examine some of the 3rd party tests of Windows CE.
The following Windows CE tutorial may also be of interest to better understand the operating system and interrupt architectures.
Microsoft Windows CE Operating System and Memory Architecture
Watch this video to get an in-depth look at the internal workings of the Windows CE operating system. This tutorial covers operating system architecture and memory management of Windows CE. (51:03 minutes)
100K Version | 300K Version
There are also some resources that may assist with your understanding of Windows CE real-time behavior.
- Windowsfordevices – Chris Tacke & Lawrence Ricci – this article shows interrupt responses of a fully loaded system maxing out at 7uS
- Dedicated Systems Reports – There are two reports covering Windows CE on an ARM processor, and Windows CE on an x86 processor. On the ARM based reference board 1MM interrupts generated at 25uS frequency resulted in no lost interrupts.
- Maarten Struys and Michel Verhagen – .NET Compact Framework and Real-Time
- Windows Embedded Real-Time page
<Snip>Linux has no such provision for prioritizing threads relative to interrupts; however, the actual situation is worse. Real-time operating systems provide priority-based scheduling because it must be possible to guarantee that the most critical threads in the system can run immediately in response to an event. It is forbidden to use heuristics or any other constructs in the kernel that might make this response nondeterministic.</Snip>
Windows CE supports 256 levels of thread priority, all threads in the system are created by default at thread priority 251, this can be adjusted in two ways, first through a call to CESetThreadPriority (which changes the thread priority), and CESetThreadQuantum (which changes the amount of time a thread gets when it’s scheduled by the kernel). we can clearly see from the real-time discussion above that Windows CE 5.0 response times for hardware interrupts are within the bounds required by real-time systems.
<Snip>Device driver code adds less risk to the system if it runs in its own protected address space. An operating system architecture designed to facilitate virtual device drivers is preferred over the traditional method of requiring device drivers to run in physical memory along with the kernel.</Snip>
Windows CE device drivers run in the context of the device driver manager (Device.exe), interrupt handling is divided into two sections, the ISR (Interrupt Service Routine) which runs in the kernel space, and the IST (Interrupt Service Thread) which runs in the context of the device driver manager (or as a thread within a process), the ISR has limited functionality, this has access to physical hardware and memory but doesn’t have the ability to make operating system calls – the ISR passes off to the Kernel, which in turn wakes up the appropriate IST thread (through a call to SetEvent on a registered event handle) – the IST is special cased in that it can only make a call to WaitForSingleObject – a call to WaitForMultipleObjects would of course break the determinism of the operating system – at the IST level (since this is running in user mode) the IST has full access to operating system API’s (for example a Touch Screen Driver could call mouse_event to synthesize mouse motion and button clicks).
Perceived to be Free
<Snip>The hidden “royalty” due to Linux’s large footprint is just one example of the misconception that Linux is “free”. MontaVista, purveyors of the “Hard Hat” flavor of Linux, charges $15,000 per developer per year to support its version of Linux.</.Snip>
Windows CE and Windows XP Embedded evaluation tools are free to download from the WindowsEmbeddedKit website – the evaluation tools run for 120 days, after which you will need to use the full version of the operating system development tools which costs $995 – Licensing of the operating system doesn’t kick in until you ship a final version of your device, this means that you can configure, build, debug, and ship embedded operating system images to your customers to evaluate and test without needing to license the operating system – it’s only when you ship your final product that you need to license the operating system – for hobbyists or home tinkerers this is not an issue, you can build and deploy operating systems for your own use without needing to license the operating system (of course if you’re planning on selling the devices then you do need to license the O/S) – How much is a license ? – Check out the “How to Buy” page on MSDN/Embedded.
As far as support is concerned there are various levels of support ranging from free support (newsgroups, online chats, free incidents with the development tools), partner support – there are over 2,500 partners registered on the Windows Embedded Partners site which can assist with hardware development, software application development, BSP (Board Support Package) development, training, real-time on Windows XP Embedded, and so on – There’s also paid support through Microsoft Product Support – for a complete listing of support options, go here.
Long Term Support
<Snip>Most embedded products have a shelf life of several years. An aircraft avionics system may be in development for as long as a decade before it is fielded, and then it might remain in service for much longer than that. Even the life of a handheld PDA may span multiple years from the start of development until obsolescence.
Embedded systems developers put a high value on a vendor that has a stable, successful, proven business model, because they must rely on that vendor to support their electronic products for such an extended period of time and to be around for the next generation of product development as well.</Snip>
Microsoft Embedded operating systems are supported for 7 years after the release date of the operating system – It’s generally realized that Embedded Products and Desktop Products are not the same thing, in the desktop world consumers are (perhaps) expected to update to the latest and greatest version of product “x”, some embedded devices are shipping and running for 15+ years without having an operating system update – of course this varies depending on the type of device you’re building, in the consumer electronics space device updates occur on a far more regular basis than deeply embedded, real-time, robotics and/or telecoms test kit. For a listing of Microsoft’s support program for embedded systems take a look at the Embedded Operating Systems Lifecycle page.
<Snip>Linux is licensed under the GNU Public License (GPL), which governs how companies may incorporate the licensed software into the products that they sell to their customers. Much has been written about the pitfalls of incorporating GPL software into a product. An often overlooked consideration, however, are the costs of having to even worry about these licensing issues. The obvious concern is whether a proprietary product will be subject to the GPL because of its use of a GPL product. </Snip>
I don’t think there’s any need to talk to this point, suffice to say that Windows CE is not licensed under the GPL, we do ship 2.5 Million lines of “Shared Source” with the Windows CE 5.0 product, this is available for OEM’s to use to get a better understanding of the operating system, assist with debugging and bringing up the operating system on new hardware – any IP that you add to a Windows CE platform continues to be your IP, there’s no nead for you to share this with anyone.
The original article from Cots Journal Online made a number of statements about Linux in embedded systems, I’ve tried to list out how Windows CE compares against each of these items – I would be interested in your view on the Linux article, are the statements correct about the real-time behavior of Linux, Driver model, support, perceived cost etc