This section lists the major differences between the μT-Kernel 3.0 specification and other legacy RTOS specifications that have close relationship with μT-Kernel 3.0.
Removal of features that assumes process management and virtual memory
μT-Kernel 3.0 defines a real-time OS to control small embedded systems and IoT edge nodes equipped with 16-bit or 32-bit CPU. It is not designed to be used as the OS kernel with process management or virtual memory for generic information processing systems. Because of this design decision, Address Space Management Functions (Address Space Configuration, Address Space Checking, Logical Address Space Management) and System Memory Allocation function which μT-Kernel 2.0 has are not included in μT-Kernel 3.0. Also, among Subsystem Management Functions, startup/cleanup processing and functions for resource group are not included in μT-Kernel 3.0.
Addition of handling system time
API that uses 0:00:00 of January 1st 1970 (UTC) as epoch to set system time have been added to μT-Kernel 3.0: these are tk_set_utc, tk_set_utc_u, tk_get_utc, tk_get_utc_u, td_get_utc, td_get_utc_u.
Removal of Rendezvous Function
μT-Kernel 3.0 does not have Rendezvous function, one of Extended Synchronization and Communication Functions of T-Kernel.
Removal of features that assumes process management and virtual memory
μT-Kernel 3.0 defines a real-time OS to control small embedded systems and IoT edge nodes equipped with 16-bit or 32-bit CPU. It is not designed to be used as the OS kernel with process management or virtual memory for generic information processing systems. Because of this design decision, Address Space Management Functions (Address Space Configuration, Address Space Checking, Logical Address Space Management) and System Memory Allocation function which T-Kernel 2.0 has are not included in μT-Kernel 3.0. Also, among Subsystem Management Functions, startup/cleanup processing and functions for resource group are not included in μT-Kernel 3.0.
Introduction of service profile
For μT-Kernel that addresses the needs of small-scale embedded systems, the specification aims at the ease of optimization and customization. However, at the same time, to improve the ease of distribution of middleware and applications by increasing portability, a formal mechanism to describe the issues for implementation-dependency of μT-Kernel is now introduced. For details, see the Section called Service Profile in the Chapter called μT-Kernel Concepts .
Specification of user buffer
APIs that need to use internal memory on the stack or in the memory pools can use a user-specified buffer area instead of using the automatically allocated area by the kernel. Specification by TA_USERBUF is enough to use a user-specified buffer in general.
Type changes for supporting 16-bit CPU
μT-Kernel needs to support 16-bit CPU, and the integer that can be represented by INT or UINT type may be restricted to 16-bit integer values. For this reason, some arguments of APIs and members of structures now have wide enough scalar types, instead of INT or UINT types, so that they can present the values adequately.
Customization for small-scale embedded systems
μT-Kernel is meant for small-scale embedded systems, and so the specification has been tuned to such usage. For example, an implementation with a smaller value, than in T-Kernel, for the largest value of task priority is allowed.
Re-organization and extension of interrupt management function
μT-Kernel 3.0 offers interrupt management functions that are based on those of T-Kernel 2.0 after re-organizing and extending these one way or the other. There are differences as follows.
Addition of functions to obtain and set interrupt mask level
Add APIs for obtaining and setting the interrupt mask level of CPU and/or interrupt controller namely SetCpuIntLevel, GetCpuIntLevel, SetCtrlIntLevel, and GetCtrlIntLevel.
Abolishing interrupt vector number (INTVEC)
In order to simplify number systems used for interrupts and make it simple to understand, we abolished with the specification using interrupt vector number (INTVEC) For APIs that take INTVEC as argument in T-Kernel 2.0, we use the common interrupt number used in tk_def_int() as the argument instead of INTVEC.
Specification of μT-Kernel 3.0 is upward compatible with the specification of IEEE 2050-2018 standard which IEEE published for the standard RTOS for IoT edge nodes. Because of this, an OS that satisfies the μT-Kernel 3.0 specification automatically satisfies IEEE 2050-2018 specification.
On the other hand, the specification of IEEE 2050-2018 is a subset of μT-Kernel 3.0 specification. The following functions of μT-Kernel 3.0 are not included in IEEE 2050-2018: Subsystem Management Functions, and Kernel Internal State Acquisition Functions and Trace Functions for debugging purposes provided by μT-Kernel/DS. Also the following functions are not in IEEE 2050-2018: Functions that handle DS Object Names(dsname) and APIs to handle system time using 00:00:00, January 1, 1985 (GMT) as epoch (tk_get_tim, tk_get_tim_u, tk_set_tim, tk_set_tim_u).