Sunteți pe pagina 1din 10

Programarea Aplicatiilor In Timp Real

Aplicatiile in timp real asigura un raspuns in timp util. Sistemele trebuie sa aiba costuri scazute. Dezavantajul consta in faptul ca avem resurse limitate. Avem:

- sisteme concurete - sisteme current ( sistemele de operare ) Sistemele cu raspuns in timp real, asigura un raspuns la stimuli/ evenimente externe. Ca intrari au stimuli, iar ca iesiri au raspunsul propriu zis. Sistemul trebuie sa fie in stare sa interpreteze stimuli( stimulul trebuie captat ). Aplicatiile cu raspuns in timp real sunt folosite in sisteme incorporate ( embedded system ). Printr-un system incorporate intelegem un system de calcul cu hardware si software strans integrat, conceput pentru a indeplinii o functie dedicate ( cu un anumit scop). Sistemele de timp real trebuie sa aiba: pret corespunzator, dimensiuni mici, consum scazut si un raspuns in timp util. <<Print-un sisteme de timp real se intelege un system care raspunde evenimentelor externe in timp util.>>

Un system este de timp real, daca asigura raspunsul la anumite evenimente externe intr-un timp garantat. Un system de timp real este un system care raspunde unor stimuli externi inclusiv curgerea unei perioade de timp intr-un interval specificat finit de timp.

Evenimentele pot fi:

Singular

Multiple

Sincrone: intreruperi, planificare procese, threaduri

Asincrone: while(conditie) {…}

Interactiunea unui system de timp real cu mediul:

Periodica( comunicatia este initiate de catre systemul in timp real asupra sistemului care il controleaza. Actiunea este predictibila si are loc in interval predefinite de timp.)

Aperiodica( comunicatia initiate de catre sistemul controlat, este impredictibila cu aparitii aleatoare).

Mixta ( sistemul de timp real proceseaza si raspund in acelasi timp la evenimentele si stimuli generate de catre sistemul controlat, intr-un cadru de timp garantat ).

Interactiunea:

1. Periodica

2. Aperiodica

1/28/2013

1

3. Mixta

Tipuri de arhitecturi RTS:

Time line ( executie ciclica) fiecare subsistem executa o parte, fiecare se executa cyclic

Orientata

si

pe

eveniment(

event

driven

)

activitati

periodice

aperiodice

Pipe line

Client server

Caracteristicile STR:

Corectitudinea logica si functional

Corectitudinea cronometrarii calculele trebuie executate intr-o perioada de timp predefinita

Deterministice : timpul de raspuns la un anumit eveniment este marginit

Operare autonoma

Tolerant la defecte

Interoperabilitate

Predictibilitate

Posibilitatea de operare distribuita

Constrangeri de timp:

Termene

Termene strice ( hard ) termene cu toleranta 0, constrangeri strice. Daca termenul a expirat, rezultatele prelucrarii datelor nu mai au nici o valoare.

Termene soft sisteme care trebuie sa repsecte termenele cu un grad de flexibilitate. Dead line, diferite grade de tolerant. Realizate a.i. sa minimizeze numarul termenelor ratate. Un system soft poate fi transformat in sism hard prin constrangerea termenilor de timp, a.i. sa devina strice.

Fara constrangeri

Taskurile trebuiesc planificate a.i. sa respecte termenele strice sau mai putin stricte.

SISTEME DE OPERARE IN TIMP REAL

Sistemul de operare are rolul de a realize gestiunea resurselor hardware si software ale sistemului de calcul. Sistemul de operare este o masina virtuala care abstractizeaza functiile hardware. Sarcinile de baza:

- Control si alocare memorie

1/28/2013

2

- Gestionarea apeluri catre functiile system

- Controlul dispozitivelor de i/o

- Gestionarea comunicatiilor

- Manipularea fisiserelor

- Platform pentru rularea programelor si aplicatiilor.

Tipuri de sisteme de operare:

- sisteme de uz general ( GPOS ) - sisteme de timp real ( RTOS ), strans legate de platform FreeRTOS, RealTimeLinks.

Exista module care transforma sistemul de operare general in system de operare de timp real. Elemente commune prezente in ambele timpuri de SO:

Ambele tipuri au un grad de multiprocesare

Gestioneaza resursele hardware si software existente

Ofera servicii programelor de aplicatii( exp: i/o, comunicatii, intreruperi etc. )

Abstractizeaza partea hardware care o folosesc

Diferente intre tipuri:

Rtos au fiabilitate mai mare

Rtos au aplicatii facute stric pentru scopul pentru care lucreaza

Rtos au o adaptare mai buna la resursele puse la dispozitie

Rtos au viteza de lucru mai mare, termenul limita este mult mai bine respectat

Rtos au un necesar de memorie mai redus

Algoritmii de planificare sunt adaptati aplicatiilor de timp real

Rtos prezinta support pentru sisteme inglobate fara disc( incarcare din ROM, flash etc.)

Gpos au o portabilitate mai buna a aplicatiilor

SISTEME DE OPERARE DE TIMP REAL Structura RTOS:

Sarcina de planificare planificator

Obiecte de timp real

Servicii Elementele unui RTOS:

1. Planificatorul

2. Obiecte de timp real

i) Temporizatoare, timere

ii) Procese, fire, taskuri

iii) Interrupt service routine

iv) Asynchronous service routine

v) Evenimente

1/28/2013

3

vi)

Mutex

vii)Semafoare binare sau generalizate viii) Cozei de mesaje

ix) Cutii postale

x) Canale de comunicatie ( pipes )

3. Servicii

- gestionare a timpului/ memorie/ dispozitivelor IO

- tratare a intreruperiilor

Planificatorul RT In central sistemului de operare se afla nucleul ( kernelul ), iar in central nucleului se afla planificatorul. Planificatorul stabileste pe baza un algoritmi

ordinea de executie a taskurilor ( care va fi urmatorul task ). Planificatorul are un dispecer care salveaza informatii legate de starea taskuri-lor, asigura schimbarea de context si predarea controlului executie noului task. Flux de control al executiei taskurilor:

- context task

- context intrerupere

- context kernel

Obiectele Obiectele sunt niste context specifice apelate de kernel. (parte statica ) Evenimentele Parte dinamica operatii pe care le executa nucleul asupra obiectele sistemului de operare de timp real. Servicii Planificare, temporizarea, intreruperi, gestionare a resurselor, gestionare serviciilor periferice, gestionare comunicatiilor. Facilitati obiecte: apel functie de system.

NUCLEUL SISTEMELOR DE OPERARE IN TIMP REAL (KERNEL ) :

Orice nucleu are 3 functii de baza:

Planificare resurselor : regula dupa care taskurile sunt lansate in productie

Dispecer: schimbarea starii taskurilor

Comunicare intre procese ( taskuri )

Are acces la mai multe nivele :

Nivelul aplicatie

Mediului de executie

Sistemului de operare

Masina

Hardware

1/28/2013

4

Utilizator :

System de operare - > interfata utilizator Executiv -> support fisiere Nucleu -> sincronizare, comunicare intre procese Micronucleu -> planificarea proceselor Nanonucleu -> controlul proceselor, gestiunea de memorie

Procesele:

Un process este un program aflat in executie ( GPOS ). Are posibilitatea de a lucre in propriul spatiu de memorie.

Facilitate de protective

Este controlat la nivel de client prin PID

Prezinta facilitate de comunicare si sincronizare

Fire de executie :

Au un spatiu comun de memorie

Cod separate

Prezinta facilitate de sincronizare

Fiindca ruleaza doar o singura aplicatiei, se poate renunta la protective, spatial de memorie propriu.

Task: imaginea unui program aflat in executie, in carcat din memorie. Are un ID propriu si prezinta facilitate de comunicare si sincronizare.

TIPURI DE PROCESE In functie de modalitatea de executie, avem:

Periodice operatiuni care se repeat la interval egale de timp ( citirea unor date de la traductoare, reactualizarea unor variabile de stare, implementarea unor algoritmi de control, reglare ). Prezinta trei timpi: timpul de calcul Tc, perioada de executie a intregului task T si timpul limita Tl.

Aperiodice frecventa minima la care trebuie sa se execute, frecventa in anumite situatii poate sa creasca. Procesele se implementeaza astfel incat frecventa de executie sa nu scada sub o anumita frecventa minima, cresterea sau scaderea frecventei este conditionate de incarcarea sau eliberarea procesului.

Sporadice utilizate pentru a raspunde unor solicitari a caror aparitie nu este specifica celorlalte procese. In unele situatii pot fi assimilate proceselor aperiodice, dar caracterizate de o perioada de minima de aparitie a evenimentelor. Taskurile pot functiona in :

- modul cooperativ

- modul preemptive ( planificatorul are grija sa aloce o felie de timp, apar

1/28/2013

5

prioritati, algoritmi de planificare, politici )

Procesele, taskurile, firele de executie, corutinele, semafoarele, toate sunt obiecte ale sistemului de operare, obiecte ce pot fi planificate si care concureaza pentru utilizarea timpului processor. In RTOS avem 2 tipuri de taskuri:

Procese system sunt create de sistemul de operare, initializarea lor se face la pornirea sistemului, find utile initalizarilor so. Exemple de procese: procese de generare a mesajelor system, de tratare a exceptiilor, de generare a semnalului de tact, de depanare. Mai exista si taskul IDLE, un taske care este pornit automat si care se foloseste de obicei la eliberarea memoriei. **

sunt create de utilizator si sunt dependente de

Procese utilizator, natura aplicatiei.

** Procesul IDLE are cea mai mica prioritate din system, utilizeaza doar timpul liber al procesorului in mai multe situatii pentru a optimiza, elibera memoria, iar alteori este folosit doar in bucla infinita. Asigura validitatea contorului de instructiuni ( in unele SO ) sau poate fi inlocuit de un alt task definit de utilizator in vederea utilizarii unor actiuni (ex: economisire energie prin suspendarea acitivatii procesorului ).

Sistemele de operare permit taskuri cu acelasi nivel de prioritate, insa se pot implementa taskuri si cu nivele diferite. Nivele de prioritate existente sunt limitate. Limitarea nr. de nivele de prioritate si de procese care pot avea acelasi nivel de prioritate, limiteaza numarul de taskuri care pot fi create in cadrul unei aplicatii. Procesele sistemului cu mici execptii, ruleaza la nivele de prioritate ridicate.

Caracteristici commune:

Succesiunea indepenta de instructiuni care are allocate resurse pentru executie

Procesele concureaza intre ele pentru a fi executate de process si pentru a accesa anumite resurse ale sistemului.

Implementarea la nivel de taskuri sau corutine permite descompunerea functional a unui system, prezentand avantajul optimizarii intrarilor si iesirilor.

Complicatii serioase la gestionarea taskurilor, oblige programele sa aleaga un algoritm de planificare.

Orice task este caracterizate de 5 variabile :

Nume

Identificator unic

1/28/2013

6

Prioritatea

Stiva

Bloc de control al taskului.

Creare taskurilor din punct de vedere al utilizatorului, prezinta urmatoarele

sarcini:

Atribuirea numelui, prioritatea

Dimensiunea stivei

Subrutina procesului/ taskului

Din punct de vedere al RTOS, unui task I se acorda: id-ul unic, I se creaza automat blocul de control asociat si I se aloca stiva de dim. Specificata de utilizator.

STARILE PROCESELOR/ TASKURILOR In decursul evolutiei unei aplicatii, taskurile component trec prin una sau mai multe stari posibile. Numarul de stari este dependent de fiecare SO in parte. In FreeRTOS exista 4 stari posibile:

Running ( ruleaza ) taskul current utilizeaza procesorul ( are alocat timp processor )

Ready ( pregatit ) taskul este gata de executie ( nu este in stare blocata sau suspendata )

Suspended ( suspendat ) stare care caracterizeaza taskurile ce nu sunt disponibile pentru planificare.

Delayed ( amanat, blocat ) task care a fost amanat, ex: trebuie sa iasa din executie pentru un anumit timp setat. Evolutia taskurilor si proceselor

La firele de executie se consuma prea mult timp cu crearea proceselor. In RTOS sunt resurse putin, iar timpul primit trebuie sa fie utilizat cat mai efficient. Task : cod propriu, stiva proprie, multiprocessor, rulare in parallel. Alocarea stivei pentru fiecare task este o pierdere de resurse, de aceea se utilizeaza o stiva comuna. In RTOS se implementeaza notiunea de automat finit, structura si regula de evolutie sunt specific fiecarui SO. Fiecare task este intr-o stare, iar de-a lungul timpul trece prin mai multe stari. Tipuri stari :

Active ( in executie ) stare in care taskul este active ( prioritatea cea mai mare)

Blocata semnificatia starii depinde de SO in cauza, poate ingloba:

amanre si asteptare

Gata de executie ( ready ) procesul este gata de executie, dar nu au prioritatea necesara pentru a fi executate

Amanita starea in care procesul asteapta trecerea unei

1/28/2013

7

temporizari

Suspendata de obicei utilize pentru depanarea sistemului

Asteptare specifica taskurilor care asteapta eliberarea unor resurse sau aparitia unor evenimente

Tratare a intreruperilor se trece la aparitia unei intreruperi

Adormita folosita in cazul proceselor aflat intr-o stare inainte de a fi disponibile sistemului de operare sau eliminate complet din aplicatie ( terminated )

Observatie:

Modelul cel mai simplu: 2 stari -> ready + run Model cu 3 stari : gata de executie, blocat, rulat

la inceput planificare G E deplanificare utilizare
la inceput
planificare
G
E
deplanificare
utilizare
la inceput planificare G E deplanificare utilizare planif S G deplanif creare G planificare E

planif

S

G

deplanif

creare G planificare E deplanificare D termin ast. temporizare
creare
G
planificare
E
deplanificare
D
termin
ast.
temporizare

G : gata de executie

B : blocat

E : executie

S : suspendat

A : asteptare

D : adormita

I : tratarea intreruperiilor Din B in G se trece printr-o coada de astepare, pregatite de executie.

Observatie

:

cand un task

este

ready,

el

concureaza

la resursele

1/28/2013

8

procesorului impreuna cu celelalte taskuri in acea stare.

In marea majoritate pe platformele monoprocesor, cand un task este in executie poate trece in starea Ready daca nu si-a terminat executia ( interrupt de un task cu o prioritate mai mare ) sau Blocata ( a cerut o resursa indisponibila, a facut un apel ce necesita apariata unui eveniment, a facut un apel la o functie care introduce o intarziere a executiei ). Starea blocata a fost introdusa pentru a permite taskurilor cu prioritate mai mica sa fie executate. In aceasta stare se poate ajunge in urma unui apel de system blocant siu se ramane in aceasta stare atat timpcat este valabila conditia de blocare. La “deblocarea” taskului se poate trece in starea de executie, data are prioritatea mai mare si in starea ready in celelalte situatii.

Trecerea dintr-o stare in alta a unui task se face prin niste apeluri special de system:

vTaskSuspend

vTaskResume

vTaskCreate ( taskul se creaza in starea ready )

vTaskSchedulerTask ( disponibilitatea taskurilor )

Regula presupune pargurea unui numar de pasi:

- creara de procese

- intializarea RTOS

- taskurile sunt facute disponibile sistemului de operare

Eliminarea taskurilor:

scoaterea taskului

din

operare( vTaskDelete, exit () )

evidenta

sistemului

de

poate presupune sau nu eliberarea resurselor folosite de catre acesta

intotdeauna terminarea unui process trebuie realizata dupa eliberarea tuturor resurselor, in caz contrar se ajunge la alocarea unor resurse sau a intregului system. Planificarea taskurilor In planificarea preemptive se realizeaza automat prin intermediul algoritmului de planificare, astfel ca acest algoritm determina tranzitia taskurilor dintr-o stare in alta. RTOS: apeluri de system pentru schimbarea starii taskurilor (daca schimbam prioritatea este schimbat taskul cu prioritate mare ). Din punct de vedere al programatorului, exista un set de functii pentru controlul starii taskurilor:

suspendarea vTaskSuspend()

reluarea executie vTaskResume()

intarzierea executiei vTaskDelay()/ vTaskDelayUntil()

1/28/2013

9

repornirea proceselor vTaskResumeAll()

modificarea prioritatii

blocarea/ deblocarea vEnterCritical()/ vPortExitCritical()

CONTROLUL CONCURENTEI IN SISTEME DE OPERARE IN TIMP REAL

O aplicatie de timp real poate fi implementata in 2 stiluri:

Structurat aplicatia se desfasoara pe un singur fir. Determinam fiecare secventa de cod ce timp dureaza si planificam astfel codul sa fie indeplinita conditia de timp limita. Anumite secvente pot aparea asincron: intrerupere( pseudo parallelism ). Resursele sunt mult mai evaluate( ARM ).

Programarea paralela fire de executie, procese/ taskuri, corutine. Problema controlului concurrent: comunicare, sincronizare. Programatorul rezolva problemele de concurenta. Resursa critica se gaseste in regiune critica( zona de cod in care un task acceseaza resursa ). Excluziunea mutual a doua sau mai multe taskuri este o modalitate prin care un singur task se gaseste la un moment dat in regiunea critica. Exista obligativittea asigurarii sincronizarii la nivelul resursei. Activitatile taskurilor trebuie sa fie sincronizate din 2 puncte de vedere:

Blocarea accesului la resursa cand este utilizata de mai multe taskuri simultan

Taskurile trebuie coordonate a.i sa fie informate cand resursa este libera

Sincronizarea poate duce la problema: infometare( starvation ), impas ( dead lock ).

Mecanisme de rezolvare a problemelor ( FreeRTOS ):

- semafor binary

- semafor generalizat ( numerator )

- cozi de mesaje

Creare unui semafor binary: vSemaphoreCreateBinary, xSemaphoneCreateMutex, vSemaphoreCreateCounting, xSemaphoreTake, xSemaphoreGive.

Apeluri system de intreruperi: xSemaphoreGiveFromISR.

Coada de mesaje: xQueueCreate, xQueueDelete, xQueueSend, xQueueReceive, xQueueSendToBack, xQueueSendToFront.

1/28/2013

10