Embedded Programming Pattern: No Kernel

Often embedded software developers ask: "Why should I use a kernel in my application? I'm fine without, what kind of advantages does it bring to me?". The answer is simple: a kernel is not always needed.

Introduction

Telling the truth, we use BeRTOS' kernel module in just about half of our projects. Generally our projects are medium/large sized and must be maintained for a long time. In spite of this we handle it even without a kernel.

In some applications the kernel simply is not needed. For this reason BeRTOS can be used even with the kernel module completely disabled.

In contrast with other comparable RTOSes, BeRTOS includes a large library of drivers, algorithms and general purpose protocols. Most of the time it's enough to put some modules together to come close to the final result.

In fact, the typical embedded application must execute different jobs, possibly in parallel, at fixed time intervals and nothing more. If the jobs are number limited (about ten at maximum), we can get away with the good old infinite loop and some if's, without using the kernel.

When to use a Kernel

Why did you develop a kernel, I hear you asking? Because many more other cases it's useful and it simplifies the code.

An application that uses processes scales better with rising complexity. The application is much faster and more reactive, it's simpler to modify and it's easier to debug. The whole processes management code is left to the kernel and we just need to write application code. To me, you should base your decision of using a kernel not by just counting the number of jobs, but rather by looking at your requested latency, the complexity of the relationships and the dependencies between them.

Example application and first solution

In this section I'll introduce a typical application and I'll show how to implement it using the modules that BeRTOS gives in your toolbox.

Let's define the problem: we need to develop a firmware for an MCU-based electronic board that controls a device. It's duties are mainly control and supervision.

For the sake of simplicity we'll assume that the board, among other things, should:

• sample a temperature level and activate protections above certain levels;
• acquire voltage levels that represent physical measurements and drive an output after some computation;
• load and save settings from a memory when pressing a button;
• make safety checks: if an alarm pin becomes high, we must read a value from ADC, do some computation and throttle down the speed of a power motor in the shortest possible time.

Temperatures and voltages should be acquired at a constant rate, with different intervals between them.

Here is a possible implementation of the application's main loop, using BeRTOS API but without any kernel or scheduler.

/* Global system status */
Parameter prm;

ticks_t temp_time, voltage_time, now;

init();

for (;;)
{
    now = timer_clock();

    /* Temperature */
    if (now - temp_time > TEMP_PERIOD)
    {
        temp_time = now;
        /* Check current temperature state. */
        temp = adc_read(TEMP_CH);
        temp *= T_SCALE + T_OFFSET;
        temp_check(temp);
        prm.temp = temp;
    } 

    /* Voltage levels  */
    if (now - voltage_time > VOLTAGE_PERIOD)
    {
        voltage_time = now;
        /* Acquire and check voltages */
        v = adc_read(VOLT_CH);
        v = v * V_SCALE + V_OFFSET;
        valve = voltage_check(&prm, v);
        /* Update output */
        prm.valve = vale;
        setvalve(valve)
    }

    /* Handle parameter save/load */
    if (load_pressed())
    {
        /* Load */
        load_preset(&prm);
    }

    if (save_pressed())
    {
        /* Save */
        save_preset(&prm);
    }

    /* Check motor alarm */
    if (motor_alarmOn())
    {
        a = adc_read(SPEED_CH);
        a *= SPEED_SCALE;
        motor_setSpeed(a);
    }

    ...
}

The implementation is linear and easy to understand if there are few jobs, but it quickly becomes unmanageable when adding jobs.

In the next issue we'll see how to extract pieces of code out of the application's main loop.