Difference form the Existing Specifications

This section lists the major changes in μT-Kernel from the base specifications, T-Kernel 2.0 and μT-Kernel 1.0.

Difference from T-Kernel 2.0

For the details of differences of each API, see the section "Difference from T-Kernel 2.0" in the description of each API.

  1. 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 .

  2. 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.

  3. 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.

  4. 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.

  5. Re-organization and extension of interrupt management function

    μT-Kernel 2.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.

    1. 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.

    2. 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.

Difference from μT-Kernel 1.0

For the details of differences of each API, see the section "Difference from μT-Kernel 1.0" in the description of each API.

  1. 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 .

  2. Expansion of the specification based on the expansion of T-Kernel 2.0.

    μT-Kernel 2.0 supports hardware-dependent functions such as MMU and FPU, or other functions that affect performance greatly as options (not mandatory features) by introducing service profile. Using this approach of adopting service profile, μT-Kernel 2.0 has extended the specification's scope in order to improve the compatibility with T-Kernel 2.0. Some functions that were dropped in μT-Kernel 1.0 have been added in the specification.

  3. Introduction of SZ data type

    In μT-Kernel 1.0, certain arguments of API and structure members were made into a wider scalar type even on 16-bit CPU so that memory can be accessed over 32KB boundary. μT-Kernel 2.0 pays attention to the case where it is not necessary to address memory regions beyond 32KB boundary on 16-bit CPU, and so converted the data type of these objects into SZ type. SZ type is an implementation-dependent scalar data type, and shall be properly defined based on the CPU bit width and memory space size for each implementation.