OSEK OS in Practice

Micael Coutinho, • autosarbswos
Back

Last time out, we took a look at the theory behind the OSEK/VDX OS, the backbone of the Autosar OS. Today we find how we can use tasks, events and ISR's.

Before we begin, this article is a follow-up to our last article about the OSEK/VDX OS, where we explain the theory behind it. Today we'll focus on how these concepts can be used in practice. So, if you haven't checked it out, please read the first part, OSEK OS Overview (opens in a new tab)), as it will give you the basis you need for this one.

As we discussed in the first part, OIL (Osek/VDX Implementation Language) is the configuration language for all the resources you create within your OS. Even for Autosar, as the version 3 of the OIL standard is used by it, at least in older versions (Autosar partially parted ways with OIL to ARXML, but there is still some support from the Autosar tools for OIL files). Then, these files will be used to generate code. In the end of this article, you will be a pro when it comes to it. Well, not quite, but you'll be in a good spot.

So, let's start with tasks. How can we declare a task in an OIL file? Easy:

    Task myTask {
        AUTOSTART       = TRUE {
            APPMODE         = myAppMode;
        };
        PRIORITY        = 1;
        ACTIVATION      = 1;
        SCHEDULE        = NON;
    }

Does not look that complicated, does it? Let's see what each parameter means:

After generating code, you are going to find something like this:

    TASK (myTask) {
        /*task functionality goes here, along with task API's*/
    }

Now, let's look at some task-related API's. There are more, but I trust you'll look into the references to further improve your knowledge, if you are curious. These will be more useful than learning OIL, as you are going to find a certain variation of it on the Autosar OS:

Now, let's take a look at events. We already explained that events are a consumable for extended tasks, that can only be consumed by 1 task. Since they are associated to an extended task, your task that depends on the event also needs to reference it. The OIL file will look something like this:

    Task myTask {
        // everything else related to the task
        EVENT = myEvent;
    } 

    EVENT myEvent {
        MASK = 1;
    }

As you can see in the example above, the event gets a mask, and is also associated with the consumer task. Regarding the API's available for an event, you have the following at your disposal:

Regarding ISR's, you can check how they are described in OIL below. In it, you'll find the category, priority, stack size and its source, which is linked to the interrupt vector of the microcontroller.

    ISR myCat2ISR {
        CATEGORY    = 2;
        PRIORITY    = 5;
        STACKSIZE   = 1024;
        SOURCE      = SPI1_RX;
    }

The generated C code will look like this:

    ISR (myCat2ISR) {
        /*ISR2 functionality goes here, along with authorized API's*/
    }

For the first part, we'll stop here, just to keep this article as a digestable piece, instead of a lecture. Next time out, we'll dive into counters, alarms and hooks. In the meantime, we encourage you to play around TrampolineRTOS (opens in a new tab) and the RTA-OSEK manual, which will enrich your learning experience even further. Stay tuned for the next part!

Author: Micael Coutinho (opens in a new tab)

References:

© AutosarToday —@LinkedIn