OSEK / VDX. System Generation. OIL: OSEK Implementation Language Version January 23, 2003
|
|
|
- Norman Hill
- 10 years ago
- Views:
Transcription
1 Open Systems and the Corresponding Interfaces for Automotive Electronics OSEK / VDX System Generation OIL: Version January 23, 2003 This document is an official release and replaces all previously distributed documents. The OSEK group retains the right to make changes to this document without notice and does not accept any liability for errors. All rights reserved. No part of this document may be reproduced, in any form or by any means, without permission in writing from the OSEK/VDX steering committee. OSEK/VDX OIL by OSEK Document: OIL241.doc
2 Preface OSEK/VDX is a joint project within the automotive industry. It aims at an industry standard for an open-ended architecture for distributed control units in vehicles. For detailed information about OSEK's project goals and partners, please refer to the OSEK Binding Specification. This document describes the (OIL) concept for the description for the OSEK real-time systems, capable of multitasking and communications, which can be used for motor vehicles. It is not a product description that relates to a specific implementation. General conventions, explanations of terms and abbreviations have been compiled in the additional inter-project "OSEK Overall Glossary", which is part of the OSEK Binding Specification. Note: To simplify matters, the term OSEK is used instead of OSEK/VDX throughout this document. OSEK/VDX OIL by OSEK Page 2
3 Table of contents 1 INTRODUCTION GENERAL REMARKS MOTIVATION LANGUAGE DEFINITION PREAMBLE GENERAL CONCEPT OIL BASICS OIL file structure Syntax OIL versions Implementation definition Application definition Dependencies between attributes Automatic attribute assignment Default values Include mechanism Comments Descriptions OIL OBJECT DEFINITIONS RULES OIL OBJECTS, STANDARD ATTRIBUTES AND REFERENCES CPU OS APPMODE TASK COUNTER ALARM RESOURCE EVENT ISR MESSAGE COM IPDU NM DEFINITION OF A PARTICULAR IMPLEMENTATION ATTRIBUTE TYPES UINT INT UINT INT FLOAT ENUM BOOLEAN STRING REFERENCE TYPES MULTIPLE VALUES EXAMPLE SYNTAX AND DEFAULT DEFINITION SYNTAX OF OIL OSEK/VDX OIL by OSEK Page 3
4 5.2 DEFAULT DEFINITION OF OIL OBJECTS AND STANDARD ATTRIBUTES Subset for internal communication (CCCA and CCCB only) APPENDIX A GENERATOR HINTS APPENDIX B CHANGES IN SPECIFICATIONS APPENDIX C INDEX APPENDIX D HISTORY List of Figures FIGURE 1-1: EXAMPLE OF DEVELOPMENT PROCESS FOR APPLICATIONS (OSEK OS ONLY)... 5 List of Tables TABLE 2-1: POSSIBLE COMBINATIONS OF ATTRIBUTES WITH DEFAULT VALUES FOR ENUM OSEK/VDX OIL by OSEK Page 4
5 1 Introduction 1.1 General remarks This document refers to the OSEK OS Specifications 2.2 and 2.2.x, the OSEK COM Specifications 3.0 and 3.0.x and the OSEK Binding Specification 1.4. For a better understanding of this document, the reader should be familiar with the contents of these other specifications. 1.2 Motivation To reach the goal of OSEK of portable software, a way has been defined to describe the configuration of an application using OSEK. This specification only addresses a single central processing unit (CPU) in an electronic control unit (ECU), not an ECU network. optional OSEK Builder Application configuration file (OIL) C code User s source codecod System Generator (SG) Files produced by SG C code Compiler C code OSEK OS Kernel Make tool Third party tools & related files Linker Object libraries OS components, tools & related files User written/defined Executable file Device driver Figure 1-1: Example of development process for applications (OSEK OS only) OSEK/VDX OIL by OSEK Page 5
6 Figure 1-1 shows an example of a development process for applications. The OIL description may be hand-written or generated by a system configuration tool. Sub-systems delivered in source code are compiled together with the application; others delivered as a library are integrated by the linker. OSEK/VDX OIL by OSEK Page 6
7 2 Language Definition 2.1 Preamble The goal of OIL is to provide a mechanism to configure an OSEK application inside a particular CPU. This means for each CPU there is one OIL description. All OSEK system objects are described using OIL objects. 2.2 General concept The OIL description of the OSEK application is considered to be composed of a set of OIL objects. A CPU is a container for these OIL objects. OIL defines standard types for its objects. Each object is described by a set of attributes and references. OIL defines explicitly all standard attributes for each OIL object. Each OSEK implementation can define additional implementation-specific attributes and references. It is possible only to add attributes to existing OIL objects. Creating new OIL objects, or other changes to the grammar, are not allowed. All non-standard attributes (optional attributes) are considered to be fully implementation-specific and have no standard interpretation. Each OSEK implementation can limit the given set of values for attributes (e.g. restrict the possible value range for priorities). Description of the OIL objects: CPU: OS: APPMODE: ISR: RESOURCE: TASK: COUNTER: EVENT: ALARM: COM: the CPU on which the application runs under the control of OSEK subsystems. the OSEK OS that runs on the CPU. No standard references are defined in OIL from OSEK OS to other OIL objects. defines different modes of operation for the application. No standard attributes are defined for the APPMODE object. interrupt service routines supported by the OS. a resource that can be occupied by a task. a task handled by the OS. a counter represents hardware/software tick source for alarms. an event tasks may react on. an alarm is based on a counter and can either activate a task, set an event or activate an alarm-callback routine. the communication subsystem. The COM object has standard attributes to define general properties for OSEK COM. OSEK/VDX OIL by OSEK Page 7
8 MESSAGE: IPDU: NM: a message is defined in OSEK COM and defines a mechanism for data exchange between different entities (entities being tasks or ISRs) and with other CPUs. an IPDU is defined in OSEK COM. IPDUs carry messages used in external communication. the network management subsystem. 2.3 OIL basics OIL file structure The OIL description contains two parts - one for the definition of standard and implementation-specific features (implementation definition) and another one for the definition of the structure of the application located on the particular CPU (application definition). The OIL description consists of one main OIL file that can refer to included files (see section 2.3.9) Syntax The grammar rules for an OIL file are presented in the document using a notation similar to the Backus-Naur Form (BNF 1 ), see section 5.1. All keywords, attributes, object names, and other identifiers are case-sensitive. Comments in the BNF notation are written as C ++ -style comments OIL versions OIL version "2.0" corresponds to OSEK OS specification 2.0 revision 1. OIL version "2.1" also corresponds to OSEK OS specification 2.0 revision 1. It contains an OIL-internal extension in syntax and semantics. OIL version 2.1 is not compatible with OIL version 2.0. OIL version 2.2 only defines new standard attributes. It is compatible with OIL version NAUR, Peter (ed.), "Revised Report on the Algorithmic Language ALGOL 60.", Communications of the ACM, Vol. 3, No.5, pp , May 1960 or M. Marcotty & H. Ledgard, The World of Programming Languages, Springer-Verlag, Berlin 1986., pages 41 and following. OSEK/VDX OIL by OSEK Page 8
9 OIL version 2.3 corresponds to OSEK OS specification 2.2 and is compatible with OIL version 2.2. OIL version 2.3 only defines new standard attributes. OIL version 2.4 corresponds to OSEK OS specifications 2.2 and 2.2.x and OSEK COM specifications 3.0 and 3.0.x. It is not backwards compatible with OIL version "2.3" in two respects: the ACCESSOR attribute in the TASK and ISR object has been replaced by the MESSAGE attribute, the MESSAGE object has been completely redefined. Two OIL sets of objects and standard attributes are defined: - Full set of objects and standard attributes: OS and full featured COM, supporting the conformance classes: BCC1, BCC2, ECC1, ECC2, CCCA, CCCB, CCC0, CCC1. - Subset of objects and standard attributes: OS with internal communication only, supporting the conformance classes: BCC1, BCC2, ECC1, ECC2, CCCA, CCCB Implementation definition For each OIL object, the implementation definition defines all attributes and their properties for a particular OSEK implementation. The implementation definition must be present in the OIL description and must contain all standard attributes, which are listed in section 3.2. The value range of those attributes may be restricted. Attribute definition is described in chapter 4. Additional attributes and their properties can be defined for the objects for a particular OSEK implementation. Additional attributes are optional. The include mechanism (see section 2.3.1) can be used to define the implementation definition as a separate file. Thus, corresponding implementation definition files can be developed and delivered with particular OSEK implementations and then included with the application definition in user's OIL files. An implementation of OIL must support either all objects and standard attributes or a specific subset defined in section Application definition The application definition comprises a set of objects and the values for their attributes. Except for the OS, COM and NM objects, the application definition can contain more than one OIL object of a particular type. Each object is characterised by a set of attributes and their values. No attribute may appear that is not defined in the implementation definition. Attribute values must comply with the attribute properties specified in the implementation definition. OSEK/VDX OIL by OSEK Page 9
10 Attributes that take a single value may only be specified once per object. Attributes that take a list of values have to be specified as multiple statements. Example for multiple statement: RESOURCE = RES1; RESOURCE = RES2; Dependencies between attributes The OIL Specification allows the expression of dependencies between attributes. To be more open to vendor-specific and standard extensions the OIL syntax includes conditional attributes (parameters). OIL allows infinite nesting of those dependencies. To express dependencies, ENUM and BOOLEAN attributes can be parameterised. If attributes in several sets of one conditional attribute have the same name, they must have the same type Automatic attribute assignment Attribute values may be calculated by the generator. For these attributes, the keyword WITH_AUTO has to be used in the attribute's definition in the implementation definition. In conjunction with WITH_AUTO, the attribute value AUTO is valid in the application definition and as a default value Default values Default values are used by the generator in the case that an attribute is missing in the application definition. Default values are mandatory for optional attributes. Because the syntax of the implementation-specific part requires the definition of default values, a special default value NO_DEFAULT is defined explicitly to suppress the default mechanism. In this case, the attribute must be defined in the application part. Default values are forbidden for standard attributes except if explicitly stated otherwise in the specification. If a default value is allowed for a standard attribute, it is defined in the specification in section 5.2. It is an error if a standard attribute that does not have a default value defined in the implementation definition is missing from the application definition. The OIL grammar uses assignment in the implementation definition to specify default values. All possible combinations of attributes with default values are shown in the following example for ENUM (see Table 2-1). The OIL syntax allows six combinations for the implementation-specific part and three combinations for the application part. OSEK/VDX OIL by OSEK Page 10
11 Implementation part Application part param = A; param = AUTO; // nothing ENUM [A, B, C] param = B; param A ERROR param B ENUM [A, B, C] param = NO_DEFAULT; param A ERROR ERROR ENUM [A, B, C] param = AUTO; ERROR ERROR ERROR ENUM WITH_AUTO [A, B, C] param = B; param A Generatorspecific param B ENUM WITH_AUTO [A, B, C] param = NO_DEFAULT; param A Generatorspecific ERROR ENUM WITH_AUTO [A, B, C] param = AUTO; param A Generatorspecific Generatorspecific Table 2-1: Possible combinations of attributes with default values for ENUM Example: IMPLEMENTATION myos { TASK { UINT32 [1..0xff] STACKSIZE = 16; // If STACKSIZE is missing, // 16 is used as a default Include mechanism The include mechanism allows for separate definitions for some parts of OIL. The implementation definition can be delivered with an OSEK implementation and used (included) by the system designer. The include statement has the same syntax as in ISO/ANSI-C: #include <file> #include "file" For each OIL tool there must be a way to specify search-paths for include files. #include <file> uses the search-path #include "file" uses the directory where the including file resides Placement of include directives The same rules apply as for ISO/ANSI-C, e.g. the include statement has to be on a separate line and can appear anywhere in the description files. OSEK/VDX OIL by OSEK Page 11
12 Comments The OIL file may contain C ++ -style comments (/* */ and //). C ++ rules apply Descriptions To describe OIL objects, attributes, and values, the OIL syntax offers the concept of descriptions. Descriptions are optional. They start after a colon (:), are enclosed in double quotes ("), and must not contain a double quote. Example:... BOOLEAN START = FALSE:"Automatic start of alarm on system start";... Descriptions give the user additional information about OIL objects, attributes and values in a well-defined format. The interpretation of descriptions is implementation-specific. OSEK/VDX OIL by OSEK Page 12
13 3 OIL Object Definitions 3.1 Rules The application configuration files must conform to some rules to be successfully processed. These rules are: All objects are described using the OIL syntax. Each object must have a unique name. Each object may be divided into several parts. All object names must be accessible from the application. An attribute defines some object properties (for example, the task priority). Attributes that take a single value may only be specified once per object. Attributes that take a list of values must be specified as multiple statements. An object can have a set of references to other objects. Per object, there may be more than one reference to the same type of object (e.g. more than one reference to different events, see example in section ). Unless stated otherwise, values must be defined for all standard attributes of all objects, except for multiple attributes, which can be empty. If default values are required for standard attributes, they are specified in this document and must not be changed. The <name> non-terminal represents any ISO/ANSI-C identifier. The <number> non-terminal represents any integer constant. The range of integers is determined by the target platform. Both decimal and hexadecimal integers are allowed, and using the same notation as C. Decimal integers with leading zeroes are not allowed as they might be misinterpreted as octal values. The <string> non-terminal represents any 8-bit character sequence enclosed in doublequotes ("), but not containing double-quotes. The description represents any 8-bit character sequence enclosed in double-quotes ("), but not containing double-quotes. A reference defines a unidirectional link to another object (for example, the task X has to be activated when the alarm Y expires). Implementation-specific additional parameters are only allowed for optional attributes. For portability reasons, it is forbidden to define implementation-specific additional parameters for standard attributes. OSEK/VDX OIL by OSEK Page 13
14 3.2 OIL objects, standard attributes and references For each object, the standard set of attributes and their values is defined. They must be supported by any implementation CPU CPU is used as a container for all other objects OS 2 OS is the object used to define OSEK OS properties for an OSEK application. In a CPU exactly one OS object has to be defined STATUS The STATUS attribute specifies whether a system with standard or extended status has to be used. Automatic assignment is not supported for this attribute. This attribute is of type ENUM and has one of the following possible values: STANDARD EXTENDED Hook routines The following attribute names are defined for the hook routines supported by OSEK OS: STARTUPHOOK ERRORHOOK SHUTDOWNHOOK PRETASKHOOK POSTTASKHOOK These attributes are of type BOOLEAN. If a hook routine is used, the value is set to TRUE otherwise the value is set to FALSE. The usage of the access macros to the service ID and the context-related information in the error hook is enabled by the following attributes of type BOOLEAN: USEGETSERVICEID USEPARAMETERACCESS 2 Attributes for Conformance Class and Scheduling are not defined as these are not part of the OS specification OSEK/VDX OIL by OSEK Page 14
15 USERESSCHEDULER The USERESSCHEDULER attribute is of type BOOLEAN and defines whether the resource RES_SCHEDULER is used within the application Example OS ExampleOS { STATUS = STANDARD; STARTUPHOOK = TRUE; ERRORHOOK = TRUE; SHUTDOWNHOOK = TRUE; PRETASKHOOK = FALSE; POSTTASKHOOK = FALSE; USEGETSERVICEID = FALSE; USEPARAMETERACCESS = FALSE; USERESSCHEDULER = TRUE; APPMODE APPMODE is the object used to define OSEK OS properties for an OSEK OS application mode. No standard attributes are defined for APPMODE. In a CPU, at least one APPMODE object has to be defined TASK TASK objects represent OSEK tasks PRIORITY The priority of a task is defined by the value of the PRIORITY attribute. This value has to be understood as a relative value, i.e. the values of PRIORITY show only the relative ordering of the tasks. This attribute is of type UINT32. OSEK OS defines the lowest priority as zero (0), larger values of the PRIORITY attribute correspond to higher priorities SCHEDULE The SCHEDULE attribute defines the preemptability of the task. This attribute is of type ENUM and has one of the following possible values: NON FULL OSEK/VDX OIL by OSEK Page 15
16 The FULL value of this attribute corresponds to a preemptable task, the NON value to a nonpreemptable task. If the SCHEDULE attribute is set to NON, no internal resources may be assigned to this task ACTIVATION The ACTIVATION attribute defines the maximum number of queued activation requests for the task. A value equal to "1" means that at any time only a single activation is permitted for this task (see OSEK OS specification). This attribute is of type UINT AUTOSTART The AUTOSTART attribute determines whether the task is activated during the system startup procedure or not for some specific application modes. This attribute is of type BOOLEAN. If the task shall be activated during the system start-up, the value is set to TRUE otherwise the value is set to FALSE. When set to TRUE, a list of application modes is defined in the APPMODE sub-attribute of type APPMODE_TYPE. These define in which application modes the task is auto-started RESOURCE The RESOURCE reference is used to define a list of resources accessed by the task. This attribute is a multiple reference (see sections 4.2, 4.3) of type RESOURCE_TYPE EVENT The EVENT reference is used to define a list of events the extended task may react to. This attribute is a multiple reference (see sections 4.2, 4.3) of type EVENT_TYPE MESSAGE The MESSAGE reference is used to define a list of messages accessed by the task. This attribute is a multiple reference (see sections 4.2, 4.3) of type MESSAGE_TYPE Example TASK TaskA { PRIORITY = 2; SCHEDULE = NON; ACTIVATION = 1; AUTOSTART = TRUE { APPMODE = AppMode1; APPMODE = AppMode2; RESOURCE = resource1; RESOURCE = resource2; RESOURCE = resource3; OSEK/VDX OIL by OSEK Page 16
17 EVENT = event1; EVENT = event2; MESSAGE = anymesssage1; COUNTER A COUNTER serves as a base for the ALARM mechanism MAXALLOWEDVALUE The MAXALLOWEDVALUE attribute defines the maximum allowed counter value. This attribute is of type UINT TICKSPERBASE The TICKSPERBASE attribute specifies the number of ticks required to reach a counterspecific unit. The interpretation is implementation-specific. This attribute is of type UINT MINCYCLE The MINCYCLE attribute specifies the minimum allowed number of counter ticks for a cyclic alarm linked to the counter. This attribute is of type UINT Example COUNTER Timer { MINCYCLE = 16; MAXALLOWEDVALUE = 127; TICKSPERBASE = 90; ALARM An ALARM may be used to asynchronously inform or activate a specific task. It is possible to start alarms automatically at system start-up depending on the application mode COUNTER The COUNTER reference defines the counter assigned to this alarm. Only one counter has to be assigned to the alarm. Any alarm has to be assigned to a particular counter. This attribute is a single reference (see section 4.2). OSEK/VDX OIL by OSEK Page 17
18 ACTION The ACTION attribute defines which type of notification is used when the alarm expires. This attribute is a parameterised ENUM with the following possible values: ACTIVATETASK {TASK_TYPE TASK;} SETEVENT {TASK_TYPE TASK; EVENT_TYPE EVENT;} ALARMCALLBACK {STRING ALARMCALLBACKNAME;} For an alarm, only one action is allowed. ACTION = ACTIVATETASK The TASK reference parameter defines the task to be activated when the alarm expires. This parameter is a single reference (see section 4.2) of type TASK_TYPE. ACTION = SETEVENT The TASK reference parameter defines the task for which the event is to be set. The EVENT reference parameter defines the event to be set when the alarm expires. TASK is a single reference of type TASK_TYPE. EVENT is a single reference of type EVENT_TYPE. ACTION = ALARMCALLBACK The ALARMCALLBACKNAME parameter defines the name of the callback routine that is called when the alarm expires AUTOSTART The AUTOSTART attribute of type BOOLEAN defines if an alarm is started automatically at system start-up depending on the application mode. When this attribute is set to TRUE, sub-attributes are used to define the ALARMTIME, i.e. the time when the ALARM shall expire first, the CYCLETIME, i.e. the cycle time of a cyclic ALARM and a list of application modes (APPMODE) for which the AUTOSTART shall be performed. BOOLEAN [ TRUE { UINT32 ALARMTIME; UINT32 CYCLETIME; APPMODE_TYPE APPMODE[]; FALSE ] AUTOSTART; OSEK/VDX OIL by OSEK Page 18
19 Examples ALARM WakeTaskA { COUNTER = Timer; ACTION = SETEVENT { TASK = TaskA; EVENT = event1; AUTOSTART = FALSE; ALARM WakeTaskB { COUNTER = SysCounter; ACTION = ACTIVATETASK { TASK = TaskB; AUTOSTART = TRUE { ALARMTIME = 50; CYCLETIME = 100; APPMODE = AppMode1; APPMODE = AppMode2; ALARM RunCallbackC { COUNTER = SysCounter; ACTION = ALARMCALLBACK { ALARMCALLBACKNAME = "CallbackC"; AUTOSTART = FALSE; RESOURCE A RESOURCE object is used to co-ordinate the concurrent access by tasks and ISRs to a shared resource, e.g. the scheduler, any program sequence, memory or any hardware area. There is one attribute of type ENUM defined to specify the RESOURCEPROPERTY. This attribute can take the following values: STANDARD: A normal resource that is not linked to another resource and is not an internal resource. LINKED: A resource that is linked to another resource with the property STANDARD or LINKED. The resource to which the linking shall be performed is defined by the subattribute LINKEDRESOURCE of type RESOURCE_TYPE. The code generator for the operating system must resolve chains of linked resources. INTERNAL: An internal resource that cannot be accessed by the application Example RESOURCE MsgAccess { RESOURCEPROPERTY = STANDARD; OSEK/VDX OIL by OSEK Page 19
20 3.2.8 EVENT An EVENT object is represented by its mask. The name of the event is a synonym for its mask. The same event may be set for different tasks. Events with the same name are identical, therefore the event mask is identical. Events with the same mask are generally not identical i.e. their names may be different MASK The event mask is an integer number MASK of type UINT64. The other way to assign an event mask is to declare it as AUTO. In this case, one bit is automatically assigned to the event mask. This bit is unique with respect to the tasks that reference the event Examples EVENT event1 { MASK = 0x01; EVENT event2 { MASK = AUTO; In C Code, the user is allowed to combine normal event masks and AUTO event masks. C Code:... WaitEvent ( event1 event2 );... The next example shows the same EVENT object (i.e. with the same name) used by different tasks: EVENT emergency { MASK = AUTO; TASK task1 { EVENT = myevent1; EVENT = emergency; TASK task2 { EVENT = emergency; EVENT = myevent2; TASK task7 { EVENT = emergency; EVENT = myevent2; In C Code, the user is allowed to use the emergency event with all three tasks. C Code:... SetEvent (task1, emergency); SetEvent (task2, emergency); OSEK/VDX OIL by OSEK Page 20
21 SetEvent (task7, emergency);... Another use for the same event name for events of different tasks is in control loops: C Code:... TaskType mylist[] = {task1, task2, task7 int mylistlen = 3; int i=0; for (i=0;i<mylistlen;i++) { SetEvent(myList[i],emergency); } ISR ISR objects represent OSEK interrupt service routines (ISR) CATEGORY The CATEGORY attribute defines the category of the ISR. This attribute is of type UINT32, only values of 1and 2 are allowed RESOURCE The RESOURCE reference is used to define a list of resources accessed by the ISR. This attribute is a multiple reference (see sections 4.2, 4.3) of type RESOURCE_TYPE MESSAGE The MESSAGE reference is used to define a list of messages accessed by the ISR. This attribute is a multiple reference (see sections 4.2, 4.3) of type MESSAGE_TYPE Example ISR TimerInterrupt { CATEGORY = 2; RESOURCE = someresource; MESSAGE= anymessage2; MESSAGE MESSAGE objects represent OSEK messages. The MESSAGE object has three attributes, MESSAGEPROPERTY (see section ), NOTIFICATION (see section ) and NOTIFICATIONERROR (see section ). OSEK/VDX OIL by OSEK Page 21
22 MESSAGEPROPERTY The MESSAGEPROPERTY attribute has the following sub-attributes: MESSAGEPROPERTY Sub-attributes Described in section SEND_STATIC_INTERNAL CDATATYPE SEND_STATIC_EXTERNAL SEND_DYNAMIC_EXTERNAL CDATATYPE TRANSFERPROPERTY IPDU BITPOSITION SIZEINBITS SWAPBYTES FILTER NETWORKORDERCALLOUT CPUORDERCALLOUT INITIALVALUE TRANSFERPROPERTY IPDU BITPOSITION MAXIMUMSIZEINBITS NETWORKORDERCALLOUT CPUORDERCALLOUT INITIALVALUE SEND_ZERO_INTERNAL none none SEND_ZERO_EXTERNAL IPDU NETWORKORDERCALLOUT CPUORDERCALLOUT RECEIVE_ZERO_INTERNAL SENDINGMESSAGE RECEIVE_ZERO_EXTERNAL IPDU OSEK/VDX OIL by OSEK Page 22
23 MESSAGEPROPERTY Sub-attributes Described in section RECEIVE_UNQUEUED_INTERNAL RECEIVE_QUEUED_INTERNAL RECEIVE_UNQUEUED_EXTERNAL RECEIVE_QUEUED_EXTERNAL RECEIVE_DYNAMIC_EXTERNAL RECEIVE_ZERO_SENDERS NETWORKORDERCALLOUT CPUORDERCALLOUT SENDINGMESSAGE FILTER INITIALVALUE SENDINGMESSAGE FILTER QUEUESIZE CDATATYPE FILTER LINK INITIALVALUE CDATATYPE QUEUESIZE FILTER LINK LINK INITIALVALUE CDATATYPE INITIALVALUE A transmit message that is at the same time received internally and transmitted externally is declared as external (using one of the SEND_xx_EXTERNAL properties). Internal receivers of this message refer to it using the SENDINGMESSAGE attribute. The property RECEIVE_ ZERO_SENDERS is used for messages with zero senders. The message attributes are defined in the following CDATATYPE The CDATATYPE attribute describes the data type of the message data using C language types (e.g. int or a structure name). This attribute is of type STRING. OSEK/VDX OIL by OSEK Page 23
24 The purpose of this attribute is the representation of the message in a form that is meaningful to the application TRANSFERPROPERTY The TRANSFERPROPERTY attribute is of type ENUM and describes the action that OSEK COM takes when this message is sent by the application. Possible actions are: TRANSFERPROPERTY = TRIGGERED The IPDU containing the message may or may not be sent immediately depending upon the IPDU s TRANSMISSIONMODE. TRANSFERPROPERTY = PENDING No action is taken IPDU The IPDU reference is used to define the IPDU that carries this MESSAGE BITPOSITION The BITPOSITION attribute is of type UINT32 and specifies the offset from bit 0 of the IPDU to bit 0 of the message. Bit position is calculated as follows: The IPDU is regarded as an unsigned integer of the length of the IPDU. The least significant bit of the IPDU is regarded as bit SIZEINBITS The SIZEINBITS attribute is of type UINT32 and specifies, in bits, the size of a static-length message in an IPDU SWAPBYTES The SWAPBYTES attribute is of type BOOLEAN and specifies whether the bytes of the MESSAGE should be swapped in order to correct for different endianness in the application and network. The default value for SWAPBYTES is FALSE and means that no byte swapping is performed FILTER The FILTER attribute specifies the action of the message filter. This attribute is of type ENUM and has the following values, which are defined in the COM specification. FILTER = ALWAYS This value has no sub-attributes. It is the default value for FILTER. OSEK/VDX OIL by OSEK Page 24
25 FILTER = NEVER This value has no sub-attributes. FILTER = MASKEDNEWEQUALSX This value has the sub-attributes MASK and X. FILTER = MASKEDNEWDIFFERSX This value has the sub-attributes MASK and X. FILTER = NEWISEQUAL This value has no sub-attributes. FILTER = NEWISDIFFERENT This value has no sub-attributes. FILTER = MASKEDNEWEQUALSMASKEDOLD This value has the sub-attribute MASK. FILTER = MASKEDNEWDIFFERSMASKEDOLD This value has the sub-attribute MASK. FILTER = NEWISWITHIN This value has the sub-attributes MIN and MAX. FILTER = NEWISOUTSIDE This value has the sub-attributes MIN and MAX. FILTER = NEWISGREATER This value has no sub-attributes. FILTER = NEWISLESSOREQUAL This value has no sub-attributes. FILTER = NEWISLESS This value has no sub-attributes. FILTER = NEWISGREATEROREQUAL This value has no sub-attributes. FILTER = ONEEVERYN This value has the sub-attributes PERIOD and OFFSET NETWORKORDERCALLOUT The NETWORKORDERCALLOUT attribute defines the name of the network-order callout routine for this MESSAGE. The default value corresponds to no callout specified. This attribute is of type STRING. OSEK/VDX OIL by OSEK Page 25
26 CPUORDERCALLOUT The CPUORDERCALLOUT attribute defines the name of the CPU-order callout routine for this MESSAGE. The default value corresponds to no callout specified. This attribute is of type STRING INITIALVALUE The INITIALVALUE attribute is of type UINT64 and specifies the initial value of a MESSAGE. The default value for INITIALVALUE is MAXIMUMSIZEINBITS The MAXIMUMSIZEINBITS attribute is of type UINT32 and specifies in bits the maximum size that a dynamic message might reach SENDINGMESSAGE The SENDINGMESSAGE attribute is used by a receiver of an internal message to identify the sender of the message. Therefore, this attribute is a reference to a sent message within this OIL file QUEUESIZE The QUEUESIZE attribute is of type UINT32 and defines the maximum number of messages that the queue for a queued message can store LINK The LINK attribute is of type ENUM. It determines whether this message has its own field within the IPDU or fans out from another message's IPDU field. OSEK COM allows a field in a received IPDU to correspond to one or more MESSAGE objects. When the IPDU is received, all the corresponding MESSAGE objects receive the same data. LINK = TRUE When LINK is set to TRUE a sub-attribute called RECEIVEMESSAGE refers to another message that must be received from the network. The link must point to a MESSAGE with LINK set to FALSE. This implies that the field in the IPDU fans out to more than one MESSAGE object. The RECEIVEMESSAGE sub-attribute is a reference to another MESSAGE object. LINK = FALSE When LINK is set to FALSE the sub-attributes IPDU (see section ) and BITPOSITION (see section ) must be defined. The sub-attributes NETWORKORDERCALLOUT (see section ) and CPUORDERCALLOUT (see section ) may be defined. OSEK/VDX OIL by OSEK Page 26
27 In the case of dynamic-length messages, the sub-attribute MAXIMUMSIZEINBITS (see section ) must also be defined. In the case of static-length messages, the sub-attribute SIZEINBITS (see section ) must also be defined, and SWAPBYTES (see section ) may be defined NOTIFICATION and NOTIFICATIONERROR The notification classes are called NOTIFICATION and NOTIFICATIONERROR. Depending on the message property this is either a send or a receive notification. Each notification class is defined as an ENUM with the following values: NONE No notification is performed. This is the default value for NOTIFICATION and NOTIFICATIONERROR. ACTIVATETASK To perform the required notification a task is activated. The task is named by the TASK subattribute, which is a reference to a TASK object. SETEVENT To perform the required notification an event is set for a task. The event and task are named by the EVENT and TASK sub-attributes. The EVENT sub-attribute is a reference to an EVENT object. The TASK sub-attribute is a reference to a TASK object. COMCALLBACK To perform the required notification a callback routine is called. The name of the callback routine is specified in the CALLBACKROUTINENAME sub-attribute. The MESSAGE subattribute must list all the messages that are sent and/or received by this callback routine. FLAG To perform the required notification a FLAG is set. The flag is named using the FLAGNAME sub-attribute, which is of type STRING. INMCALLBACK To perform the required notification a callback routine in an OSEK NM sub-system is called. The name of the callback routine is specified with the CALLBACKROUTINENAME subattribute. The callback routine is called with a parameter specified by the MONITOREDIPDU sub-attribute, which is of type UINT32, but must be within the range 0 to inclusive. MONITOREDIPDU allows the IPDU to be identified to the NM sub-system. Both of these attributes are defined as WITH_AUTO so that the system configuration tool can automatically create values consistent between COM and NM if it is able to. OSEK/VDX OIL by OSEK Page 27
28 Example MESSAGE mymess1 { MESSAGEPROPERTY = SEND_STATIC_EXTERNAL { CDATATYPE = "long"; TRANSFERPROPERTY = PENDING; IPDU = slow_can_traffic; BITPOSITION = 5; SIZEINBITS = 17; FILTER = NEWISWITHIN { MAX = 0x1234; MIN = 0x12; INITIALVALUE = 0x12; NOTIFICATION = FLAG { FLAGNAME = "slow_can_finished"; MESSAGE speed { MESSAGEPROPERTY = RECEIVE_UNQUEUED_EXTERNAL { CDATATYPE = "long"; LINK = FALSE { IPDU = vehicle_data; BITPOSITION = 0; SIZEINBITS = 7; SWAPBYTES = TRUE; NETWORKORDERCALLOUT = "vehicle_data_active"; NOTIFICATION = ACTIVATETASK { TASK = speedo_update; MESSAGE speed_copy { MESSAGEPROPERTY = RECEIVE_UNQUEUED_EXTERNAL { CDATATYPE = "long"; LINK = TRUE { RECEIVEMESSAGE = speed; // size etc. are therefore inherited from the // MESSAGE called speed. MESSAGE water_temperature { MESSAGEPROPERTY = SEND_STATIC_INTERNAL { CDATATYPE = "short"; MESSAGE water_temperature_copy1 { MESSAGEPROPERTY = RECEIVE_UNQUEUED_INTERNAL { SENDINGMESSAGE = water_temperature; FILTER = NEWISWITHIN { MAX = 0x1234; MIN = 0x12; INITIALVALUE = 0x12; OSEK/VDX OIL by OSEK Page 28
29 NOTIFICATION = COMCALLBACK { CALLBACKROUTINENAME = "valid_water_temperature"; MESSAGE = water_temperature_copy1; MESSAGE = speed; MESSAGE water_temperature_copy2 { MESSAGEPROPERTY = RECEIVE_UNQUEUED_INTERNAL { SENDINGMESSAGE = water_temperature; FILTER = NEWISOUTSIDE { MAX = 0x1234; MIN = 0x12; INITIALVALUE = 0x12; NOTIFICATION = COMCALLBACK { CALLBACKROUTINENAME = "invalid_water_temperature"; MESSAGE = water_temperature_copy1; MESSAGE next_radio_station_pushed { MESSAGEPROPERTY = SEND_ZERO_EXTERNAL { IPDU = next_radio_station; MESSAGE next_radio_station_pushed_event { MESSAGEPROPERTY = RECEIVE_ZERO_INTERNAL { SENDINGMESSAGE = next_radio_station_pushed; NOTIFICATION = SETEVENT { TASK = change_radio_station; EVENT = next_station; OSEK/VDX OIL by OSEK Page 29
30 COM COM is the object used to define OSEK COM sub-system properties. In a CPU object, only one COM object can be defined COMTIMEBASE The COMTIMEBASE attribute defines the time base for OSEK COM. This attribute is of type FLOAT. The OSEK COM time base defined by COMTIMEBASE is one second multiplied by the parameter value. Any time that is specified in OSEK COM is multiplied by this time base to arrive at the intended real time. The default value for COMTIMEBASE is 0.001, which is equal to one millisecond Error hook routine The following attributes are defined for the hook routine supported by OSEK COM. These attributes are of type BOOLEAN. The hook routine is used if the value is set to TRUE. The hook routine is not used if the value is set to FALSE. COMERRORHOOK The usage of the access macros to the service ID and the context-related information in the error hook routine is enabled by the following attributes: COMUSEGETSERVICEID COMUSEPARAMETERACCESS The default value for these parameters is FALSE COMSTARTCOMEXTENSION The COMSTARTCOMEXTENSION attribute defines whether the user-supplied function StartCOMExtension is called from the OSEK COM function StartCOM. The function is called if the value is set to TRUE. The function is not called if the value is set to FALSE, which is the default value for this attribute COMAPPMODE The COMAPPMODE attribute lists all COM application modes that are supported. This attribute is of type STRING and can have multiple values COMSTATUS The COMSTATUS attribute defines the level of error checking. This attribute is of type ENUM. Extended error checking is done if the value of COMSTATUS is set to COMEXTENDED. Standard error checking is done if the value of COMSTATUS is set to COMSTANDARD, which is the default value. OSEK/VDX OIL by OSEK Page 30
31 Example COM ExampleCOM { COMTIMEBASE = 0.001; COMERRORHOOK = TRUE; COMUSEGETSERVICEID = FALSE; COMUSEPARAMETERACCESS = FALSE; COMSTARTCOMEXTENSION = FALSE; COMAPPMODE = "COMNormalMode"; COMAPPMODE = "COMDiagnosticMode"; COMSTATUS = COMEXTENDED; IPDU SIZEINBITS The SIZEINBITS attribute specifies the length of an IPDU in bits. This attribute is of type UINT IPDUPROPERTY The IPDUPROPERTY attribute is of type ENUM and describes the direction of the IPDU transfer. Possible values are: SENT RECEIVED TRANSMISSIONMODE The TRANSMISSIONMODE attribute specifies the transmission mode. This attribute is of type ENUM. Possible values are: PERIODIC DIRECT MIXED TRANSMISSIONMODE is a sub-attribute of IPDUPROPERTY = SENT TIMEPERIOD The TIMEPERIOD attribute defines, depending on the chosen transmission mode, the parameter I_TMP_TPD or I_TMM_TPD. This attribute is of type UINT64. The unit of the TIMEPERIOD parameter is multiples of the COM time base. TIMEPERIOD is a sub-attribute of TRANSMISSIONMODE = PERIODIC and TRANSMISSIONMODE = MIXED. OSEK/VDX OIL by OSEK Page 31
32 TIMEOFFSET The TIMEOFFSET attribute defines, depending on the chosen transmission mode, the parameter I_TMP_TOF or I_TMM_TOF. This attribute is of type UINT64. The unit of the TIMEOFFSET parameter is multiples of the COM time base. The value AUTO is the default value for this attribute and means that TIMEOFFSET assumes the same value as TIMEPERIOD. TIMEOFFSET is a sub-attribute of TRANSMISSIONMODE = PERIODIC and TRANSMISSIONMODE = MIXED MINIMUMDELAYTIME The MINIMUMDELAYTIME attribute specifies, depending on the chosen transmission mode, the parameter I_TMD_MDT or I_TMM_MDT. This attribute is of type UINT64. The unit of the MINIMUMDELAYTIME parameter is multiples of the COM time base. The default value for MINIMUMDELAYTIME is 0, which means that no minimum delay time is enforced. MINIMUMDELAYTIME is a sub-attribute of TRANSMISSIONMODE = DIRECT and TRANSMISSIONMODE = MIXED TIMEOUT The TIMEOUT attribute defines, depending on the chosen IPDU property and, if IPDUPROPERTY = SENT, on the chosen transmission mode, the parameter I_DM_RX_TO, I_DM_TMD_TO, I_DM_TMP_TO or I_DM_TMM_TO. This attribute is of type UINT64. The unit of the TIMEOUT parameter is multiples of the COM time base. The notification of an IPDU timeout takes place per message. The default value for TIMEOUT is 0, which is interpreted as no timeout FIRSTTIMEOUT The FIRSTTIMEOUT attribute specifies, if IPDUPROPERTY = RECEIVED, the parameter I_DM_FRX_TO. This attribute is of type UINT64. The unit of the FIRSTTIMEOUT parameter is multiples of the COM time base. The value AUTO is the default value for this attribute and means that FIRSTTIMEOUT assumes the same value as TIMEOUT. FIRSTTIMEOUT is a sub-attribute of IPDUPROPERTY = RECEIVED IPDUCALLOUT The IPDUCALLOUT attribute defines the name of the IPDU callout routine. The default value corresponds to no callout specified. This attribute is of type STRING. OSEK/VDX OIL by OSEK Page 32
33 LAYERUSED The LAYERUSED attribute defines the underlying layer that is used. The default value corresponds to no underlying layer specified. This attribute is of type STRING Example IPDU mysendipdu { SIZEINBITS = 64; IPDUPROPERTY = SENT { TRANSMISSIONMODE = PERIODIC { TIMEPERIOD = 2; TIMEOFFSET = 100; MINIMUMDELAYTIME = 0; TIMEOUT = 250; IPDUCALLOUT = ""; LAYERUSED = "network"; IPDU myreceiveipdu { SIZEINBITS = 64; IPDUPROPERTY = RECEIVED { TIMEOUT = 250; FIRSTTIMEOUT = 100; IPDUCALLOUT = ""; LAYERUSED = "network"; NM NM objects represent the network management sub-system. No standard attributes are defined for the NM object. OSEK/VDX OIL by OSEK Page 33
34 4 Definition of a particular implementation OIL is intended to be used for the description of applications in any OSEK implementation. The implementation definition describes a set of attributes for each object and valid values for these attributes. All standard attributes must be defined here. For standard attributes, the implementation definition can only limit the value range, but in no case extend the value range or change the value type. Optional attributes must specify a default value, AUTO (if defined WITH_AUTO), or NO_DEFAULT. 4.1 Attribute types Any implementation-specific attribute has to be defined before it is used. The attribute type and attribute value range (if it exists) has to be defined. The range of attribute values can be defined in two ways: either the minimum and maximum allowed attribute values are defined (the [0..12] style) or the list of possible attribute values is presented. A mix of both is not allowed. The WITH_AUTO specifier can be combined with any attribute type except for references. If WITH_AUTO is specified the attribute can have the value AUTO and the possibility of automatic assignment by an off-line tool. OIL data types are listed below. Note that these data types are not necessarily the same as the corresponding C data types UINT32 Any unsigned integer number (possibly restricted to a range of numbers, see <impl_attr_def> section 5.1). UINT32 [1..255] NON_SUSPENDED_TASKS; UINT32 [0,2,3,5] FreeInterrupts; UINT32 anumber; This data type allows expressing any 32-bit value in the range of [0..(2 32-1)] INT32 Any signed integer number in the range of [ (2 31-1)] UINT64 Any unsigned integer number in the range [0..(2 64-1)] OSEK/VDX OIL by OSEK Page 34
35 4.1.4 INT64 Any signed integer number in the range [ (2 63-1)] FLOAT Any floating point number according to IEEE-754 standard (Range: +/- 1,176E-38 to +/- 3,402E+38). FLOAT [ ] ClockFrequency; // Clock frequency in MHz ENUM ENUM defines a list of ISO/ANSI-C enumerators. Any enumerator from this list can be assigned to an attribute of the according type. ENUM [NON, FULL] SCHEDULE; ENUM [mon, tue, wed, thu, fri] myweek; ENUM types can be parameterised, i.e. the particular enumerators can have parameters. The parameter specification is denoted in curly braces after the enumerator. Any kind of attribute type is allowed as parameter of an enumerator. ENUM [ ACTIVATETASK {TASK_TYPE TASK; SETEVENT {TASK_TYPE TASK; EVENT_TYPE EVENT;} ] ACTION; BOOLEAN An attribute of this type can take the values TRUE and FALSE. BOOLEAN DontDoIt;... DontDoIt = FALSE; BOOLEAN types can be parameterised, i.e. the particular Boolean values can have parameters. Parameter specifications are denoted in curly braces after an explicit enumeration of the Boolean values. Any kind of attribute type is allowed as parameter of a Boolean value. BOOLEAN [ TRUE {TASK_TYPE TASK; EVENT_TYPE EVENT; FALSE {TASK_TYPE TASK;} ] IsEvent; STRING Any 8-bit character sequence enclosed in double-quotes, but not containing double-quotes, can be assigned to this attribute. OSEK/VDX OIL by OSEK Page 35
36 4.2 Reference Types A reference type is a data type that refers to an OIL object, e.g. to a TASK object, to an EVENT object, to an ALARM object, etc. Reference types can be used to establish links between objects, e.g. within an ALARM object description a reference type attribute can refer to the TASK object that is to be activated by the alarm. The definition of a reference type specifies which type of object is referred to, e.g. the referenced objects are of type TASK, of type EVENT, of type ALARM, etc. The reference type is taken from the referenced object (e.g., a reference to a task shall use the TASK_TYPE keyword as reference type). A reference can refer to any object. A single reference type refers to exactly one object. A definition of a single reference type consists of the object type to be referred followed by the symbolic name of the reference type being defined. 4.3 Multiple values It is possible to use one attribute name to refer to a set of values of the same type. The set may be empty. For example, the EVENT attribute of a TASK object can refer to a set of events. Multiple values are allowed for all types. A definition of a multiple reference type consists of the object type to be referred followed by the symbolic name of the reference type being defined followed by an empty pair of brackets '[]'. Example: EVENT_TYPE MYEVENTS[]; A definition of a multiple attribute is the symbolic name followed by an empty pair of brackets '[]'. Example: INT32 InterruptNumber[]; 4.4 Example The implementation can define some additional attributes for an OIL object or restrict the value range of standard attributes. The example below shows: 1. The limitation of the ENUM value range for the standard OS attribute STATUS. 2. The definition of an implementation-specific attribute NON_SUSPENDED_TASKS of type UINT32 with a value range. 3. The limitation of the UINT32 value range for the standard task attribute PRIORITY. 4. The default value for StackSize is set to 16. OSEK/VDX OIL by OSEK Page 36
37 5. The limitation of the ENUM value range for the standard alarm attribute ACTION. 6. The definition of an implementation-specific attribute START of type BOOLEAN for alarms. 7. The definition of an implementation-specific attribute ITEMTYPE of type STRING for messages. 8. The definition of a reference to MESSAGE objects for ISRs. 9. The possible usage of the defined or modified attributes in the application definition. 10. Separation of the object MyTask1 into two definitions. IMPLEMENTATION SpecialOS { OS { ENUM [EXTENDED] STATUS; UINT32 [1..255] NON_SUSPENDED_TASKS = 16;... TASK { UINT32 [ ] PRIORITY; INT32 StackSize= 16;... // define range of standard // attribute PRIORITY // stacksize in bytes for a task ALARM { ENUM [ACTIVATETASK {TASK_TYPE TASK;}] ACTION; // define possible value(s) of standard attribute ACTION BOOLEAN START = FALSE; // define implementation-specific // attribute START of type BOOLEAN... MESSAGE { STRING ITEMTYPE = "";... // define implementation-specific // attribute ITEMTYPE of type STRING ISR { MESSAGE_TYPE RCV_MESSAGES[] = NO_DEFAULT; // define implementation-specific // attribute RCV_MESSAGES of type // 'multiple reference to objects // of type MESSAGE'... // End IMPLEMENTATION SpecialOS CPU ExampleCPU { OSEK/VDX OIL by OSEK Page 37
38 OS MyOs {... TASK MyTask1 { PRIORITY = 17;... TASK MyTask1 { StackSize = 64;... ALARM MyAlarm1 { ACTION = ACTIVATETASK { TASK = MyTask1; START = TRUE;... MESSAGE MyMsg1 { ITEMTYPE = "SensorData";... MESSAGE MyMsg2 { ITEMTYPE = "Acknowledge";... ISR MyIsr1 { RCV_MESSAGES = MyMsg1; RCV_MESSAGES = MyMsg2;... // End CPU ExampleCPU This example is not a complete OIL file therefore the ellipses represent missing parts. OSEK/VDX OIL by OSEK Page 38
39 5 Syntax and default definition 5.1 Syntax of OIL The OIL file has the following structure: <file> ::= <OIL_version> <implementation_definition> <application_definition> <OIL_version> ::= "OIL_VERSION" "=" <version> <description> ";" <version> ::= <string> <implementation_definition> ::= "IMPLEMENTATION" <name> "{" <implementation_spec_list> "}" <description> ";" <implementation_spec_list> ::= <implementation_spec> <implementation_spec_list> <implementation_spec> <implementation_spec> ::= <object> "{" <implementation_list> "}" <description> ";" <object> ::= "OS" "TASK" "COUNTER" "ALARM" "RESOURCE" "EVENT" "ISR" "MESSAGE" "COM" "NM" "APPMODE" "IPDU" <implementation_list> ::= /* empty list */ <implementation_def> <implementation_list> <implementation_def> <implementation_def> ::= <impl_attr_def> <impl_ref_def> <impl_attr_def> ::= "UINT32" <auto_specifier> <number_range> <attribute_name> OSEK/VDX OIL by OSEK Page 39
40 <multiple_specifier><default_number> <description> ";" "INT32" <auto_specifier> <number_range> <attribute_name> <multiple_specifier> <default_number> <description> ";" "UINT64" <auto_specifier> <number_range> <attribute_name> <multiple_specifier> <default_number> <description> ";" "INT64" <auto_specifier> <number_range> <attribute_name> <multiple_specifier> <default_number> <description> ";" "FLOAT" <auto_specifier> <float_range> <attribute_name> <multiple_specifier> <default_float> <description> ";" "ENUM" <auto_specifier> <enumeration> <attribute_name> <multiple_specifier> <default_name> <description> ";" "STRING" <auto_specifier> <attribute_name> <multiple_specifier> <default_string> <description> ";" "BOOLEAN" <auto_specifier> <bool_values> <attribute_name> <multiple_specifier> <default_bool> <description> ";" <impl_parameter_list> ::= /* empty definition */ "{" <impl_def_list> "}" <impl_def_list> ::= /* empty definition */ <implementation_def> <implementation_def> <impl_def_list> <auto_specifier> ::= /* empty definition */ "WITH_AUTO" <number_range> ::= /* empty definition */ "[" <number> ".." <number> "]" "[" <number_list> "]" <number_list> ::= <number> <number_list> "," <number> <default_number> ::= /* empty definition */ "=" <number> "=" "NO_DEFAULT" "=" "AUTO" OSEK/VDX OIL by OSEK Page 40
41 <description> ::= /* empty definition */ ":" <string> <float_range> ::= /* empty definition */ "[" <float> ".." <float> "]" <default_float> ::= /* empty definition */ "=" <float> "=" "NO_DEFAULT" "=" "AUTO" <enumeration> ::= "[" <enumerator_list> "]" <enumerator_list> ::= <enumerator> <enumerator_list> "," <enumerator> <enumerator> ::= <name> <description> <name> <impl_parameter_list> <description> <bool_values> ::= /* empty definition */ "[" "TRUE" <impl_parameter_list> <description> "," "FALSE" <impl_parameter_list> <description> "]" <default_name> ::= /* empty definition */ "=" <name> "=" "NO_DEFAULT" "=" "AUTO" <default_string> ::= /* empty definition */ "=" <string> "=" "NO_DEFAULT" "=" "AUTO" <default_bool> ::= /* empty definition */ "=" <boolean> "=" "NO_DEFAULT" "=" "AUTO" OSEK/VDX OIL by OSEK Page 41
42 <impl_ref_def> ::= <object_ref_type> <reference_name> <multiple_specifier> <description> ";" <object_ref_type> ::= "OS_TYPE" "TASK_TYPE" "COUNTER_TYPE" "ALARM_TYPE" "RESOURCE_TYPE" "EVENT_TYPE" "ISR_TYPE" "MESSAGE_TYPE" "COM_TYPE" "NM_TYPE" "APPMODE_TYPE" "IPDU_TYPE" <reference_name> ::= <name> <object> <multiple_specifier> ::= /* empty definition */ "[" "]" <application_definition> ::= "CPU" <name> "{" <object_definition_list> "}" <description> ";" <object_definition_list> ::= /* empty definition */ <object_definition> <object_definition_list> <object_definition> <object_definition> ::= <object_name> <description> ";" <object_name> "{" <parameter_list> "}" <description> ";" <object_name> ::= <object> <name> <parameter_list> ::= /* empty definition */ <parameter> <parameter_list> <parameter> <parameter> ::= <attribute_name> "=" <attribute_value> <description> ";" <attribute_name> ::= <name> <object> OSEK/VDX OIL by OSEK Page 42
43 <attribute_value> ::= <name> <name> "{" <parameter_list> "}" <boolean> <boolean> "{" <parameter_list> "}" <number> <float> <string> "AUTO" <name> ::= Name <string> ::= String <boolean> ::= "FALSE" "TRUE" <number> ::= <dec_number> <hex_number> <dec_number> ::= <sign> <int_digits> <sign> ::= /* empty definition */ "+" "-" <int_digits> ::= <zero_digit> <pos_digit> <pos_digit> <dec_digits> <dec_digits> ::= <dec_digit> <dec_digit> <dec_digits> <float> ::= <sign> <dec_digits> "." <dec_digits> <exponent> <exponent> ::= /* empty definition */ OSEK/VDX OIL by OSEK Page 43
44 "e" <sign> <dec_digits> "E" <sign> <dec_digits> <zero_digit> ::= "0" <pos_digit> ::= "1" "2" "3" "4" "5" "6" "7" "8" "9" <dec_digit> ::= <zero_digit> <pos_digit> <hex_number> ::= "0x" <hex_digits> <hex_digits> ::= <hex_digit> <hex_digit> <hex_digits> <hex_digit> ::= "A" "B" "C" "D" "E" "F" "a" "b" "c" "d" "e" "f" "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" OSEK/VDX OIL by OSEK Page 44
45 5.2 Default definition of OIL objects and standard attributes The definition of standard attribute types and parameters can be presented in the following form 3 : IMPLEMENTATION Standard { OS { ENUM [STANDARD, EXTENDED] STATUS; BOOLEAN STARTUPHOOK; BOOLEAN ERRORHOOK; BOOLEAN SHUTDOWNHOOK; BOOLEAN PRETASKHOOK; BOOLEAN POSTTASKHOOK; BOOLEAN USEGETSERVICEID; BOOLEAN USEPARAMETERACCESS; BOOLEAN USERESSCHEDULER = TRUE; APPMODE { TASK { BOOLEAN [ TRUE { APPMODE_TYPE APPMODE[]; FALSE ] AUTOSTART; UINT32 PRIORITY; UINT32 ACTIVATION; ENUM [NON, FULL] SCHEDULE; EVENT_TYPE EVENT[]; RESOURCE_TYPE RESOURCE[]; MESSAGE_TYPE MESSAGE[]; ISR { UINT32 [1, 2] CATEGORY; RESOURCE_TYPE RESOURCE[]; MESSAGE_TYPE MESSAGE[]; COUNTER { UINT32 MINCYCLE; UINT32 MAXALLOWEDVALUE; UINT32 TICKSPERBASE; ALARM { COUNTER_TYPE COUNTER; ENUM [ ACTIVATETASK {TASK_TYPE TASK; SETEVENT {TASK_TYPE TASK; EVENT_TYPE EVENT;} ALARMCALLBACK {STRING ALARMCALLBACKNAME;} ] ACTION; 3 Ordering of the elements is free. OSEK/VDX OIL by OSEK Page 45
46 BOOLEAN [ TRUE { UINT32 ALARMTIME; UINT32 CYCLETIME; APPMODE_TYPE APPMODE[]; FALSE ] AUTOSTART; EVENT { UINT32 WITH_AUTO MASK; RESOURCE { MESSAGE { ENUM [ STANDARD, LINKED { RESOURCE_TYPE LINKEDRESOURCE; INTERNAL ] RESOURCEPROPERTY; ENUM [ SEND_STATIC_INTERNAL { STRING CDATATYPE; SEND_STATIC_EXTERNAL { STRING CDATATYPE; ENUM [ TRIGGERED, PENDING ] TRANSFERPROPERTY; IPDU_TYPE IPDU; UINT32 BITPOSITION; UINT32 SIZEINBITS; BOOLEAN SWAPBYTES = FALSE; ENUM [ ALWAYS, NEVER, MASKEDNEWEQUALSX { UINT64 MASK; UINT64 X; MASKEDNEWDIFFERSX { UINT64 MASK; UINT64 X; NEWISEQUAL, NEWISDIFFERENT, MASKEDNEWEQUALSMASKEDOLD { UINT64 MASK; OSEK/VDX OIL by OSEK Page 46
47 MASKEDNEWDIFFERSMASKEDOLD { UINT64 MASK; NEWISWITHIN { UINT64 MIN; UINT64 MAX; NEWISOUTSIDE { UINT64 MIN; UINT64 MAX; NEWISGREATER, NEWISLESSOREQUAL, NEWISLESS, NEWISGREATEROREQUAL, ONEEVERYN { UINT64 PERIOD; UINT64 OFFSET; } ] FILTER = ALWAYS; STRING NETWORKORDERCALLOUT = ""; STRING CPUORDERCALLOUT = ""; UINT64 INITIALVALUE = 0; SEND_DYNAMIC_EXTERNAL { ENUM [ TRIGGERED, PENDING ] TRANSFERPROPERTY; IPDU_TYPE IPDU; UINT32 BITPOSITION; UINT32 MAXIMUMSIZEINBITS; STRING NETWORKORDERCALLOUT = ""; STRING CPUORDERCALLOUT = ""; UINT64 INITIALVALUE = 0; SEND_ZERO_INTERNAL { SEND_ZERO_EXTERNAL { IPDU_TYPE IPDU; STRING NETWORKORDERCALLOUT = ""; STRING CPUORDERCALLOUT = ""; RECEIVE_ZERO_INTERNAL { MESSAGE_TYPE SENDINGMESSAGE; RECEIVE_ZERO_EXTERNAL { IPDU_TYPE IPDU; STRING NETWORKORDERCALLOUT = ""; STRING CPUORDERCALLOUT = ""; RECEIVE_UNQUEUED_INTERNAL { OSEK/VDX OIL by OSEK Page 47
48 MESSAGE_TYPE SENDINGMESSAGE; ENUM [ ALWAYS, NEVER, MASKEDNEWEQUALSX { UINT64 MASK; UINT64 X; MASKEDNEWDIFFERSX { UINT64 MASK; UINT64 X; NEWISEQUAL, NEWISDIFFERENT, MASKEDNEWEQUALSMASKEDOLD { UINT64 MASK; MASKEDNEWDIFFERSMASKEDOLD { UINT64 MASK; NEWISWITHIN { UINT64 MIN; UINT64 MAX; NEWISOUTSIDE { UINT64 MIN; UINT64 MAX; NEWISGREATER, NEWISLESSOREQUAL, NEWISLESS, NEWISGREATEROREQUAL, ONEEVERYN { UINT64 PERIOD; UINT64 OFFSET; } ] FILTER = ALWAYS; UINT64 INITIALVALUE = 0; RECEIVE_QUEUED_INTERNAL { MESSAGE_TYPE SENDINGMESSAGE; ENUM [ ALWAYS, NEVER, MASKEDNEWEQUALSX { UINT64 MASK; UINT64 X; MASKEDNEWDIFFERSX { UINT64 MASK; UINT64 X; OSEK/VDX OIL by OSEK Page 48
49 }, NEWISEQUAL, NEWISDIFFERENT, MASKEDNEWEQUALSMASKEDOLD { UINT64 MASK; MASKEDNEWDIFFERSMASKEDOLD { UINT64 MASK; NEWISWITHIN { UINT64 MIN; UINT64 MAX; NEWISOUTSIDE { UINT64 MIN; UINT64 MAX; NEWISGREATER, NEWISLESSOREQUAL, NEWISLESS, NEWISGREATEROREQUAL, ONEEVERYN { UINT64 PERIOD; UINT64 OFFSET; } ] FILTER = ALWAYS; UINT32 QUEUESIZE; RECEIVE_UNQUEUED_EXTERNAL { STRING CDATATYPE; ENUM [ ALWAYS, NEVER, MASKEDNEWEQUALSX { UINT64 MASK; UINT64 X; MASKEDNEWDIFFERSX { UINT64 MASK; UINT64 X; NEWISEQUAL, NEWISDIFFERENT, MASKEDNEWEQUALSMASKEDOLD { UINT64 MASK; MASKEDNEWDIFFERSMASKEDOLD { UINT64 MASK; NEWISWITHIN { UINT64 MIN; UINT64 MAX; OSEK/VDX OIL by OSEK Page 49
50 NEWISOUTSIDE { UINT64 MIN; UINT64 MAX; NEWISGREATER, NEWISLESSOREQUAL, NEWISLESS, NEWISGREATEROREQUAL, ONEEVERYN { UINT64 PERIOD; UINT64 OFFSET; } ] FILTER = ALWAYS; BOOLEAN [ TRUE { MESSAGE_TYPE RECEIVEMESSAGE; FALSE { IPDU_TYPE IPDU; UINT32 BITPOSITION; UINT32 SIZEINBITS; BOOLEAN SWAPBYTES = FALSE; STRING NETWORKORDERCALLOUT = ""; STRING CPUORDERCALLOUT = ""; } ] LINK; UINT64 INITIALVALUE = 0; RECEIVE_QUEUED_EXTERNAL { STRING CDATATYPE; UINT32 QUEUESIZE; ENUM [ ALWAYS, NEVER, MASKEDNEWEQUALSX { UINT64 MASK; UINT64 X; MASKEDNEWDIFFERSX { UINT64 MASK; UINT64 X; NEWISEQUAL, NEWISDIFFERENT, MASKEDNEWEQUALSMASKEDOLD { UINT64 MASK; MASKEDNEWDIFFERSMASKEDOLD { UINT64 MASK; NEWISWITHIN { UINT64 MIN; OSEK/VDX OIL by OSEK Page 50
51 UINT64 MAX; NEWISOUTSIDE { UINT64 MIN; UINT64 MAX; NEWISGREATER, NEWISLESSOREQUAL, NEWISLESS, NEWISGREATEROREQUAL, ONEEVERYN { UINT64 PERIOD; UINT64 OFFSET; } ] FILTER = ALWAYS; BOOLEAN [ TRUE { MESSAGE_TYPE RECEIVEMESSAGE; FALSE { IPDU_TYPE IPDU; UINT32 BITPOSITION; UINT32 SIZEINBITS; BOOLEAN SWAPBYTES = FALSE; STRING NETWORKORDERCALLOUT = ""; STRING CPUORDERCALLOUT = ""; } ] LINK; RECEIVE_DYNAMIC_EXTERNAL { BOOLEAN [ TRUE { MESSAGE_TYPE RECEIVEMESSAGE; FALSE { IPDU_TYPE IPDU; UINT32 BITPOSITION; UINT32 MAXIMUMSIZEINBITS; STRING NETWORKORDERCALLOUT = ""; STRING CPUORDERCALLOUT = ""; } ] LINK; UINT64 INITIALVALUE = 0; RECEIVE_ZERO_SENDERS { } STRING CDATATYPE; UINT64 INITIALVALUE = 0; ] MESSAGEPROPERTY; OSEK/VDX OIL by OSEK Page 51
52 ENUM [ NONE, ACTIVATETASK { TASK_TYPE TASK; SETEVENT { TASK_TYPE TASK; EVENT_TYPE EVENT; COMCALLBACK { STRING CALLBACKROUTINENAME; MESSAGE_TYPE MESSAGE[]; FLAG { STRING FLAGNAME; INMCALLBACK { STRING WITH_AUTO CALLBACKROUTINENAME; UINT32 WITH_AUTO MONITOREDIPDU; } ] NOTIFICATION = NONE; ENUM [ NONE, ACTIVATETASK { TASK_TYPE TASK; SETEVENT { TASK_TYPE TASK; EVENT_TYPE EVENT; COMCALLBACK { STRING CALLBACKROUTINENAME; MESSAGE_TYPE MESSAGE[]; FLAG { STRING FLAGNAME; INMCALLBACK { STRING WITH_AUTO CALLBACKROUTINENAME; UINT32 WITH_AUTO MONITOREDIPDU; } ] NOTIFICATIONERROR = NONE; COM { FLOAT COMTIMEBASE = 0.001; BOOLEAN COMERRORHOOK = FALSE; BOOLEAN COMUSEGETSERVICEID = FALSE; BOOLEAN COMUSEPARAMETERACCESS = FALSE; BOOLEAN COMSTARTCOMEXTENSION = FALSE; STRING COMAPPMODE[]; ENUM [ OSEK/VDX OIL by OSEK Page 52
53 COMSTANDARD, COMEXTENDED ] COMSTATUS = COMSTANDARD; IPDU { NM { UINT32 SIZEINBITS; ENUM [ SENT { ENUM [ DIRECT { UINT64 MINIMUMDELAYTIME = 0; PERIODIC { UINT64 TIMEPERIOD; UINT64 WITH_AUTO TIMEOFFSET = AUTO; MIXED { UINT64 TIMEPERIOD; UINT64 WITH_AUTO TIMEOFFSET = AUTO; UINT64 MINIMUMDELAYTIME = 0; } ] TRANSMISSIONMODE; UINT64 TIMEOUT = 0; RECEIVED { UINT64 TIMEOUT = 0; UINT64 WITH_AUTO FIRSTTIMEOUT = AUTO; } ] IPDUPROPERTY; STRING IPDUCALLOUT = ""; STRING LAYERUSED = ""; OSEK/VDX OIL by OSEK Page 53
54 5.2.1 Subset for internal communication (CCCA and CCCB only) This subset is different from the full definition in the following objects: MESSAGE object (changes), COM object (changes), IPDU object (removed). IMPLEMENTATION Standard { OS { ENUM [STANDARD, EXTENDED] STATUS; BOOLEAN STARTUPHOOK; BOOLEAN ERRORHOOK; BOOLEAN SHUTDOWNHOOK; BOOLEAN PRETASKHOOK; BOOLEAN POSTTASKHOOK; BOOLEAN USEGETSERVICEID; BOOLEAN USEPARAMETERACCESS; BOOLEAN USERESSCHEDULER = TRUE; APPMODE { TASK { BOOLEAN [ TRUE { APPMODE_TYPE APPMODE[]; FALSE ] AUTOSTART; UINT32 PRIORITY; UINT32 ACTIVATION; ENUM [NON, FULL] SCHEDULE; EVENT_TYPE EVENT[]; RESOURCE_TYPE RESOURCE[]; MESSAGE_TYPE MESSAGE[]; ISR { UINT32 [1, 2] CATEGORY; RESOURCE_TYPE RESOURCE[]; MESSAGE_TYPE MESSAGE[]; COUNTER { UINT32 MINCYCLE; UINT32 MAXALLOWEDVALUE; UINT32 TICKSPERBASE; ALARM { COUNTER_TYPE COUNTER; OSEK/VDX OIL by OSEK Page 54
55 ENUM [ ACTIVATETASK {TASK_TYPE TASK; SETEVENT {TASK_TYPE TASK; EVENT_TYPE EVENT;} ALARMCALLBACK {STRING ALARMCALLBACKNAME;} ] ACTION; BOOLEAN [ TRUE { UINT32 ALARMTIME; UINT32 CYCLETIME; APPMODE_TYPE APPMODE[]; FALSE ] AUTOSTART; EVENT { UINT32 WITH_AUTO MASK; RESOURCE { MESSAGE { ENUM [ STANDARD, LINKED { RESOURCE_TYPE LINKEDRESOURCE; INTERNAL ] RESOURCEPROPERTY; ENUM [ SEND_STATIC_INTERNAL { STRING CDATATYPE; RECEIVE_UNQUEUED_INTERNAL { MESSAGE_TYPE SENDINGMESSAGE; UINT64 INITIALVALUE = 0; RECEIVE_QUEUED_INTERNAL { MESSAGE_TYPE SENDINGMESSAGE; UINT32 QUEUESIZE; } ] MESSAGEPROPERTY; ENUM [ NONE, ACTIVATETASK { TASK_TYPE TASK; SETEVENT { TASK_TYPE TASK; EVENT_TYPE EVENT; OSEK/VDX OIL by OSEK Page 55
56 COMCALLBACK { STRING CALLBACKROUTINENAME; MESSAGE_TYPE MESSAGE[]; FLAG { STRING FLAGNAME; } ] NOTIFICATION = NONE; COM { NM { BOOLEAN COMERRORHOOK = FALSE; BOOLEAN COMUSEGETSERVICEID = FALSE; BOOLEAN COMUSEPARAMETERACCESS = FALSE; BOOLEAN COMSTARTCOMEXTENSION = FALSE; STRING COMAPPMODE[]; ENUM [ COMSTANDARD, COMEXTENDED ] COMSTATUS = COMSTANDARD; OSEK/VDX OIL by OSEK Page 56
57 Appendix A Generator hints All topics concerning generator hints are not part of the specification. They are recommendations. Generator interface Recommendations for system generator parameters parameter -a for accept unknown attributes (i.e. ignore attributes which are defined in the implementation-specific part of OIL but for which the generator has no rule) parameter -i for include paths parameter -f for command file parameter -r for generating resource statistics parameter -v for version parameter -t for test/verify From the point of view of the user, all implementation-specific switches (of the generator) should be attributes of the matching OIL objects. This would allow the user to place all the implementation-specific information in the OIL file and not into command-line parameters. Resource usage statistics The system generator should provide to the user a breakdown of all system resources used by the application (e.g. number of tasks, priorities,...). Naming convention for OIL files For ease of use, the main OIL file should have the file extension.oil. The extensions for other files that are included in the main OIL file are undefined. OSEK/VDX OIL by OSEK Page 57
58 Appendix B Changes in specifications Changes from specification 1.0/2.0 to 2.1 The specifications 1.0/2.0 were no official versions, so no change description is provided. Changes from specification 2.1 to 2.2 Resources According to the OS specification 2.1, resources may be used in interrupt service routines. A standard attribute to reference a RESOURCE object was added. Messages The OS specification 2.1 refers to OSEK COM as two additional conformance classes for local message handling. Standard attributes for messages were added. References from TASKs and ISRs to messages were added, too. COM The COM object acquired two standard attributes. Additionally it was stated that the COM object may be defined only once. Changes from specification 2.2 to 2.3 The following changes were made to support the new features of the OS specification 2.2. ALARM An AUTOSTART attribute was added to the ALARM object. The ACTION attribute was amended with a third value, ALARMCALLBACK. ISR The ISR category 3 was removed. RESOURCE The RESOURCEPROPERTY attribute was introduced to handle the new concepts of linked and internal resources. TASK The AUTOSTART attribute was modified to support different application modes. OS New attributes USEGETSERVICEID and USEPARAMETERACCESS. OSEK/VDX OIL by OSEK Page 58
59 Changes from specification 2.3 to 2.4 OS object: new attribute USERESSCHEDULER. MESSAGE object: definition of this object was completely re-written. COM object: definition of this object was completely re-written. IPDU object: definition of this object was added. TASK object / ISR object: ACCESSOR attribute was replaced by MESSAGE attribute. The concept of a subset for internal communication was introduced. Default values for standard attributes were introduced. Changes from specification 2.4 to Small error corrections, but no changes in content. OSEK/VDX OIL by OSEK Page 59
60 Appendix C Index ACTION comments 8, 12 definition 18 COMTIMEBASE ACTIVATION definition 30 definition 16 COMUSEGETSERVICEID ALARM definition 30 ACTION 18 COMUSEPARAMETERACCESS COUNTER 17 definition 31 container 7 definition 17 COUNTER description 7 definition 17 EVENT 18 description 7 TASK 18 MAXALLOWEDVALUE 17 ALARMCALLBACK 18 ALARMTIME 18 MINCYCLE 17 application definition 8 TICKSPERBASE 17 APPMODE 7, 15, 16, 18 CPU definition 15 definition 14 attribute description 7 definition 13 CPUORDERCALLOUT type 34 definition 26 value range 34 attributes CYCLETIME 18 description non-standard 9 definition 13 AUTOSTART 18 EVENT definition 16 definition 16, 18, 20 BITPOSITION description 7 definition 24 MASK 20 case-sensitive 8 FILTER CATEGORY definition 24 definition 21 FIRSTTIMEOUT CDATATYPE definition 32 definition 23 grammar rules 8 COM implementation definition 8, 9 definition 30 INITIALVALUE description 7 definition 26 example 31 INMCALLBACK definition 27 hook routines 30 INTERNAL 19 COMERRORHOOK IPDU definition 30 description 8, 31 OSEK/VDX OIL by OSEK Page 60
61 example 33 NOTIFICATIONRX reference 24 description 27 IPDUCALLOUT NOTIFICATIONRXERROR definition 32 description 27 IPDUPROPERTY ISR NOTIFICATIONTX definition 31 description 27 NOTIFICATIONTXERROR CATEGORY 21 description 27 definition 21 number description 7 definition 13 RESOURCE 21 OIL LAYERUSED version 8 definition 33 OS 7 LINK definition 14, 30 definition 26 PRIORITY LINKED 19 definition 15 MASK QUEUESIZE definition 20 definition 26 MAXALLOWEDVALUE reference definition 17 definition 13 MAXIMUMSIZE RESOURCE definition 26 definition 16, 19, 21 MESSAGE description 7 definition 21 RESOURCEPROPERTY 19 description 8 SCHEDULE definition 15 example 28 SENDING_MESSAGE properties 22 definition 26 reference 16, 21 SIZE MINCYCLE definition 24 definition 17 SIZE (of IPDU) MINIMUMDELAYTIME definition 31 definition 32 STATUS name definition 14 definition 13 string NETWORKORDERCALLOUT definition 13 definition 25 SWAPBYTES NM definition 24 definition 33 TASK description 8 ACTIVATION 16 notification classes AUTOSTART 16 description 27 OSEK/VDX OIL by OSEK Page 61
62 definition 15, 18 TIMEOUT description 7 definition 32 EVENT 16 TIMEPERIOD PRIORITY 15 definition 31 RESOURCE 16 TRANSFERPROPERTY definition 24 SCHEDULE 15 TRANSMISSIONMODE TICKSPERBASE definition 31 definition 17 USEGETSERVICEID 14 TIMEOFFSET USEPARAMETERACCESS 15 definition 32 OSEK/VDX OIL by OSEK Page 62
63 Appendix D History Version Date Authors 2.0 December 16, June 30, July 4, August 28, December 2, January 23, 2003 Jürgen Aminger Vladimir Belov Jürgen Betzelt Volker Ebner Bob France Gerhard Göser Martin Huber Adam Jankowiak Winfried Janz Helmar Kuder Ansgar Maisch Rainer Müller Salvatore Parisi Jochem Spohr Stephan Steinhauer Karl Westerholz Andree Zahir Michael Barbehenn Irina Bratanova Manfred Geischeder Gerhard Göser Andrea Hauth Adam Jankowiak Winfried Janz Helmar Kuder Stefan Schimpf Markus Schwab Carsten Thierer Hans-Christian Wense Andree Zahir Irina Bratanova Manfred Geischedder Peter Großhans Hartmut Hörner Winfried Janz Walter Koch Reiner Kriesten Jochem Spohr OS working group Oliver Bremicker Alexander Burst Hartmut Hörner Robert Hugel Winfried Janz Simone Kriso Thomas Lutz Christophe Marchand Gary Morgan Maurice Mücke Sven-Oliver Schneele Jochem Spohr Maxim Tchervinsky Oliver Bremicker Gary Morgan Jochem Spohr IBM GmbH Motorola SPRL Daimler-Benz AG Vector Informatik Motorola SPS Siemens Automotive SA Daimler-Benz AG Daimler-Benz AG Vector Informatik Daimler-Benz AG University of Karlsruhe IBM GmbH Centro Ricerche Fiat ATM Computer GmbH Daimler-Benz AG Siemens Semiconductors ETAS GmbH & Co. KG Motorola Motorola BMW Siemens Automotive 3Soft DaimlerChrysler Vector Informatik DaimlerChrysler ETAS Infineon University of Karlsruhe Motorola ETAS Motorola BMW IMH Vector Vector Siemens IIIT, Uni Karlsruhe IMH ISO SiemensVDO Automotive ETAS Vector Informatik Bosch Vector ETAS SiemensVDO Automotive PSA Peugeot Citroën LiveDevices Volkswagen BMW IMH Motorola SiemensVDO Automotive LiveDevices IMH OSEK/VDX OIL 2.3 by OSEK Page 63
OSEK / VDX. System Generation. OIL: OSEK Implementation Language Version 2.5. Open Systems and the Corresponding Interfaces for Automotive Electronics
Open Systems and the Corresponding Interfaces for Automotive Electronics OSEK / VDX System Generation OIL: Version 2.5 July 1, 2004 This document is an official release and replaces all previously distributed
OSEK/VDX. Operating System. Version 2.2.3. February 17 th, 2005
OSEK/VDX Version 2.2.3 February 17 th, 2005 This document is an official release and replaces all previously distributed documents. The OSEK group retains the right to make changes to this document without
Servo Motor API nxt_motor_get_count nxt_motor_set_count nxt_motor_set_speed
Servo Motor API int nxt_motor_get_count(u32 n) gets Servo Motor revolution count in degree. n: NXT_PORT_A, NXT_PORT_B, NXT_PORT_C Servo Motors revolution in degree void nxt_motor_set_count(u32 n, int count)
The programming language C. sws1 1
The programming language C sws1 1 The programming language C invented by Dennis Ritchie in early 1970s who used it to write the first Hello World program C was used to write UNIX Standardised as K&C (Kernighan
Embedded OS. Product Information
Product Information Table of Contents 1 Operating Systems for ECUs... 3 2 MICROSAR.OS The Real-Time Operating System for the AUTOSAR Standard... 3 2.1 Overview of Advantages... 3 2.2 Properties... 4 2.3
Pemrograman Dasar. Basic Elements Of Java
Pemrograman Dasar Basic Elements Of Java Compiling and Running a Java Application 2 Portable Java Application 3 Java Platform Platform: hardware or software environment in which a program runs. Oracle
Trampoline OSEK-VDX & AUTOSAR Compliant Open Source Real-Time Operating System
Trampoline OSEK-VDX & AUTOSAR Compliant Open Source Real-Time Operating System Jean-Luc Béchennec, Mikaël Briday, Sylvain Cotard, Sébastien Faucou, Yvon Trinquet Journée ACTRISS Outils. November 7, 2012
Motorola 8- and 16-bit Embedded Application Binary Interface (M8/16EABI)
Motorola 8- and 16-bit Embedded Application Binary Interface (M8/16EABI) SYSTEM V APPLICATION BINARY INTERFACE Motorola M68HC05, M68HC08, M68HC11, M68HC12, and M68HC16 Processors Supplement Version 2.0
GETTING STARTED WITH LABVIEW POINT-BY-POINT VIS
USER GUIDE GETTING STARTED WITH LABVIEW POINT-BY-POINT VIS Contents Using the LabVIEW Point-By-Point VI Libraries... 2 Initializing Point-By-Point VIs... 3 Frequently Asked Questions... 5 What Are the
Remote Access Server - Dial-Out User s Guide
Remote Access Server - Dial-Out User s Guide 95-2345-05 Copyrights IBM is the registered trademark of International Business Machines Corporation. Microsoft, MS-DOS and Windows are registered trademarks
Export of audit trail events from Salto software. Version 2.0
Export of audit trail events from Salto software Version 2.0 Historic of changes Version Status Date Author Change description 1.0 Stable 20/12/2011 Mikel Larreategi First version of the specs. 2.0 Stable
Operating System Manual. Realtime Communication System for netx. Kernel API Function Reference. www.hilscher.com.
Operating System Manual Realtime Communication System for netx Kernel API Function Reference Language: English www.hilscher.com rcx - Kernel API Function Reference 2 Copyright Information Copyright 2005-2007
BTF-Specification. Version History. Version Author Datum Description
BTF-Specification Version History Version Author Datum Description V1.0 [Timing-Architects] 2011-07-18 Initial specification approved with thanks by Continental Automotive GmbH, extended by source-entity-instance
73M1866B/73M1966B FXOCTL Application User Guide November 2, 2009 Rev. 4.1 UG_1x66B_009
Simplifying System Integration TM 73M1866B/73M1966B FXOCTL Application User Guide November 2, 2009 Rev. 4.1 73M1866B/73M1966B FXOCTL Application User Guide 2009 Teridian Semiconductor Corporation. All
EE8205: Embedded Computer System Electrical and Computer Engineering, Ryerson University. Multitasking ARM-Applications with uvision and RTX
EE8205: Embedded Computer System Electrical and Computer Engineering, Ryerson University Multitasking ARM-Applications with uvision and RTX 1. Objectives The purpose of this lab is to lab is to introduce
SD Specifications Part A2 SD Host Controller Simplified Specification
SD Specifications Part A2 SD Host Controller Simplified Specification Version 2.00 February 8, 2007 Technical Committee SD Association Revision History Date Version Changes compared to previous issue April
Core Components Data Type Catalogue Version 3.1 17 October 2011
Core Components Data Type Catalogue Version 3.1 17 October 2011 Core Components Data Type Catalogue Version 3.1 Page 1 of 121 Abstract CCTS 3.0 defines the rules for developing Core Data Types and Business
NAND Flash Memories. Using Linux MTD compatible mode. on ELNEC Universal Device Programmers. (Quick Guide)
NAND Flash Memories Using Linux MTD compatible mode on ELNEC Universal Device Programmers (Quick Guide) Application Note April 2012 an_elnec_linux_mtd, version 1.04 Version 1.04/04.2012 Page 1 of 16 As
AKD EtherNet/IP Communication
AKD EtherNet/IP Communication Edition August 2012, Revision C Valid for firmware version 1.7 Patents Pending Part Number 903-200008-00 Keep all manuals as a product component during the life span of the
INTERNATIONAL TELECOMMUNICATION UNION
INTERNATIONAL TELECOMMUNICATION UNION ITU-T X.690 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (07/2002) SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI networking and system aspects Abstract
Syslog Windows Tool Set (WTS) Configuration File Directives And Help
orrelog Syslog Windows Tool Set (WTS) Configuration File Directives And Help The CO-sysmsg.cnf file contains all the parameters and specifications related to the program s operation. This file is found
CANnes PC CAN Interface Manual
CANnes PC CAN Interface Manual Version: 1.21 October 1 st, 2004 D 20375 Hamburg, Germany Phone +49-40-51 48 06 0 FAX: +49-40-51 48 06 60 2 CANnes Card Manual V1.21 Version Version Date Author Comment 1.00
CSI 333 Lecture 1 Number Systems
CSI 333 Lecture 1 Number Systems 1 1 / 23 Basics of Number Systems Ref: Appendix C of Deitel & Deitel. Weighted Positional Notation: 192 = 2 10 0 + 9 10 1 + 1 10 2 General: Digit sequence : d n 1 d n 2...
RTI Database Integration Service. Release Notes
RTI Database Integration Service Release Notes Version 5.2.0 2015 Real-Time Innovations, Inc. All rights reserved. Printed in U.S.A. First printing. June 2015. Trademarks Real-Time Innovations, RTI, NDDS,
STORM. Simulation TOol for Real-time Multiprocessor scheduling. Designer Guide V3.3.1 September 2009
STORM Simulation TOol for Real-time Multiprocessor scheduling Designer Guide V3.3.1 September 2009 Richard Urunuela, Anne-Marie Déplanche, Yvon Trinquet This work is part of the project PHERMA supported
Bachelors of Computer Application Programming Principle & Algorithm (BCA-S102T)
Unit- I Introduction to c Language: C is a general-purpose computer programming language developed between 1969 and 1973 by Dennis Ritchie at the Bell Telephone Laboratories for use with the Unix operating
Audit Trail Administration
Audit Trail Administration 0890431-030 August 2003 Copyright 2003 by Concurrent Computer Corporation. All rights reserved. This publication or any part thereof is intended for use with Concurrent Computer
Origins of Operating Systems OS/360. Martin Grund HPI
Origins of Operating Systems OS/360 HPI Table of Contents IBM System 360 Functional Structure of OS/360 Virtual Machine Time Sharing 2 Welcome to Big Blue 3 IBM System 360 In 1964 IBM announced the IBM-360
Informatica e Sistemi in Tempo Reale
Informatica e Sistemi in Tempo Reale Introduction to C programming Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa October 25, 2010 G. Lipari (Scuola Superiore Sant Anna)
Chapter 7D The Java Virtual Machine
This sub chapter discusses another architecture, that of the JVM (Java Virtual Machine). In general, a VM (Virtual Machine) is a hypothetical machine (implemented in either hardware or software) that directly
13. Publishing Component Information to Embedded Software
February 2011 NII52018-10.1.0 13. Publishing Component Information to Embedded Software NII52018-10.1.0 This document describes how to publish SOPC Builder component information for embedded software tools.
Keil C51 Cross Compiler
Keil C51 Cross Compiler ANSI C Compiler Generates fast compact code for the 8051 and it s derivatives Advantages of C over Assembler Do not need to know the microcontroller instruction set Register allocation
SYSTEM ecos Embedded Configurable Operating System
BELONGS TO THE CYGNUS SOLUTIONS founded about 1989 initiative connected with an idea of free software ( commercial support for the free software ). Recently merged with RedHat. CYGNUS was also the original
Implementation Guide. SAS Serial Protocol. for. Montana Department of Justice Gambling Control Division. October 22, 2012. Version 1.4.
Implementation Guide for SAS Serial Protocol Montana Department of Justice Gambling Control Division October 22, 2012 Version 1.4.1 Montana SAS Implementation Guide Page 2 Table of Contents 1 Introduction...
Freescale Semiconductor, I
nc. Application Note 6/2002 8-Bit Software Development Kit By Jiri Ryba Introduction 8-Bit SDK Overview This application note describes the features and advantages of the 8-bit SDK (software development
Moven Studio realtime. streaming
Moven Studio realtime network streaming UDP protocol specification Document MV0305P Revision B, 19 December 2007 Xsens Technologies B.V. phone +31 88 XSENS 00 Pantheon 6a +31 88 97367 00 P.O. Box 559 fax
Applies to Version 6 Release 5 X12.6 Application Control Structure
Applies to Version 6 Release 5 X12.6 Application Control Structure ASC X12C/2012-xx Copyright 2012, Data Interchange Standards Association on behalf of ASC X12. Format 2012 Washington Publishing Company.
Alternate Representations of the Public Key Cryptography Standards (PKCS) Using S-Expressions, S-PKCS
Alternate Representations of the Public Key Cryptography Standards (PKCS Using S-Expressions, S-PKCS Matthew D. Wood Carl M. Ellison Intel Security Technology Lab Alternate Representations of the Public
GCE Computing. COMP3 Problem Solving, Programming, Operating Systems, Databases and Networking Report on the Examination.
GCE Computing COMP3 Problem Solving, Programming, Operating Systems, Databases and Networking Report on the Examination 2510 Summer 2014 Version: 1.0 Further copies of this Report are available from aqa.org.uk
Simple Cooperative Scheduler for Arduino ARM & AVR. Aka «SCoop»
Simple Cooperative Scheduler for Arduino ARM & AVR Aka «SCoop» Introduction Yet another library This library aims to provide a light and simple environment for creating powerful multi-threaded programs
Postgres Plus xdb Replication Server with Multi-Master User s Guide
Postgres Plus xdb Replication Server with Multi-Master User s Guide Postgres Plus xdb Replication Server with Multi-Master build 57 August 22, 2012 , Version 5.0 by EnterpriseDB Corporation Copyright 2012
10.04.2008. Thomas Fahrig Senior Developer Hypervisor Team. Hypervisor Architecture Terminology Goals Basics Details
Thomas Fahrig Senior Developer Hypervisor Team Hypervisor Architecture Terminology Goals Basics Details Scheduling Interval External Interrupt Handling Reserves, Weights and Caps Context Switch Waiting
Embedded Event Manager Commands
This module describes the commands that are used to set the Embedded Event Manager (EEM) operational attributes and monitor EEM operations. The Cisco IOS XR software EEM functions as the central clearing
Data Link Layer(1) Principal service: Transferring data from the network layer of the source machine to the one of the destination machine
Data Link Layer(1) Principal service: Transferring data from the network layer of the source machine to the one of the destination machine Virtual communication versus actual communication: Specific functions
Exceptions in MIPS. know the exception mechanism in MIPS be able to write a simple exception handler for a MIPS machine
7 Objectives After completing this lab you will: know the exception mechanism in MIPS be able to write a simple exception handler for a MIPS machine Introduction Branches and jumps provide ways to change
Operating Systems. Lecture 03. February 11, 2013
Operating Systems Lecture 03 February 11, 2013 Goals for Today Interrupts, traps and signals Hardware Protection System Calls Interrupts, Traps, and Signals The occurrence of an event is usually signaled
Linux Scheduler. Linux Scheduler
or or Affinity Basic Interactive es 1 / 40 Reality... or or Affinity Basic Interactive es The Linux scheduler tries to be very efficient To do that, it uses some complex data structures Some of what it
TSX ETY 110 Module 8
Module 8 Introduction Subject of this chapter What s in this Chapter? This chapter describes the implementation of a TSX ETY 110 module. This chapter contains the following sections: Section Topic Page
The Answer to the 14 Most Frequently Asked Modbus Questions
Modbus Frequently Asked Questions WP-34-REV0-0609-1/7 The Answer to the 14 Most Frequently Asked Modbus Questions Exactly what is Modbus? Modbus is an open serial communications protocol widely used in
Real Time Programming: Concepts
Real Time Programming: Concepts Radek Pelánek Plan at first we will study basic concepts related to real time programming then we will have a look at specific programming languages and study how they realize
Field Properties Quick Reference
Field Properties Quick Reference Data types The following table provides a list of the available data types in Microsoft Office Access 2007, along with usage guidelines and storage capacities for each
Instruction Set Architecture (ISA)
Instruction Set Architecture (ISA) * Instruction set architecture of a machine fills the semantic gap between the user and the machine. * ISA serves as the starting point for the design of a new machine
Programming Languages CIS 443
Course Objectives Programming Languages CIS 443 0.1 Lexical analysis Syntax Semantics Functional programming Variable lifetime and scoping Parameter passing Object-oriented programming Continuations Exception
Embedded Programming in C/C++: Lesson-1: Programming Elements and Programming in C
Embedded Programming in C/C++: Lesson-1: Programming Elements and Programming in C 1 An essential part of any embedded system design Programming 2 Programming in Assembly or HLL Processor and memory-sensitive
ARM Thumb Microcontrollers. Application Note. Software ISO 7816 I/O Line Implementation. Features. Introduction
Software ISO 7816 I/O Line Implementation Features ISO 7816-3 compliant (direct convention) Byte reception and transmission with parity check Retransmission on error detection Automatic reception at the
GE PACS Conformance Statement for DICOM v3.0
g GE Medical Systems Technical Publications IIS P/N 4361668 Revision 01 GE PACS Conformance Statement for DICOM v3.0 Copyright 1998 By General Electric Company g GE Medical Systems GE Medical Systems,
RTI Real-Time Connect. Release Notes
RTI Real-Time Connect Release Notes Version 4.5f 2012 Real-Time Innovations, Inc. All rights reserved. Printed in U.S.A. First printing. March 2012. Trademarks Real-Time Innovations, RTI, and Connext are
Software Development for Multiple OEMs Using Tool Configured Middleware for CAN Communication
01PC-422 Software Development for Multiple OEMs Using Tool Configured Middleware for CAN Communication Pascal Jost IAS, University of Stuttgart, Germany Stephan Hoffmann Vector CANtech Inc., USA Copyright
Appendix B RCS11 Remote Communications
Appendix B RCS11 Remote Communications B.1 Host Computer Remote Communications Control and status messages are conveyed between the RCS11 and the host computer using packetized message blocks in accordance
How To Port A Program To Dynamic C (C) (C-Based) (Program) (For A Non Portable Program) (Un Portable) (Permanent) (Non Portable) C-Based (Programs) (Powerpoint)
TN203 Porting a Program to Dynamic C Introduction Dynamic C has a number of improvements and differences compared to many other C compiler systems. This application note gives instructions and suggestions
COMP 356 Programming Language Structures Notes for Chapter 4 of Concepts of Programming Languages Scanning and Parsing
COMP 356 Programming Language Structures Notes for Chapter 4 of Concepts of Programming Languages Scanning and Parsing The scanner (or lexical analyzer) of a compiler processes the source program, recognizing
Gigabit Ethernet Packet Capture. User s Guide
Gigabit Ethernet Packet Capture User s Guide Copyrights Copyright 2008 CACE Technologies, Inc. All rights reserved. This document may not, in whole or part, be: copied; photocopied; reproduced; translated;
Embedded Software Development with MPS
Embedded Software Development with MPS Markus Voelter independent/itemis The Limitations of C and Modeling Tools Embedded software is usually implemented in C. The language is relatively close to the hardware,
The Bus (PCI and PCI-Express)
4 Jan, 2008 The Bus (PCI and PCI-Express) The CPU, memory, disks, and all the other devices in a computer have to be able to communicate and exchange data. The technology that connects them is called the
Numbering Systems. InThisAppendix...
G InThisAppendix... Introduction Binary Numbering System Hexadecimal Numbering System Octal Numbering System Binary Coded Decimal (BCD) Numbering System Real (Floating Point) Numbering System BCD/Binary/Decimal/Hex/Octal
Useful Number Systems
Useful Number Systems Decimal Base = 10 Digit Set = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9} Binary Base = 2 Digit Set = {0, 1} Octal Base = 8 = 2 3 Digit Set = {0, 1, 2, 3, 4, 5, 6, 7} Hexadecimal Base = 16 = 2
Object Oriented Software Design
Object Oriented Software Design Introduction to Java - II Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa September 14, 2011 G. Lipari (Scuola Superiore Sant Anna) Introduction
A304a: Understanding User Needs for Field Management Stations Part 1 Object Definitions for Signal System Masters (SSM) Based on NTCIP 1210 Standard
A304a: Understanding User Needs for Field Management Stations Part 1 Object Definitions for Signal System Masters (SSM) Based on NTCIP 1210 Standard Table of Contents Introduction/Purpose... 2 SSM User
AN1229. Class B Safety Software Library for PIC MCUs and dspic DSCs OVERVIEW OF THE IEC 60730 STANDARD INTRODUCTION
Class B Safety Software Library for PIC MCUs and dspic DSCs AN1229 Authors: Veena Kudva & Adrian Aur Microchip Technology Inc. OVERVIEW OF THE IEC 60730 STANDARD INTRODUCTION This application note describes
Scanning Comparator (ScanComp) Features. General Description. Input/Output Connections. When to Use a Scanning Comparator. clock - Digital Input* 1.
Scanning Comparator (ScanComp) 1.0 Features Scan up to 64 single ended or differential channels automatically Note The number of input and output channels will be limited by the hardware available in the
www.novell.com/documentation Jobs Guide Identity Manager 4.0.1 February 10, 2012
www.novell.com/documentation Jobs Guide Identity Manager 4.0.1 February 10, 2012 Legal Notices Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation,
What is new in syslog-ng Premium Edition 4 F1
What is new in syslog-ng Premium Edition 4 F1 August 26, 2011 Copyright 1996-2011 BalaBit IT Security Ltd. Table of Contents 1. Preface... 3 2. New module architecture... 4 3. Multithreading, scaling,
Binary storage of graphs and related data
EÖTVÖS LORÁND UNIVERSITY Faculty of Informatics Department of Algorithms and their Applications Binary storage of graphs and related data BSc thesis Author: Frantisek Csajka full-time student Informatics
ASSEMBLY PROGRAMMING ON A VIRTUAL COMPUTER
ASSEMBLY PROGRAMMING ON A VIRTUAL COMPUTER Pierre A. von Kaenel Mathematics and Computer Science Department Skidmore College Saratoga Springs, NY 12866 (518) 580-5292 [email protected] ABSTRACT This paper
The information in this document will be common for all X12N implementation guides.
ASC X12N Implementation Guide Common Content The information in this document will be common for all X12N implementation guides. Underlined information will be replaced with publisher-inserted implementation
1 External Model Access
1 External Model Access Function List The EMA package contains the following functions. Ema_Init() on page MFA-1-110 Ema_Model_Attr_Add() on page MFA-1-114 Ema_Model_Attr_Get() on page MFA-1-115 Ema_Model_Attr_Nth()
Embedded Systems. Review of ANSI C Topics. A Review of ANSI C and Considerations for Embedded C Programming. Basic features of C
Embedded Systems A Review of ANSI C and Considerations for Embedded C Programming Dr. Jeff Jackson Lecture 2-1 Review of ANSI C Topics Basic features of C C fundamentals Basic data types Expressions Selection
2 ASCII TABLE (DOS) 3 ASCII TABLE (Window)
1 ASCII TABLE 2 ASCII TABLE (DOS) 3 ASCII TABLE (Window) 4 Keyboard Codes The Diagram below shows the codes that are returned when a key is pressed. For example, pressing a would return 0x61. If it is
Service Availability TM Forum Application Interface Specification
Service Availability TM Forum Application Interface Specification Information Model Management Service SAI-AIS-IMM-A.02.0 This specification was reissued on September, under the Artistic License 2.0. The
Lesson-16: Real time clock DEVICES AND COMMUNICATION BUSES FOR DEVICES NETWORK
DEVICES AND COMMUNICATION BUSES FOR DEVICES NETWORK Lesson-16: Real time clock 1 Real Time Clock (RTC) A clock, which is based on the interrupts at preset intervals. An interrupt service routine executes
MPLAB TM C30 Managed PSV Pointers. Beta support included with MPLAB C30 V3.00
MPLAB TM C30 Managed PSV Pointers Beta support included with MPLAB C30 V3.00 Contents 1 Overview 2 1.1 Why Beta?.............................. 2 1.2 Other Sources of Reference..................... 2 2
Volume I, Section 4 Table of Contents
Volume I, Section 4 Table of Contents 4 Software Standards...4-1 4.1 Scope...4-1 4.1.1 Software Sources...4-2 4.1.2 Location and Control of Software and Hardware on Which it Operates...4-2 4.1.3 Exclusions...4-3
Sources: On the Web: Slides will be available on:
C programming Introduction The basics of algorithms Structure of a C code, compilation step Constant, variable type, variable scope Expression and operators: assignment, arithmetic operators, comparison,
INF5140: Specification and Verification of Parallel Systems
INF5140: Specification and Verification of Parallel Systems Lecture 7 LTL into Automata and Introduction to Promela Gerardo Schneider Department of Informatics University of Oslo INF5140, Spring 2007 Gerardo
2.8 861 Receiving Advice/Acceptance Certificate - SERVICE PARTS ONLY
2.8 861 Receiving Advice/Acceptance Certificate - SERVICE PARTS ONLY INFORMATION TMM REQUIRES FROM TRADING PARTNER SCOPE THIS INFORMATION INCLUDES START-UP INFORMATION SPECIFIC TO TRADING PARTNER. APPROACH
Data Tool Platform SQL Development Tools
Data Tool Platform SQL Development Tools ekapner Contents Setting SQL Development Preferences...5 Execution Plan View Options Preferences...5 General Preferences...5 Label Decorations Preferences...6
INTERNATIONAL TELECOMMUNICATION UNION
INTERNATIONAL TELECOMMUNICATION UNION ITU-T X.680 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (07/2002) SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI networking and system aspects Abstract
Apache Cassandra Query Language (CQL)
REFERENCE GUIDE - P.1 ALTER KEYSPACE ALTER TABLE ALTER TYPE ALTER USER ALTER ( KEYSPACE SCHEMA ) keyspace_name WITH REPLICATION = map ( WITH DURABLE_WRITES = ( true false )) AND ( DURABLE_WRITES = ( true
VISUAL GUIDE to. RX Scripting. for Roulette Xtreme - System Designer 2.0
VISUAL GUIDE to RX Scripting for Roulette Xtreme - System Designer 2.0 UX Software - 2009 TABLE OF CONTENTS INTRODUCTION... ii What is this book about?... iii How to use this book... iii Time to start...
RPDO 1 TPDO 1 TPDO 5 TPDO 6 TPDO 7 TPDO 8
EN ZC - 6DI8DO CANopen I/O Module 6 Digital Input 8 Digital Output Or 8 Counters (3 bit) 8 Digital input 8 Digital output User Manual Contents: Features PDOs PDO Type Emergency Message Functional Diagrams
1. Computer System Structure and Components
1 Computer System Structure and Components Computer System Layers Various Computer Programs OS System Calls (eg, fork, execv, write, etc) KERNEL/Behavior or CPU Device Drivers Device Controllers Devices
ECE 341 Coding Standard
Page1 ECE 341 Coding Standard Professor Richard Wall University of Idaho Moscow, ID 83843-1023 [email protected] August 27, 2013 1. Motivation for Coding Standards The purpose of implementing a coding standard
C Programming. for Embedded Microcontrollers. Warwick A. Smith. Postbus 11. Elektor International Media BV. 6114ZG Susteren The Netherlands
C Programming for Embedded Microcontrollers Warwick A. Smith Elektor International Media BV Postbus 11 6114ZG Susteren The Netherlands 3 the Table of Contents Introduction 11 Target Audience 11 What is
Section 29. Real-Time Clock and Calendar (RTCC)
Section 29. Real-Time Clock and Calendar (RTCC) HIGHLIGHTS This section of the manual contains the following topics: 29.1 Introduction... 29-2 29.2 Status and Control Registers... 29-3 29.3 Modes of Operation...
Exercise 1: Python Language Basics
Exercise 1: Python Language Basics In this exercise we will cover the basic principles of the Python language. All languages have a standard set of functionality including the ability to comment code,
This section describes how LabVIEW stores data in memory for controls, indicators, wires, and other objects.
Application Note 154 LabVIEW Data Storage Introduction This Application Note describes the formats in which you can save data. This information is most useful to advanced users, such as those using shared
Multi-Protocol decoder 76 400
Multi-Protocol decoder 76 For locomotives with DC motors on digital layouts operating in the DCC- and Motorola data format. Features Regulated multi-protocol decoder for DCC and Motorola Suitable for DC
Modbus Communications for PanelView Terminals
User Guide Modbus Communications for PanelView Terminals Introduction This document describes how to connect and configure communications for the Modbus versions of the PanelView terminals. This document
Communication Protocol
Analysis of the NXT Bluetooth Communication Protocol By Sivan Toledo September 2006 The NXT supports Bluetooth communication between a program running on the NXT and a program running on some other Bluetooth
Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science
Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science 6.035, Fall 2005 Handout 7 Scanner Parser Project Wednesday, September 7 DUE: Wednesday, September 21 This
