With µC/OS, a world-renowned embedded real-time operating system (RTOS), hitting its 25th anniversary this year, it’s an ideal time to examine the kernel and address some of the many myths that have proliferated in the embedded market over the years.
1. The µC/OS kernels were community-developed.
Absolutely not. I wrote 100% of the code as well as a series of books describing the internals of the µC/OS kernels: µC/OS (1992), µC/OS-II (1998), and µC/OS-III (2008). The only help I got as an author was editing, but that’s typical for most authors. I did receive a lot of feedback from embedded developers, and of course evolved the code to satisfy some of those requests. But for the past couple of years, Micrium’s developers have been maintaining the code following the strict coding guidelines I established for Micrium.
That being said, I’m always keen on hearing from customers about their needs. Ultimately, for this reason, the µC/OS kernels are reflections of their users’ requirements. In this way, I feel we offer the “best of both worlds.” The kernels benefit from feedback and contributions submitted by users and the community, but they’re professionally developed and managed by a commercial entity.
2. The µC/OS kernel was based on other kernels.
µC/OS was inspired by Ready System’s VRTX kernel, but only as a guide to know what functionality was necessary at the time. µC/OS was a clean-room design, written in C and designed from the get-go to be highly portable. It turns out that other kernels have been inspired by the µC/OS kernels. Case in point: FreeRTOS recently added a few features that were previously unique to µC/OS-III: task semaphores, task message queues, and static allocation of kernel objects. However, task stacks can be allocated anywhere, whether statically or dynamically, on the heap.
3. µC/OS is a real-time kernel, not an RTOS.
When I designed µC/OS, a real-time kernel meant the same thing as an RTOS. In 1992, every RTOS was really just a kernel. I probably should have called it µC/RTK, but I thought it was more of an operating system for microcontrollers (MCUs), since at the time (1992), operating systems were much simpler than they are now. The definition of an RTOS is debatable these days. For example, FreeRTOS is really just a kernel (like µC/OS), yet a decade or so after the introduction of µC/OS, Richard Barry (the author of FreeRTOS) used RTOS prominently in the name of his kernel.
4. µC/OS is limited to 64 tasks.
Actually, that’s true for the original µC/OS, which was introduced in 1992. The reason for the limitation is that µC/OS targeted small MCUs (typically 8-bit machines). I decided that each task would be assigned a unique priority that was represented by a bit (set or clear) in a bitmap (8×8 matrix of bits). I used a very efficient algorithm (to set or clear a bit) so that execution time was both constant and deterministic, a highly desirable feature for a real-time kernel.
We introduced µC/OS-II in 1998, also with the bitmap approach. However, it was configurable to either an 8×8 or 16×16 bitmap, thus enabling up to 256 different tasks and, as a result, priorities.
We then introduced µC/OS-III in 2008, and removed the limitation that each task needed to have its own priority level. In other words, you could have any number of tasks of the same priority. This enabled priority inheritance for mutexes as well as support for round-robin scheduling. We kept the scheduling bitmap, but the order of the table reversed. Therefore, we could speed up the scheduling process using the count-leading-zeros (CLZ) instruction found on the ARM Cortex-M processor and other architectures. In fact, if you only need 32 priority levels, then the scheduling algorithm is reduced to the CLZ instruction, which can be performed in-line through a single assembly language instruction.
In 2017, we introduced Micrium OS (a full-featured embedded operating system), which contains the µC/OS 5 kernel. We skipped µC/OS-IV because Micrium OS contains middleware (i.e., a file system, a GUI, and stacks) derived from Micrium’s highly popular µC/ products. Some of these modules were already labeled as version 5 so we didn’t want to go backward in revision number for those modules that were already V5. µC/OS 5 is based heavily on µC/OS-III, with a few enhancements for consistency with other Micrium OS modules.
5. An RTOS requires a memory management unit (MMU).
Customers often tell us that they’re under the impression that RTOSs require hardware memory management. The reality is that they don’t, and µC/OS is no exception. Although MMUs are more common than they once were, they have never been required when using an RTOS.
6. The µC/OS-xx kernels are free and just for hobbyists, not professionals.
The µC/OS kernels were designed for professional use and have been used in thousands of products and systems around the world, including NASA’s Mars Curiosity Rover. Both µC/OS-II and µC/OS-III are certifiable for safety-critical applications. µC/OS 5 is based on µC/OS-III, but hasn’t yet undergone the certification process. The following table summarizes certification status.
If you use the kernel in a commercial product where you intend to profit, then we expect you to pay a license fee to use the kernel. That said, the µC/OS kernels are free for noncommercial use, and in fact are downloadable in full source form. If you are not intending to make money using the µC/OS kernel, then you should not be charged for it. Generally, students, educators, hobbyists and makers can download and use the kernels for free.
7. The µC/OS-III books are user guides.
The books are far more than just user guides. They were written to be both highly educational and pragmatic. Of course, the quality and content have evolved over the years (from the µC/OS book to the µC/OS-III book). The latest books (µC/OS-III) were designed as four parts:
1. The first two-thirds of the book explains what a kernel is, how to use one, and how a kernel works using µC/OS-III as the implementation example.
2. The latter one-third of the book provides examples of how to use µC/OS-III with an actual MCU and tools.
3. Each book is targeted at a specific evaluation board so that you can actually test the examples.
4. Finally, each book includes access to a free toolchain (compiler, assembler, linker/locator, and debugger), allowing you to run the µC/OS-III examples on the evaluation board.
There are seven versions of the µC/OS-III book, each one targeting a different MCU and semiconductor vendor:
1. ST and the STM32F107 (IAR tools)
2. NXP and the LPC1768 (Keil tools)
3. Renesas and the SH7216 (HEW tools)
4. Renesas and the RX62N (HEW tools)
5. Freescale/NXP and the Kinetis K53 (IAR tools)
6. Infineon XMC4500 (IAR tools)
7. TI and the Stellaris LM3S9B92 (IAR tools)
8. The µC/OS kernels are not popular.
Industry surveys have consistently shown broad adoption of the µC/OS kernels. The books have also made the kernels very popular. You can download all of the µC/OS books (except µC/OS version 1) free of charge from the Micrium website. Over the years, we have sold or provided for free (either in print or PDF format) hundreds of thousands of copies, reaching about 50% of the embedded developers worldwide. Some of the books have also been translated into selected languages:
• µC/OS was translated into Chinese, and portions of the book were translated into Japanese.
• µC/OS-II was translated into Chinese and Korean.
• µC/OS-III was translated into Chinese.
In addition to the books, the µC/OS kernels have been ported to just about every processor out there. Name a processor, and there’s a good likelihood that the kernel runs on it.
9. The µC/OS kernels were the first kernels ported to many ARM CPUs.
That’s absolutely true. µC/OS was the first kernel ported to the ARM6, ARM7, and ARM9 processors. µC/OS-II was also the first kernel ported to the Cortex line. Also, the µC/OS kernels were used to validate a number of new CPU architectures (new at the time), including the AMD 29000 line, Altera NIOS and NIOS-II, Xilinx MicroBlaze, and others. In fact, ARM designed a number of features in its Cortex-M architecture based on the µC/OS kernel:
• Dedicated timer for the tick interrupt (called the SysTick)
• CLZ instruction to help the scheduling algorithm in µC/OS as well as for use in floating-point math normalization
• Dedicated interrupt vector for context switching (called the PendSV handler)
• Tail-chaining capability to avoid saving and restoring CPU registers during back-to-back interrupts
10. The code for the µC/OS kernels isn’t very clean, and the kernels are hard to use.
I am very picky about coding convention and code quality. Don’t take my word for it: Jack Ganssle (renowned embedded-system developer, author, lecturer and consultant) has said that Micrium code is the prettiest, cleanest code he’s ever seen. The code for the kernel is extremely consistent, fully commented, and very efficient.
For example, all kernel APIs, variables, data types, and macros are prefixed by “OS.” This makes it easier for users to better use the kernel. Also, as a convention, code is placed on the left and comments on the right of code. This makes it easier for programmers to follow the code (if they ever need to). I’ve always assumed that programmers are not limited to 80 columns, as used to be the case many years ago.
Another convention is that every function is prefixed with a comment header block describing what the function does, its arguments, return value, and so on. Scanning through the Micrium code, you will also notice some additional aspects such as lined-up equal signs and lined-up comment delimiters reflecting our deep attention to detail.
As for the µC/OS kernels being hard to use, that’s not the case. Given the wide availability of books, blogs, application notes, training material, coding conventions, commented code, and user communities, the µC/OS kernels require very little support. The APIs are highly intuitive and consistent.
11. Micrium is abandoning µC/OS-II and µC/OS-III and will only support Silicon Labs chips.
Not at all. We (Micrium and Silicon Labs) have no intention of abandoning these highly popular products or support for other architectures; in fact, we plan to support them for years to come. Micrium already supports about 45 architectures, so for most developers considering the kernel, chances are good that we support their hardware.
We often get requests asking what would be required to write a port for some architecture that, in reality, is already supported. Silicon Labs’ acquisition of Micrium is not changing this commitment. The mandate for Micrium as part of Silicon Labs is to continue supporting Micrium customers regardless of the CPUs customers want to use. So, if customers have been using and desire to continue using ST, NXP, TI, Renesas, Altera, Xilinx, etc., parts, then Micrium will continue supporting them.
from Electronic Design - Engineering Essentials Curated By Experts http://bit.ly/2r80Mjh
Aucun commentaire:
Enregistrer un commentaire