How Embedded Applications using an RTOS can stay within On-chip Memory Limits

The major requirement from manufacturers designing embedded systems for high-volume products is to keep production costs as low as possible. The most costeffective solution is to use small single chip microcontrollers / DSPs. Developers of software for resource constrained systems are increasingly in a difficult position: they have to write complex programs that must fit into very low cost microcontrollers and yet endproduct quality must not suffer. This leads to a desire to use a real-time operating system (RTOS), yet remain within on-chip memory limits (typically 512bytes to 4K RAM). This is not possible with many conventional RTOS, which allocate a separate stack for each task. We ask the question "why don't they use a single stack?" and explain the key elements of an execution model required for single stack operation. The novel concept of non-preemption groups is introduced and shown to enable significant reductions in stack size. An effective priority allocation algorithm is essential to realize the advantages of non-preemption groups. The results of applying such an algorithm show that the number of preemption levels required to maintain schedulability is strongly correlated with the spread of deadlines and for typical systems is relatively small. We conclude that a priority allocation algorithm combined with the non-preemption group mechanism reduces stack requirements by a significant factor. This enables efficient operation using an RTOS, whilst remaining within on-chip memory limits. Stack requirements are similar to those for a cyclic executive. INTRODUCTION The major requirement from manufacturers designing embedded systems for high volume products is to keep production costs as low as possible. The most cost effective solution is to use small single chip microcontrollers or DSPs with the program executing out of onchip ROM and using only the very limited amounts of on-chip RAM. This is borne out by the market for microcontrollers: in 1998, 2.5 billion 8-bit microcontrollers were sold, compared to only 63.7 Million 32-bit microcontrollers. The average selling price of an 8-bit device was $2.23 compared to $8.97 for faster 32-bit devices. Adding external RAM leads to significant increases in cost. Even internal RAM is transistor hungry and expensive (8-16 times as costly as ROM). Typically, a number of microcontroller variants are produced with only those on-chip peripherals specifically required and with varying amounts of on-chip RAM. For example 256, 512, 768 or 1024 bytes of RAM on an 8-bit device (or up to a few Kbytes on an expensive 32-bit device). The functionality and complexity of embedded software is constantly increasing in response to "more for less" demands by end customers. The challenge for manufacturers is to squeeze new functionality into the lowest cost hardware possible, without cutting corners on reliability and hence product quality. The conventional way to build embedded software in resource constrained systems is to write a monolithic program where the logical software functions are broken into small pieces. These pieces are then run in a 'round robin' sequence. Building the sequence and writing the code for the functions turns out to be difficult to do when the number of functions becomes large and they become complex. It also starts to be difficult to make changes to the system, so incorporating new enhancements is time consuming and risky. As well as being difficult to write, the software ends up using the available processor time inefficiently, requiring a faster and more expensive microcontroller. [1]. Developers of software for resource constrained systems are increasingly in a difficult position: they have to write complex programs without impacting endproduct quality. This leads to a need to use a real-time operating system (RTOS), yet the application must fit into very low cost microcontrollers.