Nucleus SE - an introduction
For the remainder of the RTOS Revealed series, we will be looking in detail at how an RTOS is implemented and deployed. To do that, we will work with a specific RTOS: Nucleus SE. Even if you have no intention of using this kernel, or others related to it, understanding how it works will give you a good basis for coming to grips with any RTOS.
To understand why Nucleus SE was designed the way it is, it is useful to outline the design goals of the kernel and the objectives that I had in embarking upon the project:
Simplicity – The code of the kernel should be simple, clear, well commented and documented, and thus easy to understand. Nucleus SE is primarily intended to be useful in an educational context.
Size – It should be a small, very scalable kernel (as memory, particularly RAM, might be in short supply).
Functionality – It should have a useful level of functionality, supporting standard RTOS facilities.
8/16-bit Support – It should be 8/16-bit “friendly”: byte-size data should be used wherever possible; data structures should not require exotic memory addressing modes; constant data should not be copied to RAM unnecessarily.
Future – There should be a growth path from Nucleus SE to Nucleusâ RTOS. Users should be able to easily port code between the kernels. More importantly, their expertise should be portable. The Nucleus SE API effectively implements a subset of the Nucleus RTOS application programmer interface (API).
Cost - The business model needed to be attractive to all potential users: 8/16-bit device developers, first time RTOS users and those learning about RTOS technology. It was decided to make Nucleus SE freely available and royalty free for both commercial and educational applications; you may use and modify the code in any way that you wish.
Nucleus SE Target Users
The result of this approach was a kernel that may be useful by three kinds of developers:
Programmers of 8/16-bit devices, who have a need for a simple kernel or task scheduler. It is particularly attractive if such developers are keen to acquire some RTOS usage skills or if the development is of a system where other 32-bit devices are in use, where Nucleus RTOS may be a good choice.
Developers of embedded applications employing 32-bit devices where the software complexity does not merit the cost of a conventional, commercial RTOS. Utilizing Nucleus SE may provide some useful facilities, while offering a growth path (to Nucleus RTOS) if the application complexity increases.
Students in education and training contexts may find Nucleus SE a useful basis for the study of RTOSes. The skills acquired are useful later, when they commence employment in the “real world”.
Design Decisions and Trade-offs
To achieve the aforementioned goals, several carefully considered design decisions were necessary. Details of these will be included later, when the specific features are covered, but this is a summary of the key issues.
Nucleus SE is a statically configured RTOS – i.e. all the decisions about configuration are made at build time, not dynamically at runtime. This has multiple benefits including the simplification of data structures and a reduction on code size, as use of simplified data has this side-effect and there is no need for “create” and “delete” API calls. For most applications, dynamic object creation is really not required.
The number of objects of each type is limited in a Nucleus SE application. There may be between one and sixteen tasks and between zero and sixteen of each other type of kernel object. This simplifies object addressing (see below). This limitation is not a constraint to the small applications for which the kernel is intended.
Objects are addressed by means of an “index”, which can have values from zero to fifteen. Compared with the conventional use of pointers, this can be more efficient on small processors and uses less storage – an index requires only 4 bits of storage; an address is 16-32 bits.
An area of the kernel’s design, that was subjected to careful simplification, was the scheduler. Instead of providing a flexible mechanism with priority scheduling, round robin and time slicing options, four separate scheduler types are available; the specific scheduler for an application is selected at configuration time.
Some functionality, which is available in Nucleus RTOS, has not been implemented in Nucleus SE. In some cases, this may just be for simplicity. In other cases, a small loss of functionality in one area renders something else much simpler to implement. These incompatibilities are highlighted in relevant articles in the series.