Chapter 1: Implementation Startup
1.3 OSEK/VDX Implementation Language
OIL provides a method of configuring the objects in an OSEK/VDX implementation for a specific application. The system is configured by using an OIL configuration file that contains the definition of the application. Throughout this book, I will introduce the OIL language as necessary to configure the system up to the current level of discussion. Most OIL files have two parts: that specific to the implementation and that specific to the application. The imple-mentation-specific portion is supplied with the OSEK/VDX implementation and should not be changed. Some implementations, such as OSEKWorks, include this information in the OIL generator file, which simplifies the actual OIL application-specific configuration file. The
ApplicationErrorType ChangeMode(AppModeType mode)
OSEK/VDX Implementation Language
15
application-specific portion of the OIL file is defined by the user during application develop-ment. I will develop an application section for the example in this book.
The method of generating the OIL configuration file varies with each OSEK/VDX imple-mentation and ranges from hand-coding the file to the use of an intuitive GUI (graphical user interface) with context-sensitive help. I strongly recommend purchasing an implementation that includes a GUI unless you enjoy debugging so much that you actually look forward to debugging the OIL file!
The Wind River OSEKWorks GUI is shown in Figure 1.1 as an example. Some of the key features that can be found in other OSEK/VDX GUIs as well are
• a list of OSEK/VDX objects in a Windows Explorer format on the left,
• a graphical and tabular display of attributes for each object on the right (both standard and implementation-specific attributes are shown), and
• a log window on the bottom.
Figure 1.1 OIL setup screen.
The OIL configuration file appears similar to a C structure definition. It consists of objects that correspond to the objects in the OS, with a minimum set of attributes that are defined for each object. An attribute can be required (mandatory) or optional. Because the OIL standard only defines the minimum attributes for each object, an actual OSEK/VDX implementation may define additional attributes. Because these attributes are not portable, they should be
16
Chapter 1: Implementation Startupavoided. A GUI is helpful when porting to a new implementation because undefined attributes are ignored and implementation-specific attributes are readily apparent.
At this point in the development of the application, three objects in the OIL need to be defined:CPU (central processing unit), OS, and APPMODE. The Wind River OIL file also contains two standard objects that are required in all applications. One is the RESOURCE object RES_SCHEDULER, and the other is the COUNTER object SYSTEM_COUNTER. These can be ignored for now; they are discussed later in the appropriate sections.
At least one CPU must be defined in each OIL file. Some implementations allow all applica-tions to be configured in one OIL file if the application consists of multiple identical CPUs with some type of interprocessor communication, such as a Controller Area Network (CAN). List-ing 1.4 shows the application-specific portion of the OIL configuration file for the example.
Listing 1.4 OIL definitions for initial application.
CPU cardgame {
/**************************************************/
/* Tasks */
/**************************************************/
TASK background { TYPE = BASIC;
SCHEDULE = NON;
PRIORITY = 1;
ACTIVATION = 1;
AUTOSTART = TRUE;
STACKSIZE = 64;
SCHEDULE_CALL = FALSE;
};
/**************************************************/
/* Resources */
/**************************************************/
RESOURCE RES_SCHEDULER {
/* No attributes defined */
};
/**************************************************/
/* Counters */
/**************************************************/
COUNTER SYSTEM_COUNTER {
MAXALLOWEDVALUE = 65535;
TICKSPERBASE = 100;
MINCYCLE = 5;
};
OSEK/VDX Implementation Language
17
TheCPU object is defined first in the OIL file and is a container object for all other objects defined for the configuration. In this example, the CPU object is called cardgame because there is only one CPU in this application. The CPU object has no attributes.
Within the cardgame CPU object are five additional objects. The first is a TASK object. Most implementations require that at least one TASK is defined to operate. To compile the program, I defined a do-nothing task that immediately terminates itself. This task is included in main.c and is shown in Listing 1.5. It is probably a good idea to add this task as a sanity check when the system is started. Place a breakpoint at the entrance to this task to verify that the OS has started properly.
Listing 1.5 Startup background task.
The next two objects, RESOURCE and COUNTER, are discussed later. The fourth object is APP-MODE. A system must have at least one APPMODE object, although it usually has many more. At this point in the example, there is only one: SINGLE_PLAYER. Other APPMODEs will be added throughout the book.
/**************************************************/
/* Application Modes */
/**************************************************/
APPMODE SINGLE_PLAYER { VALUE = AUTO;
};
/**************************************************/
/* O/S */
/**************************************************/
OS OSEKWorks_os { CC = AUTO;
STATUS = EXTENDED;
SCHEDULE = AUTO;
SYSTEMSTACKSIZE = 1024;
StartupHook = FALSE;
ErrorHook = FALSE;
ShutdownHook = FALSE;
PreTaskHook = FALSE;
PostTaskHook = FALSE;
};
};
TASK(background) {
TerminateTask();
}
18
Chapter 1: Implementation StartupThe final object, OS, defines the parameters of the OS configuration used on the cardgame processor. Only one OS object can be in each CPU; consequently, I have chosen to leave the name as OSEKWorks_os, which is the default name in the Wind River system. Other implemen-tations will have different default names. Six required attributes are in this object: STATUS, STARTUPHOOK, SHUTDOWNHOOK,PRETASKHOOK,POSTTASKHOOK, and ERRORHOOK.STATUS defines the return status of each OSEK/VDX OS API service and is either STANDARD or EXTENDED. The return status is discussed in more detail in later chapters. The other five attributes define the existence of each of the hook routines within the application and are either TRUE or FALSE. The application provides the hook routines, which are introduced in later chapters. At this time, the OS operates in EXTENDED status and the application does not define any of the hook routines.
The provider of the implementation usually adds many attributes in the OS object. Because each microcontroller has its own quirks, the OS object is the most likely section in which to add attributes that configure the microcontroller-specific features. The added attributes in Wind River OSEKWorks are defined in Table 1.1. Similar attributes can exist in any imple-mentation; unfortunately, a naming standard for these attributes does not exist, so names will likely be different between implementations.