MxV OS API
Please refer to the official OSEK v2.2.3 specification for details about the OS API.
MxV OS provides an ECC2 (with extended error codes) compliant implementation except the GetResource and ReleaseResource API functions.
OIL v2.5 Compiler
An OIL compiler, MxVOIL, is provided to produce an MSVC and MxV compatible header and source file. These source files should be used in place of the target generated OS source files when building for MxV. The .oil file can be recompiled by right-clicking on the .oil file and picking Compile or MSVC can be configured to recompile the .oil with a custom build string as follows:
MxVOIL "$(InputPath)" "$(InputDir)mxvoil.h" "$(InputDir)mxvoil.c"
MxVOS is built on top of the MxVuC simulation library. Please make the appropriate changes to begin using the MxVuC library prior to integrating OSEK.
The OSEK StartOS API function kicks-off MxV OS and begins executing tasks. If the application has its own idle task, this function must invoke MxVuC_Yield(), otherwise MxV OS provides its own idle task and it will yield.
By default, the execution engine does calling context check and throws an error and halts execution if the context is not correct according to http://portal.osek-vdx.org/files/pdf/specs/os223.pdf (Figure 12-1: API service restrictions). For example: calling ActivateTask() service is not allowed from alarm-callback. Most services cannot be called from an alarm callback function.
If your implementation of OSEK ignores those restrictions, you can disable halting on a failed context check by adding the following line to your MxOpen() function in AppIF.c:
MxVuC_Stop_On_Invalid_Context_Error = mxFalse;
Access to MxVuC_Stop_On_Invalid_Context_Error is gained by including uC_core.h, which should be included to access other uC API.
There are several areas that are left unspecified by the OSEK standard, most notably how to increment counters.
The MxV implementation provides the MxVOS_CounterAdvance1() function to increment a counter by 1.
The files generated by the .oil configuration file are also unspecified so some manual effort may be required to stitch the files generated by MxVOIL to the SUT code.
In the OSEK sample project, which is included with the MxSuite installation, there is a 1ms task that runs in parallel with another task. You can use it as an example of how Tasks and Alarms are configured and modify your project accordingly.
There are two different task concepts provided by the OSEK operating system:
Basic tasks only release the processor if
•the OSEK operating system switches to a higher-priority task, or
•an interrupt occurs which causes the processor to switch to an interrupt service routine (ISR).
Extended tasks are distinguished from basic tasks by being allowed to use the operating system call WaitEvent. The waiting state allows the processor to be released and to be reassigned to a lower-priority task without the need to terminate the running extended task.
For more information, refer to chapter 4, "Task management" of the OSEK specification.
Task type and task priority can be assigned as a property for Task in the .oil configuration file. The scheduler decides on the basis of the task priority which is the next of the ready tasks to be transferred into the running state. The value 0 is defined as the lowest priority of a task. Accordingly bigger numbers define higher priorities.
In your project solution you should have an AppIF.c file. Some of the functions below might already exist in your project, so you just need to modify accordingly if some lines are missing.
Create a stub for state change function:
void mxvStateChange(e_ScnState state);
then add these functions where appropriate:
//Call-back for MxVSetScnStateFunction
void mxvStateChange(e_ScnState state)
MxVOpen is called when the project is open. This will configure mxvStateChange function.
When the Scenario is complete, it will call mxvStateChange() which in turn will call SUT_Complete() which will call ShutdownOS() routine.