Nucleus SE migration: Unimplemented facilities and compatibility
A key design requirement of Nucleus SE was a high level of compatibility with Mentor’s flagship real time operating system product, Nucleus RTOS. Nucleus SE has a subset of the functionality of Nucleus RTOS and I have highlighted this on all relevant occasions in this series, but, in this article, I will attempt to bring together all the key differences in one place. The intention is to give a quick reference for anyone planning migration between the two kernels or making a selection of a kernel for a specific project.
Apart from having limited or simplified functionality, as compared to Nucleus RTOS, Nucleus SE is also designed to be as memory-efficient as possible, with plenty of opportunities for tuning by the user. A key part of this strategy is scalable functionality. Many features of the kernel’s functionality can be enabled or disabled, as required. Obviously, disabling functionality increases incompatibility with Nucleus RTOS for a given implementation.
In Nucleus RTOS, a system may be built with indefinite numbers of kernel objects – the only major limitation is the amount of available resources (i.e. memory). Nucleus SE has a limit of no more that sixteen of each object type; a system may have one to sixteen tasks and zero to sixteen of each other type of object (mailboxes, queues etc.). Although this limit could be increased, it would take a considerable amount of work, as the ability to store an object index in a nibble (four bits) is widely exploited. Additionally, the Priority scheduler is likely to become very inefficient if more than sixteen tasks were permitted. An application which is seriously constrained by these limits is not really suited to Nucleus SE and Nucleus RTOS is likely to be a much better choice.
Like any modern real-time kernel, Nucleus RTOS has a very flexible scheduler, offering numerous priority levels (with an indefinite number of tasks on any given level); along with the possibility for round robin and time slice scheduling. Nucleus SE is much simpler, offering four different schedulers, which must be selected at build time: Run to Completion, Round Robin, Time Slice and Priority. There is no option to combine the scheduling methods (i.e. there is no composite scheduler) – mixing priority with time slice, for example. Also, the priority scheduler only allows a single task at each priority level – there are only as many priority levels as there are tasks. A task’s priority is fixed at build time, as is the time slice, if that option is used.
The application program interface (API) is the visible “face” of an operating system. It is unsurprising that it is here that the differences between Nucleus RTOS and Nucleus SE are most obvious.
Nucleus SE does not have the same API as Nucleus RTOS. However, its API is carefully designed to map very readily onto a subset of the Nucleus RTOS API. Licensees of Nucleus RTOS can obtain a “wrapper” (a header file containing #define macros) which render the mapping almost completely transparent.
Because the Nucleus SE API is a subset of Nucleus RTOS, there is the implication that some API calls are missing. This is true and an inevitable result of the design criteria of Nucleus SE. Some API calls would just be irrelevant, as they apply to non-existent functionality; others are missing because of simplifications in the implementation of some kernel objects. This is all detailed in the following sections of this article.
Common API Functions
In Nucleus RTOS there are some API functions that are common across a number of different types of kernel object – or even across all of them. Some of these are also implemented in Nucleus SE – “reset” is a good example. Others are not applicable to the Nucleus SE implementation of kernel objects.
Create and Delete
In Nucleus RTOS, all kernel objects are dynamic – they are created and deleted as required. Hence API calls are provided for this purpose. In Nucleus SE all objects are static – they are created at build time – so such API calls are not required.
Return of Object Pointers
The primary identifier (handle) used for kernel objects by Nucleus RTOS is a pointer to the object’s control block, which is assigned when the object is created. There is, therefore, a set of API calls that return list of pointers to objects of each type. Since Nucleus SE uses a simple index to identify a kernel object, such a call would be redundant. A program can interrogate the kernel to ascertain how many instances of a given object type are configured (using a call like NUSE_Mailbox_Count()); if this value is n, the indexes for the object type will range from zero to n-1.
For a number of Nucleus RTOS kernel object types (notably mailbox, queue and pipe), a “broadcast” API call is provided. This facilitates sending a data item to every task which is blocked on reading from the object. This capability was omitted from Nucleus SE for simplicity, as access to data in such objects is always gained in the context of the relevant task, which then frees the object; an additional flagging mechanism would be required in order to implement a broadcast.
Object-Specific API Functions
Many kernel objects have API calls that are very specific to the particular object type and vary between Nucleus RTOS and Nucleus SE.
Since the Nucleus RTOS scheduler is considerably more sophisticated than Nucleus SE’s, a number of facilities provided by API functions are not required:
Change of task’s preemption posture – not supported by Nucleus SE
Change a task’s priority – priorities are set at configuration time with Nucleus SE and cannot be changed
Change a task’s time slice – the time slice value is global for all tasks and fixed at configuration time in Nucleus SE
Terminate a task – the “terminated” task state is not supported by Nucleus SE
As everything is created statically in Nucleus SE, dynamic memory is not supported (or required). Hence a number of specific API functions are not needed.
Nucleus RTOS supports signal handlers – routines that are run (rather like interrupt service routines) when a task’s signals are modified. This capability was omitted from Nucleus SE and, hence, the API calls to control signals and register a signal handler are not required.
Nucleus SE takes a “hands off” attitude to interrupts, simply facilitating the option to perform some API calls from within an interrupt service routine. Hence, the set of Nucleus RTOS API calls that specify how the kernel processes interrupts are not required.
Nucleus SE has very modest diagnostic facilities, in keeping with its “lean” design, being limited to (optional) parameter checking and the reporting of the product version code. Hence, Nucleus RTOS API calls associated with history logging and assertions are not implemented.
Nucleus RTOS has a well-defined, formal driver structure, with a number of API functions associated with the management of drivers. Nucleus SE does not have such a structure, so the relevant API calls are not required.