Nucleus SE migration: Unimplemented facilities and compatibility
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.
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.
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.
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.
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.
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: http://blogs.mentor.com/colinwalls. He may be reached by email at email@example.com