Nucleus SE migration: Unimplemented facilities and compatibility -

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.

The Scheduler

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.

API Calls

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 .

Broadcast Data

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

Dynamic Memory

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.

API Call Functionality

Several of aspects of Nucleus SE’s functionality, which are implemented in a simplified way, result in differences from Nucleus RTOS. A number of these impact the way API calls are used and the facilities available.


With Nucleus RTOS, there are many situations when an API call may optionally suspend a task pending the availability of a resource – the task is blocked. This suspension may be indefinite – i.e. until the resource is available – or a timeout value may be specified. Nucleus SE offers blocking API calls as an option, but only indefinite suspension may be specified – i.e. the call may only include NUSE_SUSPEND or NUSE_NO_SUSPEND , not a timeout value. This capability could be added to Nucleus SE in a reasonably straightforward manner.

Suspend Order

When many types of object are created with Nucleus RTOS, the suspend order may be specified. This is the sequence in which a number of blocked tasks will be resumed as resources become available. Two options are available: first in first out, where tasks are resumed in the same order that they are blocked, or priority order, where the highest priority task is always resumed first. Nucleus SE does not offer this choice. Only priority order is implemented. Actually, the order is by task index, as this does not only apply to the Priority scheduler, but also to Round Robin and Time Slice.

Object Specific Functionality

In some cases, there is a change in functionality which is quite specific to a particular type of object.

Signal Handlers

As mentioned earlier in this article, the implementation of signals in Nucleus SE does not support signal handling routines.

Application Timer Parameters

A timer has an initial duration and a restart duration and may optionally execute a user-specified function on expiration. This functionality is all supported in both Nucleus RTOS and Nucleus SE. However, Nucleus SE, unlike Nucleus RTOS, does not allow any of these parameters to be changed when a reset API call is made. Additionally, in Nucleus SE the entire support for expiration routines is optional.

Event Flags

With Nucleus RTOS, there is an option to “consume” event flags. This means that flags that meet a task’s criteria for a match are cleared. This functionality is not offered in Nucleus SE as complexity is greatly increased by accommodating the possibility of multiple tasks’ match criteria being met.

Data Sizes

The two Nucleus SE design criteria of maintaining simplicity and minimizing memory usage result in a number of differences in the size of data items as compared with Nucleus RTOS. It should be noted that Nucleus RTOS commonly uses data of type unsigned , which is probably 32 bits; whereas Nucleus SE uses rationalized data types like U32 , U16 , U8 , etc.


In Nucleus RTOS a mailbox carries a message consisting of four unsigned data items. In Nucleus SE a mailbox carries a sign data item of type ADDR . My thinking is that a common use for mailboxes is the passing of an address (pointing to some data) between tasks.


In Nucleus RTOS a queue handles messages of one or more unsigned data elements; a queue may also be configured to handle messages of variable size. In Nucleus SE a queue handles messages that consist of a single data item of type ADDR . My thinking is that queues are used in a similar way to mailboxes. Also, in Nucleus RTOS the total size of the queue (i.e. total number of unsigned elements for which there is space) is specified as an unsigned value. In Nucleus SE this value is of type U8 . A queue thus has smaller data capacity.


In Nucleus RTOS a pipe handles messages of one or more bytes; a pipe may also be configured to handle messages of variable size. In Nucleus SE a pipe handles messages that consist of one or more data items of type U8 . The message size is set at configuration time for each pipe. Also, in Nucleus RTOS the total size of the pipe (i.e. total number of bytes for which there is space) is specified as an unsigned value. In Nucleus SE this value is of type U8 and represents the number of messages (in the NUSE_Pipe_Information() API call). A pipe thus has smaller data capacity.

Event Flag Groups

In Nucleus RTOS an event flag group contains 32 flags; in Nucleus SE this is reduced to eight. This size was chosen as likely target processors for Nucleus SE efficiently handle 8-bit data. It would not be difficult to change Nucleus SE to handle event flag groups of a different size.


In Nucleus RTOS every task has a set of 32 signal flags. In Nucleus SE signals are optional and each task has a set of just eight flags. This size was chosen as likely target processors for Nucleus SE efficiently handle 8-bit data. It would not be difficult to change Nucleus SE to handle signal flag sets of a different size.

Memory Partitions

In Nucleus RTOS the specification of the number and size of partitions are both unsigned parameters. In Nucleus SE the number of partitions is a parameter of type U8 and the partition size is U16 . This implies some limitations on the partition and pool size.


In Nucleus RTOS timers (both application timers a task sleep) handle values of type unsigned . In Nucleus SE they are of type U16 . This type was chosen as likely target processors for Nucleus SE efficiently handle 16-bit data (and eight bits would not be enough to be useful). It would not be difficult to change Nucleus SE to handle timers of a different size.

The next article will look at how Nucleus SE may be used for an embedded software project.

Colin Walls has nearly forty years’ experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor, a Siemens business, and is based in the UK. His regular blog is located at: He may be reached by email at

2 thoughts on “Nucleus SE migration: Unimplemented facilities and compatibility

  1. “At the beginning of this series, Colin says that the source code would be available. Is it available, or is it just the code snippets in the articles? “

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.