RTA Knowledge Base

Introduction

Scope

In this application note we will explain to you how interrupts work in the VRTA OS port, and provide a demonstration of how to configure an ISR and call it while the VRTA is running.

Definitions and Abbreviations

BSW: AUTOSAR Basic Software, Hardware independent service layer

RTE: AUTOSAR Run-Time Environment

OS: AUTOSAR Operating System

SWC: Software Component

CAN: Controlled Area Network

ECU: Engine/Electronic Control Unit

SK: Starter Kit

Confgen: Configuration Generation

VRTA: RTA-OS virtual target (virtual ECU)

ISR: Interrupt Service Routine

IPL: Interrupt Priority Level

Toolchain

It is assumed you are using the RTA-CAR 9.2.1 toolchain

ToolVersion
ISOLAR-ABv 9.2.1
RTA-RTEv 7.5.3
RTA-BSWv 6.1.3
RTA-OSv 6.2.0

It is also expected you are using RTA-OS VRTA port on version 3.0.46. Other versions may be similar but not the same.

For the workflow section of this guide it will be assumed you are working on the latest version of the standard VRTA starterkit: RTA-SK_VRTA_GCC_Standard_9.2.1_R1.

Prerequisites

It is assumed that the reader has good knowledge of AUTOSAR Methodology and Architecture.

VRTA ISRs Explained

RTA-OS plus the Virtual Target (VRTA) is a complete environment for developing AUTOSAR OS applications that can run on either Windows or Linux machines.

Mostly you’ll use it to prototype a new application before migrating it on to production hardware, but you will also find that it is a good tool for learning how to use RTA-OS to develop applications for embedded targets.

You needn’t stop there though. Because RTA-OS is a complete and fast implementation of AUTOSAR, you can add inter-ECU communication using a standard networking solution such as CAN. You can write applications that sit on your CAN network as test or simulation units. You can remotely monitor the state and progress of your applications using the supplied vrtaMonitor program, or you can write your own monitoring applications that connect directly to the VECU’s virtual devices. And of course the development turnaround time is tiny - just recompile and run. No downloading of hex files to an emulator. No programming flash.

More on the topic of this AN, in a VRTA application there is a simulated interrupt controller. You have the ability to map an interrupt to a priority and to a simulated address. This is a simulated address as when the OS port for the VRTA creates the vector tables it cannot accurately caluclate the actual address in memory the interrupt function call will be at runtime (unlike on a hardware target where this is possible). To get around this for the VRTA port you instead map the an interrupt to a channel and this channel will be used by the OS vector tables to call interrupt's function when the interrupt is raised.

While you are not actually mapping the interrupt to a real address, the functionality of mapping the interrupt to a simulated address is effectively the same as mapping your interrupt to a real address. In this manner you can realistically use the VRTA port to simulate interrupts on a hardware target, in software.

Much more information of how the VRTA Monitor and VRTA OS port works can be found in the documents released with the port.

Workflow Summary

For a simple example of this we will configure a new ISR in the RTA-OS configuration using ISOLAR. The ISR will send a warning to the user when a temperature detected by an external device is too high. We will define this external device as a virtual temerature sensor in a .cpp file in the MCAL. This virtual device will be able to be used with the VRTA monitor to trigger the ISR to simulate sending a warning to the user when the temperature is too high.

  • Step 1. Add a new ISR to your OS configuration.
  • Step 2. Create definition for a virtual device.
  • Step 3. Test triggering the ISR through the VRTA monitor.

Step 1. Add a new ISR to your OS configuration.

Open the VRTA project in ISOLAR. In the ECU navigator select and open the OS configuration in the OS editor:

Limitation of OS Editor

Currently there is a limitation in the OS editor that means you cannot choose which arxml your configuration goes into. Because of this you should use the BSW editor for this step. (To open this right click os.arxml → open with → BSW Editor then click the split files button in the navigation window.)


Then use the OS editor to create a new ISR:

You must configure the ISR; call it anything sensible, set the address to anything that is not already used by any of the other previous ISRs and set the ISR to any priority (IPL_32 is the highest interrupt priority, and IPL_1 is lowest priority interrupt, but even the lowest priority interrupt is still higher priority than any task).

Finally you must add the definition for your ISR in your code in a .cpp file that includes Os.h

ISR
#include "Os.h"
#include "<stdio.h>"

ISR(TempSense_ISR) {
    printf("The interrupt was raised!!!\r\n");
}

Finally regenerate the OS source code.

Step 2. Create definition for a virtual device.

To add a definition of our sensor as a virtual device you can create a .cpp file and add the following code for the definition of our virtual device. We will require:

  • Class for the device, registering its name as a string.
  • Function for getting the devices info.
  • An action and event handler for allowing the user to give the the device a numerical input.
  • A function that will be called when the event is handled.
Virtual Device
#include "virtualDevice.hpp"
#include "Os.h"
 
class MyDevice : public VirtualDevice
{
    public:
        MyDevice(const char *name) {
            RegisterAs(name);
        };
 
    protected:
        unsigned int TheTemperature;
        void GetDeviceInfo(OptList &info)
        {
            info.Add("Type", "MyDevice");
            info.Add("Description", "This is a description of a device.");
            info.Add("Version", "1.0.0");
        }
        void GetDeviceActions(ActionList &actions) {
            ADD_ACTION_HANDLER(MyDevice::DoMyAction);
            actions.Add("SetTemp", "", "").
            In("Temp","Degree of hotness","%u");
 
        }
        void GetDeviceEvents(EventList &events) {
            ADD_EVENT_HANDLER(MyDevice::TemperatureEvent);
            events.Add("Temperature",  "", "Poll").
            Out("Current Temp", "","%u");
        }
 
        vrtaErrType DoMyAction(const vrtaAction &action) {
            vrtaUInt Value;
            UnpackData(action, Value);
            printf("The temperature is now: %d\r\n", Value);
            TheTemperature = (unsigned int)Value;
            if (80 < TheTemperature)
            {
                RaiseInterrupt(OS_ISR_VECTOR_TempSense_ISR);
            }
          return RTVECUErr_NONE;
        }
 
        vrtaErrType TemperatureEvent(vrtaEvent &event) {
            VECU_LOCK();
            PackData(event, TheTemperature, (sizeof(unsigned int)));
            VECU_UNLOCK();
            return RTVECUErr_NONE;
        }
};
 
static MyDevice TheDevice("MySensor");

Step 3. Test triggering the ISR through the VRTA monitor.

Run the VECU by launching RTA-SK_VRTA.exe.

When it has started the following window should appear. From the application tab, select the monitor option (or press ctrl+M) to open the VRTA monitor.

Expand the menu option for the sensor we have configured ("MySensor") and right click the option send and left click the option "Params" to edit the parameter that we will simulate the sensor sending to the ECU.

Enter any integer value between 1-99 then select 'Okay'.

Then send the value of the sensor.

You will be able to see that the value of the sensors temperature is now the value you sent to the device.

Now set the parameter to an integer > 100 and send it again and see that the paramater is updated again and ISR is triggered.