On Time RTOS-32 Versus Linux for Real-Time Embedded Systems

This paper discusses some of the issues that should be considered before an embedded or real-time software project is committed to Linux.

Linux Was Not Designed for Embedded and/or Real-Time Systems
This is probably the most fundamental difference between Linux and On Time RTOS-32. All embedded and/or real-time extensions or special distributions of Linux implement various work-arounds for problems rooted in Linux's desktop and server origin.
Real-Time Programming Model
Real-time extensions for Linux deploy a real-time scheduler beneath the Linux scheduler. The Linux kernel and all Linux processes run in the single idle task of the real-time scheduler. Thus, the real-time tasks do not actually run under Linux but rather under a different operating system. The Linux API is not available to real-time tasks. Instead, real-time tasks have to communicate through a FIFO buffer with Linux processes, e.g., to display data or to access disk files. Such communication is not real-time.
No Protection for Linux Real-Time Tasks
All real-time tasks under Linux run in ring 0 (CPL 0) and can therefore crash the real-time scheduler, the Linux kernel, other real-time tasks, or Linux processes. Under On Time RTOS-32, all threads are real-time and run in ring 3 by default. Program code and critical data structures such as the GDT, IDT, and the page table are protected through the CPU's MMU.
No Code Executed from ROM
Linux must copy a process image to RAM, even read-only data such as a program's code. On Time RTOS-32 can leave any read-only data in ROM (e.g., code, string data, etc.).
Boot Time
Linux requires a standard PC BIOS and it needs to load a lot of files from disk at boot time. Even with a very fast BIOS, typical boot times are at least 30 seconds to 1 minute. On Time RTOS-32 can boot in less than 1 second.
Resource Overhead
Linux is a large monolithic kernel and not self-scaling. Developers must manually exclude portions of the Linux kernel not desired on the embedded system. This is far from trivial because the potential dependencies of Linux components must be known and understood. A typical Linux kernel distribution consists of more than 10000 source files with several hundred MB of source code. Even with a lot of code (e.g. TCP/IP and GUI) removed, a minimal Linux system will need at least 4MB of RAM and about the same amount of ROM.
On Time RTOS-32 is automatically self-scaling. Components actually used by the embedded application are linked into the system or excluded if not used. No manual kernel configuration is required. A minimal On Time RTOS-32 system can run in 8k of RAM and 8k of ROM. A Linux based product will usually require more expensive hardware than the same product developed with On Time RTOS-32.
Development Tools
The preferred development tools are, to a large degree, a matter of taste. Both Linux and On Time RTOS-32 support high quality tools. Under Linux, Unix command line tools such as EMACS, vi, make, etc are most commonly used. Standard debuggers which debug Linux processes cannot be used to debug device drivers, interrupt handlers, or real-time tasks under real-time Linux. Instead, kernel mode debuggers have to be used as cross debuggers.
While Unix tools are also available for Win32 (and thus On Time RTOS-32), On Time RTOS-32 programs can also be developed with graphical environments such as Microsoft Visual Studio and various add-ons (e.g., version control, project management, etc.). High level debuggers can access all software including real-time tasks, device drivers, and interrupt handlers.
Learning Curve
Linux is a large and complex operating system. Using it for embedded systems requires a lot of know-how because the kernel must be fine-tuned and configured for an embedded application. For Real-time Linux, the API of the real-time scheduler must also be learned.
On Time RTOS-32 is small and very easy to use. Most users are able to start working productively within minutes by using one of the about 60 examples included and plugging in their own source code.
Technical Support
For Linux, support is a paid service. Obtaining support may be difficult, because every embedded Linux user needs to customize his Linux kernel, frequently making it impossible for support engineers to reproduce problems. Many problems can only be understood and resolved by hiring consultants working on site (typical cost: 2000-3000 USD per day).
On Time RTOS-32 users can receive support by phone or email from the operating system's developer teams located in the USA and Europe. In addition, On Time maintains a support mailing list with a typical turnaround time of 1 to 4 hours (less than 24 hours guaranteed). All of these support facilities are completely free and guaranteed to be available.
Business Model
On Time has been consistently producing increasing revenue and profit since 1989 and operates under a proven business model.
Most Linux vendors build their business model on a free product and paid support, while On Time charges for the product and offers free technical support. As a consequence, On Time is highly motivated to keep its software free of bugs, easy to use, and to supply good documentation with many examples to minimize its support load and cost.
For Linux vendors, such a strategy would lower the company's revenue and profit from support contracts.
Time to Market
Building the expertise to configure Linux, use the real-time extensions, use the standard Linux tools, and use the Linux kernel debugger can be very time-consuming. In particular, programmers who are familiar with Windows development tools will typically have a head start of several months by using On Time RTOS-32 rather than Linux.
Total Cost of Ownership
Even though Linux can be obtained at negligible cost, its total cost of ownership is usually significantly higher than for On Time RTOS-32. Additional costs for Linux are: technical support, hardware (more RAM/ROM, CPU speed), Linux training, engineering time to understand and configure Linux.

Here is an article posted to newsgroup comp.arch.embedded, which illustrates some of the points discussed above.

   From: Mike
   Newsgroups: comp.arch.embedded
   Subject: Tips for cross-development on Linux?

   I'm a total Linux (and any *ix) newbie who would like to explore using
   the GNU tools for cross-development.  To this end I have installed
   RedHat 7.0 on my machine (reasonable choice?), and purchased an
   O'Reilly book on GNU software development.  Currently I'm developing on
   Windows using various IDEs such as VC++ and the Keil tools.  My first
   impression is that I'm taking a tremendous backwards leap.  For
   example, I'm told that emacs is the best editor etc. ever made, but it
   looks like I have to remember and hand-enter the names of any file I
   want to open.  Apparently I have to go back to manually maintaining
   makefiles again as well.  Are *ix developers really still required to
   use 20-30 year old tools?  I'm spoiled, I admit it.  I haven't edited
   in text mode in about 10 years now.  I want all the conveniences I've
   got with my Windows IDEs.  So, am I still just too clueless to use
   these tools properly?  What *are* the best programming editors / IDEs
   available under Linux?  Should I bite the bullet and learn emacs, for
   all it's apparent strangeness and clumsiness?  All I want is the most
   painless way possible to write C, C++ and Ada software for various
   embedded platforms.  How much of this bad initial impression is just
   me, and how much is "real"?

   Mike