Sistemul de operare OSEK/VDX - aut.upt.roandreea.robu/CursSPTRPart2.pdf · sistemului de operare atât pentru sisteme cu procesoare simple, cât şi pentru sisteme cu procesoare complexe

1

Sistemul de operare OSEK/VDX

- Specificaţii 2.2.3 -

1. Introducere

Specificaţiile sistemului de operare OSEK au ca scop asigurarea unui mediu unitar care

să permită utilizarea eficientă a resurselor pentru aplicaţii software de conducere automată în domeniul automotive. Sistemul de operare OSEK este un sistem de operare destinat unităţilor de control cu un singur procesor din sistemele încorporate, inclusiv distribuite.

1.1. Despre OSEK

Aplicaţiile automotive sunt caracterizate de cerinţe riguroase de timp real. Prin urmare,

sistemul de operare OSEK oferă funcţionalităţile necesare pentru a sprijini sistemele de control de tip event driven (conduse de evenimente).

Serviciile (funcţionalităţile) sistemului de operare OSEK constituie o bază pentru a se

permite integrarea modulelor software fabricate de diferiţi producători. Deoarece sistemul de operare este destinat utilizării în orice tip de sisteme de control, el

va trebui să suporte aplicaţii de timp critic pe o arie largă de hardware-uri. Utilizabilitatea sistemului de operare atât pentru sisteme cu procesoare simple, cât şi pentru sisteme cu procesoare complexe necesită cerinţe precum un înalt grad de modularitate si un bogat set de capabilităţi pentru asigurarea de configuraţii flexibile. Aceste cerinţe au fost incluse în conceptul de “clasă de conformanţă”.

Interfeţe standardizate

Interfaţa dintre aplicaţia software şi sistemul de operare OSEK este definită de serviciile

sistemului. Interfaţa este identică pentru toate implementările sistemului de operare pe diferite familii de procesoare.

Serviciile sistemului sunt specificate într-o sintaxă conformă standardului C -ANSI / ISO.

2

Scalabilitatea

Diferite clase de conformanţă, mecanisme de dispecerizare şi caracteristici de configurare fac sistemul de operare OSEK practicabil pentru un spectru larg de aplicaţii şi de hardware. Sistemul de operare OSEK este realizat să necesite un minim de resurse hardware (RAM, ROM, timp CPU) şi prin urmare funcţionează chiar şi pe microcontrolere pe 8 biţi.

Verificarea erorilor

Sistemul de operare OSEK oferă două versiuni din punct de vedere al verificării erorilor, versiunea extinsă pentru faza de dezvoltare a aplicaţiei şi versiunea standard pentru faza de funcţionare propriu-zisă. Din cauza verificării erorilor, versiunea extinsă necesită un timp de execuţie mai lung şi un spaţiu de memorie mai mare decât versiunea standard. După ce toate erorile sunt eliminate în faza de testare, sub versiunea extinsă, sistemul poate fi recompilat cu versiunea standard.

Portabilitatea aplicaţiei software

Unul din obiectivele OSEK este de a asigura portabilitatea şi reutilizarea aplicaţiilor software. Prin urmare, interfaţa dintre aplicaţiile software şi sistemul de operare este realizată de servicii de sistem standardizate cu funcţionalităţi bine definite. Utilizarea de servicii de sistem standardizate reduce atât efortul de a menţine şi de a porta aplicaţiile software, cât şi costul dezvoltării. Portabilitatea reprezintă capacitatea de a transfera un modul al aplicaţiei software de la un ECU (Electronic Control Unit) la alt ECU fără schimbări majore în cadrul aplicaţiei. Interfaţa standardizată (apeluri de servicii sistem, definiţii de tip şi constante) a sistemului de operare suportă portabilitatea la nivel de cod sursă. Aplicaţia software este grefată pe învelişul format de sistemul de operare şi de sistemul de intrare/ieşire, sistem (acesta din urmă) care nu este standardizat în specificaţia OSEK. În Fig. 1, software-ul de aplicaţie este reprezentat ca fiind format din 4 module (taskuri). Modulele 1 si 2 interacţionează cu hardware-ul prin intermediul sistemului de operare, modulul 4 prin intermediul sistemului de intrare / ieşire, iar modulul 3 prin ambele. Sistemul de intrare / ieşire cuprinde programele de deservire a perifericelor. Modulul 1 este de sine stătător, neavând nicio interacţiune cu celălalte, iar modulele 2 şi 3, respectiv 3 şi 4 interacţionează între ele (prin operaţii de sincronizare sau schimb de date).

3

Fig. 1. Interfaţa software în ECU.

Suport special pentru cerinţe automotive

Următoarele caracteristici vizează cerinţe precum siguranţa, randamentul în timp real şi sensibilitatea faţă de cost:

• Sistemul de operare OSEK este configurat şi scalat într-un mod static (la compilare şi nu în execuţie). Utilizatorul specifică static numărul de task-uri, resursele şi serviciile necesare.

• Specificaţiile sistemului de operare OSEK suportă implementări capabile a fi executate direct din ROM (Read-Only-Memory).

• Sistemul de operare OSEK suportă portabilitatea task-urilor aplicaţiei. • Specificaţiile sistemului de operare OSEK asigură ca implementările sistemului de

operare să aibă un comportament predictibil, care corespunde cerinţelor aplicaţiilor în timp real din domeniul automotive.

• Specificaţiile sistemului de operare OSEK permit implementări la parametri de performanţă predictibili.

1.2. Scopul acestei prezentări

Descrierea ce urmează a sistemului de operare OSEK trebuie privită ca o descriere generică, care este imperativă pentru orice implementare a sistemului de operare OSEK. Ea cuprinde descrierea generală a strategiei şi a funcţionalităţilor, interfaţa apelurilor, declararea şi semnificaţia parametrilor, precum şi posibilele coduri de eroare.

4

2. Sumar Sistemul de operare OSEK furnizează o arie largă de diferite servicii şi mecanisme de procesare. Acesta este construit în funcţie de instrucţiunile de configurare ale utilizatorului la momentul generării sistemului. Există patru clase de conformanţă, menite să satisfacă diferite cerinţe în ceea ce priveşte funcţionalităţile şi capabilităţile sistemului de operare OSEK. Astfel, utilizatorul poate adapta sistemul de operare la complexitatea aplicaţiei şi la hardware-ul ţintă. Sistemul de operare nu poate fi modificat mai târziu, în timpul execuţiei. Aplicaţiile care au fost scrise pentru o anumită clasă de conformanţă trebuie să fie portabile pe implementări OSEK din aceeaşi clasă. În cadrul claselor de conformanţă, se impun aspecte legate de:

Managementul taskurilor, cu referire la: • Activarea şi terminarea taskurilor • Dispecerizarea taskurilor

Sincronizare, cu referire la: • Managementul resurselor, adică: controlul accesului pentru operaţiuni critice

(care trebuie executate în regim de excludere mutuală) pe resurse logice sau dispozitive utilizate în comun

• Managementul evenimentelor pentru sincronizarea taskurilor

Managementul întreruperilor, cu referire la: • Serviciile pentru tratarea întreruperilor

Alarme, care sunt de două tipuri: • Alarme relative • Alarme absolute

Manevrarea mesajelor, cu referire la: • Servicii pentru schimbul de date

Depanarea erorilor, care are în vedere: • Mecanisme ce ajută utilizatorul în caz de diverse erori

5

3. Arhitectura sistemului de operare OSEK 3.1. Nivele de procesare Sistemul de operare OSEK asigură executarea controlată în timp real a unui număr de taskuri (fire de execuţie, thread-uri) care par să funcţioneze în paralel.

Sistemul de operare OSEK oferă un set definit de servicii / apeluri sistem pentru utilizator. Aceste servicii / apeluri sistem sunt folosite de entităţi care concurează pentru CPU (Central Processing Unit). Există două tipuri de entităţi:

• Rutine de tratare a întreruperilor administrate de sistemul de operare (există şi rutine de tratare a întreruperilor neadministrate de sistemul de operare, ci direct de utilizator, fără vreun apel la vreun serviciu sistem)

• Taskuri (de bază şi extinse)

OSEK defineşte trei nivele de procesare (Fig. 2): • Nivelul rutinelor de întrerupere • Nivelul scheduler-ului (dispecerului) • Nivelul taskurilor

În cadrul nivelului taskurilor, acestea sunt programate în funcţie de prioritatea atribuită lor de către utilizator. Contextul de rulare este restaurat / instituit la începutul fiecărei reprize de rulare şi salvat la sfârşitul fiecărei reprize de rulare.

Fig. 2. Nivelele de procesare ale sistemului de operare OSEK.

6

Au fost stabilite următoarele reguli de prioritate: • Rutinele de întrerupere (rutinele de deservire a întreruperilor) au cea mai mare prioritate.

Pot exista mai multe nivele de prioritate pentru tratarea întreruperilor • Rutinele de deservire a întreruperilor au nivelele de prioritate atribuite static • Atribuirea nivelelor de prioritate către rutinele de deservire a întreruperilor depinde de

implementare şi de arhitectura hardware • În OSEK, numerele mai mari se referă la priorităţi mai mari. • Prioritatea unui task este atribuită static de către utilizator (static înseamnă la compilare)

3.2. Clase de conformanţă Diversele cerinţe ale aplicaţiilor şi diferitele caracteristici ale hardware-ului (procesor, memorie) necesită diferite caracteristici ale sistemului de operare. Aceste caracteristici sunt referite, după cum s-a arătat, prin termenul “clasă de conformanţă” (CC). Este obligatoriu ca o clasă de conformanţă să fie implementată complet, chiar dacă, de fapt, în final vor fi legate (link-ate) doar acele servicii de sistem care sunt apelate efectiv în aplicaţie. Clasele de conformanţă nu pot fi modificate în timpul execuţiei. Clasele de conformanţă sunt determinate de următoarele atribute (Fig. 3):

• Solicitările multiple de activare a taskurilor • Tipurile de taskuri (de bază sau extinse) admise • Numărul de taskuri per prioritate

Fig. 3. Compatibilitatea impusă de clasele de conformanţă.

Sunt descrise următoarele clase de conformanţă:

• BCC1 (admite doar taskuri de bază, limitate la o cerere de activare per task şi un task per prioritate, adică: toate taskurile au priorităţi diferite)

7

• BCC2 (ca şi BCC1, în plus: mai mult de un task per prioritate posibil şi solicitări multiple de activare a taskurilor posibile)

• ECC1 (ca şi BCC1, plus că admite şi taskuri extinse) • ECC2 (ca şi ECC1, plus că: mai mult de un task per prioritate posibil şi solicitări multiple

de activare a taskurilor posibile pentru taskurile de bază) Clasele de conformanţă sunt prezentate mai detaliat în Fig. 4.

Fig. 4. Cerinţele minime pentru clasele de conformanţă.

8

4. Managementul taskurilor 4.1. Conceptul de task Un software de control complex poate fi convenabil subdivizat în părţi executate în acord cu cerinţele de timp real. Aceste părţi poartă numele de taskuri, în accepţiunea de fir de execuţie sau thread (aşa cum am văzut, există pentru termenul task şi accepţiunea de program de sine stătător sau proces). Sistemul de operare asigură execuţia concurentă şi asincronă a taskurilor, într-o succesiune a lor la procesor stabilită de scheduler. Sub sistemul de operare OSEK există două tipuri de taskuri:

• taskuri de bază (basic tasks) • taskuri extinse (extended tasks)

Taskurile de bază

Taskurile de bază eliberează procesorul, o dată ce l-au obţinut, dacă:

• se încheie • sistemul de operare li-l iau pt. a-l atribui unui task de prioritate mai înaltă • o întrerupere apare care cauzează atribuirea procesorului către rutine de tratare a

întreruperii (ISR: interrupt service routine).

Taskurile extinse Taskurile extinse se disting de taskurile de bază prin aceea că pot folosi serviciul OSEK (numit şi apel de sistem, system call) WaitEvent, care conduce la trecerea taskurilor în starea waiting (a se vedea capitolul Mecanismul evenimentelor). Starea waiting face ca procesorul să fie disponibilizat pentru a fi alocat altui task posibil chiar mai puţin prioritar, înainte ca taskul care l-a deţinut să se încheie. Managementul taskurilor extinse este mai complex decât managementul taskurilor de bază.

9

4.2. Evoluţia taskurilor în spaţiul stărilor 4.2.1. Taskurile extinse Taskurile extinse pot atinge patru stări (Fig. 5, 6):

running În starea running, taskul deţine procesorul şi rulează efectiv. Doar un singur task poate fi la un moment în starea running, în timp ce toate celelalte stări pot fi atinse simultan de mai multe taskuri.

ready În starea ready, toate condiţiile pentru rulare, deci şi pt. tranziţia în starea running sunt îndeplinite, taskul doar aşteptând să i se aloce procesorul. Decizia cărui task i se alocă la un moment dat procesorul o ia scheduler-ul.

waiting În starea waiting, taskurile nu pot rula pentru că le lipseşte ceva: o condiţie de ordin cronologic, o nouă valoare pt. o dată, etc.

suspended În starea suspended, taskurile ajung după ce se termină. De asemenea, starea suspended este starea iniţială din care pleacă toate taskurile.

10

Fig. 5. Modelul de stare al taskurilor extinse.

Transition Former state New state Description activate suspended ready Prin activate, un task din starea suspended

–aflat în ea ca stare iniţială sau ajuns în ea în urma terminării sale- este dus în starea ready. Rularea taskurilor ajunse în starea ready din starea suspended începe cu prima lor instrucţie.

start ready running Prin start, se introduce în rulare taskul dintre cele ready selectat de scheduler.

wait running waiting Prin wait, un task aflat în rulare trece din starea running în starea waiting, în aşteptarea unui eveniment.

release waiting ready Prin release se anunţă taskul că cel puţin un eveniment dintre cele pe care el le aşteaptă s-a produs.

preempt running ready Preempt indică faptul că unui task i se ia procesorul (de către scheduler, bineînţeles), el fiind dus în starea ready.

terminate running suspended Prin terminate, se marchează faptul că un task a ajuns la finalul său şi, prin urmare, el este dus în starea suspended.

Fig. 6. Stări şi tranziţii de stări pentru taskurile extinse.

11

4.2.2. Taskurile de bază Taskurile de bază pot atinge trei stări. Acestea sunt trei dintre cele patru pe care le pot atinge taskurile extinse, şi anume (Fig. 7, 8):

running ready suspended

toate trei cu aceleaşi semnificaţii ca şi în cazul taskurilor extinse. Aşadar, diferenţa e făcută de faptul că taskurile de bază nu pot avea starea waiting.

Fig. 7. Modelul de stare al taskurilor de bază.

12

Transition Former state New state Description activate suspended ready Prin activate, un task din starea suspended –

aflat în ea ca stare iniţială sau ajuns în ea în urma terminării sale- este dus în starea ready. Rularea taskurilor ajunse în starea ready din starea suspended începe cu prima lor instrucţie.

start ready running Prin start, se introduce în rulare taskul dintre cele ready selectat de scheduler.

preempt running ready Preempt indică faptul că unui task i se ia procesorul (de către scheduler, bineînţeles), el fiind dus în starea ready.

terminate running suspended Prin terminate, se marchează faptul că un task a ajuns la finalul său şi, prin urmare, el este dus în starea suspended.

Fig. 8. Stări şi tranziţii de stări pentru taskurile de bază. 4.3. Activarea taskurilor

Activarea taskurilor se realizează folosind serviciile sistemului de operare ActivateTask sau ChainTask. După activare, taskul este pregătit să se execute de la prima instrucţiune.

Sistemul de operare OSEK nu acceptă transmiterea de parametri în maniera C către

funcţiile ce reprezintă taskuri. Parametrii vor trebui transmişi prin mecanisme de comunicare sau prin variabile globale.

Cereri multiple de activare a taskurilor

Depinzând de clasa de conformanţă, un task poate fi activat o dată sau de mai multe ori. Prin "cereri multiple de activare a taskurilor" înţelegem solicitarea către sistemul de operare OSEK a activării unui task în timp ce el este deja activat pentru ca el să poată fi rulat în paralel cu el însuşi.

Numărul cererilor multiple de activare paralelă a unui task este definit printr-un atribut specific, în timpul generării sistemului. Cererile de activare a unui task sunt puse în aşteptare în funcţie de prioritate, în ordinea sosirii lor.

13

4.4. Mecanismul de comutare a taskurilor

Spre deosebire de programarea secvenţială convenţională, principiul de multitasking permite sistemului de operare să execute diferite taskuri în acelaşi timp. Politica de planificare a taskurilor la procesor, numită şi politică de dispecerizare (respective politică de scheduling) trebuie definită în mod clar.

Entitatea care decide care task va intra în execuţie și care se ocupă cu declanșarea tuturor

activităților interne necesare ale sistemului de operare OSEK este numită dispecer (scheduler). Dispecerul este activat ori de câte ori o comutare de task trebuie să aibă loc, în conformitate cu politica de dispecerizare implementată. Dispecerul poate fi considerat ca o resursă care poate fi ocupată și eliberată de taskuri. Astfel, un task poate rezerva dispecerul pentru a evita o comutare între taskuri până când acesta este eliberat. 4.5. Prioritatea taskurilor

Dispecerul decide pe baza priorităţii taskurilor care este următorul dintre taskurile în starea ready care va fi transferat în starea running.

Valoarea 0 este definită ca şi prioritatea cea mai mică a unui task. Alocând numere mai

mari, definim priorităţi mai mari ale taskurilor. Pentru a spori eficiența, nu este acceptat un management de priorităţi dinamic. În

consecință, prioritatea unui task este stabilită static, adică utilizatorul nu o poate schimba în timpul execuției. Cu toate acestea, în anumite cazuri, în timpul lucrului cu resurse, sistemul de operare poate trata un task considerându-l cu prioritate mai mare decât o are el stabilită, şi anume, cu o prioritate egală cu cea a resursei în cauză.

Ca mai multe taskuri să aibă priorităţi identice este permis în clasele de conformanţă

BCC2 şi ECC2. Taskurile care au acelaşi nivel de prioritate sunt introduse în rulare dependent de ordinea

lor de activare. Un task scos de la procesor prin preempţie (adică: prin luarea de la el a procesorului, deşi

el ar fi putut rula în continuare) este inserat în capul listei de taskuri ready de prioritatea respectivă, ca şi cum ar fi cel mai vechi în acea listă.

Un task care a fost eliberat din starea waiting este inserat în coada listei de taskuri ready

de prioritatea respectivă, ca şi cum ar fi cel mai nou în acea listă.

14

Figura 4-5 prezintă un exemplu de implementare a utilizării dispecerului pentru fiecare nivel de prioritate. Câteva taskuri de diferite priorităţi se află în starea ready: trei taskuri de prioritate 3, unul de prioritate 2, unul de prioritate 1, plus două taskuri de prioritate 0. Taskul care aşteaptă de cel mai mult timp este prezent în partea de jos a fiecărei cozi. Procesorul doar ce a executat şi a terminat un task. Dispecerul selectează următorul task care să intre în execuţie (prioritate 3, prima coadă, pt. că aceasta este presupusă cea mai puternică prioritate cu listă de taskuri rulabile nevidă). Taskurile de prioritate 2 pot fi procesate doar după ce toate taskurile de prioritate mai mare au părăsit stările running şi ready, adică după ce ele au ajuns să fie şterse din coada de aşteptare la procesor, fie datorită terminării lor (trecerii în starea suspended), fie datorită tranziţiei lor în starea waiting.

Figura 4-5 Dispecer: ordinea evenimentelor

Următorii paşi fundamentali sunt necesari pentru a determina care este următorul task care va intra în execuţie: • Dispecerul analizează toate taskurile care se află în starea ready / running. • Din seturile de taskuri care se află în starea ready / running, dispecerul determină setul de

taskuri cu cea mai mare prioritate. • În cadrul setului de sarcini în stare ready / running de cea mai mare prioritate, dispecerul

selectează cel mai vechi task.

15

4.6. Politica de scheduling 4.6.1. Full preemptive scheduling

Dispecerizarea „full preemptive” înseamnă că un task care este la un moment în starea running poate fi scos de la procesor şi replanificat pentru rulare în orice moment, de apariţia unei condiţii declanşatoare pre-stabilită de sistemul de operare. Dispecerizarea full preemptive va trece taskul din starea running în starea ready, de îndată ce un task de prioritate mai mare a devenit ready. Contextul taskului este salvat, astfel că taskul scos din rulare poate fi continuat din punctul în care acest lucru s-a întâmplat.

În modul de lucru full preemptive scheduling, timpul de latență este independent de

timpul de rulare al taskurilor de prioritate mai mică. El comportă, însă, utilizarea unui volum de memorie (RAM) mai mare şi o complexitate mai mare a problemei sincronizării între taskuri.

In Figura 4-6, taskul T2 cu o prioritate mai mică nu întârzie programarea taskului T1 cu

prioritate mai mare.

Figura 4-6 Full preemptive scheduling

Rezumând, replanificarea taskurilor are loc în următoarele cazuri:

• Terminarea cu succes a unui task (serviciul de sistem Terminate Task) • Terminarea cu succes a unui task cu activarea explicită a taskului succesor (serviciul de

sistem ChainTask). • Activarea unui task (serviciul de sistem ActivateTask). • Apelul explicit wait dacă o tranziţie în starea waiting are loc (doar pentru taskurile

extinse, serviciul de sistem WaitEvent). • Setarea unui eveniment pentru un task în starea waiting (serviciul sistem SetEvent). • Eliberarea de resurse la nivelul unui task (serviciul de sistem ReleaseResource) • Întoarcerea de la nivelul întrerupere la nivelul task

În timpul rutinelor de tratare a întreruperilor, nu sunt permise replanificările.

16

Aplicaţiile care utilizează strategia de dispecerizare ”full preemptive” nu au nevoie de

serviciul de sistem Schedule, în timp ce alte politici de dispecerizare utilizează acest serviciu de sistem, prin el ele asigurând perindarea diferitelor taskuri la procesor.

4.6.2. Non preemptive scheduling

Politica de dispecerizare este de tip ”non preemptive”, dacă comutarea între taskuri este realizată doar la iniţiativa taskului care rulează.

Dispecerizarea ”non preemptive” impune anumite constrângeri asupra cerinţelor de timp

ale taskurilor. Prezenţa unor secţiuni”non preemptive” în taskuri în starea running cu prioritate mai mică, poate întârzia începerea unui task cu prioritate mai mare.

În Figura 4-7, taskul T2 cu prioritate mai mică întârzie taskul T1 cu prioritate mai mare

până la următorul punct de dispecerizare (în acest caz terminarea taskului T2).

Figura 4-7 Non preemptive scheduling

Puncte de re-dispecerizare

În cazul unui task non preemptiv, re-dispecerizarea va avea loc în următoarele cazuri: • Terminarea cu succes a taskului care rulează (serviciul de sistem TerminateTask). • Terminarea cu succes a taskului care rulează cu activarea explicită a taskului succesor

(serviciul de sistem ChainTask). • Apelul explicit al dispecerului (serviciul de sistem Schedule). • Trecerea taskului care rulează în starea waiting (serviciul de sistem WaitEvent).

Implementări ale sistemelor non preemptive pot prevedea că serviciile sistemului de operare,

care determină re-dispecerizarea pot fi apelate numai din puncte de cel mai înalt nivel (adică: de la nivelul taskurilor, nu din funcţii apelate de către acestea).

17

Observaţii: Apelul WaitEvent nu conduce la starea waiting dacă unul dintre evenimentele aşteptate este deja setat. În acest caz, WaitEvent nu conduce la o re-dispecerizare.

4.6.4. Mixed preemptive scheduling

Dacă într-un sistem sunt admise atât dispecerizarea full preemtive, cât şi dispecerizarea non preemtive , se spune că sistemul este cu dispecerizare mixed preemtive.

Prezenţa unui task non preemptive într-un sistem preemptive are sens dacă:

• Timpul de execuţie a taskului este de acelaşi ordin de mărime cu timpul de comutare • Dacă există suficient RAM pt. a salva contextul taskurilor care ies din rulare • Dacă activităţile din task nu pot fi întrerupte

Multe aplicaţii comportă doar un număr mic de taskuri cu timp de execuţie mare, pentru care este adecvată comutarea ”preemptive”, în timp ce majoritatea takurilor sunt scurte şi se pretează la lucrul ”non preemptive”. 4.6.5. Selectarea politicii de dispecerizare

Dezvoltatorul software sau integratorul de sistem determină secvenţa de execuţie a taskurilor prin configurarea priorităţilor şi asignarea preemtabilităţii drept atribut al taskului.

4.7. Terminarea taskurilor

In sistemul de operare OSEK, un task se poate termina doar prin prevederile de terminare din cadrul său (TerminateTask, ChainTask). Aceste apeluri sistem / directive sunt folosite prin intermediul lui TerminateTask or ChainTask

18

5. Procesarea întreruperilor

Funcţiile pt. procesarea unei întreruperi (Interrupt Service Routine: ISR) sunt subdivizate în două ISR-uri:

ISR category 1 ISR nu poate conţine apeluri la sistemul de operare. După ce ISR este finalizată, procesarea taskului în curs continuă exact de la instrucţia care ar fi urmat să se execute în taskul întrerupt, dacă n-ar fi fost întrerupt

ISR category 2 ISR conţine apeluri la sistemul de operare. Rutina este asignată întreruperii cu ocazia generării sistemului de operare, printr-un mecanism specific.

În interiorul rutinelor de tratare a întreruperilor (ISR), folosirea serviciilor sistemului de

operare OSEK este restricţionată aşa cum se arată în figura 5-1.

Figura 5-1 Categorii ISR ale sistemului de operare OSEK

În interiorul rutinelor de tratare a întreruperilor (ISR) nu poate avea loc nicio re-

dispecerizare. Re-dispecerizarea va avea loc la terminarea ISR de categoria 2 dacă un task preemtiv a fost întrerupt şi dacă nu este activă o altă întrerupere.

Fast Disable/Enable API-functions

OSEK oferă funcţii pentru a invalida / valida (sau dezactiva / activa) toate întreruperile: EnableAllInterrupts, DisableAllInterrupts, ResumeAllInterrupts, SuspendAllInterrupts), respectiv pentru a invalida / valida (sau dezactiva / activa) întreruperile de categoria 2 (ResumeOSInterrupts, SuspendOSInterrupts). Folosirea tipică a acestora este pt. a proteja secţiunile critice scurte.

19

6. Mecanismul evenimentelor

Mecanismul evenimentelor reprezintă: • un mijloc de sincronizare • este prevăzut doar pentru taskuri extinse, din punct de vedere al recepţiei evenimentelor • iniţiază tranziţii de stare ale taskurilor către şi de la starea waiting

Evenimentele sunt entităţi gestionate de sistemul de operare. Doar taskurile instituite drept

proprietare ale evenimentelor se pot afla în aşteptarea lor. Acest statut îl pot avea doar taskurile extinse. Semnalarea producerii evenimentelor (setarea evenimentelor) o pot însă face şi taskurile de bază.

Un anumit eveniment este identificat prin proprietarul său şi prin numele său (masca sa). La activarea unui task extins, toate evenimentele sale sunt şterse de către sistemul de operare.

Evenimentele pot fi utilizate pentru a comunica o informaţie binară taskului extins căruia îi sunt atribuite. Semnificaţia evenimentelor este definită de către aplicaţie, de exemplu, cum ar fi, semnalizarea expirării unui timp programat la un timer, disponibilitatea unei resurse, primirea unui mesaj, etc.

Diverse opţiuni sunt la dispoziţia taskurilor pentru a manipula evenimente, diferenţiat pentru taskurile cu statut de proprietar faţă de celelalte. Toate taskurile pot anunţa (seta) orice evenimente, pentru orice taskuri extinse nesuspendate. Numai proprietarul, însă –proprietar care, cum am văzut, este obligatoriu să fie un task extins- este în măsură să îşi şteargă evenimentele şi să se pună în aşteptarea recepţionării (setării) lor.

Evenimentele sunt criterii pentru tranziţia taskurilor extinse din starea waiting în starea ready.

Sistemul de operare oferă servicii de setare, de ştergere, de interogare şi de aşteptare a evenimentelor.

Orice task sau ISR din categoria 2 poate semnala (seta) un eveniment pentru un task extins nesuspendat, şi, astfel, taskul în cauză este informat cu privire la orice schimbare de stare, prin intermediul respectivului eveniment.

Insistăm: receptorul unui eveniment este un task extins. Prin urmare, nu este posibil pentru o rutină de tratare de întrerupere sau pentru un task de bază să aştepte un eveniment. Un eveniment poate fi şters numai de taskul care este proprietarul respectivului eveniment. Taskurile extinse

20

pot să şteargă evenimentele pe care le deţin, în timp ce taskurile de bază, nu au permisiunea să folosească serviciul sistemului de operare pentru ştergerea de evenimente.

Un task extins aflat în starea waiting este eliberat şi trece în starea ready în cazul în care cel puţin un eveniment aşteptat de el are loc. În cazul în care un task extins aflat în starea running se anunţă interesat de apariţia unui eveniment, dacă acest eveniment a avut loc deja, taskul rămâne în starea running.

Figura 6-1 explica sincronizarea taskurilor extinse prin stabilirea de evenimente în cazul full preemptive scheduling, unde taskul extins T1 are prioritatea cea mai mare.

Figura 6-1 Sincronizarea taskurilor extinse “preemptable”

Figura 6-1 ilustrează ce se întâmplă la semnalarea (setarea) unui eveniment: Taskul T1 aşteaptă un eveniment. Taskul T2 setează acest eveniment de care este interesat T1. Dispecerul este activat. El tranzitează T1 din starea waiting în starea ready. Datorită priorităţii mai mari a taskului T1, are loc o comutare de taskuri la procesor: T2 este deposedat (preemptat) de procesor şi dus în starea ready, iar T1 primeşte procesorul şi trece în running. La un moment, T1 resetează evenimentul. Ulterior, T1 se anunţă interesat de eveniment şi, presupunând că evenimentul nu s-a produs, intră în rulare scheduler-ul, care trece T1 în waiting şi T2 în running.

Dacă considerăm non preemptive scheduling, re-dispecerizarea nu are loc imediat ce evenimentul este semnalat (setat) (vezi Figura 6-2, în care taskul extins T1 este de prioritate mai mare), ci doar atunci când o solicită taskul care deţine procesorul.

21

Figura 6-2 Sincronizarea taskurilor extinse non preemptable

Se observă în figura 6-2, că la un moment, în T2, se setează evenimentul aşteptat de T1 şi, implicit, se schimbă starea lui T1 din waiting în ready, dar abia când T2 solicită un rescheduling, intră în rulare scheduler-ul, care ia procesorul de la T2, pe care-l lasă în starea ready, şi îl dă lui T1, pe care, implicit, îl duce în starea running.

22

7. Mecanismul de management al resurselor

Mecanismul de management al resurselor este utilizat pentru a coordona accesul concurenţial al mai multor taskuri cu diferite priorităţi la resurse comune, cum sunt: funcţiile nereentrante, variabilele globale, anumite zone ale ecranului, imprimanta / imprimantele, etc.

În OSEK, mecanismul de management al resurselor este operaţional în toate clasele de

conformanţă. Utilizarea mecanismului de management al resurselor poate fi extinsă şi la nivelul

rutinelor de tratare a întreruperilor, care şi ele pot accesa resurse, alături de taskuri. Managementul resurselor asigură că:

• nu se ajunge ca două sau mai multe taskuri să ocupe aceeaşi resursă la acelaşi moment de timp

• inversarea de prioritate nu poate interveni. • interblocajele nu pot interveni în utilizarea resurselor • taskurile care au accesat o resursă nu intră niciodată în starea waiting până nu eliberează

acea resursă.

Dacă managementul resurselor este extins şi la nivelul ISR, atunci textul de la bulina 1 se înlocuieşte cu:

• nu se ajunge ca două sau mai multe taskuri, ISR-uri sau taskuri şi ISR-uri să ocupe aceeaşi resursă la acelaşi moment de timp

Mecanismul de management al resurselor este util în următoarele situaţii: • se lucrează cu task-uri preemptive • resursa este partajată între taskuri, ISR-uri sau taskuri şi ISR-uri

7.1. Comportarea în timpul accesului la resurse ocupate

Sistemul de operare (SO) OSEK dispune de aşa-numitul protocol de plafonare de prioritate (vezi cap. 7.5) Drept urmare, nu apare nicio situaţie în care un task sau o ISR încearcă să acceseze o resursă ocupată.

Dacă se foloseşte conceptul de resursă pentru coordonarea taskurilor şi ISR-urilor, SO

OSEK asigură de asemenea că o ISR este procesată doar dacă toate resursele care ar putea fi ocupate de ea în timpul execuţiei sale sunt libere la acel moment.

23

OSEK interzice strict accesul încuibat la o resursă. În cazuri rare în care accesul încuibat este necesar, este recomandat să se folosească o a doua resursă cu aceeaşi funcţionalitate ca şi prima, altfel spus: să se procedeze la replicarea acelei resurse. 7.2. Restricţii în folosirea resurselor

TerminateTask, ChainTask, Schedule, WaitEvent nu vor fi apelate în interiorul secvenţelor de program în care sunt ţinute ocupate resurse. O ISR nu va fi încheiată înainte ca ea să elibereze resursele pe care le-a ocupat.

În cazul ocupării multiple de resurse în cadrul unui task, utilizatorul are obligaţia să

solicite şi să elibereze resursele urmând principiul LIFO. 7.3. Scheduler-ul ca o resursă

Dacă un task vrea să se protejeze el însuşi împotriva preempţiilor (deposedărilor de procesor) la care l-ar supune alte taskuri, el poate bloca scheduler-ul. Scheduler-ul este tratat ca o resursă care este accesibilă tuturor taskurilor. În acest scop, o resursă cu nume predefinit, RES_SCHEDULER, este automat generată ca resursă globală a fiecărei aplicaţii.

Întreruperile sunt recepţionate şi procesate independent de starea resursei

RES_SCHEDULER. Se asigură, însă, prevenirea re-dispecerizării taskurilor. 7.4. Probleme generale cu mecanismele de sincronizare 7.4.1. Explicarea inversării de prioritate

O problemă tipică a mecanismelor de sincronizare clasice –semafoare, etc.- este problema inversării de prioritate.

Inversarea de prioritate înseamnă ajungerea în situaţia ca un task de prioritate mai mică să

întârzie execuţia unui task de prioritate mai mare. SO OSEK dispune de mecanismul numit Protocol de Plafonare de Prioritate -OSEK Priority Ceiling Protocol- (a se vedea cap. 7.5) pentru a evita inversarea de prioritate.

24

Figura 7-1 Inversarea de prioritate pe semafoarele ocupate

Figura 7-1 ilustrează secvenţarea unui acces clasic al două taskuri la o resursă gestionată

cu ajutorul unui semafor, S1. Se presupune că suntem într-un sistem deplin preemptiv şi că taskul T1 are cea mai mare prioritate, iar taskul T4 cea mai mică prioritate. Taskul T4 ocupă resursa şi trece semaforul S1 pe ocupat. T1, devenind ready, îl deposedează pe T4 de procesor –cu ajutorul scheduler-ului, evident-, astfel că T1 trece în running şi T4 în ready. La un moment, T1 necesită aceeaşi resursă şi încearcă să o acceseze cu ajutorul aceluiaşi semafor, S1. Cum S1 este deja pe ocupat, T1 intră în starea waiting. Presupunând că, între timp, imediat după ce T1 a devenit ready, au devenit ready şi alte două taskuri, T2 şi T3, cu proprietăţile că prior(T4) < prior (T3) < prior (T2) < prior (T1), procesorul nu va fi acordat direct lui T4, ci mai întâi lui T2, apoi lui T3 şi abia după aceea lui T4. În felul acesta, în mod indirect, T2 şi T3, deşi au priorităţi mai mici decât T1, întârzie reluarea rulării acestuia, ocupând procesorul şi implicit nelăsându-l pe T4 să-şi avanseze şi să-şi încheie prompt sesiunea de utilizare a resursei după care aşteaptă T1. T4 va putea rula abia după ce se încheie (ajung în starea suspended) atât T2, cât şi T3, iar T1 şi mai târziu, mai precis după ce T4 eliberează resursa şi pune semaforul S1 pe liber. 7.4.2. Interblocările

O altă problemă tipică a mecanismelor de sincronizare clasice –semafoare, etc.- este problema interblocărilor între taskuri.

O interblocare înseamnă ţinerea la infinit în starea waiting a două taskuri TX şi TY,

datorită faptului că TX a ajuns să aibă nevoie de o resursă R1 pe care a apucat să o ocupe TY iar TY a ajuns să aibă nevoie de o resursă R2 pe care a apucat să o ocupe TX. Dacă accesul la cele două resurse se gestionează cu ajutorul a două semafoare, S1 şi S2, atunci următorul scenariu conduce la interblocare (vezi Figura 7-2): Fie T1 şi T2 două taskuri cu prior(T1)>prior(T2) şi R1 şi R2 două resurse folosite de ele, asociate cu două semafoare, S1 şi S2, respectiv. Presupunem că T1 reuşeşte să ocupe resursa R1, punând semaforul S1 pe ocupat şi că, ceva mai târziu, el se blochează, trecând în starea waiting, întrucât aşteaptă producerea unui eveniment. Presupunem

25

că, în continuare, intră în execuţie, trecând în starea running, T2 şi că T2 are nevoie de resursa R2, reuşind să o ocupe şi, implicit, punând semaforul S2 pe ocupat. După un timp, evenimentul aşteptat de T1 se produce. T1 devine ready şi apoi reintră în rulare, trecând în starea running. T2, pierzând procesorul, trece în starea ready. Presupunem că T1 are nevoie de resursa R2. El nu o poate accesa, ea fiind în lucru la T2, fapt indicat de semaforul S2, aflat pe ocupat. T1 se blochează, intrând în starea waiting, în care aşteaptă ca T2 să termine lucrul cu R2. Intră în rulare din nou T2. Presupunem că T2, înainte de a termina lucrul cu R2, are nevoie de R1. El nu o poate accesa, ea fiind în lucru la T1, fapt indicat de semaforul S1, aflat pe ocupat. T2 se blochează, intrând în starea waiting, în care aşteaptă ca T1 să termine lucrul cu R1. S-a ajuns, astfel, la interblocare.

Figura 7-2 Situaţia deadlock în utilizarea semafoarelor

7.5. OSEK Priority Ceiling Protocol (Protocolul OSEK de Plafonare a Priorităţilor)

Pentru a evita inversarea de prioritate şi interblocarea, SO OSEK asigură următoarele: • La generarea sistemului, se asignează static fiecărei resurse propria prioritate de plafon.

Prioritatea de plafon va fi setată cel puţin la cea mai înaltă dintre priorităţile tuturor taskurilor care accesează resursa şi sub cea mai joasă dintre priorităţile tuturor taskurilor care nu accesează resursa, având priorităţile mai sus decât cea mai înaltă dintre priorităţile tuturor taskurilor care accesează resursa.

• Dacă un task solicită o resursă şi prioritatea sa este mai mică decât prioritatea de plafon a acelei resurse, prioritatea taskului este crescută la această prioritate de plafon.

• Când taskul eliberează resursa, prioritatea sa este resetată la nivelul la care era înainte de a primi resursa.

Plafonarea de prioritate poate conduce la o posibilă întârziere pentru taskurile cu prioritatea

egală sau inferioară priorităţii de plafon. Această întârziere este limitată de timpul maxim cât resursa este ocupată de orice task de prioritate inferioară.

26

Taskurile care ar putea ocupa aceeaşi resursă ca taskul care rulează nu vor intra în starea running, datorită priorităţii lor cel mult egală cu a taskului care rulează, egală cu prioritatea de plafon asociată resursei. Abia când o resursă ocupată de un task este eliberată de către acesta, un alt task care are dreptul să o ocupe poate intra în starea running. Pentru taskurile preemptive (deposedabile de procesor), acest moment este un punct de re-dispecerizare (rescheduling).

Figura 7-3 Atribuirea unei resurse sub protocolul de plafonare a priorităţilor între taskuri premptive

Exemplul arătat în Figura 7-3 descrie următorul scenariu: Taskul T0 are cea mai înaltă prioritate şi taskul T4 cea mai joasă prioritate. Taskul T1 şi

taskul T4 sunt interesate să acceseze resursa. Se poate observa clar că inversarea de prioritate nu mai poate avea loc. Taskul de cea mai înaltă prioritate T1 aşteaptă doar pentru un timp cel mult egal cu durata maximă a ocupării resursei de către taskul T4.

7.6. OSEK Priority Ceiling Protocol with extensions for interrupt levels (Protocolul OSEK de Plafonare a Priorităţilor extins la rutinele de tratare a întreruperilor)

Extensia managementului resurselor la rutinele de întrerupere este opţională. Pentru a determina prioritatea de plafon a resurselor care sunt folosite de rutinele de tratare a întreruperilor, se asignează acestora priorităţi virtuale superioare priorităţilor tuturor taskurilor. Modulul în care sunt gestionate priorităţile –entităţi software- şi întreruperile –entităţi hardware- se stabileşte static.

• La generarea sistemului, se asignează static fiecărei resurse propria prioritate de plafon. Prioritatea de plafon va fi setată cel puţin la cea mai înaltă dintre priorităţile tuturor

27

taskurilor şi rutinelor de tratare a întreruperilor care accesează resursa şi sub cea mai joasă dintre priorităţile tuturor taskurilor şi rutinelor de tratare a întreruperilor care nu accesează resursa, având priorităţile mai sus decât cea mai înaltă dintre priorităţile tuturor taskurilor şi rutinelor de tratare a întreruperilor care accesează resursa.

• Dacă un task sau o rutină de tratare de întrerupere solicită o resursă şi prioritatea sa este mai mică decât prioritatea de plafon a acelei resurse, prioritatea taskului sau rutinei de tratare de întrerupere este crescută la această prioritate de plafon.

• Când taskul sau rutina de tratare de întrerupere eliberează resursa, prioritatea sa este resetată la nivelul la care era înainte de a primi resursa. Taskurile sau rutinele de tratare a întreruperilor care ar putea ocupa aceeaşi resursă ca

taskul sau rutina de tratare de întrerupere care rulează nu vor intra în starea running, datorită priorităţii lor cel mult egală cu a taskului sau rutinei de tratare de întrerupere care rulează, egală cu prioritatea de plafon asociată resursei. Abia când o resursă ocupată de un task sau o rutină de tratare de întrerupere este eliberată de către acesta / aceasta, un alt task sau rutină de tratare de întrerupere care are dreptul să o ocupe poate intra în starea running. Pentru taskurile preemptive (deposedabile de procesor), acest moment este un punct de re-dispecerizare (rescheduling), dacă noua prioritate a taskului aflat în rulare nu este o prioritate virtuală a unei rutine de tratare de întrerupere.

Figura 7-4 Atribuirea unei resurse sub protocolul de plafonare a priorităţilor între taskuri premptive şi rutine de tratare a întreruperilor

Exemplul arătat în Figura 7-4 descrie următorul scenariu:

28

Taskul preemptiv T1 este în rulare şi solicită o resursă partajată cu rutina de tratare de

întrerupere ISR1, asociată întreruperii INT1. Taskul T1 activează taskurile de prioritate mai înaltă T2 şi T3. Datorită protocolului OSEK de plafonare a priorităţilor, taskul T1 rămâne în rulare. Apare întreruperea INT1. Datorită protocolului OSEK de plafonare a priorităţilor, taskul T1 rămâne în rulare, iar rutina ISR1 este pusă în aşteptare. Apare întreruperea INT2. Rutina ISR2 întrerupe taskul T1, luându-i procesorul şi intrând ea în execuţie în locul său. Când ISR2 se finalizează, se reia taskul T1. Taskul T1 eliberează resursa. Rutina ISR1 intră în execuţie în locul taskului T1, care rămâne în starea ”întrerupt”, stare negestionată de SO. Când ISR1 se finalizează, intră în execuţie taskul T3. Când taskul T3 se finalizează, intră în execuţie taskul T2. După terminarea lui T2, reajunge la procesor pentru a-şi continua rularea T1.

Figura 7-5 Atribuirea unei resurse sub protocolul de plafonare a priorităţilor între rutine de tratare a întreruperilor

Exemplul arătat în Figura 7-5 descrie următorul scenariu:

Taskul preemptiv T1 este în rulare. Apare întreruperea INT1. Taskul T1 este întrerupt şi

intră în rulare ISR1. Rutina ISR1 solicită o resursă partajată cu rutina de tratare de întrerupere ISR2, asociată întreruperii INT2. Apare întreruperea INT2, de prioritate superioară. Datorită protocolului OSEK de plafonare a priorităţilor, rutina ISR1 rămâne în rulare, iar rutina ISR2 este pusă în aşteptare. Apare întreruperea INT3. Datorită faptului că rutina sa de deservire, ISR3, are

29

o prioritate mai mare decât ISR1, ISR1 este întreruptă şi intră în execuţie ISR3. ISR3 activează taskul T2. După ce INT3 se finalizează, INT1 reintră la procesor şi continuă. După ce INT1 eliberează resursa în dispută, se execută INT2, datorită priorităţii sale mai mari decât a lui ISR1. După ce ISR2 se încheie, continuă ISR1. După ce ISR1 se încheie, reintră la procesor şi continuă T2, datorită priorităţii sale mai înalte decât a lui T1, T1 care rămâne în starea ready. După ce T2 se încheie, se reia execuţia lui T1.

8. Alarme 8.1. Preliminarii

Alarmele sunt întreruperi generate de timer-e la momente de timp programate. Timer-ele sunt numărătoare de impulsuri prevăzute cu diverse facilităţi, cum ar fi semnalarea atingerii prin incrementare a unui anumit conţinut sau semnalarea ajungerii, prin decrementare, la zero. O perioadă a impulsurilor numărate de timer-e se numeşte „tic”, în engleză ”tick”. SO OSEK are asociat cel puţin un timer. 8.2. Managementul alarmelor

SO OSEK asigură tratarea alarmelor prin activarea taskurilor, setarea evenimentelor sau apelul unor rutine utilizator de tratare a alarmelor (alarm-callback routine).

O alarmă expiră (se produce) când o valoare predefinită este atinsă într-un numărător

aflat pe post de timer. Această valoare poate fi relativă la conţinutul din momentul programării al numărătorului sau absolută. În primul caz, vorbim de alarme relative, iar în cazul al doilea, de alarme absolute. Alarmele pot fi definite ca singulare sau repetitive, ciclice. SO OSEK prevede, suplimentar, servicii de anulare a alarmelor şi de obţinere a stării curente a unei alarme. Alarmele se asignează static, la generarea sistemului, precizându-se timer-ul, task-ul ce trebuie activat, evenimentul ce trebuie setat sau rutina utilizator ce trebuie apelată.

Dependent de configurare, când o alarmă expiră se apelează o rutină utilizator (alarm-callback routine) sau se activează un task sau se setează un eveniment. Serviciile sistem permise în rutinele utilizator sunt listate în Figura 8-1. Activarea unui task sau setarea unui eveniment la expirarea unei alarme se face la fel ca în alte împrejurări, nimic specific nederivând din faptul că ele au loc ca urmare a expirării unei alarme.

Modul de asignare a alarmelor la timer‐e, ca şi acțiunile care trebuie să aibă loc când alarmele expiră se definesc static. Parametrii dinamici sunt doar valoarea contorului corespunzătoare expirării alarmei şi perioada alarmelor ciclice, respectiv dacă alarma este relativă sau absolută.

30

Figura 8-1. Serviciile sistem permise în rutinele utilizator

31

9. Gestiunea erorilor, trasarea şi depanarea 9.1. Rutinele cârlig (Hook routines)

SO OSEK oferă mecanismul rutinelor cârlig pentru a permite utilizatorului să definească acţiuni specifice.

Rutinele cârlig sunt: apelate de SO, într-un context dependent de implementare de prioritate mai înaltă decât toate taskurile parte a sistemului de operare (doar ca şi cadru) implementate de utilizator cu funcţionalitate definită de către acesta standardizate ca interfaţă, dar nu şi ca functionalitate, de aceea ele nu sunt, de obicei,

portabile abilitate să execute doar o parte din serviciile sistem (vezi Figura 8-1).

În SO OSEK, rutinele cârlig pot fi utilizate pentru:

start sistem (vezi cap. 9.3, System start-up). Rutina cârlig corespunzătoare

(StartupHook) este apelată după ce sistemul de operare startează, înainte de primul apel la scheduler

stop sistem (vezi cap. 9.4, System shutdown). Rutina cârlig corespunzătoare (ShutdownHook) este apelată când sistemul de operare îşi încheie activitatea, la comandă expresă sau în caz de erori severe

trasare-depanare (vezi cap. 9.5, Debugging) gestiunea erorilor

9.2. Gestiunea erorilor (Error handling)

Remarci generale

SO OSEK oferă un serviciu de tratare a erorilor, bazat pe un cadru predefinit, completat de utilizator. Două feluri de erori se disting: • Erori de aplicaţie

SO nu poate executa serviciul cerut corect, dar asumă corectitudinea datelor sale interne.

În acest caz, se recurge la o tratare centralizată a erorii. SO returnează un cod de eroare care poate fi folosit pentru tratarea descentralizată a erorii. Este la latitudinea utilizatorului să decidă ce să se întâmple, dependent de situaţia concretă. • Erori fatale

SO nu poate asuma corectitudinea datelor sale interne. În acest caz, sistemul de operare recurge la oprire (shutdown) centralizată.

32

Rutina cârlig de eroare (Error hook routine)

Rutina cârlig de eroare (ErrorHook) este apelată dacă un serviciu sistem returnează o

valoare diferită de E_OK. În funcţie de valoarea respectivă, în cadrul rutinei se desfăşoară acţiuni specifice. 9.3. Pornirea sistemului (System start-up)

Pornirea sistemului după un reset la procesor depinde de implementare, dar SO OSEK oferă suport pentru o demarare standardizată. SO OSEK nu forţează aplicaţia să definească taskuri speciale care să fie lansate după pornirea sistemului, dar el permite utilizatorului să specifice taskuri cu autostart (de la început Ready, în mod implicit) şi alarme cu autostart, cu ocazia generării sistemului.

Figura 9-1. Pornirea sistemului (System start-up)

1. După un reset, utilizatorul este liber să execute cod specific hardware-ului, cu întreruperile de categoria 2 nepermise. După executarea acestui cod:

2. Se apelează StartOS, ceea ce lansează sistemul de operare 3. SO execută funcţii de uz intern (iniţializări) şi apoi: 4. Apelează rutina cârlig StartupHook, în cadrul căreia utilizatorul poate face toate

iniţializările pe care le crede de cuviinţă. În timpul rutinei StartupHook, toate întreruperile utilizatorului sunt dezactivate.

5. SO validează întreruperile utilizatorului şi apelează scheduler-ul. 9.4. Oprirea sistemului (System shutdown)

SO OSEK oferă un serviciu pentru oprirea sistemului, ShutdownOS. Acest serviciu poate fi solicitat de către aplicaţie sau de către SO (de exemplu, în cazul unei erori fatale. Când serviciul ShutdownOS este apelat, SO va apela rutina cârlig ShutdownHook şi apoi va determina oprirea.

33

9.5. Depanarea (Debugging)

Două rutine cârlig (PreTaskHook şi PostTaskHook) sunt apelate când are loc o comutare de context sau, altfel spus, un schimb de taskuri la procesor. Aceste două rutine pot fi folosite pentru depanare sau pentru măsurarea timpului. Rutina PostTaskHook este apelată de fiecare dată înainte ca taskul vechi să părăsească starea Running. Rutina PreTaskHook este apelată de fiecare dată după ce noul task intră în starea Running.

Figura 9-2. Intrarea şi ieşirea din rulare a rutinelor PreTaskHook şi PostTaskHook

34

10. Serviciile sistem 10.1. Legitimitatea apelurilor

Serviciile sistem sunt apelabile din taskuri, rutine de tratare a întreruperilor, rutine cârlig şi rutine asociate alarmelor (alarm-callback routines). Tabelul 12-1 arată apelabilitatea fiecărui serviciu raportată la aceste entităţi.

Figura 10-1. API service restrictions

35

10.2. Aspecte privind tratarea erorilor

Pentru a păstra eficienţa şi rapiditatea sistemului, SO OSEK nu testează toate erorile în folosirea serviciilor sistem. Dacă aplicaţia utilizează serviciile sistem incorect, poate rezulta un comportament de sistem nedefinit.

Cele mai multe servicii sistem returnează o stare către utilizator. Returnarea stării E_OK

arată că a fost posibilă execuţia în bune condiţiuni a serviciului sistem. În situaţiile în care acest lucru nu a fost posibil, se returnează alte valori decât E_OK.

O stare alta decât E_OK ar putea semnifica nu neapărat o eroare, ci şi o avertizare. Un exemplu este returnarea stării serviciului sistem CancelAlarm, care informează că alarma de anulare este deja expirată. User-ul este astfel informat că taskul care aştepta expirarea alarmei a fost deja activat / scos din aşteptare, după caz, ceea ce, probabil, nu s-ar fi dorit.

Dacă este posibil să se elimine orice eroare în etapa de punere la punct a programului,

atunci varianta validată a programului se va genera fără tratarea erorilor, fiind superfluu să se mai testeze chiar şi dacă starea returnată este E_OK, fiind subînţeles că este.

Toate valorile returnate de serviciile sistem sunt listate în documentaţia OSEK, cu

descriere individualizată. În caz de eroare, SO OSEK apelează rutina ErrorHook, dacă este definită. Scopul rutinei

ErrorHook este de a trata informaţia de stare centralizat. Rutina ErrorHook este apelată doar dacă se returnează o valoare alta decât E_OK. În cazul unor erori fatale, din serviciul sistem nu se mai revine în aplicaţie, ci se produce

oprirea sistemului, prin serviciul ShutdownOS. Funcţionalitatea lui ShutdownOS este specifică implementării.

36

10.3. Descrierea serviciilor sistem 10.3.1. DeclareTask Sintaxă: DeclareTask ( <TaskIdentifier> ) Parametri (In):

TaskIdentifier = Identificatorul taskului (identificator C) Parametri (Out): - Descriere: DeclareTask serveşte pe post de declaraţie externă a unui task. Efectul şi utilizarea

acestui serviciu sunt similare cu cele ale declarării externe a variabilelor. Particularităţi: - Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.2. ActivateTask Sintaxă: StatusType ActivateTask ( TaskType <TaskID> ) Parametri (In):

TaskID = referinţa la taskul de trecut în starea ready Parametri (Out): - Descriere: Taskul <TaskID> este trecut din starea suspended în starea ready. SO asigură ca

taskul să intre la un moment dat, când el va fi cel mai îndreptăţit să primească procesorul, în execuţie, începând cu prima sa instrucţie.

Particularităţi: Serviciul poate fi apelat din taskuri şi ISR-uri (vezi Figura 12-1).

Redispecerizarea după apelul lui ActivateTask depinde de locul unde acesta este plasat (ISR, task nonpreemptiv, task preemptiv).

Dacă se returnează E_OS_LIMIT, atunci activarea este ignorată, pentru că există deja maximum de activări.

Când un task extins este trecut din starea suspended în starea ready, toate eventualele sale evenimente sunt şterse. Status:

• E_OK : lipsă eroare • E_OS_LIMIT: prea multe activări ale taskului <TaskID>

Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.3. TerminateTask Sintaxă: StatusType TerminateTask ( void ) Parametri: - Descriere: Acest serviciu cauzează terminarea taskului în rulare. Taskul în rulare este

transferat din starea running în starea suspended. Particularităţi: Resursele interne asignate taskului chemat să se termine sunt automat eliberate.

Alte resurse trebuie să fie eliberate înainte de apelul lui TerminateTask. Dacă

37

serviciul TerminateTask este rulat cu succes, el forţează o redispecertizare. Terminarea unei funcţii task fără apelul lui TerminateTask sau ChainTask este strict interzisă. Ea ar putea duce la un comportament imprevizibil.

Status:

• E_OK : lipsă eroare • E_OS_RESOURCE: Taskul încă ocupă resurse

Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.4. ChainTask Sintaxă: StatusType ChainTask ( TaskType <TaskID> ) Parametri (In):

TaskID = referinţa la taskul care trebuie activat pentru a-i succede taskului care se încheie Parametri (Out): - Descriere: Acest serviciu cauzează terminarea taskului în rulare. După terminarea acestui task,

este activat taskul <TaskID>. Folosind acest serviciu, se asigură ca taskul <TaskID> să-i urmeze la procesor taskului care se termină.

Particularităţi: Resursele interne asignate taskului chemat să se termine sunt automat eliberate. Alte resurse trebuie să fie eliberate înainte de apelul lui TerminateTask. Dacă taskul <TaskID> este tocmai taskul curent, atunci e ca şi cum el nici n-ar mai trece prin stările suspended şi ready, ci ar rămâne running, fără a putea vorbi însă de activare multiplă. Dacă serviciul ChainTask este rulat cu succes, el forţează o redispecerizare. Dacă serviciul TerminateTask este rulat cu succes, el forţează o redispecertizare. Terminarea unei funcţii task fără apelul lui TerminateTask sau ChainTask este strict interzisă. Ea ar putea duce la un comportament imprevizibil.

Status: • E_OK : lipsă eroare • E_OS_RESOURCE: Taskul încă ocupă resurse

Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.5. Schedule Syntax: StatusType Schedule (void ) Parametri: - Descriere: Dacă un task de prioritate mai mare este ready, resursele interne ale taskului în

rulare sunt eliberate, taskul în rulare este trecut în starea ready, contextul său este salvat şi taskul de prioritate mai mare este trecut în running. Altfel, taskul din care se apelează Schedule continuă.

Status: • E_OK : lipsă eroare • E_OS_RESOURCE: Taskul încă ocupă resurse

Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.6. GetTaskID Sintaxă: StatusType GetTaskID ( TaskRefType <TaskID> ) Parametri (In): -

38

Parametri (Out): TaskID = referinţa la taskul care tocmai rulează (este în starea running)

Descriere: GetTaskID returnează ID-ul taskului care tocmai rulează (este în starea running) Particularităţi: Poate fi apelat din task, ISR şi anumite rutine cârlig (vezi Figura 12-1). Status:

• E_OK : lipsă eroare Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.7. GetTaskState Sintaxă: StatusType GetTaskState ( TaskType <TaskID>, TaskStateRefType <State> ) Parametri (In):

TaskID = referinţa la taskul a cărui stare interesează Parametri (Out): -

State = referinţa la starea taskului <TaskID> Descriere: Returnează starea taskului indicat prin parametrul 1 (running, ready, waiting,

suspended) la momentul respectiv Particularităţi: Poate fi apelat din task, ISR şi anumite rutine cârlig (see Figure 12-1). Când este

apelat pentru un task care este activat multiplu, starea indicată va fi running dacă oricare din instanţe este în rulare.

Status: • E_OK : lipsă eroare • E_OS_ID: Taskul <TaskID> este invalid

Conformanţă: BCC1, BCC2, ECC1, ECC2 Starea în care este găsit taskul <TaskID> este indicată prin constantele: RUNNING pentru running. WAITING pentru waiting. READY pentru ready. SUSPENDED pentru suspended. INVALID_TASK pentru situa�ia în care indica�ia de task nu este validă. 10.3.8. EnableAllInterrupts Sintaxă: void EnableAllInterrupts ( void ) Parametri: - Descriere: Acest serviciu restaurează starea tuturor întreruperilor salvată prin

DisableAllInterrupts. Particularităţi: Serviciul poate fi apelat din task, ISR1, ISR2, dar nu şi din rutine cârlig.

Acest serviciu este perechea serviciului DisableAllInterrupts, iar scopul său este să delimiteze la capăt secţiunile critice de cod. Nu se admite niciun apel de serviciu sistem în interiorul secţiunilor critice. DisableAllInterrupts / EnableAllInterrupts nu admit încuibarea (imbricarea).

39

Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.9. DisableAllInterrupts Sintaxă: void DisableAllInterrupts (void ) Parametri (In): - Parametri (Out): - Descriere: Acest serviciu dezactivează toate întreruperile pentru care hardware-ul suportă

dezactivarea. Starea de dinainte de dezactivare este salvată pentru a putea fi apoi restaurată de EnableAllInterrupts.

Particularităţi: Serviciul poate fi apelat din task, ISR1, ISR2, dar nu şi din rutine cârlig Acest serviciu este destinat să delimiteze începutul secţiunilor critice de cod. Evident, aceste secţiuni vor fi încheiate prin apelul serviciului EnableAllInterrupts. În secţiunile critice, nu se admite apelul niciunui serviciu system.

DisableAllInterrupts / EnableAllInterrupts nu admit încuibarea (imbricarea). Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.10. ResumeAllInterrupts Sintaxă: void ResumeAllInterrupts ( void ) Parametri (In): - Parametri (Out): - Descriere: Acest serviciu restaurează starea de recunoaştere a tuturor întreruperilor salvată prin

SuspendAllInterrupts. Particularităţi: Serviciul poate fi apelat din task, ISR1, ISR2, dar nu şi din rutine cârlig

Acest serviciu este perechea serviciului SuspendAllInterrupts, iar scopul său este să delimiteze la capăt secţiunile critice de cod. În secţiunile critice, nu se admite apelul niciunui serviciu system. SuspendAllInterrupts/ResumeAllInterrupts pot fi încuibate. Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.11. SuspendAllInterrupts Sintaxă: void SuspendAllInterrupts ( void ) Parametri (In): - Parametri (Out): - Descriere: Acest serviciu salvează starea de recunoaştere a tuturor întreruperilor pentru a putea

fi apoi restaurată de ResumeAllInterrupts şi dezactivează toate întreruperile pentru care hardware-ul suportă dezactivarea.

Particularităţi: Serviciul poate fi apelat din task, ISR1, ISR2, rutină de tratare alarmă, dar nu şi din rutine cârlig.

40

Acest serviciu este destinat să delimiteze începutul secţiunilor critice de cod. Evident, aceste secţiuni vor fi încheiate prin apelul serviciului ResumeAllInterrupts. În secţiunile critice, nu se admite apelul niciunui serviciu sistem

SuspendAllInterrupts/ResumeAllInterrupts pot fi încuibate. Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.12. ResumeOSInterrupts Sintaxă: void ResumeOSInterrupts (void ) Parametri (In): - Parametri (Out): - Descriere: Acest serviciu restaurează starea de recunoaştere a întreruperilor salvată prin

SuspendOSInterrupts. Particularităţi: Serviciul poate fi apelat din task, ISR1, ISR2, dar nu şi din rutine cârlig

Acest serviciu este perechea serviciului SuspendOSInterrupts, iar scopul său este să delimiteze la capăt secţiunile critice de cod. În secţiunile critice, nu se admite apelul niciunui serviciu sistem SuspendOSInterrupts/ResumeOSInterrupts pot fi încuibate. Conformanţă: BCC1, BCC2, ECC1, ECC2 10.3.13. SuspendOSInterrupts Sintaxă: void SuspendOSInterrupts ( void ) Parametri (In): - Parametri (Out): - Descriere: Acest serviciu salvează starea de recunoaştere a întreruperilor de categoria 2 pentru a

putea fi apoi restaurată de ResumeOSInterrupts şi dezactivează recunoaşterea acestor întreruperi

Particularităţi: Serviciul poate fi apelat din task, ISR1, ISR2, dar nu şi din rutine cârlig

Acest serviciu este destinat să delimiteze începutul secţiunilor critice de cod. Evident, aceste secţiuni vor fi încheiate prin apelul serviciului ResumeOSInterrupts. În secţiunile critice, nu se admite apelul niciunui serviciu sistem

SuspendOSInterrupts/ResumeOSInterrupts pot fi încuibate. Conformanţă: BCC1, BCC2, ECC1, ECC2 Notă: ISR de categoria 2 se numesc prin sintaxa:

ISR (NumeFuncţieC) { }

Cuvântul cheie ISR este evaluat corespunzător la generarea sistemului. NumeFuncţieC

reprezintă numele funcţiei C aflată per post de rutină efectivă de tratare a întreruperii.

ISR de categoria 1 nu primesc nume, ele nefiind referite de SO OSEK.

41

10.4. Management-ul resurselor 10.4.1. DeclareResource Sintaxă:

DeclareResource (<ResourceIdentifier>) Parametri (In):

ResourceIdentifier = Identificator C dedicat numelui resursei Descriere:

DeclareResource serveşte la declararea unei resurse în sistem, similar cu declararea variabilelor externe

Particularităţi: - Conformanţă:

BCC1, BCC2, ECC1, ECC2 10.4.2. GetResource Sintaxă:

StatusType GetResource ( ResourceType <ResID> ) Parametri (In):

ResID = Identificatorul C al resursei Parametri (Out): - Descriere:

Acest apel serveşte pentru intrarea în secţiunea critică a resursei indicate prin ResID. Părăsirea respectivei secţiuni critice se face cu ReleaseResource.

Particularităţi: GetResourse implementează protocolul de plafonare a priorităţilor. Este recomandat ca apelurile lui GetResource şi ReleaseResource să apară în aceeaşi funcţie. În secţiunile critice nu este permis să se folosească servicii sistem care comportă puncte de rescheduling pentru taskurile non-preemptive (TerminateTask, ChainTask, Schedule şi WaitEvent). În general, secţiunile critice sunt scurte.

Conformanţă: BCC1, BCC2, ECC1, ECC2

10.4.3. ReleaseResource Sintaxă:

StatusType ReleaseResource ( ResourceType <ResID> ) Parametri (In):

ResID = Identificatorul C al resursei Parametri (Out): - Descriere:

ReleaseResource este perechea lui GetResource şi serveşte pentru ieşirea din secţiunea critică a resursei indicate prin ResID.

Particularităţi: Aceleaşi de la GetResource.


42

10.5. Controlul evenimentelor 10.5.1. DeclareEvent Sintaxă:

DeclareEvent (<EventIdentifier>) Parametri (In):

EventIdentifier = Identificator C dedicat numelui evenimentului Descriere:

DeclareEvent serveşte la declararea unui eveniment în sistem, similar cu declararea variabilelor externe


ECC1, ECC2 10.5.2. SetEvent Sintaxă:

StatusType SetEvent ( TaskType <TaskID> EventMaskType <Mask> ) Parametri (In):

TaskID = Identificatorul taskului pentru care unul sau mai multe evenimente sunt setate, conform măştii <Mask> Mask = Masca evenimentelor care se setează

Parametri (Out): - Descriere:

SetEvent serveşte la a anunţa taskul <TaskID> de producerea unuia sau mai multor evenimente, conform parametrului <Mask>


ECC1, ECC2

10.5.3. ClearEvent Sintaxă:

StatusType ClearEvent (EventMaskType <Mask>) Parametri (In) :

Mask = Masca evenimentelor care se şterg Parametri (Out): - Descriere:

Evenimentele taskului extins care apelează (adică: în care se execută) ClearEvent sunt şterse, conform parametrului <Mask>

Particularităţi: Serviciul sistem ClearEvent poate fi executat cu referire la un anumit eveniment doar în taskul proprietar al acestui eveniment

Conformanţă: ECC1, ECC2

10.5.4. GetEvent Sintaxă:

43

StatusType GetEvent ( TaskType <TaskID>, EventMaskRefType <&Event> ) Parametri (In) :

TaskID = Identificatorul taskului a cărui mască de evenimente se returnează Parametri (Out):

Event = Variabila în care se returnează masca de evenimente în cauză. <&Event> este referinţa la această variabilă.

Descriere: Acest serviciu returnează starea curentă a tuturor evenimentelor taskului <TaskID>, nu numai a evenimentelor pe care taskul <TaskID> tocmai le aşteaptă


10.5.5. WaitEvent Sintaxă:

StatusType WaitEvent ( EventMaskType <Mask> ) Parametri (In) :

Mask = Masca evenimentelor pe care taskul care apelează serviciul le aşteaptă Parametri (Out): - Descriere:

Starea taskului care apelează serviciul este setată la waiting, mai puţin în cazul în care, respectiv până când cel puţin unul dintre evenimentele specificate prin parametrul <Mask> este setat.

Particularităţi: Acest serviciu forţează un rescheduling (o redispecerizare) dacă o condiţie de aşteptare apare. Dacă are loc un resceduling, resursa internă a taskului este eliberată cât timp taskul este în starea waiting.


10.6. Alarme 10.6.1. DeclareAlarm Sintaxă:

DeclareAlarm ( <AlarmIdentifier> ) Parametri (In) :

AlarmIdentifier = Identificatorul C al alarmei Descriere:

DeclareAlarm serveşte la declararea unei alarme în sistem, similar cu declararea variabilelor externe


44

10.6.2. GetAlarmBase Sintaxă:

StatusType GetAlarmBase ( AlarmType <AlarmID>, AlarmBaseRefType <&Info> ) Parametri (In):

AlarmID = Identificatorul alarmei Parametri (Out):

Info = Variabila în care se returnează structura cu constantele bazei alarmei, AlarmBase. <&Info> este referinţa la această variabilă

Descriere: Serviciul sistem GetAlarmBase citeşte caracteristicile bazei alarmei şi le returnează prin variabila <Info>. Valoarea returnată, <Info> este o structură în care se stochează informaţia de tipul de dată AlarmBase.


10.6.3. GetAlarm Sintaxă:

StatusType GetAlarm ( AlarmType <AlarmID> TickRefType <&Tick>) Parametri (In):

AlarmID = Identificatorul C al alarmei vizate Parametri (Out):

Tick = Variabila în care se returnează valoarea relativă în tick-uri rămasă până la expirarea alarmei indicate de parametrul <AlarmID>; <&Tick> este referinţa la această variabilă.

Descriere: Serviciul sistem GetAlarm returnează în variabila spre care pointează parametrul <&Tick> -deci: în variabila Tick- valoarea relativă în tick-uri rămasă până la expirarea alarmei indicate de parametrul <AlarmID>.


10.6.4. SetRelAlarm Sintaxă:

StatusType SetRelAlarm ( AlarmType <AlarmID>, TickType <increment>, TickType <cycle> )

Parametri (In): AlarmID = Identificatorul unei entităţi de tip alarmă increment = Valoarea relativă în tick-uri, după care expiră alarma cycle = Valoarea cu care alarma ciclează în cazul că alarma este ciclică. În cazul alarmelor singulare, parametrul <cycle> va fi zero


45

Serviciul sistem acaparează şi programează entitatea alarmă indicată de parametrul <AlarmID>. Când contorul alarmei ajunge să aibă numărat numărul de tick-uri indicat de parametrul <increment>, taskul asignat alarmei <AlarmID> este activat ori evenimentul asociat este setat ori o rutină alarm-callback este apelată.

Particularităţi: Dacă valoarea relativă <increment> este foarte mică, este posibil ca alarma să expire şi taskul să devină ready sau apelul la rutina alarm-callback să se producă înainte ca serviciul sistem SetRelAlarm să fie părăsit şi să se revină în zona user-ului. Dacă <cycle> este diferit de zero, elementul alarmă în cauză este reamorsat imediat după ce valoarea relativă <cycle> expiră. Alarma <AlarmID> trebuie să nu fie deja în uz când se execută SetRelAlarm. Pentru a programa un element alarmă în uz, trebuie mai întâi anulat respectivul uz.

Conformanţă: BCC1, BCC2, ECC1, ECC2; În cazul asocierii cu evenimente: doar ECC1, ECC2

10.6.5. SetAbsAlarm Sintaxă:

StatusType SetAbsAlarm ( AlarmType <AlarmID>, TickType <start>, TickType <cycle> )

Parametri (In): AlarmID = Identificatorul unei entităţi de tip alarmă start = Valoarea absolută, în tick-uri cycle = Valoarea de ciclare în cazul alarmelor ciclice. În cazul unei alarme singulare, parametrul <cycle> este zero.


Serviciul sistem acaparează şi programează entitatea alarmă indicată de parametrul <AlarmID>. Când contorul alarmei atinge numărul de tick-uri indicat de parametrul <start>, taskul asignat alarmei <AlarmID> este activat ori evenimentul asociat este setat ori o rutină alarm-callback este apelată.

Particularităţi: Dacă valoarea relativă <start> este foarte apropiată de valoarea curentă, este posibil ca alarma să expire şi taskul să devină ready sau apelul la rutina alarm-callback să se producă înainte ca serviciul sistem SetAbsAlarm să fie părăsit şi să se revină în zona user-ului. Dacă <cycle> este diferit de zero, elementul alarmă în cauză este reamorsat imediat după ce valoarea relativă <cycle> expiră. Dacă valoarea absolută <start> a fost deja atinsă înaintea apelului serviciului sistem, alarma va expira abia când valoarea absolută <start> va fi atinsă din nou. Dacă <cycle> este diferit de zero, elementul alarmă în cauză este reamorsat imediat după ce valoarea relativă <cycle> expiră. Alarma <AlarmID> trebuie să nu fie deja în uz când se execută SetRelAlarm. Pentru a programa un element alarmă în uz, trebuie mai întâi anulat respectivul uz.

Conformanţă: BCC1, BCC2, ECC1, ECC2; În cazul asocierii cu evenimente: doar ECC1, ECC2

46

10.6.6. CancelAlarm Sintaxă:

StatusType CancelAlarm ( AlarmType <AlarmID> ) Parametri (In):

AlarmID = Identificatorul alarmei Parametri (Out): - Descriere:

Serviciul sistem CancelAlarm anulează alarma indicată prin parametrul <AlarmID>. Conformanţă:

BCC1, BCC2, ECC1, ECC2 Observaţie: O rutină alarm-callback este definită după modelul următor:

ALARMCALLBACK (AlarmCallBackName) { }

10.7. Controlul execuţiei Sistemului de Operare 10.7.1. StartOS Sintaxă:

void StartOS ( AppModeType <Mode> ) Parametri (In):

Mode = modul de aplicare Parametri (Out): - Descriere:

Utilizatorul poate apela acest serviciu sistem pentru a starta sistemul de operare într-un anume mod indicat de parametrul <Mode> dintre mai multe moduri posibile


10.7.2. ShutdownOS Sintaxă: void ShutdownOS ( StatusType <Error> ) Parametri (In):

Error = Cod de eroare Parametri (Out): - Descriere:

Utilizatorul poate apela acest serviciu sistem pentru a opri aplicaţia, atunci când ceva fatal se produce şi aceasta nu mai poate continua.

47

Dacă o rutină ShutdownHook este prinsă în configuraţie, atunci ea este apelată înainte de a se opri sistemul.


10.8. Rutinele cârlig (Hook routines) 10.8.1. ErrorHook Sintaxă:

void ErrorHook (StatusType <Error> ) Parametri (In):


Această rutină cârlig este apelată de sistemul de operare la sfârşitul serviciilor sistem atunci când acestea nu se execută corect şi returnează un cod de eroare ca atare.


10.8.2. PreTaskHook Sintaxă:

void PreTaskHook ( void ) Parametri (In): - Parametri (Out): - Descriere:

Această rutină cârlig este apelată de sistemul de operare înaintea execuţiei unui nou task, dar după realizarea tranziţiei respectivului task în starea running


10.8.3. PostTaskHook Sintaxă:

void PostTaskHook ( void ) Parametri (In): - Parametri (Out): - Descriere:

Această rutină cârlig este apelată de sistemul de operare după execuţia taskului curent, dar încă înaintea părăsirii de către el a stării running.


48

10.8.4. StartupHook Sintaxă:

void StartupHook ( void ) Parametri (In): - Parametri (Out): - Descriere:

Această rutină cârlig este apelată de sistemul de operare la sfârşitul iniţializării SO şi înainte ca scheduler-ul să-şi intre în rol.


10.8.5. ShutdownHook Sintaxă:

void ShutdownHook ( StatusType <Error> ) Parametri (In):


Această rutină cârlig este apelată de sistemul de operare când se execută serviciul ShutdownOS.


Documents

Sistemul de operare OSEK/VDX - aut.upt.roandreea.robu/CursSPTRPart2.pdf · sistemului de operare atât pentru sisteme cu procesoare simple, cât şi pentru sisteme cu procesoare complexe