The whole truth about RTOS. Article # 32. Nucleus SE Migration: Unrealized Features and Compatibility

The main requirement for the development of Nucleus SE was a high degree of compatibility with the main Mentor RTOS product - Nucleus RTOS. Nucleus SE supports a certain part of the functionality of Nucleus RTOS, which has been discussed many times in previous articles, but in this article I will try to collect all the key differences in one place. This article was conceived as a quick reference for everyone who is going to switch from one core to another, or is in the process of choosing a kernel for a specific project.







In addition to limited or simplified functionality, compared to Nucleus RTOS, Nucleus SE has also been designed with the emphasis on maximizing memory utilization with extensive customization options. An important part of this approach is scalability. Many features of the kernel functionality can be activated or disabled as necessary. Obviously, disabling functionality in a particular implementation increases its incompatibility with Nucleus RTOS.



In Nucleus RTOS, a system can be created with an undetermined number of kernel objects; the only limitation here is the amount of available resources (i.e. memory). Nucleus SE has a limit of sixteen objects of each type; the system can have from one to sixteen tasks and from zero to sixteen objects of each type (mailboxes, queues, etc.). Despite the fact that this limit can be increased, considerable effort will be required, since Nucleus SE makes extensive use of the ability to store the index of an object in nibble (four bits). In addition, with more than sixteen tasks, the Priority Scheduler is likely to become very inefficient. An application whose functionality seriously suffers from these limitations is not suitable for Nucleus SE, in this case Nucleus RTOS is a much more suitable choice.

Scheduler

Like all modern real-time cores, Nucleus RTOS has a very flexible scheduler that provides several priority levels (with an undetermined number of tasks at each priority level), as well as the ability to select the Round Robin and Time Slice scheduler. Nucleus SE is much simpler and offers four schedulers that must be selected at build time: Run to Completion, Round Robin, Time Slice, and Priority. You cannot combine different schedulers (that is, there is no composite scheduler). For example, you cannot select a combination of Time Slice and Priority schedulers. In addition, the Priority scheduler allows you to assign only one task to each priority level, that is, there are as many priority levels as there are tasks. The priority of the task is set during the build and does not change anymore (like the time slot if the Time Slice scheduler is selected).

API calls

Application Programming Interface (API) - the visible “face” of the operating system. Not surprisingly, this is where the differences between Nucleus RTOS and Nucleus SE are most obvious.



The Nucleus SE API is different from the Nucleus RTOS API. However, the Nucleus SE API has been carefully designed so that it can be transferred to the Nucleus RTOS API fragment. Holders of licensed Nucleus RTOS can get a “shell” (a header file containing #define macros) that will perform the transfer almost directly.



From the fact that the Nucleus SE API can be called a “subset” of the Nucleus RTOS API, it follows that some API calls are missing. This is true and it is an inevitable result of the development criteria of Nucleus SE. Some API calls simply do not make sense, since they are associated with non-existent functionality; other calls were excluded in order to simplify the implementation of some kernel objects. All of this is described in detail in the following sections of this article.

Common API Functions

Nucleus RTOS has API functions that are common to several different types of kernel objects, or even all types of objects. Some of them were also implemented in Nucleus SE, a good example of such a function is reset. Other functions are not applicable to the implementation of kernel objects in Nucleus SE.



Create and delete



In Nucleus RTOS, all kernel objects are dynamic; they are created and deleted as needed. Therefore, there are API calls for this. In Nucleus SE, all objects are static (they are created at build time), so these API calls are not needed.



Returning pointers to objects



The main identifier (descriptor) of kernel objects in Nucleus RTOS is a pointer to the object control block, which is assigned when the object is created. Therefore, there is also a set of API calls that return a list of pointers to objects of each type. Since Nucleus SE uses a simple index to identify kernel objects, such calls are not necessary. A program can query the kernel to find out how many instances of objects of a particular type are configured (using a call like NUSE_Mailbox_Count () ); if this value is n , the indices of objects of this type will have values ​​from zero to n-1 .



Data streaming



For some types of Nucleus RTOS kernel objects (such as mailboxes, queues, and pipes), an API overhead is provided to translate the data. This allows you to send data to every task that expects data from the object. This possibility was excluded from Nucleus SE for simplification, since access to the data of such objects is always performed in the context of a specific task, which then frees the object. Therefore, to implement translation, an additional flag mechanism would be required.

Unique Features API Objects

Many kernel objects have API calls that are unique to a particular type of object and differ in Nucleus RTOS and Nucleus SE.



Tasks



Since the Nucleus RTOS Scheduler is much more complex than Nucleus SE, some API functions are not necessary:

• Changing the position of a task interrupt - not supported in Nucleus SE.
• Change task priority - In Nucleus SE, task priority is assigned during configuration and cannot be changed.
• Change task time slot - in Nucleus SE, the time slot value is common to all tasks and is set during configuration.
• Task Completion - Nucleus SE does not support the “completed” task state.

Dynamic memory



Since everything is created statically in Nucleus SE, dynamic memory is not supported (and not required). Therefore, the associated API functions are also unnecessary.



Signals



Nucleus RTOS supports signal handlers, programs that run (like interrupt handlers) when task signals change. This feature was excluded from Nucleus SE, therefore, API calls to manage the signals and create a signal handler are not required.



Interruptions



Nucleus SE uses the “non-interference” approach to interrupts, simply providing the ability to make some API calls from the interrupt handler. Therefore, some Nucleus RTOS API calls that specify how the kernel should handle interrupts are not supported.



Diagnostics



Nucleus SE has very modest diagnostic services, following its "restrained" development style, limiting itself to (optional) parameter checking and outputting the product version code. Therefore, Nucleus RTOS API calls related to history logging and error confirmation are not supported.



Drivers



Nucleus RTOS has a well-defined formal driver structure and several API functions related to driver management. Nucleus SE does not have this structure; therefore, corresponding API calls are not necessary.

API Call Functionality

Some aspects of the functionality of Nucleus SE, which are implemented in a simplified form, lead to differences from Nucleus RTOS. Some of them affect how API calls are used and the services available.

Timeouts

When using Nucleus RTOS, there are often situations where an API call can pause a task waiting to access a resource: the task is blocked. Such a suspension of the task can be implicit (that is, until the resource becomes available), or the timeout value can be specified. Nucleus SE provides blocking by API calls as an option, however, only implicit suspension can be used (that is, a call can only use NUSE_SUSPEND or NUSE_NO_SUSPEND , not a timeout value). This feature is quite simple to add to Nucleus SE.

Suspension Procedure

When multiple object types are created in Nucleus RTOS, a suspension order can be assigned. This is a sequence in which several blocked tasks will resume as resources become available. Two options are available: FIFO, first come - first leave (first in first out), in which tasks are resumed in the same order in which they are blocked; or by priority, in which the task with the highest priority always resumes first. Nucleus SE does not offer such a choice. It implements only the priority order. In fact, it is more correct to say the order by the task index, since the suspension order can be applied not only when using the Priority scheduler, but also when using the Round Robin and Time Slice schedulers.

Unique feature functionality

In some cases, functional changes related to certain types of objects were necessary.



Signal handlers

As mentioned above, signal implementation in Nucleus SE does not support signal processing procedures.



Application Timer Settings

The timer has an initial duration / initial duration of operation and a restart duration and can optionally perform a user-defined function at completion. This functionality is supported in both Nucleus RTOS and Nucleus SE. However, Nucleus SE, unlike Nucleus RTOS, does not allow changing the parameters described above when calling the API function for reset. In addition, in Nucleus SE, all support for timer completion procedures is optional.



Event flags

Nucleus RTOS has an option to “absorb” event flags. This means that flags that match the criteria set by the task are reset. Such functionality is not supported in Nucleus SE, since the ability to search for criteria for several tasks significantly increases the complexity of the system.

Data sizes

Two development criteria for Nucleus SE: maintaining simplicity and minimizing memory usage, have led to certain differences in data element sizes compared to Nucleus RTOS. It is worth noting that Nucleus RTOS usually uses unsigned data, which is most likely 32-bit. while Nucleus SE uses streamlined data types like U32 , U16 , U8 and so on. ( Translator's note: In my opinion, the author is right for 8-bit systems. In modern systems, registers are still 32 bit, so cutting off the older part consumes memory for code and clock cycles for its execution, and the data is all the same equal to 32 bits when stored in memory, otherwise the performance of the system will drop, so this approach does not give a gain for modern systems, and a loss due to the instructions added by the compiler that cut off the older part may very well. ).

Mailboxes

In Nucleus RTOS, a mailbox stores a message consisting of four unsigned data elements. In Nucleus SE, a mailbox stores an ADDR data item. In my opinion, mailboxes are often used to transfer an address (indicating specific data) from task to task.

Queues

In Nucleus RTOS, a queue processes messages from one or more unsigned data elements. The queue can also be configured to handle variable-length messages. In Nucleus SE, a queue processes messages consisting of a single ADDR data item. In my opinion, queues are used in a similar way with mailboxes. In addition, in Nucleus RTOS, the total size of the queue (i.e. the total number of unsigned elements that can be placed in the queue) is specified as an unsigned value. In Nucleus SE, this value is of type U8 . Therefore, a queue can hold less data.

Data channels

In Nucleus RTOS, a channel processes messages from one or more bytes; The channel can also be configured to handle variable-length messages. In Nucleus SE, a channel processes messages consisting of one or more data elements of type U8 . The message size is set during setup for each channel. In addition, in Nucleus RTOS, the total channel size (that is, the total number of bytes that can be placed in a channel) is specified as an unsinged value . In Nucleus SE, this value is of type U8 and represents the number of messages (in the NUSE_Pipe_Information () API call). Therefore, a channel can hold less data.

Event Flag Groups

In Nucleus RTOS, an event flag group contains 32 flags; in Nucleus SE, their number is reduced to eight. This size has been chosen since the likely target Nucleus SE processors can efficiently process 8-bit data. At the same time, changing the number of flags in the flag groups of events processed by Nucleus SE will not be difficult.

Signals

In Nucleus RTOS, each task has a set of 32 signal flags. In Nucleus SE, signals are optional, and each task has a set of 8 flags. This size has been chosen since the likely target Nucleus SE processors can efficiently process 8-bit data. At the same time, changing the number of flags in the signal flag sets processed by Nucleus SE will not be difficult.

Sections of memory

In Nucleus RTOS, the number and size of partitions are unsigned . In Nucleus SE, the number of partitions is a parameter of type U8 and the partition size is U16 . This leads to some partition and pool size restrictions.

Timers

In Nucleus RTOS, timers (both application timers and task sleep timers) work with unsigned values. In Nucleus SE they are of type U16 . This type was chosen because the likely target Nucleus SE processors can process 16-bit data efficiently (and eight bits is clearly not enough to use a timer). At the same time, changing the size of timers in Nucleus SE will not be difficult.



The following article will examine how Nucleus SE can be used in an embedded software project.



About the author: Colin Walls has been working in the electronics industry for more than thirty years, devoting most of his time to firmware. He is now a firmware engineer at Mentor Embedded (a division of Mentor Graphics). Colin Walls often speaks at conferences and seminars, the author of numerous technical articles and two books on firmware. Lives in the UK. Colin's Professional Blog , e-mail: colin_walls@mentor.com.