Aknoledgement Form embedded O.S. to A special thanks Code Generation to Paolo Gai (Evidence S.r.l.) Mauro Marinoni [[email protected] ] for the sopport preparing this Retis Lab presentation. Scuola Superiore Sant' Anna 2 / 66 Objectives Embedded O.S. OSEK standard Part I Erika kernel Hardware platform FLEX board Demo addon board Embedded O.S. Scilab/Scicos Embedded Codegen Structure and implementation Examples 3 / 66 Why an embedded O.S. ? Why a Real -Time embedded O.S. ? It reduces the complexity of the An embedded applications tipically application; presents a lot of interactions with It increases the reusability of the code; the environment; It simplify the SW debugging; That requires a management of the It reduces the time to market: response time to an external event. ... 5 / 66 6 / 66 1 Developement scenario The footprint problem ... Typical scenario for an embedded system: Considering typical multiprogrammed environments: microcontroller (typically with reduced number instruction) a full -fledged POSIX footprint is around 1 Mb lack of resources (especially RAM!!!) use of profiles to support subset of the standard dedicated HW a profile is a subset of the full standard that lists a set of services typically used in a given environment dedicated interaction patterns POSIX real time profiles are specified by the ISO/IEEE a microwave oven is NOT a general purpose computer a microwave oven is NOT a general purpose computer standard 1003.13 The system we want to be able must fit on a typical These assumptions leads to different programming styles, system -on -chip memory footprint and to SW architectures different from general purpose computers . that is, around 10 Kb of code and around 1 Kb of RAM... 7 / 66 8 / 66 POSIX top -down approach SoC needs bottom -up approaches! POSIX defines a top -down approach towards we would like to have footprint in the order of 1 -10 Kb embedded systems API design the idea is to have a bottom -up approach the interface was widely accepted when the profiles starting from scratch, design came out a minimal system these profiles allow easy upgrades to more powerful that provides a minimal API systems that is able to efficiently describe embedded systems possibility to reuse previous knowledges and code with stringent temporal requirements with limited resources PSE51 systems around 50 -150 Kbytes Results : that size fits for many embedded devices, like single RTOS standards (OSEK -VDX, uITRON) board PCs 2 Kbytes typical footprint SHaRK is a PSE51 compliant system 2 Kbytes typical footprint 9 / 66 10 / 66 What is OSEK/VDX? Objectives It is a standard for an open -ended architecture for distributed control units in vehicles portability and reusability of the application The name: software OSEK : Offene Systeme und deren Schnittstellen für die Elektronik specification of abstract interfaces for RTOS and im Kraft -fahrzeug (Open systems and the corresponding interfaces for automotive electronics) network management VDX : Vehicle Distributed eXecutive (another french proposal of API similar to OSEK) specification independent from the HW /network OSEK/VDX is the interface resulted from the merge of the two details projects ( http://www.osek -vdx.org ) Motivations: scalability between different requirements to high, recurring expenses in the development and variant adapt to particular application needs management of non -application related aspects of control unit software. verification of functionality and implementation incompatibility of control units made by different manufacturers using a standardized certification process due to different interfaces and protocols. using a standardized certification process 11 / 66 12 / 66 2 Advantages System philosophy clear savings in costs and development time. standard interface ideal for automotive applications scalability scalability enhanced quality of the software using conformance classes creation of a market of uniform competitors configurable error checking independence from the implementation and portability of software the firmware on an automotive ECU is 10% RTOS and 90% drivers standardised interfacing features for control units Static is better: with different architectural designs everything is specified before the system runs intelligent usage of the hardware present on the static approach to system configuration no dynamic allocation on memory vehicle no dynamic creation of tasks for example, using a vehicle network the ABS controller no flexibility in the specification of the constraints could give a speed feedback to the powertrain custom languages that helps off -line configuration of the system microcontroller OIL : parameters specification (tasks, resources, stacks…) microcontroller KOIL : kernel aware debugging 13 / 66 14 / 66 Support for automotive requirements Application building process input the idea is to create a system that is RTOS configuration drivers configuration OIL DIL output reliable device drivers third part libraries templates with real -time predictability DIL Conf. Tool OIL support for Debugger Conf. Tool fixed priority scheduling with immediate priority ceiling non preemptive scheduling preemption thresholds RTOS configuration device drivers ORTI description binary image ROM execution of code C code C/ASM code KOIL .elf stack sharing (limited support for blocking primitives) documented system primitives Linker behavior objects application C/ASM objects performance of a given RTOS must be known .o objects C code Compiler .o RTOS library .o .a 15 / 66 16 / 66 OSEK/VDX standards Processing levels The OSEK/VDX consortium packs its standards the OSEK OS specification describes the in different documents processing levels that have to be supported by OSEK OS operating system an OSEK operating system OSEK Time time triggered operating system OSEK COM communication services OSEK FTCOM fault tolerant communication OSEK NM network management OSEK OIL kernel configuration OSEK ORTI kernel awareness for debuggers 17 / 66 18 / 66 3 Conformance classes Conformance classes There are four conformance classes OSEK OS should be scalable with the application needs There are four conformance classes BCC1 BCC1 different applications require different services basic tasks, one activation, one task per priority the system services are mapped in Conformance Classes BCC2 a conformance class is a subset of the OSEK OS standard BCC1 plus: > 1 activation, > 1 task per priority ECC1 objectives of the conformance classes BCC1 plus: extended tasks allow partial implementation of the standard ECC2 allow an upgrade path between classes ECC1 plus: > 1 activation (basic tasks), > 1 task per priority services that discriminates the different conformance classes multiple requests of task activations task types number of tasks per priority 19 / 66 20 / 66 Basic tasks Extended tasks a basic task is extended tasks can use events for synchronization a C function call that is executed in a proper context an event is simply an abstraction of a bit mask that can never block can lock resources events can be set/reset using appropriate primitives can only finish or be preempted by an higher priority task or IS R a task can wait for an event in event mask to be set a basic task is ideal for implementing a kernel -supported stack sharing, because extended tasks typically the task never blocks have its own stack when the function call ends, the task ends, and its local variab les are are activated once destroyed in other words, it uses a one -shot task model have as body an infinite loop over a WaitEvent() primitive support for multiple activations extended tasks do not support for multiple activations in BCC2, ECC2, basic tasks can store pending activations (a task can be ... but supports multiple pending events activated while it is still running) ... but supports multiple pending events 21 / 66 22 / 66 Scheduling algorithm Interrupt service routine the scheduling algorithm is fundamentally a OSEK OS directly addresses interrupt management in the standard API fixed priority scheduler interrupt service routines (ISR) can be of two types with immediate priority ceiling Category 1: without API calls simpler and faster, do not implement a with preemption threshold call to the scheduler at the end of the ISR Category 2: with API calls these ISR can call some primitives the approach allows the implementation of (ActivateTask, ...) that change the scheduling behavior. The end of the ISR is a rescheduling point preemptive scheduling ISR 1 has always a higher priority of ISR 2 non preemptive scheduling mixed finally, the OSEK standard has functions to directly manipulate the CPU interrupt status 23 / 66 24 / 66 4 Counters and alarms Application modes Counter OSEK OS supports the concept of is a memory location or a hardware resource used to count events application modes for example, a counter can count the number of timer an application mode is used to influence interrupts to implement a time reference the behavior of the device Alarm Alarm is a service used to process recurring events example of application modes an alarm can be cyclic or one shot normal operation when the alarm fires, a notification takes place debug mode task activation diagnostic mode call of a callback function set of an event ... 25 / 66 26 / 66 Hooks Error handling OSEK OS specifies a set of the OSEK OS has two types or error return values hooks that are