By the end of 1999, we plan to make the RTOS freely distributable to academic institutions to provide the following major benefits: (1) More students without in-depth real-time systems backgrounds, such as those studying controls, communications, and signal processing, will be able to more easily implement their theoretical algorithms. This will increase the availability of real-time applications for control and signal processing. (2) University researchers will have a solid base of free source code, similar to Linux and freeBSD, but for embedded processors, thus allowing more advanced RTOS technology to be investigated. (3) Component-based software design will become a reality for embedded system designers, just as object-oriented design has become the norm for desktop graphic applications.

The creation of a freely-distributable RTOS does not preclude the development of commercial RTOS with similar features. In particular, companies will still turn to commercial RTOS in order to get customer support and service and upgrade guarantees. The university RTOS, however, can fuel advances in these commercial RTOS, thus accelerating their rate of improvement, which has been at a turtle-pace for the past ten years. Companies interested in licensing this technology can contact UMD's Office of Technology Liaison.

The features discussed are part of a plan which we have not yet fully implemented.

While there exist many commercial real-time operating systems (RTOS), most have been targeted towards the recent generation of general-purpose processors, such as SPARC, MIPS, and 486 and Pentium families. There are few satisfactory operating systems for microcontrollers and DSPs. Those that do exist, such as SPOX and Nucleus, have huge license costs, preventing their widespread use in academia and by small companies. Furthermore, these RTOS only provide minimal system functionality. Few modern innovations in real-time systems and software engineering are supported. This includes threads, component-based design, advanced interprocess communication, automated analysis, error detection and handling, and visual programming.

In this project, we are creating an RTOS, called Echidna, to support reconfigurable component-based software for these embedded processors. The RTOS is being designed to reduce development time by improving tools and maximizing portability of modules across both applications and target platforms, while maintaining the high-performance and predictability required in a real-time system. Memory usage will also be minimized as memory bandwidth is limited. We have begun developing a version for microcontrollers such as the Z180, MC6812, and 8086 processors, as part of a project sponsored by Pulse Electronics. Since advanced DSP features not found in microcontrollers are generally only used by the application, and not by an operating system, many of the optimization and analysis techniques used for the microcontroller implementation can be used to create a low-memory footprint, high-performance RTOS for DSPs.

Threads are modeled as port-based objects, as originally developed by the PI of this project and implemented in Carnegie Mellon University's Chimera RTOS. Chimera is designed to support dynamically reconfigurable and reusable software components in a shared-memory multiprocessor environment. Chimera's template-based software paradigm allows engineers to develop application code without regards to the underlying integration, synchronization, and communication issues. Furthermore, it allows for visual assembly of applications from library components, thus quickly allowing an engineer to customize an application.

Echidna uses a similar application-programmer interface (API) and development environment as Chimera. To address the operating system overhead issues that are of great concern in microcontrollers and DSPs, the shared-memory multiprocessing capabilities are exchanged for high-performance single-processor algorithms with low memory usage that are more suitable for embedded systems.

There exists over a hundred commercial RTOS, most costing several thousands of dollars. Currently, however, very few educational courses and research labs use these RTOS in their work, primarily due to the huge costs. Top universities that have acquired licenses usually have a very limited number of them in their research labs, such that the RTOS is available to only a small percentage of the students. Consequently, students graduating from university are not properly skilled in software development using an RTOS.

The quality of commercial RTOS is also a major concern. The most advanced features in many of today's RTOS are not much different than the features of RTOS over ten years ago! On the other hand, in the general- purpose processing domain and in the same time frame, UNIX progressed to have built-in X-windows support, and personal computer operating systems went from MS-DOS 1.0 to Windows `98. Much of the progress was a result of the widespread availability of such systems in academia. Research into these systems also improved dramatically, to include support for networking and the web. Much of this can be attributed to the availability of free versions of the operating systems, in particular Linux, freeBSD, and X-windows, so that university researchers have a solid base of software to use as a stepping stone for advanced research.

There is little ongoing academic research into RTOS technology for embedded processors. Universities studying real-time systems have focused on more theoretical aspects, like scheduling, synchronization, and quality of service. Only a few commercial software developers have been investigating RTOS for embedded processors. However, these developers are typically constrained by deadlines and immediate customer needs, rather than the more basic research and experimentation of a complete design space that is typical in a university research setting.

Microkernel. The core of the microkernel is the minimum code required to run the RTOS. It provides for CPU-specific initialization, timer control, basic error detection and handling functions, and task management. Key research challenges are to adapt to DSPs the fast scheduling and switching between processes in a limited memory environment that we developed for microcontrollers.

For maximum performance on the embedded processors, support for the port-based object model [1] will be built into the microkernel core. In contrast, the Chimera implementation, on which Echidna is based, uses a more traditional POSIX-like notion of a thread in the microkernel, and builds the reconfigurable software support as a layer above the core. As discussed in [5], the port-based object model of a thread is much preferred over POSIX-style threads to support reconfigurable software in a real-time environment.

Echidna will support several extended microkernel features that can be configured by the application programmer. Specifically, these include timing and global error detection and handling, embedded task profiling, memory management, and use of non-volatile memory for dynamic configuration management.

Interprocess Communication. The primary interprocess communication (IPC) to support data transfer between port-based objects is the global state variable table mechanism (SVAR). During this first year, this will be the only mechanism implemented, as the other mechanisms are non-essential. The embedded version of SVAR can support both low volume data, as used in control systems, and high volume data, as used in communication systems. However, we have not yet tested the effects of managing large amounts of data using an SVAR mechanism, and we expect some DSP-specific modifications to be made.

In the second year, the desirable but non-essential IPC mechanisms will be developed, including alternate forms of global shared memory, typed messages, semaphores, streams, and pipelines. The IPC mechanisms will be provided a libraries that are linked only on an as-needed basis.

The key challenge for IPCs is to create a set of mechanisms that are easy to use by communication and control system engineers. Most UNIX-based and commercial RTOS IPC mechanisms are so complex that even many computer engineers avoid their use!

Device Interfacing. Input/output (I/O) devices are an integral part of any embedded system. Device drivers will be provided for serial, parallel, analog-to-digital (A/D) and digital-to-analog (D/A) devices on the TI boards that we use to test the first prototype. Drivers for RAMdisks and ROMdisks are being created, which will allow application developers to download data to and from the embedded system, and to access that data as a file, but with deterministic access times.

A device driver framework as we describe in [2] will be provided so that other users can quickly create their own drivers, and integrate them into the RTOS. With this framework, driver creation will be a straightforward step, rather than the complex and scary procedure as it is now. A key challenge is to create an implementation of the device driver framework that is of sufficiently low overhead that software designers have little or no motivation to bypass the drivers. Although device drivers aid in reducing software development and maintenance time, they have traditionally been slow and bulky, thus significantly hampering performance.

Development Environment. The primary development environment for the TMS320 version of Echidna will be the software tools supplied by Texas Instruments. As part of Echidna, however, we will provide extensions to the environment, to make it easy to use the RTOS and its libraries, to support visual programming and analysis methods, and to interface to unique features like the embedded task profiling.

Beginning in the second year of the project, we will develop automated analysis tools to aid in fine-tuning and debugging the temporal aspects of real-time programs. In this past year, we developed a first prototype of such a tool for the VRTX RTOS running on an Intel 486 platform. The analysis that is incorporated into the tool, however, needs to be specific for both the computer architecture and the operating system. The effectiveness of the tool is largely dependent on how well we can model the operating system's usage of the processor. A key research challenge is to develop an accurate model, and when necessary, instrumentize the operating system so that it can be more analyzable, while not affecting the run-time performance of the code.

In the third year of the project, we propose to develop a visual programming and configuration environment for Echidna. Our prior work developing Onika for Chimera [4] proved the feasibility of such an environment. As an alternative to creating the environment from scratch, we will investigate tailoring existing visual programming or unified modeling tools for use with Echidna.

Advanced Features. Part of the research in the third year will focus on advanced features specifically for microcontrollers and DSPs that we are not yet familiar with. In particular, as we gain more users, we will ask them for opinions and closely observe the way they are using the RTOS. We will identify areas in which RTOS features can help reduce their development time or improve the functionality and performance provided to them. It was this type of observation that led to many of the advanced features in Chimera. By the end of the second year, we will write a technical report that summarizes these observations and user discussions, and we will include a detailed list of advanced features that will be investigated and implemented in the third year of the project.