What is µC/OS-III?

µC/OS-III (pronounced “Micro C O S Three) is a scalable, ROMable, preemptive real-time kernel that manages an unlimited number of tasks. µC/OS-III is a third-generation kernel and offers all of the services expected from a modern real-time kernel, such as resource management, synchronization, inter-task communications, and more. However, µC/OS-III offers many unique features not found in other real-time kernels, such as the ability to complete performance measurements at run-time, to directly signal or send messages to tasks, and more.

Why a new µC/OS version?

The µC/OS series, first introduced in 1992, has undergone a number of changes over the years based on feedback from thousands of people using and deploying its evolving versions.

µC/OS-III is the sum of this feedback and experience. Rarely used µC/OS-II features were eliminated and newer, more efficient features and services, were added. Probably the most common request was to add round robin scheduling, which was not possible for µC/OS-II, but is now a feature of µC/OS-III.

µC/OS-III also provides additional features that better exploit the capabilities of today’s newer processors. Specifically, µC/OS-III was designed with 32-bit processors in mind, although it certainly works well with 16- and even several 8-bit processors.

µC/OS-III Goals

The main goal of µC/OS-III is to provide a best-in-class real-time kernel that literally shaves months of development time from an embedded-product schedule. Using a commercial real-time kernel such as µC/OS-III provides a solid foundation and framework to the design engineer dealing with the growing complexity of embedded designs.

Another goal for µC/OS-III, and therefore this documentation, is to explain inner workings of a commercial-grade kernel. This understanding will assist the reader in making logical design decisions and informed trade-offs between hardware and software that make sense.

Intended Audience

This documentation is written for embedded systems programmers, consultants, hobbyists and students interested in understanding the inner workings of a real-time kernel. µC/OS-III is not just a great learning platform, but also a commercial-grade software package ready to be part of a range of products.

To get the most from this documentation, it is assumed that the reader has a good working knowledge of microprocessors, microcontrollers, and/or Digital Signal Processors (DSPs). That knowledge should extend to CPU instructions, interrupts, I/O devices, RAM and ROM or Flash, memory addresses, and stack pointers.

It is also expected that the reader will have a good working knowledge of the C programming language and assembly language.

The µC/OS Story

The µC/OS story started when, in 1989, I joined Dynalco Controls in Fort Lauderdale, Florida, and began working on the design of a new microprocessor-based ignition control system for a large industrial reciprocating engine.

Given that I had experience using a kernel, I was convinced that an operating system would substantially benefit this project and other planned projects at Dynalco. Time to market was of paramount importance for this ignition control system, and I knew that a kernel would help meet scheduling requirement. I also knew that new features would be added to this product in the future, and a preemptive operating system would allow for such updates without negatively impacting system responsiveness.

The kernel that I initially considered was one that had served me well in the past. However, it carried a hefty price tag, and my budget was somewhat meager. The alternative was a kernel that I had not used before, but it was five-times cheaper than my original choice. Ultimately, I decided that the financial benefits of using the unfamiliar operating system outweighed the potential advantages that its higher-priced counterpart could offer.

I quickly realized, however, that I would pay for the seemingly cheaper operating system with my time. During the two months after receiving the kernel, I was in constant contact with technical support, trying fruitlessly to determine why even the simplest applications would not run. The operating system, said to be written in C, required me to initialize all of the kernel’s internal variables in assembly language, a task laden with problems. I eventually discovered that I was one of the first customers to purchase this operating system and was essentially an unknowing beta tester.

Frustrated with the software’s many shortcomings, I turned to the relatively expensive operating system that I originally rejected. It seems that if a project is late, money is no object. Within two days, I was running simple applications that the cheap operating system seemed unable to support. My kernel-related problems seemed to be over.

Before long, however, I would find myself at another impasse. My second set of problems began when one of my engineers reported that the new operating system seemed to contain a bug. I promptly relayed the engineer’s findings to the software vendor, assuming that the company would be interested. Instead of receiving assurance that the bug would be fixed, I was notified that the 90-day warranty expired. Unless I purchased a maintenance contract, the bug would not be eliminated, which was absurd to me. The software provider thought otherwise, and I forked over the maintenance fee.

Incredibly, the vendor took six months to actually remove the bug. All told, I completed my ignition system, incorporating the second operating system, a year after receiving the software. Clearly, I needed a better solution.

Twice disappointed, I began to develop my own kernel. In my naive opinion, all a kernel really did was to save and restore CPU registers; writing one should not be especially challenging.

The project kept me busy at night and on weekends, and proved to be much more difficult than anticipated. Approximately a year after I starting the project, my first operating system was complete.

With a new kernel in hand, there was finally a handy means of developing multitasking applications. The operating system, consisted of little more than a single C file and allowed up to 64 tasks to be created in a single application. Each task was required to be have a unique priority. The highest priority task that was ready to run when the operating system’s scheduler was invoked was given control of the CPU. µC/OS was preemptive, so scheduling could occur at practically any time.

Efficient task scheduling was actually one of many services offered by µC/OS. The operating system also facilitated inter-task communication (via message queues and mailboxes) and task synchronization (through semaphores). All elements of µC/OS were designed to be both highly dependable and easy to use.

Presumably, most kernel developers have similar goals in mind when they write new software. I was especially well equipped to meet these goals, in part because of my punctilious coding style. Throughout my career, I focused on consistency and documentation. I began using formal coding standards in 1984, and the consistency of the µC/OS code is a testimony to this process.

µC/OS was designed according to the stringent standards that I created and promulgated at Dynalco. The operating system’s source code featured liberal spacing, carefully worded comments, and consistent naming. Offering further evidence of the prudent coding techniques, the kernel was also highly portable. Although µC/OS, like its kernel peers, featured a small number of processor-specific functions, these routines were clearly separated from other portions of the operating system. Engineers could easily adapt µC/OS to new CPU architectures.

Unfortunately, I was the only one to know about the virtues of µC/OS. Eager to describe my new software to others, I wrote an in-depth paper explaining the inner workings of µC/OS. There was plenty to say, and my final paper was approximately 70 pages in length.

I offered my paper to C User’s Journal, and they rejected it on the grounds that it was too long and that its subject matter wasn’t fresh. The magazine had already published several kernel articles, and this was just one more. Convinced that my article was unique, I offered it to Embedded Systems Programming. The editor of this periodical likewise expressed misgivings, but I convinced him that µC/OS was attention-worthy. I explained that the operating system was comparable in quality to products that major embedded software companies offered (and better than at least two). I also explained that the source code for µC/OS could actually be placed on the publication’s bulletin board service (BBS).

Embedded Systems Programming published a trimmed-down version of the paper as a two-part series. Both issues generated strong responses. Engineers were grateful that the inner workings of a high-quality kernel were revealed, and they downloaded the µC/OS source code in droves. kernel vendors, on the other hand, were less than thrilled with the article. In fact, the vendor of the low cost kernel was especially upset claiming that I had copied his work. Imagine that I would base µC/OS on software that didn’t work!

There would soon be even more reason for the kernel vendors to be upset. Shortly after my article appeared in Embedded Systems Programming, R & D Publications, publisher of C User’s Journal contacted me, and they were interested in printing an entire µC/OS book.

Originally, the plan for the book simply involved printing all of the material that I had originally submitted to C User’s Journal. Had I taken that route, the resulting book would have been approximately 80 pages or so in length. To make the most of this opportunity, I prepared a comprehensive text. With the consent of R & D, I spent the next several months writing. In late 1992, my first book, aptly titled µC/OS, The Real-Time Kernel, was released. The book had 250 pages, and was available in paperback form.

Although initial sales of the book were somewhat disappointing, R & D advertised µC/OS, The Real-Time Kernel each month in C User’s Journal. At the same time, I was beginning to gain attention as a kernel expert. In the spring of 1993, I was invited to speak at the Embedded Systems Conference (ESC) in Atlanta, Georgia, where I described operating system fundamentals to a highly receptive audience of more than 70 embedded enthusiasts. Within a few years, I was an ESC fixture, delivering my kernel lectures to hundreds of engineers at each conference.

While my popularity as a speaker rose, interest in my book also picked up steam. After its slow start, µC/OS, The Real-Time Kernel, went on to sell more than 15,000 copies.

Thanks to the success of my book, the number of engineers using µC/OS increased substantially throughout the 1990s. Developers easily adapted the operating system to new hardware platforms, and were designing a myriad of µC/OS-based applications. Although several µC/OS users simply tinkered with the operating system in their spare time, many engineers used the software commercially in complex and demanding projects. Comments and suggestions from µC/OS users helped me to continue to refine and evolve the operating system.

For several years, only minor changes were made to µC/OS. However, when R & D asked me to write a second edition, I decided that a substantial update of both the operating system and the book was warranted. The updated operating system became µC/OS-II.

A quick glance at the µC/OS-II files revealed that this operating system was different from µC/OS. Whereas all of the processor-independent code incorporated by µC/OS was contained in a single C file, µC/OS-II spanned multiple files, each corresponding to one of the operating system’s services. µC/OS-II also offered many features that its predecessor lacked, including stack-checking capabilities, hook functions, and a safe means to dynamically allocate memory.

To fully describe all of the new operating system’s features, I nearly doubled the size of the book. Just as the latest version of the software received a new name, the new edition became MicroC/OS-II, The Real-Time Kernel. (“Micro” was used in place of “µ” because titles incorporating Greek letters posed problems for many book retailers.) Unlike my first text, the new book would be a hardcover.

MicroC/OS-II, The Real-Time Kernel was released in 1998. This new text was accompanied by the source code that it described and I would again have thousands of developers testing the kernel and providing valuable feedback.

Among the thousands of readers of my books using the software, there were many kernel rookies. For them, the book provided thorough and accessible coverage of operating system fundamentals. Many university professors recognized the book’s appeal to new kernel users and started designing entire courses around µC/OS-II. Soon college graduates whose kernel training focused on the operating system made their way into the workforce, where they continued to use µC/OS-II.

While students gravitated to µC/OS-II because of my book and readily available source code, a substantial number of engineers using µC/OS-II commercially selected the software for its reliability. Definitive proof of the operating system’s reliability was provided in July 2000, when DO-178B Level A certification was conferred on an avionics product incorporating µC/OS-II. This certification, recognized by the Federal Avionics Administration (FAA), is awarded to software deemed safe enough to be used in aircraft. To this day, there are few operating systems that have successfully completed the rigorous testing that certified software must undergo.

DO-178B certification is only one of µC/OS-II’s credentials. Additional certifications include Food and Drug Administration (FDA) pre-market notification (510(k)), pre-market approval (PMA) for medical devices, and IEC-61508 for industrial controls. Compliance with such standards is critical within industry segments; however, the certifications also have value for engineers in other industries as they evidence reliability, documentation, and time-to-market advantages beneficial to any design.

As the decade came to a close, I still worked full time at Dynalco, and experienced difficulty keeping up with the demand for the operating system. I felt obligated to respond to each µC/OS-II user that contacted me, and the flow of messages into my inbox was unrelenting. Since I could no longer treat the operating system as a side project, I made the decision to found my own software company. In September 1999, Micriµm, officially came into being. Micriµm comes from the word ‘Micro’ (for microprocessors or microcontrollers) and ‘ium’ (which means the Universe of) and thus, Micriµm means the Universe of Microprocessors (as seen through the eyes of software).

In the months before incorporating Micriµm, I began working on a second edition of the µC/OS-II book, which made its debut in November 1999 and was accompanied by a new version of the kernel. Two major features to the operating system were added: event flags and mutual exclusion semaphores. These new features, fully described in the book, were heartily welcomed by µC/OS-II users. The book itself was similarly embraced; the second edition of MicroC/OS-II, The Real-Time Kernel quickly became common sight on the bookshelves of embedded software developers. In fact, the MicroC/OS-II book is the most popular embedded systems book ever sold.

Micriµm expanded. Engineers were hired to adapt µC/OS-II to new hardware platforms and develop a bevy of example projects and application notes. A long-time friend of mine, Christian Legare joined Micriµm as Vice President in 2002, and his substantial corporate and technical expertise further accelerated the company’s rapid growth. Since Christian joined Micriµm, the company expanded from a one-product company to one with a portfolio of 15 products.

Meanwhile, new features were added to satisfy the ever-evolving needs of µC/OS-II users, including a variety of new API functions to the operating system and expanding the maximum number of tasks supported by the kernel from 64 to 255.

As Micriµm’s president, I remain dedicated to writing world-class kernel code, most recently µC/OS-III. The product of countless hours of meticulous programming and testing, this robust operating system has its roots in µC/OS-II, yet is an entirely new kernel. Addressing input received from customers and all of the lessons learned along the way, several additional important µC/OS-III features were included (see Introduction).

I am highly circumspect of fads and unproven technology as I write new software. Although I like to keep abreast of the latest developments in the high-tech world, the focus is on solving engineers’ problems and providing a solid and complete infrastructure, rather than on how to prematurely exploit emerging trends.

This philosophy has yielded considerable success. Micriµm, now in its 14th year, is a highly respected embedded software provider. Industry surveys consistently show the operating systems to be among the most popular in the embedded space. My goal has always been, and continues to be to provide effective solutions for the same types of problems that I confronted at Dynalco, and that millions of embedded systems developers continue to face today.

Acknowledgements

First and foremost, I’d like to thank my loving and caring wife Manon for her unconditional support, encouragement, understanding and patience. This project was again a huge undertaking, and I could not have done it without her.

I would also like to thank many fine people at Micriµm who have tested the code and reviewed the documentation. In alphabetic order:

Brian Nagel
Eric Shufro
Hong Soong
Freddy Torres

A special thanks to Frank Voorburg from Feaser and to Ian Hall and Robert Mongrain from Renesas for feedback and corrections to the text to Michael Barr for sharing his real life RTOS experiences, and to Carolyn Mathas for the incredible job of editing this huge project.

A very special thanks to my long-time friend, colleague and partner, Christian Legare, who has provided his advice and support throughout this project and on a day-to-day basis at Micrium. Thank you also to the dozens of people who provided feedback about the µC/OS-III code, as well as reviewers.

Finally, I listen to music when I write software, and artist Gino Vannelli’s awesome music has provided a creative environment for me for over three decades. I would be remiss if I did not acknowledge his contribution here as well.

Browser not supported