1/28/2013 1

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 2

3. Mixta

Tipuri de arhitecturi RTS:

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

fiecare se executa cyclic

Orientata pe eveniment( event driven ) – activitati periodice si

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 3

- 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 4

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 5

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 6

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. **

Procese utilizator, sunt create de utilizator si sunt dependente de

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 7

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 8

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

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

la inceput planificare

G

E

deplanificare

utilizare

B

resursa

nedisponibila

G

planif deplanif

S

A E

creare G

planificare E

deplanificare

D termin ast.

temporizare

A I

1/28/2013 9

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 evidenta sistemului de

operare( vTaskDelete, exit () )

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 10

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.