An Ultra Small Real Time Multi Tasking Kernel for Embedded Applications

In the need to implement several concurrent tasks within the same application firmware I decided that there is some more or less common multi tasking needed - for the sake of structure and simplicity. Else the overall firmware is getting just mess and can be hardly understood. Well, this is nothing new. But on the other hand one has to make compromises because of the very limited resources with regard to memory space and CPU power.

The investigation regarding a suitable and freely available operating system or multi tasking kernel that would fit my needs did not really yield anything suitable. So I decided to build up such a system from the scratch on my own. The result is a quite handy and simple to understood kernel. It cannot really be considered as an RTOS (Real Time Operating System) that is usually providing much more functionality. It is rather comparable to a micro kernel that is strapped down to the most elementary functionality.

Later on I found the result quite good and decided to refine it slightly and made it more general. So it can be better used as basis for future projects in that direction. I also decided to make it open-source and publish it accordingly so that others can make use of it as well.

• Traditional thread or process coding concept kept intact
  Each task consists of a root-function and can call other functions as usual. So a single task is just a normal program.

• Preemptive multi tasking
  Although the tasks have the capability to suspend their self, the general architecture has been laid out for traditional preemptive multi tasking. That is, the kernel ensures a fair and equal distribution of the CPU time across all tasks. This is an important prerequisite for the real time capabilities of the kernel.

• Small memory footprint
  The memory resources required by the kernel are with around 600 bytes of code space relatively low. The code size grows to around 700 bytes in case the kernel is compiled with kernel semaphore support.
  Apart from the kernel code there are 128 bytes of memory needed for each task. So a firmware with 4 tasks requires a total memory overhead of a little bit above 1kB.

• Little timing overhead
  Provided the fact that the 8051 does not provide traditional hardware mechanisms for efficient multi tasking support, the overhead caused by the kernel is typically around 1.5% (less than 2.5% worst-case) assuming a reasonable kernel tick rate of 100Hz.

• Source code based design
  The kernel cannot be pre-compiled into object files and then linked against various application firmware designs. Instead, it is to be compiled together with the application firmware code. This allows to hard-code several things within the kernel which is making it smaller and more efficient. For instance the number of tasks needs to be known during compilation.
  This source code based design is no general disadvantage, however, as the kernel is very small and compiles very quickly.

• C based design
  The design is generally C-based, Although a big portion of the kernel itself has been written in assembly language for the sake of a small code size and a fast execution.

Apart from the application within actual firmware designs it might be usable for educational purposes as well. This is, because the kernel is very small and easy to understand. Its main implementation source file stretches across approx. 1300 lines of code, where roughly 80% are explanatory comments.

I think it would be useful to port this kernel also to the larger Microchip PIC and Atmel AVR micro controllers. Porting it to the smaller devices from these series probably does not make much sense. First of all, the firmware for these devices is usually not that complex so that it would ask for a dedicated multi tasking. Secondly, there are very likely no resources available to afford the overhead of a kernel.

Porting the kernel into the other direction, say PowerPC, ARM, etc., is no problem at all. Even more, the kernel could be implemented much more efficient, as this processor category usually supports features that are very helpful for an efficient multi tasking implementation - not to mention the capability for a clear isolation of the tasks. However, these systems usually provide more resources so that it is mostly better to use uCLinux or Linux directly. Using this kernel there seems to make only sense in case the extra overhead needs to be reduced to an absolute minimum.

Apart from any porting efforts there are also some other points where the kernel might be extended. However, any extension does automatically mean that it is getting more complicated and more resource-demanding....

Right now there are no specific plans for any ports or extensions. I'll do that in case it appears necessary or when I'm filled up with stuffiness (which is not to happen very likely ;-)

Also notice that I cannot guarantee any support in case of problems or questions. In case you've got a question or you think you have discovered a bug, you are invited to contact me. But I cannot promise that I've got the time to check and/or fix this. But let's see....

The kernel sources including a ready-to-compile example can be downloaded via the link below. It is coming as a simple bzipped tar archive. The archive does also include the white paper that might be used as documentation.

Notice that you also need the SDCC C compliler which is available from http://sdcc.sourceforge.net. The kernel has been specifically tested with SDCC 2.9.0. Other compilers might work as well, but there are needed some precautions to be taken so that they might not work out of the box.

Downloadable Files:

The kernel source code version 1.0.0 for FX2LP including a descriptive white paper:
uC_RT_Kernel_FX2LP_Version_1.0.0.tar.bz2 (approx 300kB)