4.

Sisteme de operare embedded

4.1. Introducere
Sistemul de operare (SO) este o sum de programe ce asigur interfaarea ntre un
utilizator (mai specific, dintre programul pe care un utilizator l ruleaz) i sistemul
hardware ce poate conine drept principal component un: microprocesor,
microcontroler sau DSP. Funcia fundamental a SO este de a gestiona resursele
hardware existente i de a permite un acces concurenial al diferitelor programe la
aceste resurse.
Necesitatea utilizrii unui sistem de operare pornete n principal de la diversitatea
procesoarelor existente pe pia (microprocesoare, DSP i microcontrolere), de la
diversitatea constructiv existent n cadrul aceleiai familii de procesoare din punct
de vedere al perifericelor i arhitecturilor existente (s lum drept exemplu doar
familia TMS320C64xx) dar i a diversitii echipamentelor ce pot fi conectate la un
anumit procesor.
Din acest motiv dac lum o simpl aplicaie, precum un program utilizat n
vizualizarea unui film, observm c n momentul n care aceast aplicaie sau oricare
alta este obligat s ruleze pe un anumit sistem, n situaia inexistenei unui sistem de
operare, atunci aceast aplicaie va trebui s in cont de tipul procesorului
(arhitectura acestuia, perifericele existente etc.) dar i de configuraia hardware a
sistemului pe care ruleaz (de ex. a mediilor de stocare existente, a modalitii de
conectare a acestora, a sistemului de fiiere existent etc.).
Aplicaie utilizator
(media player,
procesor de texte,
calcul tabelar, etc.)
Aplicaie utilizator
(media player,
procesor de texte,
calcul tabelar, etc.)

Sistem hardware
(tastatur, mouse,
display, medii de
stocare etc.)

Sistem de
operare

Sistem hardware
(tastatur, mouse,
display, medii de
stocare etc.)

Figura 4.1. Sistemul de operare o interfa facil ntre aplicaiile utilizatorilor i

partea hardware a sistemului
Prin introducerea sistemului de operare dezvoltatorii de aplicaii software nu mai
trebuie s in cont de toate detaliile tehnice, de specificitile, sistemului pe care vor
rula. Simultan exist un avantaj major i de partea productorilor dispozitivelor
hardware care nu mai trebuie s se preocupe de modalitatea n care va fi utilizat
sistemul de ctre cei care dezvolt programele.
Pentru dispozitivele embedded exist pe pia, la ora actual, o plaj larg de
sisteme de operare precum Windows Embedded Compact, Linux, Android, MeeGo,
Symbian, Palm webOS, iOS etc. Constructiv multe din sistemele de operare
menionate anterior au un punct comun: acela c au fost dezvoltate pe structura
sistemului de operare Linux. Astfel, sistemele de operare precum Android, MeeGo i
1

Palm webOS au toate la baz, ca nucleu sistemul de operare Linux. Existena

nucleului Linux determin ca aceste sisteme de operare s fie open source, putnd fi
folosite, respectiv, modificate i de ctre ali productori.
O alt caracteristic fundamental a SO este capacitatea acestora de a lucra sau nu
n timp real, deci de a fi sau nu SO de tip RTOS real time operating system. Dintre
acestea putem aminti Windows Embedded Compact (singurul sistem de operare din
suita Windows care este de tip RTOS), VxWorks, RTLinux, QNX etc.
Pe plcile de dezvoltare ce se bazeaz pe sistemul SoC-ul OMAP3530 produs de
firma Texas Instruments pot fi instalate sistem de operare precum Windows
Embedded Compact, Linux, Android etc.

4.2. Sisteme de operare n timp real

n accepiunea general a publicului, prin sisteme de operare n timp real RTOS
(Real Time Operating System) se subneleg acele sisteme de operare rapide i foarte
rapide capabile s rezolve o problem ntr-un interval scurt de timp. Dar, de exemplu,
n cazul reglrii temperaturii dintr-un furnal controlerul embedded trebuie s citeasc
i s regleze temperatura doar de cteva ori ntr-o secund n conformitate cu
algoritmul ales. n acest caz, un sistem care este capabil c furnizeze comanda corect
de fiecare dat cnd a fost programat este un sistem n timp real dar nu este unul
foarte rapid chiar este un sistem lent sau foarte lent comparativ cu posibilitile
existente la ora actual.
Orice sistem embedded preia, n primul pas, un flux de date1 de la una sau mai
multe intrri, flux pe care l proceseaz i, ulterior, pe baza rezultatelor obinute ofer
diferite date utilizatorilor sau comand anumite dispozitive2. Printr-o procesare n
timp real se nelege n primul rnd capabilitatea dispozitivului de a reaciona
(oferi date corecte utilizatorului sau de a oferi comanda n mod corect unui anumit
dispozitiv) ntr-un anumit interval de timp bine prestabilit astfel nct s nu apar
diferite efecte nedorite3.
n cadrul oricrui SO n timp real vor exista anumite funcii care trebuiesc
executate n timp real (de exemplu, monitorizarea unor senzori pentru sesizare unui
scurtcircuit) i alte funcii care nu sunt critice (de exemplu, afiarea unor date pe
interfaa grafic) i care pot fi ntrziate ntr-o anumit fereastr de timp. n momentul
n care 2 astfel funcii, prima ce necesit o execuie n timp real iar cea de a doua care
nu este critic, sunt gata de rulare simultan SO trebuie s aib un mecanism de
prioritizare a lor i chiar de oprire a altor funcii ne critice i de executare ct mai
rapid a celei n timp real. De aici se observ necesitatea existenei n cadrul SO a
unei componente capabil s execute funciile critice atunci cnd este necesar i s
ntrerup n aceste momente de timp execuia celorlalte componente necritice.
Sistemele de procesare n timp real se mpart n principal n dou clase majore:
soft i hard.

1
2
3

Aceste date pot fi de orice tip i de orice natur de la curentul ce trece printr-o ramur a unei puni
trifazat la valoarea unei acceleraii pn la informaia tactil preluat de la un touchscreen.
Un tiristor (prin intermediul unghiului de comand), prezint cantitatea de benzin, acioneaz un
sistem hidraulic de frnare etc.
Prezentare sacadat a datelor (de exemplu a unor imagini sau cadre) sau o comand ntrziat sau
inoportun a sistemului mecanic, chimic etc.

Sistemele de tip soft real time sunt acelea care nu determin comportri critice sau
poate chiar catastrofe rezultante n urma generrii ntrziate sau poate chiar de loc (din
cnd n cnd) a comenzii sau a rezultatului procesrii4. Deci, sistemele de tip soft real
time pot tolera ntrzieri i/sau variaii ale momentului realizrii efective a comenzii,
generate de sistemul de ntreruperi, timer-ele sistemului, programatorului nucleului
sistemului de operare (scheduler) sau a lipsei de determinism a codului ce proceseaz
datele.
Sistemele de tip hard real time, denumite i sisteme critice de procesare n timp
real, sunt acele sisteme ce trebuie s-i finalizeze rezultatul procesrii n mod
obligatoriu ntr-un anumit interval de timp foarte clar delimitat, nerespectarea unei
astfel de cerine putnd genera rezultate catastrofale5.
Dac lum n considerare faptul c cea mai mare parte a evenimentelor, datelor
etc. (ce trebuiesc procesate, analizate i ulterior n urma procesrii pe baza acestor
rezultate se va da o comand) se preiau la intervale regulate de timp sau se cunoate
cu certitudine intervalul minim de timp dup care poate avea loc un nou eveniment
atunci vom spune c un sistem este de tip hard real time dac timpul de ateptare pn
la preluarea noului set de date va fi ntotdeauna mai mare ca zero, vezi Figura 4.2.
Timp necesar prelurii, procesrii
i comenzii dispozitivului

Timp de
ateptare
t

n+1
n
Figura 4.2. Comportarea temporar a unui sistem de tip embedded
Din perspectiva celor afirmate n paragraful anterior i a Figura 4.2 putem afirma
c pentru un anumit sistem embedded ntotdeauna putem gsi o aplicaie pentru care
s nu avem un timp de ateptare mai mare ca zero i deci sistemul respectiv s nu fie
unul de tip hard real time. Dar din fericire nu aceasta este metoda de abordare a unei
probleme pentru o anumit problem se gsete acel sistem capabil s o rezolve i
nu invers.
Organizaia OMAC (Organization for Machine Automation and Control) ce
reprezint Industrial Automation Comunity din Statele Unite ale Americii dup
analiza a sute de aplicaii embedded, a concluzionat c n jur de 95% dintre aplicaiile
n timp real impun pentru buna funcionare timpi de laten de 1 ms sau mai mari n
timp ce variabilitatea de rspuns a sistemului nu trebuie s fie mai mare de 10% din
timpul de laten (100 s) [Hall, 2005].
n Figura 4.3 se prezint zonele n care sunt definite cea mai mare parte din
aplicaiile de timp real soft i hard aa cum au fost descrise acestea anterior. Se
observ c sistemele de operare ncepnd cu Windows NT i pn la sistemul de
operare Windows 7 se regsesc cu certitudine n zona sistemelor de operare de tip soft
(soft real time). Primul pas ctre zona SO de tip hard real time a fost realizat prin
intermediul SO Windows CE 2.0 dar care chiar dac avea caracteristici mult mai bune
4

Un astfel de sistem este de exemplu un DVD player. El proceseaz n timp real fluxul de date de
intrare dar n cazul n care din cnd n cnd nu reuete s decodeze corect un cadru nu se ntmpl
nici o catastrof.
De exemplu, n cazul sistemelor de tip ESP (Electronic Stability Program) existente n cadrul
automobilelor.

era nc era departe de ceea ce dorea piaa. n schimb SO Windows CE.Net (care este
versiunea Windows CE 4.0) este poziionat adnc n zona SO hard real time.
Versiunea Windows Embedded Compact chiar dac aduce mbuntiri fa de
versiunea Windows CE 4.0, performanele acestui SO sunt similare cu acesta sau
puin mai bune, poziionndu-se de asemenea adnc n zona SO hard real time.

Windows
CE 2.x

Linux

Figura 4.3. Caracterizarea diferitelor sisteme de operare6

O problem fundamental a tuturor SO care au interfa grafic (GUI graphical
user interface) este dat de consumul mare de resurse sistem necesare susinerii
funcionalitii interfeei grafice cu utilizatorul. Astfel, pe un SO de operare de tipul
Windows NT, pentru o procesare care dura n medie 1.5 ms fr nici o activitate de tip
tastatur i mouse s-a obinut un timp maxim de execuie, n situaia cea mai
defavorabil, de 60 ms atunci cnd tastatura i mouse-ul au fost utilizate simultan cu
aplicaia respectiv [Dekey, 2011]. n momentul n care s-au prioritizat n mod corect
funciile, procesarea a durat n medie de aceast dat doar 1.9 ms n acest caz pe
toat durata execuiei procesrii tastatura i mouse-ul nu au avut nici un efect,
evenimentele generate de aceste dispozitive nici nu au fost luate n considerare
datorit sistemului de prioriti.
O trstur fundamental a sistemului de operare Windows Embedded Compact
este capacitatea acestuia de a lucra n timp real. Acest sistem de operare este de altfel
singurul sistem de operare RTOS din cadrul familiei de sisteme de operare Windows7.
Sistemul de operare Windows Embedded Compact este unul n timp real deoarece
nucleul sistemului de operare i drivere-le acestuia ndeplinesc condiiile:
1. Cea mai mare parte a nucleului sistemului de operare i a driver-elor pot fi
ntrerupte;
2. Prile care nu pot fi ntrerupte (non preempted) sunt puine la numr i au
timpi de execuie mici (deci sunt zone scurte de cod). Lungimea acestor
6

Performanele prezentate n cadrul acestei imagini sunt caracteristice sistemelor de operare originale
fr inseria unor module sau plugin-uri suplimentare produse de alte companii (third-party) ce au
drept scop transformarea SO original n unul de tip RTOS.
De exemplu, sistemul de operare Windows XP nu este un sistem de operare n timp real dar,
ulterior, prin instalarea unor aplicaii, plugin-uri, precum Venturcom RTX sau TenAsys Intime
Windows XP (versiunea Embedded Standard) poate s ndeplineasc cerinele unui sistem de
operare n timp real.

zone determin n mod direct timpii de laten.

Tabelul 4.1. Rezultatele sistemului de operare Windows CE 5.0
Timpul de rspuns al
ntreruperii
Minim
Mediu
Maxim

ISR ncepe n

IST ncepe n

1.2 s
3.3 s
13.3 s

31.7 s
67.2 s
103.0 s

Timpii de rspuns prezentai n Tabelul 4.1 au fost msurai pentru sistemul de

operare Windows Embedded CE 5.0. Pentru sistemul de operare Windows Embedded
Compact aceti timpi sunt similari cu cei din tabelul anterior sau au fost puin
mbuntii. Din aceast perspectiv putem spune c datele din tabelul Tabelul 4.1
sunt caracteristice i pentru SO Windows Embedded Compact. Sistemul hardware i
software pe care s-au fcut determinrile a avut urmtoarele caracteristici:

O plac de dezvoltare Samsung SMDK2410;

200 MHz ARM cu o memorie cache 16x16;
SO Windows CE 5.0 cu o interfa grafic ce a inclus toate
componentele;
Sistemul rula un film video de tipul WMV.

Semnificaia termenilor ISR (interrupt service routine) i IST (interrupt service

thread) va fi prezentat n unul din capitolele urmtoare. Conceptual ISR reprezint
primul rspuns al SO n cazul activrii unei ntreruperi hardware externe, n timp ce
n cadrul IST se realizeaz funcia principal a ntreruperii.

5. Windows CE
5.1. Introducere
Sistemul de operare Windows Embedded Compact (cunoscut anterior sub
denumirea de Windows CE Consumer Electronics) este un sistem de operare
embedded, de timp real pe 32 de bii scalabil8 ce are urmtoarele caracteristici
definitorii:
1. Este un SO de timp real de tip SMP (symmetric multiprocessing).
Multiprocesarea simetric (symmetric multiprocessing SMP) definete
o arhitectur a unui sistem de calcul9 cu cel puin dou procesoare ce au
acces la un singur bloc de memorie i implic, n plus, utilizare unui
singur SO pentru a le controla. Task-urile existente n sistem pot rula pe
oricare din procesoarele existente indiferent de localizarea datelor
asignate fiecrui task n memorie. Un SO de tip SMP este acel SO ce
ruleaz pe o astfel de arhitectur i, de exemplu, are posibilitatea
distribuirii task-urilor ntre procesoare pentru o ncrcare eficient a lor.
2. Poate rula pe patru tipuri diferite de arhitecturi: ARM, MIPS, x86 i SH4
(pn la versiunea 6.0 R2).
3. Este un sistem de operare de tip multitasking preemtiv. Prin sistem de
operare multitask se nelege capacitatea unui SO de a rula mai multe
programe simultan din punctul de vedere al utilizatorului. Prin SO
preemtiv se nelege capacitatea de a opri temporar funcionarea unui
anumit task, fr a fi necesar permisiunea acestuia, cu intenia de a
continua execuia lui la un moment ulterior. Prin transferarea execuiei n
mod automat de la un task la altul se realizeaz o comutare a diferitelor
contexte de lucru (context switch) asociate fiecrui task. Comparativ, un
sistem de operare multitasking bazat pe cooperarea aplicailor
(cooperative multitasking10) se bazeaz pe existena unor mecanisme
prin intermediul crora acesta n mod voluntar cedeaz execuia altor
aplicaii.
4. Este un sistem de operare modular. Acest SO poate fi privit ca un joc
LEGO n care prin alegerea acelor componente optime (din cele peste
700 de componente existente) se poate construi imaginea SO n
conformitate cu necesitile aplicaiei/aplicaiilor ce vor rula pe acesta.
5. Modelul de memorie utilizat este de tipul virtual protejat. Acest sistem
de operare accept un spaiu virtual de adresare a memorie de maximum
4 Goctei. Aplicaiile utilizator folosesc primii 2 Goctei din memoria din
memoria virtual, n timp ce, nucleul sistemului de operare (kernel-ul)
utilizeaz ultimii 2 Goctei.
8
9

10

Scalabilitatea reprezint posibilitatea extinderii dimensiunii sistemului embedded (a prii

hardware a lui) fr a schimba principiul arhitectural al SO i al aplicaiilor ce ruleaz pe el.
Odat cu introducerea dispozitivelor de tip dual-core arhitectura SMPse regsete n majoritatea
calculatoarelor personale. n cadrul arhitecturii x86 astfel de procesoare sunt cele produse de Intel
(de ex. Xeon, Pentium D, Core Duo i Core 2 Duo) sau cele de AMD (de ex. Athlon64 X2, Quad
FX or Opteron).
Acest mod de lucru a fost utilizat de ctre compania Microsoft pn la sistemul de operare
Windows 95. Alte sisteme de operare precum MacOS au suportat acest mod de lucru pn la
versiunea Mac OS X, iar NetWare pn la versiunea 6.5.

6. Accept existena mai multor procese. Numrul maxim de procese pe

care acest sistem de operare l poate susine este de 32000.
7. Accept existena mai multor fire de execuie simultane.
8. Permite existena unui numr de 256 de prioriti de execuie.
9. Utilizeaz un API similar cu Win32 existent n cadrul celorlalte sisteme
de operare de tip Windows (Windows XP, Vista sau Windows 7).
Sistemul de operare Windows Embedded Compact nu este derivat din nici un alt
sistem de operare Windows (de exemplu din Windows 95 sau Windows NT).
Windows Embedded Compact nu este o versiune minimal a acestor sisteme de
operare.
Windows Embedded Compact a fost dezvoltat n mod independent fa de
celelalte sisteme de operare din familia Windows, avnd propriile caracteristici ce l
difereniaz net fa de ele (de exemplu, este singurul sistem de operare din familie de
tip RTOS real time operating system), dar este, simultan, i un sistem de operare
care face parte din aceast familie n sensul c are n comun cu SO din a cror clas
face parte multe caracteristici i concepte existente n cadrul acestei mari familii de
sisteme de operare.
De asemenea Windows CE nu este Windows Mobile. De exemplu, sistemul de
operare Windows Mobile 6 a fost dezvoltat avndu-se la baz platforma Windows CE
5.0 versiunea 5.2.
Avantajele majore n utilizarea sistemului de operare Windows Embedded CE
sunt urmtoarele:
1. Capacitatea: de a dezvolta ntr-un timp mult mai scurt (comparativ cu
alte SO) a diferitelor aplicaii, de a oferi diferite servicii (de exemplu de
mentenan a produsului software) mult mai repede i de a utiliza larga
experien existent;
2. Echipele de dezvoltare ale sistemelor embedded bazate pe SO Windows
Embedded CE sunt mult mai mici comparativ cu productorii de
echipamnte embedded bazate pe sistemul de operare Linux. n medie,
aceste echipe sunt cu 42% mai mici.
3. Capacitatea de a oferi pieii produsul final ntr-un timp mult mai scurt.
Comparativ cu sistemele de operare Linux, n medie, acest timp este cu
43% mai scurt;
4. Costurile totale de dezvoltare a sistemelor embedded sunt n medie n
cadrul SO Windows Embedded CE cu 73% mai mici comparativ cu
costurile de dezvoltare ale acelorai sisteme embedded ce au la baz SO
embedded Linux.

5.2. Arhitectura sistemului de operare Windows Embedded CE

Arhitectura sistemului de operare Windows CE este prezentat n Figura 5.1.
Nucleul sistemului de operare este format din toate blocurile funcionale ce sunt
grupate n Figura 5.1 n blocul numrul 1. Nucleul sistemului de operare conine toate
acele module software ce gestioneaz resursele calculatorului i controleaz
activitatea echipamentelor i a programelor rulate. Nucleul sistemului de operare
ofer toate acele mecanisme de abstractizare a resurselor hardware.
Datorit existenei a patru arhitecturi diferite, suportate de sistemul de operare
(SO) Windows Embedded Compact, rezult necesitatea existenei cte unui modul
specific fiecrei arhitecturi n parte kernell.dll. Prin intermediul acestei aplicaii
7

toate facilitile i specificitile fiecrei arhitecturi sunt abstractizate ntr-un set de

caracteristici comune astfel nct tratarea tuturor acestor arhitecturi s fie realizat
ntr-un mod omogen, similar. Aplicaia kernel.dll ofer funcionalitatea de baz a
sistemului de operare. Funciile de baz ale acestei aplicaii sunt:

s gestioneze memoria sistemului;

s planifice (prin intermediul planificatorului de procese), s coordoneze
i s controleze execuia mai multor fire de execuie dup anumite criterii
(timp de execuie, prioriti etc.);
s ofere mecanisme de sincronizare a firelor de execuie;
s gestioneze execuia programelor (s aloce resursele necesare executrii
programelor, s ncarce programele n memoria intern, s le lanseze n
execuie i s ncheie execuia acestora);
s gestioneze RTC (Real Time Clock ceasul de timp real).

User Mode

Kernel Mode

Figura 5.1. Arhitectura sistemului de operare Windows CE

n momentul n care este necesar valoarea RTC kernel.dll lanseaz o cerere ctre
OAL (OEM11 Adaptation Layer). Din punctul de vedere al kernel.dll acesta nu este
11

OEM - Original Equipment Manufacturer

interesat de modalitatea prin care OAL rezolv aceast cerere, n schimb OAL trebuie
la rndul lui s interogheze o anumit component hardware pentru a obine
rezultatul. Deci, rezult c OAL este acea component care trebuie s tie cum s se
interfaeze cu partea hardware pentru a executa aceast operaie fundamental.
Sistemul de operare i aplicaiile existente interacioneaz cu diferitele dispozitive
hardware (display, tastatur, sistemul audio etc.) prin intermediul driver-elor.
Driverele realizeaz abstractizare dintre diferitele componente ale sistemului de
operare i dispozitivele hardware cu care acestea sunt asociate. Fiecare dispozitiv
hardware (SD card, USB port, display, sistem de achiziie video, port serial sau
paralel etc.) trebuie s aib asociat un driver specific care s permit accesarea lor
fcndu-se abstractizare de toate specificitile de implementare a diferitelor
dispozitive ce aparin aceleiai clase de dispozitive (de exemplu un controler video ce
poate fi produs de un numr diferit de productori). Dup cum se observ din Figura
5.1 un driver poate fi ncrcat n spaiul nucleului (denumite kernel-mode drivers) sau
n spaiul utilizator, drivere ce sunt ncrcate ntr-un proces specializat udevice.exe
sunt denumite user-mode drivers. Avantajul ncrcrii unui driver n spaiul utilizator
este dat de faptul c aceast zon de memorie este mai tolerant la erori i nu
determin crparea sistemului.
Fiecare productor al diferitelor sisteme embedded, plci de baz, plci de
dezvoltare etc. care doresc s permit rularea sistemului de operare Windows CE
trebuie s ofere o combinaie specific plcii pe care o vnd de: drivere i un modul
OAL. O astfel de combinaie format dintr-un modul OAL (specific procesorului
plcii), un numr de drivere (specifice diferitelor dispozitive hardware integrate pe
plac) i un numr de fiiere de configurare poart numele de BSP (board support
package).
Aplicaia kitl.dll implementeaz Kernel Independent Transport Layer (KITL) i
este utilizat n comunicarea cu mediul de dezvoltare (drept component software ce
ruleaz pe un calculator personal) pentru operaiile de debug i de analiz a
aplicaiilor ce se gsesc pe sistemul de dezvoltare (n cazul nostru placa OMAP35xx).
Modulul gwes.dll este responsabil cu gestionarea elementelor de grafic, a
ferestrelor i a evenimentelor din sistem. Din funciile pe care le ndeplinete i trage
i numele Graphics, Windowing i Events Subsystem GWES. Deci, tot ce are
legtur cu interfaa grafic ncepnd de la ferestre, dialoguri, controale de tip edit,
check box, list box etc. meniuri etc. sau evenimentele asociate cu acestea sau cu
sistemul de operare sunt gestionate de acest DLL (dinamic link library). Acest modul
nglobeaz cea mai mare parte din funcionalitatea SO. Din acest motiv el trebuie
lansat naintea oricrei altei aplicaii. Totodat el este i modulul cel mai
componentizat din tot SO permind sau nu selectarea diferitelor funcionaliti pe
care le nglobeaz.
GWES este o component ce integreaz GDI-ul (graphics device interface),
managerul de ferestre i managerul de evenimente. GWES este compus din dou mari
submodule: utilizator (user) i GDI. Modulul utilizator include acele componente ale
GWES ce gestioneaz mesajele, evenimentele i totalitatea aciunilor de intrare
executate de utilizator prin intermediul tastaturii, mouse-ului i a ecranului tactil.
Modulul GDI nglobeaz acele componente responsabile de ieirea grafic ctre
utilizator.
Aplicaia 5.1: Modificai mrimea font-ul sistemului de operare n sensul creterii
acestuia. Drept rezultat, o dat cu o nou boot-are a SO font-ul tuturor icoanelor,
meniurilor etc. va avea o mrime dubl.
9

Indicaii: Unul din cele mai importante fiiere din cadrul SO este baza de date
registri. n cadrul acestui fiier sunt stocate o serie larg de informaii, inclusiv
mrimea font-ului cu ajutorul cruia se vor afia diferitele informaii pe interfaa
cu utilizatorul. Astfel n cadrul cheilor sunt stocate urmtoarele informaii:

HKEY_LOCAL_MACHINE\System\GDI\SysFnt aceast cheie este

utilizat pentru a stoca parametrii fontului utilizat de SO;
HKEY_LOCAL_MACHINE\System\GWE\Menu\BarFnt n aceast
cheie se stocheaz caracteristicile font-ului utilizat n cadrul diferitelor meniuri
sau a cartuelor de tip titlu a diferitelor ferestre.
HKEY_LOCAL_MACHINE\System\GWE\Menu\PopFnt stocheaz
caracteristicile fontului utilizat n cadrul ferestrelor de tip popup;
HKEY_LOCAL_MACHINE\System\GWE\OOMFnt cheie ce stocheaz
caracteristicile font-urilor ferestrelor de dialog ce afieaz mesaje de tip out-ofmemory.

n toate aceste chei, prezentate mai sus, sunt stocate mai multe valori ce au
semnificaia prezentat n tabelul de mai jos.
Tabelul 5.1. Semnificaia cmpurilor ce caracterizeaz diferitele
fonturi utilizate n sistem
Tipul de date a
cmpului

Semnificaie cmp

Nm: REG_SZ

Cmp ce stocheaz fontul utilizat (de exemplu Tahoma sau

Arial).

Ht: REG_DWORD

Dac subcheia HtInPts este 1, atunci aceast subcheie indic

nlimea fontului n sute de puncte n acest caz valoarea acestui
subcmp, Ht, va fi ntotdeauna pozitiv. Pentru afiarea fontului
aceast valoare va fi scalat n conformitate cu valoarea DPI a
driver-ului video.
Dac subcheia HtInPts este 0, nlimea fontului este n uniti
logice, iar valoarea stocat n subcheia Ht poate fi pozitiv sau
negativ.

HtInPts: DWORD

Valoarea implicit a cmpului este 0. Dac valoarea este 1

atunci subcheia Ht este n sute de puncte i nu n uniti logice.

It: REG_DWORD

Valoarea implicit a cmpului este 0, cnd ia valoarea 1 indic o

caracteristic italic a textului.

Wt: REG_DWORD

Valoarea implicit a cmpului este 190. Aceast subcheie indic

grosimea fontului.

CS: REG_DWORD

Valoarea implicit a cmpului este 0. Aceast valoare indic

setul de caractere ce este utilizat din cadrul font-ului.

Pentru obinerea rezultatului dorit se modific nregistrrile dorite din fiierul

MyWinCE12 C:/WINCE600 PUBLIC common Parameter Files
common.reg i se recompileaz imaginea SO.
Modulul filesys.dll iniializeaz o serie de dispozitive hardware (precum RTC
real-time clock), module software de tip API-uri (precum cele care: lucreaz cu
sistemul de fiiere, gestioneaz: bazele de date, regitrii, logurile evenimentelor
importante etc.), iniializeaz sistemul de regitri, ncarc profilul utilizatorului curent,
ncarc fiierele din memoria ROM n rdcina sistemului de operare, iniializeaz
12

Reprezint numele proiectului sub care se construiete imaginea noului SO.

10

fusul orar (GMT+2 pentru Romania) i DST (daylight saving time) dac este cazul
, etc. Imediat dup ce kernel-ul este lansat n execuie procesul filesys.dll este
executat cu specificitatea c acesta trebuie s i termine execuia naintea ca
kernel.dll s-i termine iniializarea. Acest lucru are loc deoarece kernel-ul are nevoie
de informaiile stocate n regitri, iar iniializarea regitrilor este realizat de procesul
filesys.dll.
De asemenea aplicaia filesys.dll comunic kernel-ului cnd este pregtit de a
ndeplini sarcini curente, deoarece procesul de iniializare a luat sfrit. Ulterior
filesys.dll ateapt un semn de la kernel pentru a boot-a restul sistemului de operare.
Tot filesys.dll va parcurge aplicaiile listate n HKEY_LOCAL_MACHINE\Init, iar
acestea vor fi lansate n execuie respectnd dependenele existente.
File system driver (FSD) manager, fsdmgr.dll, gestioneaz toate interaciunile
sistemului cu orice tip de FSD instalat. Fsdmgr.dll ofer interfaa standard cu toate
funciile de sistem de tipul CreateFile, CreateDirectory, RemoveDirectory etc.
caracteristice sistemului de operare Windows CE, gestionnd handle-urile
diferitelor fiiere. n plus, accesului la funciile ce gestioneaz sistemul de fiiere i
directoare, fsdmgr.dll ofer suport pentru funcii de tipul FSD_MountDisk i
FSD_UnmountDisk ce sunt apelate de managerul de dispozitive, devmgr.dll, atunci
cnd un dispozitiv ce are un FSD a fost nserat sau eliminat din sistem (de exemplu un
SD card sau un USB stick). n concluzie managerul FSD existent n modulul
fsdmgr.dll gestioneaz interaciunea cu toate FSD ce au fost instalate n sistem,
mapnd cererile aplicaiilor din sistem sau ale sistemului ctre funciile specifice
instalate ntr-un FSD.
Managerul dispozitivelor (Device Manager) este format din dou module
separate, device.dll i devmgr.dll, i are rolul de ncrca i gestiona drivere-le asociate
cu dispozitivele hardware. Totodat are rolul de a ncrca managerul de resurse I/O
(I/O Resource Manager) care citete i gestioneaz lista cu resursele disponibile din
regitri. Tot managerul dispozitivelor hardware notific i controleaz driverele
dispozitivelor hardware n legtur cu consumul acestor dispozitive oferind i un
serviciu de gestionare a puterii consumate.
Funciile API ce aparin sistemului sunt disponibile aplicaiilor prin intermediul
librriei coredll.dll ce este link-editat cu orice modul executabil de ctre sistemul de
operare. Toate modulele interne nucleului sistemului de operare sunt link-editate cu o
versiune specific a coredll.dll ce poart numele k.coredll.dll. n plus fa de acest
API sistem, sistemul de operare Windows CE ofer un API destinat aplicaiilor
generale, API (Win32 API) ce este similar cu cel existent pe calculatoarele personale
desktop sau laptop ce ruleaz sisteme de operare precum Windows XP i Windows 7.
Funciile existente n acest API pot fi accesate prin diferitele librrii existente precum
WinINet.dll, WinSock.dll, Winhttp.dll etc. vezi Figura 5.1.
Aplicaia 5.2: Deoarece n cadrul plcilor de dezvoltare OMAP EVM3530 n
momentul lansrii sistemului de operare Windows CE backlight-ul LCD-ului
(liquid crystal displays) este stins s se dezvolte o aplicaie care s fie capabil s
aprind sistemul de iluminare al LCD-ului.
Rezolvare: n paragrafele urmtoare se vor prezenta un numr de soluii,
implementri succesive, ale acestei probleme, pornindu-se de la dezvoltarea
aplicaiei i pn la integrarea acesteia cu sistemul de operare.
Pasul 1: Dezvoltarea unui program capabil s aprind/sting backlight-ul LCD-ului.

11

Fiecare dispozitiv hardware existent n cadrul unui dispozitiv embedded ce

ruleaz SO Windows CE se poate afla (din punctul de vedere al sistemului de
operare) n una din cele 5 stri prezentate n Tabelul 5.2.
Tabelul 5.2. Strile prestabilite de consum a dispozitivelor sistemului embedded
Stare

Descriere

D0

Dispozitiv alimentat complet

D1

Dispozitivul este funcional, dar este ntr-un regim de

funcionare ce urmrete economisirea energiei (power
savings mode).

D2

Dispozitiv n standby

D3

Dispozitiv plasat n sleep mode

D4

Dispozitiv nealimentat

Funcie de capabilitile dispozitivului hardware i de driverul asociat lui, parte

din aceste moduri de funcionare pot fi i sunt tratate n mod similar. De exemplu,
n driverul asociat backlightului se regsete codul (Solution Explorer
WINCE600 PLATFORM TI_EVM_3530 SRC drivers
backlight PDD Source files gpio_backlight.cpp):
switch (power)
{
case D0:
case D1:
GPIOSetBit(m_hGpio, m_gpioId);
break;
case D2:
case D3:
case D4:
GPIOClrBit(m_hGpio, m_gpioId);
break;
}

Analiznd acest segment de cod se observ c strile D0 i D1 sunt tratate n mod

similar (backlight alimentat) iar strile D2, D3 i D4 sunt de asemenea tratate n
acelai mod (backlight stins).
Programul, pe care l vom dezvolta, va avea o interfa grafic cu dou butoane.
La apsarea primului dintre ele backlight-ul se va aprinde iar la apsarea celui de al
doilea se va stinge. n funciile13 asociate acestor dou butoane se vor face dou
apeluri distincte, cu ajutorul funciei SetDevicePower, n vederea stingerii
(SetDevicePower(_T("BKL1:"),
POWER_NAME,
D4))
sau
aprinderii
(SetDevicePower(_T("BKL1:"), POWER_NAME, D0)) backlight-ului. Fiecare
dispozitiv hardware are asociat un nume unic cu ajutorul cruia este apelat, dup
cum s-a observat anterior. Exemple de astfel de nume: BKL1: pentru
backlight, WAV1: dispozitiv conversie DAC sunet, COM1: port serial,
CAM1 webcam, GPS1 dispozitiv GPS etc. Cererea de schimbare a strii
de alimentare a unui dispozitiv hardware nu implic automat i schimbarea
13

Pentru ca etichetele asociate cu strile dispozitivelor sau numele asociat diferitelor dispozitive s fie
cunoscute programului se include urmtorul fiier heder: "Pm.h".

12

acesteia. Driverul asociat dispozitivului poate determina sau nu o astfel de

schimbare funcie de starea de fapt i a altor dispozitive existente sau de comanda
dat de alte programe ce ruleaz pe sistemul embedded.
Starea tuturor dispozitivelor, din punct de vedere a puterii consumate, se poate
observa foarte uor n cadrul sistemului de operare Windows CE prin executarea
urmtoarei secvene de comenzi: Start Settings Control Panel Power
Device Status.

Figura 5.2. Interfaa grafic a aplicaiei CEFileWiz.exe

Pasul 2: Integrarea programului rezultant n imaginea sistemului de operare.
Pn n acest moment pentru aprinderea backlight-ului am folosit un mic
program (Apl_Backlight.exe) ce era poziionat n rdcina SD card-ului. n cadrul
acestui pas dorim s integram programul de aprindere/stingere a backlight-ului
creat anterior chiar n imaginea sistemului de operare n fiierul NK.bin.

(b)

(a)
Figura 5.3. Rezultatele utilizrii aplicaiei CEFileWiz.exe n:
(a) Catalog Items View i (b) Solution Explorer

Pentru a ne atinge acest obiectiv n acest pas vom utiliza o mic aplicaie
CEFileWiz.exe care va crea pentru noi toate fiierele necesare a fi integrate i pe
care le va nsera n structura de directoare a proiectului nostru. Dup lansarea n
execuie a acestei aplicaii, CEFileWiz.exe, n primul pas se aps butonului Add
File(s) i se alege fiierului Apl_Backlight.exe, vezi Figura 5.2, operaia
13

finalizndu-se cu apsarea butonului Build. Drept rezultat obinut n directorul

C:\WINCE600\3rdParty se va crea un director Backlight_Application care va
conine proiectul nostru.
Prin selectarea opiunii Refresh catalog tree (
) n tabul Catalog Items
View va apare o nou component (n subdirectorul Third Party) ce poate fi
selectat sau nu pentru a fi inclus n imaginea sistemului de operare, Figura
5.3(a). Selectai aceast nou component generat de ctre utilitarul
CEFileWiz.exe. Pentru nserarea ei n imaginea sistemului de operare trebuie
reconstruit imaginea acestuia. Pentru a evita construirea integral a imagini
sistemului de operare prin opiunea Build Solution (sau prin apsarea tastei F7) se
va selecta tab-ul Solution Explorer i de aici prin selectarea directorului
Backlight_Application (din directorul Subprojects), Figura 5.3(b), se d click
dreapta cu mous-ul selectndu-se opiunea Build. n acest mod se va compila doar
acest subproiect i nu ntregul sistem de operare. n pasul urmtor, trebuie s
copiem toate fiierele n directorul de unde se va construi imaginea SO pentru
aceasta urmai instruciunile: Build Copy Files to Release Directory. Totul se
finalizeaz cu construirea imaginii SO: Build Make Run-Time Image. Pentru
a verifica rezultatul obinut ncrcai imaginea sistemului de operare n placa de
dezvoltare i verificai existena fiierului Apl_Backlight.exe n cadrul directorului
Windows. n cazul n care acesta nu se regsete n directorul Windows se execut
urmtoarea secven de comenzi View Options... submeniu n care se
deselecteaz toate checkbox-urile.
Fiierele n care se stocheaz informaiile necesare introducerii aplicaiei
Apl_Backlight.exe
n
imaginea
sistemului
de
operare
sunt
Backlight_Application.bib (bib Binary Image Builder) i postlink.bat. Fiierul
postlink.bat are rolul de a copia n mod efectiv fiierul Apl_Backlight.exe n cadrul
structurii de directoare de unde se va genera imaginea sistemului de operare
(existnd n cadrul lui o line similar cu aceasta:
copy "D:\Teste_OMAP\Backlight\Apl_Backlight.exe" %_FLATRELEASEDIR%"
n timp ce fiierul Backlight_Application.bib specific ce fiiere vor fi incluse n
mod efectiv n cadrul imaginii sistemului de operare14. n cadrul lui este obligatoriu
s existe o linie de forma:
; Name
Path
; -------------- ---------------------------------Apl_Backlight.exe (_FLATRELEASEDIR)\Apl_Backlight.exe

Memory Type
----------NK

Pasul 3: Deoarece identificarea i lansarea n execuie a aplicaiei Apl_Backlight.exe

este dificil atta timp ct backlight-ul este stins, n cadrul acestui pas vom
configura imaginea sistemului de operare astfel nct aceast aplicaie s se lanseze
automat o dat cu pornirea sistemului de operare.
n cazul utilizrii interfeei cu utilizatorul (shell-ului) standard a sistemului de
operare Windows CE, explorer.exe, un shortcut plasat n directorul

14

Utilitarul ce construiete imaginea sistemului de operare (Romimage.exe) utilizeaz fiierele de tip

.bib (binary image builder) pentru a determina ce modulele i fiierele trebuiesc incluse n imaginea
SO. n plus fiierele .bib precizeaz i unde vor fi plasate aceste componente n memoria sistemului
embedded prin intermediul cmpului Memory Type.

14

\Windows\StartUp va avea drept efect lansarea automat n execuie a programului

respectiv imediat momentului terminrii iniializrii sistemul de operare.
Un fiier de tip shortcut este descris n sistemului de operare Windows CE de
urmtoarea structur intern:
[numr de caractere ce urmeaz simbolului diez]#[Calea ctre fiier]
De exemplu, n cazul nostru particular al aplicaiei Apl_Backlight.exe ce se gsete
n directorul Windows un shortcut ctre aceasta este un fiier text cu extensia lnk
(de exemplu backlight.lnk) ce are urmtorul coninut:
26#\Windows\Apl_Backlight.exe
Dup realizarea unui nou proiect ce are drept obiectiv introducerea fiierelor
backlight.lnk i Apl_Backlight.exe n cadrul imaginii sistemului de operare mai
trebuie copiat fiierul backlight.lnk n directorul \Windows\StartUp. Acest pas
trebuie executat n mod obligatoriu deoarece ambele fiiere se vor regsi n
directorul \Windows.
Pentru a ne atinge acest obiect ne vom folosi de fiierul de configurare
Backlight_Application.dat, Figura 5.3(b). Liniile acestui fiier pot include
urmtoarele comenzi i au urmtorul format:
[root:] [-Directory(nume_director)] [-File(fiier_final, fiier_iniial)]
Prin comanda [root:] se seteaz calea implicit drept rdcina sistemului de
operare. Pentru crearea unui director sau selectarea drept implicit a cii ctre un
anumit director existent se utilizeaz comanda [-Directory(nume_director)],
dac nume_director nu exist se creeaz, dac exist se ia drept director implicit.
Cu ajutorul comenzii [-File(fiier_final, fiier_iniial)] se copie un fiier cu
numele menionat i de la poziia indicat n fiier_iniial ctre destinaia implicit
sub numele fiier_final care poate fi sau nu identic cu cel iniial.
n cazul nostru particular introducei n fiierul Backlight_Application.dat
urmtoarea secven de comenzi:
Directory("\Windows\StartUp"):-File("backlight.lnk", "\Windows\backlight.lnk")
Recompilai doar acest proiect, ncrcai imaginea sistemului de operare i
observai c o dat cu lansarea n execuie a sistemului de operare se va lansa n
execuie i aplicaia dezvoltat anterior.
Pasul 4: Lansarea n execuie, cu ajutorul informaiilor stocate n regitrii sistemului
de operare, a unei aplicaii ce va determina aprinderea backlight-ului.
Metoda prezentat n cadrul pasului anterior are dezavantajul major c
funcioneaz doar n cazul utilizrii interfeei cu utilizatorul (shell-ului) standard al
sistemului de operare Windows CE fiind o facilitate a acestuia. n cele ce
urmeaz se va prezenta o metod foarte general de lansare a diferitelor aplicaii,
metod ce nu implic existena unor anumite constrngeri. Anterior s-a prezentat
c aplicaia
filesys.dll parcurge aplicaiile listate n cheia registru
HKEY_LOCAL_MACHINE\Init lansndu-le pe acestea n execuie.
Pentru a analiza structura cheii HKEY_LOCAL_MACHINE\Init se prezint
n Figura 5.4 structura intern a acesteia n cazul practic al sistemului de operare
utilizat n toate aceste exemple. nregistrrile de tipul LaunchXX, cu XX lund
valori ntregi n intervalul [00 ... 99], semnific secvena n care aplicaiile (numele
acestora este de tipul REG_SZ i nu trebuie s conin nici un argument) vor fi
lansate. Cu ct valoarea XX este mai mic cu att aplicaiile corespondente vor fi
15

lansate mai repede n execuie. Din Figura 5.4 se observ c modulele gwes.dll
(Graphics, Windowing i Events Subsystem) i device.dll (Device Manager) sunt
lansate n execuie prin intermediul acestui mecanism. De asemenea interfaa cu
utilizatorul este lansat n execuie tot prin intermediul mecanismelor existente n
sistemul de regitri. ntre toate aceste aplicaii, care sunt lansate n execuie prin
nregistrrile din baza de date regitri, pot exista anumite dependene ce sunt
gestionate prin intermediul cmpurilor DependXX asociate n mod direct cu
nregistrrile LaunchXX. n acest mod nregistrarea DependXX conine una sau
mai multe valori de tip REG_BINARY ce ne permite s menionm dependena
unei aplicaii de o alta sau de altele care trebuie ncrcate anterior aceleia care
depinde de ele.

Figura 5.4. Structura intern a nregistrrilor din cheia

HKEY_LOCAL_MACHINE\Init
Analiznd Figura 5.4 se observ c aplicaia device.dll este prima care se va
lansa ea nedepinznd de nici una anterioar ei. Aplicaia gwes.dll (Launch30)
depinde de device.dll. n cadrul nregistrrii Depend30 se regsete valoarea hexa
00 14 (2 octei stocai n ordine invers), care n zecimal este 20 adic aplicaia
lansat n execuie conform cu ordinea Launch30 depinde de Launch20. n mod
similar se observ c shell-ul sistemului de operare (explorer.exe) depinde de
lansarea n execuie a dll-ului conform prioritii Launch20 (00 14) i de aplicaia
care s-a lansat n execuie conform prioritii Launch30 (00 1e).
Toate aplicaiile specificate n cadrul cheii HKEY_LOCAL_MACHINE\Init
trebuie s informeze sistemul de operare c au fost ncrcate cu succes prin
intermediul funciei SignalStarted(), astfel nct aplicaiile ce depind de acestea pot
i ele la rndul lor s fie ncrcate. Parametrul care trebuie trimis funciei
SignalStarted() este parametrul pe care aplicaia l primete drept valoare n linia
de comand, din acest motiv este imposibil s se specifice o anumit valoare n
linia de comand n timpul ncrcrii aplicaiei.
Pentru a lansa o aplicaie proprie prin intermediul informaiilor stocate n
regitri fiierul project.reg trebuie modificat i trebuie s introducem o serie de
nregistrri, similare cu cele prezentate anterior i care s respecte toate
specifictile i restriciile necesare. Fiierul project.reg este localizat n Solution
Explorer EVM_3530 Parameters Files TI_EVM_3530:ARMV4I
(Active) project.reg.

16

Pentru atingerea acestui ultim obiectiv vom dezvolta o nou aplicaie urmrind
paii:
1. selectm n Solution Explorer directorul Subprojects i nserm un nou
subproiect (Add New Subproject ... prin click dreapta).
2. n fereastra ce tocmai s-a deschis alegem templat-ul WCE Console
Application iar n cadrul cmpului Subproject Name introducem
BacklightON, aciuni urmate de apsare butonului Next.
3. Selectm A simple Windows Embedded CE console application i
apsm butonul Finish.
4. Se completeaz fiierul BacklightON.cpp cu codul:
#include
#include
#include
#include

"stdafx.h"
<windows.h>
<commctrl.h>
"Pm.h"

int _tmain(int argc, TCHAR *argv[], TCHAR *envp[])

{
SignalStarted(wcstol(argv[0], _T('\0'), 10));
SetDevicePower(_T("BKL1:"), POWER_NAME, D4);
return 0;
}

5. Se completeaz fiierul BacklightON.reg cu nregistrrile ce sunt

prezentate n Figura 5.5.

Figura 5.5. Completrile ce se introduc n vederea lansrii automate n

execuie a aplicaiei
6. Se compileaz i se link-editeaz numai acest proiect.
7. Se ncarc imaginea sistemului de operare n placa de dezvoltare.
8. Se verific funcionarea corect a programului.

17

5.3. Procese, fire i fibre de execuie

5.3.1. Introducere
n cadrul sistemului de operare Windows Embedded Compact unitatea
fundamental de execuie este firul de execuie (thread-ul).
Un program executabil (de exemplu, un fiier cu extensia exe) conine cod, date i
diferite alte resurse (de exemplu imagini, icoane etc.). Un program este un proces
care conine cel puin un fir de execuie, numit fir de execuie primar. Dar, numrul
firelor de execuie ce pot fi lansate n execuie de ctre un proces nu este limitat de
exemplu, firul de execuie primar poate lansa n execuie un numr infinit de fire de
execuie (numr limitat din punct de vedere practic doar de resursele sistemului), care
la rndul lor pot lansa n execuie alte fire de execuie. Numrul maxim de procese pe
care sistemului de operare Windows Embedded Compact le poate suporta este de
32000.
Din prezentarea realizat n paragraful anterior se observ c un thread poate
proveni dintr-un proces sau din alt thread. Un proces va fi lansat n execuie de un
fiier cu extensia exe, fiind o colecie de fire de execuie (cel puin unul) ce au un
context comun de execuie. Fiierele exe pot crea fire de execuie capabile s
gestioneze ntreruperi. De asemenea un thread mai poate fi lansat n execuie i de
un driver. Un driver este un DLL (dinamic link library) ce poate rula n spaiul
nucleului (kernel-mode drivers) sau n spaiul utilizatorului (user-mode drivers) a se
vedea subcapitolul 5.2 i Figura 5.1. Driver-ele lanseaz fire de execuie ce
gestioneaz i satisfac necesitile impuse de cererile de ntrerupere. n acest
subcapitol i n urmtorul (5.3.2) vom prezenta problematica firelor de execuie ce
provin din procese, n timp ce n subcapitolul 5.3.4 se vor prezenta i analiza n
principal thread-urile ce sunt lansate n execuie de drivere.
Fiecare fir de execuie are i este caracterizat de propriul context de execuie ce
nglobeaz stiva proprie, prioritatea firului, drepturile de acces ale firului de execuie
etc. Firele de execuie ce aparin aceluiai proces mpart acelai spaiu de memorie, n
sensul c memoria vizibil (alocat) unui fir de execuie este disponibil tuturor
celorlalte fire de execuie ce aparin aceluiai proces. Existena aceleiai memorii
comune pentru dou sau mai multe fire de execuie, ce aparin aceluiai proces,
constituie un mare avantaj n sincronizarea firelor de execuie i n transferul datelor
ntre acestea.
Programatorul (scheduler) existent n cadrul nucleului sistemului de operare este
componenta ce gestioneaz execuia firelor de execuie. Programatorul asigur
execuia predictibil a firelor de execuie n conformitate cu prioritile acestora,
totodat el gestioneaz i schimbarea contextelor firelor de execuie. De asemenea, n
momentul apariiei unei ntreruperi, programatorul o ia n considerare i funcie de
prioritatea acesteia i de prioritile celorlalte fire de execuie o deservete sau nu.
Firele de execuie sunt gestionate (lansate sau ntrerupte din execuie) doar de
ctre programatorul (scheduler-ul) sistemului de operare.
Fibrele sunt gestionate de ctre un thread i nu de ctre programatorul sistemului
de operare aceasta este deosebirea fundamental ntre un thread i o fibr de
execuie. Fibrele au urmtoarele caracteristici n cadrul SO Windows Embedded
Compact:
O fibr este executat n cadrul contextului firului de execuie care a creato i lansat-o n execuie:
18

CreateFiber creeaz o fibr cu propria adres i stiv, dar nu o

execut
SwitchToFiber lanseaz n execuie o anumit fibr
Fiecare fir de execuie poate lansa i gestiona mai multe fibre de execuie:
GetFiberData ntoarce data transferat ctre o fibr
GetCurentFiber ntoarce adresa unei fibre
DeleteFiber terge fibra curent
Pentru a gestiona diferite fibre un thread trebuie convertit ctre o fibr de
ctre funcia:
ConvertThreadToFiber
Sistemul de operare nu este preemtiv cu fibrele ci doar cu firele de
execuie. Firul de execuie trebuie s gestioneze oprirea temporar a unei
fibre pentru a-i continua execuia la un moment ulterior.
O fibr este executat atta timp ct firul de execuie care o gestioneaz
este executat.

5.3.2. Caracteristici
Caracteristici generale
Windows Embedded Compact este un sistem de operare multitasking ce are la
baz o rulare a firelor de execuie pe baza unor felii de timp (quantum) care sunt n
mod normal egale cu 100 ms. Valoarea implicit a acestei felii de timp este setat de
OEM15 n OAL16 prin intermediul variabilei dwDefaultThreadQuantum17. De
exemplu, dac avem 5 fire de execuie (3 lansate de acelai proces i dou lansate de
dou procese diferite) cu aceeai prioritate fiecare i avnd toate acelai quantum,
fiecare dintre acestea obine 1/5 din timpul total de execuie al tuturor celor 5 fire de
execuie. Durata acestor felii de timp asociate diferitelor fire de execuie poate fi
modificat n mod dinamic sau interogat prin intermediul urmtoarelor dou funcii:
CeSetThreadQuantum
CeGetThreadQuantum
n momentul n care durata temporal a unei astfel de felii, asociat cu un fir de
execuie, este egal cu zero sistemul de operare exclude acel thread din cadrul
procesului de execuie ciclic a lui. Dac ns acel fir de execuie ruleaz, el va fi
executat pn la finalizarea lui, firul ne putnd fi ntrerupt de nici un fir de execuie cu
o prioritate similar sau mai mic, putnd fi ntrerupt doar de thread-uri ce au
prioriti superioare (de exemplu, lansate n execuie de ntreruperi).
Un fir de execuie este activ, deci este rulat, pn n momentul n care: (a) execuia
lui se finalizeaz sau timpul alocat a expirat (programatorul constat terminarea felii
de timp asociate), (b) este blocat prin intermediul unui mecanism de sincronizare
15
16
17

OEM Original Equipment Manufacturer

OAL OEM Adaptation Layer
n cadrul sistemului de operare Windows CE 6.0 R3 aceast constant este definit printr-o
variabil de tip DWORD n fiierul schedule.c cod component al nucleului sistemului de operare
ce implementeaz programatorul (scheduler-ul) sistemului de operare. Calea ctre acest fiier,
avnd fereastra Solution Explorer activ, este urmtoarea: EVM_3530 WINCE600
PRIVATE winceos COREOS nk kernel nknormal Sources Files ../schedule.c

19

sau (c) este ntrerupt de o cerere de ntrerupere mai prioritar sau de un alt fir de
execuie mai prioritar.
Exist un numr de 256 de prioriti ce pot fi asociate diferitelor fire de execuie,
vezi Tabelul 5.3. Nivelul 0 este nivelul de prioritate maxim n timp ce nivelul 255
este nivelul de prioritate minim.
Pentru gestionarea prioritilor firelor de execuie se pot folosi urmtoarele funcii:
CeSetThreadPriority
CeGetThreadPriority
GetThreadPriority
Deosebirea ntre ultimele dou funcii este dat de faptul c funcia
CeGetThreadPriority ntoarce prioritatea oricrui thread din sistem, valoarea ntoars
situndu-se n intervalul 0 ... 255, n timp ce funcia GetThreadPriority ntoarce
prioritatea firelor de execuie utilizator ce nu sunt drivere valoarea ntoars fiind n
intervalul 248 ... 255.
Tabelul 5.3. Alocarea intervalelor de prioriti n cadrul SO Windows Embedded
Compact
Prioriti
0 -96
97-152
153-247
248-255

Asociat cu:
Rezervate pentru driver-ele ce trebuie s lucreze n timp real
Utilizate pentru driverele standard ale sistemului de operare
Windows Embedded Compact
Rezervate pentru driverele ce nu trebuie s lucreze n timp real
Rezervate pentru diferitele fire de execuie ce nu lucreaz n
timp real

Firele de execuie cu prioritate 0, nu pot fi ntrerupte de nici un alt thread un

astfel de fir de execuie ruleaz ntotdeauna pn la finalizarea propriilor obiective
fiind firul cu prioritate maxim. n mod normal un fir de execuie utilizator are o
prioritate egal cu 252. Prioritile situate n intervalul 0-247 sunt utilizate de ctre
OEM pentru implementarea funciilor BSP-ului.
Modaliti de execuie
Programatorul (scheduler sau dispatcher) SO este componenta principal ce
asigur i gestioneaz execuia thread-urilor. Rolul principal al programatorului este
de a asigna procesele existente n sistem (care ntotdeauna sunt mai multe dect
procesorul/procesoarele existente) ctre un procesor sau ctre mai multe procesoare.
Exist mai multe tipuri de algoritmi de planificare a execuiei proceselor dintr-un
sistem. Amintim doar civa dintre ei: primul intrat primul ieit, programare preemptiv cu prioriti fixe, round-robin, programare multi-nivel pe cozi etc.
n cadrul SO Windows Embedded Compact toate firele de execuie ce au o aceeai
prioritate sunt planificare pe baza unui algoritm round-robin. Utiliznd acest algoritm
de planificare, dup terminarea feliei temporare (quantum) alocate unui thread, dac
n cadrul sistemului mai exist alte fire de execuie de o prioritate similar, sistemul
suspend execuia acestuia i schimb contextul ctre unul din aceste thread-uri.
Acest prim thread i reia execuia dup ce toate celelalte thread-uri ce au aceeai
prioritate au fost executate.
20

De exemplu n Figura 5.6 Firele 2 i 3 ruleaz n modul round-robin. Apariia

unui fir de execuie cu o prioritate mai mic (fir 1, prioritate 100) determin execuia
imediat a lui, dup terminarea cuantei firului de execuie 3. Dup terminarea
execuiei firului de o prioritate maxim se revine la firele de execuie de prioritate
inferioar executate n continuare tot de o manier ciclic, vezi Figura 5.6.
La un anumit moment de timp se execut firul sau firele de execuie (n mod
round-robin) ce are/au prioritatea maxim, n momentul n care acesta/acestea i-au
finalizat execuia sau s-au blocat, programatorul ncepe execuia firului sau firelor cu
o prioritate inferioar. Acest proces continund la infinit sau pn n momentul n care
nu mai exist thread-uri de executat sau pn cnd un fir cu o prioritate mai mare este
lansat n execuie prioritar fa de toate celelalte. Acest proces continund la infinit.

Figura 5.6. Execuie de tipul round-robin a dou fire de execuie

Pentru funcionarea corect a firelor de execuie sunt necesare anumite obiecte
ce sunt utilizate n sincronizarea acestora o descriere detaliat a acestora se va
prezenta n subcapitolul Tehnici de sincronizare a firelor de execuie. Necesitatea
existenei mecanismelor de sincronizare este dat, n principal, de scopul final al
programelor (deci de funcionalitatea lor), de necesitatea execuiei n paralel a mai
multor fire de execuie care trebuie s lucreze independent dar, simultan, i sincron
din necesitatea intercomunicrii de date dar i din dorina atingerii obiectivului final al
sistemului embedded.
Un thread poate fi ntr-o stare blocata atunci cnd obiectul de sincronizare
funcie de care se realizeaz operaia de sincronizare nu este semnalizat. Thread-ul
ateptnd18 trecerea obiectului n starea semnalizat pentru a prelua date sau pentru ai continua execuia. Prin obiect de sincronizare semnalizat (sau n stare activ)
nelegndu-se c acel obiect nu este n posesia nici unui fir de execuie. Un fir de
execuie ruleaz atunci cnd obiectul cu ajutorul cruia se realizeaz sincronizeaz
firului devine semnalizat (sau n stare activ), firul sesiznd acest fapt prelund
controlul obiectului (care devine astfel inactiv, nesemnalizat) i continundu-i
execuia.
Din perspectiva existenei i posibilitii blocrii firelor de execuie, datorit
mecanismelor de sincronizare, rularea firelor n cadrul mecanismului round-robin este
prezentat n Figura 5.7. Astfel, firul de execuie 1, de prioritate maxim, ruleaz n
mod continuu atta timp ct nu este blocat prin intermediul unui mecanism de
18

Ateptarea (sincronizarea) putndu-se realiza fa de unul sau mai multe obiecte pe un timp
indefinit sau limitat (dac dup un anumit timp nici un obiect nu trece n starea semnalizat threadul continundu-i execuia indiferent de starea ulterioar a obiectelor de sincronizare).

21

sincronizare sau nu i termin execuia. n momentul n care este blocat, acesta i

termina execuia chiar dac felia de timp asociat lui nu a fost epuizat. O dat cu
finalizarea execuiei firului 1, vor fi rulate firul/firele de execuie de prioritate
inferioar cele mai prioritare. n cazul nostru particular, firele 2 i 3, printr-un
mecanism round-robin. Acestea se execut pn cnd se termin, devin i ele blocate
prin intermediul unui mecanism de sincronizare cum este cazul particular prezentat
n Figura 5.7 sau un fir de prioritate superioar trebuie executat. Dup blocarea
firelor 2 i 3, imediat se lanseaz n execuie firul/firele de prioritate inferioar
cel/cele mai prioritare firul 4 n cazul nostru. Acesta ruleaz n mod continuu pn
n momentul n care i termin execuia, este blocat sau un fir de prioritate superioar
trebuie s ruleze. Aceast ultim situaie se prezint n Figura 5.7. O caracteristic a
procesului anterior este dat de faptul c atunci cnd firul 1, de prioritate maxim, este
deblocat, mecanismul multitask-ing preemptiv intr n aciune astfel nct firului 4 nu
i se mai permite finalizarea cuantei asociate ci automat execuia lui este terminat i
va fi rulat imediat firul 1.

Figura 5.7. Programarea execuiei unui numr arbitrar de thread-uri de prioriti

diferite
Mecanismului de inversare a prioritilor
Un alt mecanism de rulare a firelor de execuie, atunci cnd apare o interblocare a
acestora, este prezentat n Figura 5.8, i poart numele de mecanismul de inversare a
prioritilor.
n exemplul prezentat n Figura 5.8 firul de execuie numrul 3 n momentul t1
preia o resurs a sistemului (de exemplu, o zon de memorie necesar unui subproces
propriu de prelucrare a datelor) blocnd-o pentru ca nici un alt proces s nu o
altereze/utilizeze n timpul operaiilor efectuate de el. Ulterior firul de execuie 2, de
prioritate mai ridicat este executat i, n final, ultimul fir de execuie, firul 1, de
prioritate i mai ridicat este cel care are dreptul de execuie i este lansat n lucru de
ctre programatorul aflat n interiorul nucleului SO. Dar, firul de execuie numrul 1
necesit utilizarea aceleiai resurse care a fost blocat de firul de execuie 3, fir ce are
o prioritate inferioar de execuie. n acest moment apare un blocaj de execuie, n
22

care un fir de o prioritate inferioar blocheaz execuia unui fir de execuie de

prioritate superioar.

t1

t2

t3

Figura 5.8. Deblocarea unui thread de prioritate ridicat blocat de un thread de o

prioritate inferioar prin intermediul mecanismului de inversare a prioritilor
Acest blocaj va exista la infinit iar sistemul i va opri funcionarea, deoarece firul
de prioritate superioar necesit utilizarea resursei i ateapt eliberarea acesteia. Dar,
firul de execuie 1 avnd prioritatea cea mai ridicat nu va permite nici o dat firelor
de execuie de prioritate inferioar s ruleze pn el nu i va termina execuia. n
aceast situaie firul de execuie 3 nu i va putea finaliza execuia i nu va elibera
resursa resurs necesar firului de execuie numrul 3. Blocarea execuiei firului 1
avnd drept consecin blocarea firelor de execuie 2 i 3. n aceast situaie
particular, prezentat n Figura 5.8, un fir de execuie de o prioritate inferioar
blocheaz execuia unui fir de execuie de o prioritate superioar.
Cnd programatorul (scheduler-ul) SO detecteaz o astfel de situaie prioritatea
firului de execuie 1 este crescut i fcut egal cu prioritatea firului de execuie
blocat. Din acest moment execuia firelor 1 i 3 continund n mod round-robin pn
n momentul n care firul de execuie 3 elibereaz resursa momentul t3. Dup acest
moment de timp firul 1 i va recpta prioritatea anterioar iar firul de execuie 3 i
poate continua acum execuia avnd dreptul de acces la resursa ce anterior era blocat.

5.3.3. Tehnici de sincronizare a firelor de execuie

O caracteristic fundamental a firelor de execuie este independena lor, dar
pentru o funcionare unitar, coerent i corect a sistemului embedded este necesar ca
acestea s coopereze ntre ele pentru atingerea obiectivului global. Din aceste motive
ntre diferitele fire de execuie trebuie s existe posibilitatea schimburilor de date
(deci, a comunicrii) i a sincronizrii acestora (deci, a alegerii momentului optim
cnd se vor ntreprinde anumite activiti sau cnd anumite date vor fi schimbate).
Mecanismele de comunicare i sincronizare a firelor de execuie sunt de altfel

23

elementele fundamentale, cheie i, totodat, centrale oricror sisteme de operare n

timp real i nu numai.
Din punct de vedere practic putem vorbi de mecanisme de:

sincronizare a firelor de execuie ce aparin aceluiai proces vom studia

doar mecanismul de tip seciuni critice, i
sincronizare a firelor de execuie ce aparin unor procese diferite prin
intermediul unor obiecte ce aparin nucleului SO. n subcapitolele
urmtoare vom studia urmtoarele mecanismele de sincronizare de acest
tip:

Mutex (mutual exclusion locks),

Semafor,
Eveniment i
Cozi de mesaje.

n mod conceptual sincronizarea se realizeaz pe baza unor obiecte de

sincronizare. Aceste obiecte, entiti, utilizate n cadrul proceselor de sincronizare se
pot gsi n dou stri: semnalate (active) sau nesemnalate (inactive).
n cadrul mecanismelor de sincronizare, un fir de execuie interogheaz starea
unui anumit obiect specific utilizat n procesul de sincronizare. De exemplu19, dac
acest obiect este n starea activ (deci este semnalizat) firul de execuie i poate
continua execuia, n caz contrar (pentru un obiect nesemnalizat) firul de execuie se
blocheaz ateptnd schimbarea strii elementului de sincronizare pentru a-i continua
execuia.
Exist n principal dou funcii care sunt utilizate, n cadrul mai multor mecanisme
de sincronizare, pentru blocarea sau continuarea execuiei diferitelor firelor de
execuie. Aceste dou funcii sunt:
WaitForSingleObject
WaitForMultipleObjects
Prima funcie, WaitForSingleObject, ateapt pn cnd un anumit obiect de
sincronizare i schimb starea sau chiar este deja n starea activ pentru a continua
execuia. n caz contrar firul respectiv este blocat (dac obiectul prin intermediul
cruia se face sincronizarea este n starea inactiv). Aceast funcie ofer i facilitatea
definirii unui interval de timp n care ateapt (thread-ul fiind blocat) ca obiectul de
sincronizare s devin activ, dac acest interval temporar este depit funcia permite
continuarea execuiei deblocnd thread-ul. Funcia, WaitForMultipleObjects,
blocheaz execuia unui thread pn n momentul n care cel puin unul din obiectele
prin intermediul cruia se realizeaz sincronizarea a trecut n starea activ. i aceast
ultim funcie ofer de asemenea i o facilitate temporal similar funciei
WaitForSingleObject pentru deblocarea strii unui thread n momentul trecerii unui
anumit interval de timp.
Seciuni critice
O seciune critic de cod este o secvena de cod ce acceseaz anumite resurse
partajate (zone de memorie, dispozitive hardware etc.). Rolul seciunilor critice este
de a partaja un numr de resurse comune astfel nct acestea s nu fie accesate
19

Particularizm aceast discuie n cazul obiectelor de tip mutex

24

simultan de mai mult de un fir de execuie. Seciunea critica este precedata de un

anumit protocol de intrare i este urmata de un alt protocol de ieire aceste
protocoale limiteaz accesarea resursei comune la un singur fir de execuie. Firul de
execuie care primete accesul n regiunea critic de cod este primul care a activat
protocolul de intrare sau n cazul n care dou sau mai multe procese ncearc s intre
simultan n propriile seciuni critice ce partajeaz resursa comun SO trebuie s
asigure mecanismele ca unul dintre ele s intre n seciunea critic cu certitudine.
Dac dou sau mai multe fire de execuie apeleaz funcia EnterCriticalSection iar
seciunea critic este deinut de un alt fir de execuie, dup ce acesta prsete zona
critic de cod, firul de execuie cu prioritatea cea mai mare dintre cele care au apelat
funcia EnterCriticalSection va intra n seciunea critic. Dac toate firele au aceeai
prioritate SO va utiliza un mecanism de tip FIFO (first-in first-out) pentru deservirea
cererilor de intrare n zona critic de cod atunci cnd firul de execuie curent o
prsete.
Pentru seciunile critice de cod funcia EnterCriticalSection este cea care
ndeplinete rolul funciilor WaitForSingleObject i/sau WaitForMultipleObjects. n
cazul n care seciunea critic este deinut deja de un anumit fir de execuie, funcia
EnterCriticalSection va fi cea care va bloca execuia unui alt fir care dorete i el s
intre n seciunea critic de cod, pn n momentul n care primul fir de execuie va
prsi propria seciune critic de cod prin intermediul funciei LeaveCriticalSection.
Este obligatoriu ca un fir care intr ntr-o seciune critic (prin apelul unei funciei
EnterCriticalSection) s i ias din aceasta (LeaveCriticalSection). O cerin
fundamental a seciunilor critice de cod este ca firul de execuie s nu se termine n
interiorul seciunii critice fr ca astfel protocolul de ieire s nu fie activat i resursa
s rmn blocat pentru totdeauna.
Din punct de vedere al programului este necesar s se declare un element de tip
seciune critic (o variabil de tip CRITICAL_SECTION) care trebuie, n primul pas,
anterior intrrii ntr-o seciune critic, s fie iniializat prin intermediul funciei
InitializeCriticalSection.
Ulterior
att
funciile
EnterCriticalSection,
LeaveCriticalSection i DeleteCriticalSection (elibereaz toate resursele structurii
CRITICAL_SECTION) vor primi adresa acestei variabile drept argument.
Prin intermediul funciei TryEnterCriticalSection se verific dac exist un fir de
execuie ntr-o seciune critic fr a se bloca accesul pn la eliberarea resursei dac
existe vreun thread ntr-o astfel de zon a codului. Dac, nu exist nici un thread ntro zon critic, atunci thread-ul curent ia controlul regiunii critice, permind intrarea
ntr-o astfel de regiune.
Prin intermediul acestor funcii nu se creeaz nici un obiect n nucleul sistemului
de operare. Din acest motiv acest mecanism de sincronizare este unul foarte rapid i
eficient, dar prezint dezavantajul imposibilitii sincronizrii firelor de execuie ce
aparin la dou procese diferite.
Mutex
O structur de tip mutex (mutual exclusion locks) este creat s ofere un acces
exclusiv unui singur fir de execuie asupra unor resurse partajabile. Cnd structura
mutex este n posesia unui anumit fir de execuie ea este inactiv, nesemnalizat, i
devine semnalizat atunci cnd nici un fir de execuie nu acceseaz resursa partajat
aceast semnalizare fiind echivalent cu un mesaj de genul resurs disponibil i
neutilizat.
25

Din descrierea anterioar se observ c un mutex este similar ca funcionalitate cu

o zon critic de cod cu deosebirea c un mutex este un obiect ce aparine nucleului
SO (kernel-ului). De fiecare dat cnd un fir de execuie dorete accesul ctre o
resurs comun controlat prin intermediul unui mecanism mutex se acceseaz
nucleul SO. Din acest motiv utilizarea unui mecanism mutex de partajare a resurselor
genereaz ntrzieri mult mai mari dect mecanismul seciunilor critice de cod. Dar,
comparativ cu acestea, avantajul major este dat de posibilitatea sincronizrii firelor de
execuie ce aparin la dou procese diferite.
Elementele de tip mutex pot avea sau nu un nume, cu observaia c doar structurile
mutex ce au un nume pot sincroniza fire de execuie ce aparin la dou sau mai multe
procese diferite.
Pentru crearea sau deschiderea unui mutex se utilizeaz funcia CreateMutex (cu
ajutorul creia poate fi creat un mutex care s aib sau nu un nume), n timp ce
eliberarea resurselor structurii mutex, din nucleul sistemului de operare, se realizeaz
cu ajutorul funciei ReleaseMutex. Sincronizarea firelor de execuie se realizeaz prin
intermediul funciilor standard WaitForSingleObject sau WaitForMultipleObjects
prezentate anterior. Pentru o funcionare corect dup eliberarea resurselor trebuie s
eliminm i resursele ocupate de handler-ul asociat structurii mutex prin intermediul
funciei CloseHandle.
Semafoare
Semafoarele sunt obiecte nucleu ce servesc la controlul accesului diferitelor fire
de execuie asupra unor resurse partajate. Semafoarele sunt o generalizare a
seciunilor critice de cod sau a mutex-urilor. n cazul semafoarelor nu doar un fir de
execuie ci mai multe pot sa dein un semafor. Numrul maxim de fire care pot
deine simultan un semafor este un parametru coninut n structura acestuia mpreun
cu o variabil de tip contor (counter) care ne arat efectiv cte fire dein la un anumit
moment semaforul.
Funcionarea semaforului este centrat pe variabila de tip contor care ne
precizeaz numrul firelor de execuie ce dein semaforul, din acest motiv vom ncepe
prezentarea elementului de sincronizare semafor cu descrierea acestei variabile.
Astfel, variabila de tip contor a semaforului nu poate lua niciodat valori negative, iar
valoarea ei maxim nu va putea fi niciodat mai mare dect valoarea specificat n
momentul crerii semaforului ca fiind numrul maxim de fire ce pot deine controlul
asupra semaforului (aceast valoare va fi fixat iniial cnd se creeaz semaforul cu
ajutorul funciei CreateSemaphore). O deosebire a semafoarelor din Windows
comparativ cu cele din Linux este dat de existena unei limite superioare a firelor de
execuie ce pot obine acces asupra unui semafor. Dac contorul semaforului are
valoarea zero, semaforul nu este semnalizat (fiind inactiv) i nici un fir nu va mai
putea obine acces asupra lui. Dac contorul semaforului are o valoare diferita de zero,
deci semaforul este activ sau semnalizat, un fir poate obine control asupra
semaforului prin intermediul funciilor de ateptare WaitForSingleObject sau
WaitForMultipleObjects. n momentul n care un fir primete controlul asupra
semaforului, n mod implicit valoarea variabilei de tip contor se decrementeaz
atunci cnd aceasta ajunge la zero nici un alt fir nu mai poate obine controlul asupra
semaforului iar firul de execuie este blocat prin intermediul funciilor
WaitForSingleObject sau WaitForMultipleObjects.

26

Semaforul poate fi de tip: (a) cu nume este un semafor folosit pentru comunicarea
ntre firele de execuie ce aparin unor procese diferite de pe aceeai main numele
semaforului este elementul de identificare al acestuia de ctre toate firele de execuie
implicate care folosesc acest nume n cadrul apelului funciei OpenSemaphore, (b)
anonim - folosit doar pentru comunicarea ntre firele de execuie ale aceluiai proces
elementul de identificare a semaforului n aceast situaie este constituit de handleul ntors de funcia CreateSemaphore care este utilizat de firele de execuie interesate.
n cadrul sistemelor de operare Windows, o dat creat un semafor cu nume se poate
realiza deschiderea accesului la semafor de ctre orice fir de execuie care cunoate acest
nume. Deschiderea se face cu ajutorul funciei OpenSemaphore. Pentru simplitate, n
cazul SO Windows Embedded CE funcia OpenSemaphore nu este implementat,
utilizai funcia CreateSemaphore pentru accesarea unui semafor. Dac n cazul
utilizrii funciei CreateSemaphore numele semaforului, furnizat drept argument, este
unul cunoscut, preexistent n cadrul nucleului SO atunci semaforul respectiv este
deschis, se obine un handle, iar parametrii funciei ce iniializeaz variabila de tip
contor i caracterizeaz numrul maxim de fire ce pot deine controlul asupra
semaforului sunt ignorai deoarece ei au fost deja definii n momentul creri iniiale a
elementului semafor n nucleul SO.
La apelul funciei ReleaseSemaphore de ctre un fir care are control asupra
semaforului, counter-ul se incrementeaz cu o unitate valoarea cu care se
incrementeaz contorul este specificat ca argument n cadrul funciei
ReleaseSemaphore. Dac variabila de tip contor a semaforului are valoarea maxim
(specificat la creare), atunci apelul funciei ReleaseSemaphore de incrementare
eueaz. De asemenea, dac se specific o valoare negativ pentru parametrul de
incrementare al funciei ReleaseSemaphore apelul eueaz din nou.
n mod similar unui mutex pentru o funcionare corect a sistemului global dup
eliberarea celorlalte resurse utilizate (de exemplu al celor create dinamic) trebuie s
eliminm i resursele ocupate de handler-ul asociat structurii semafor prin intermediul
funciei CloseHandle.
Evenimente
Evenimentele20 sunt unul din mecanismele oferite de nucleul sistemului de
operare Windows Embedded Compact ce ofer posibilitatea unui fir de execuie s
semnalizeze unul sau mai multe fire de execuie c un anumit eveniment a avut loc n
sistem.
n mod similar mecanismului de sincronizare de tip mutex un eveniment poate sau
nu s aib un nume asociat. n momentul n care evenimentele au nume asociate
acestea pot realiza sincronizarea ntre fire de execuie aparinnd unor procese
diferite; n caz contrar se pot sincroniza numai fire de execuie aparinnd aceluiai
proces.
Un eveniment este activ sau semnalizat atunci cnd este setat (prin intermediul
funciei SetEvent) i nu este semnalizat atunci cnd este resetat (prin intermediul
funciei ResetEvent). n momentul n care un eveniment este creat, prin intermediul
funciei CreateEvent, acesta poate fi setat sau nu, poate sau nu s aib un nume
asociat i poate fi un eveniment de tip cu resetare automat sau manual.
20

Dup cum se va prezenta ulterior, vezi Figura 5.11, evenimentele sunt utilizate ntr-un numr foarte
mare de situaii. De exemplu, evenimentele sunt utilizate de nucleul sistemului de operare pentru a
informa un driver c o ntrerupere a avut loc i c ntreruperea trebuie tratat.

27

Evenimentele cu resetare manual trebuiesc trecute n starea inactiv manual prin

intermediul funciei ResetEvent imediat dup ce sincronizarea este realizat prin
intermediul funciilor WaitForSingleObject sau WaitForMultipleObjects pentru a nu
permite, de exemplu, altor fire de execuie s acceseze eventualele resurse partajate.
Atta timp ct un eveniment este semnalizat toate firele de execuie ce ateapt acest
eveniment sunt deblocate simultan mpreun cu toate firele de execuie care ncep
s atepte acest eveniment n perioada de timp ntre momentul n care evenimentul
este setat i momentul n care este resetat. Utiliznd funcia PulseEvent n locul
funciei SetEvent evenimentul va fi setat, va debloca toate firele de execuie ce
ateapt s fie deblocate de acest eveniment iar ulterior evenimentul este resetat. Dac
nici un fir de execuie nu ateapt s fie deblocat evenimentul este resetat imediat
chiar dac nu a deblocat nici un fir de execuie.
n cazul evenimentelor cu auto-reset acestea sunt trecute n stare nesemnalizat de
ctre nucleul SO imediat ce evenimentul determin deblocarea unei funcii de tipul
WaitForSingleObject sau WaitForMultipleObjects. Daca un eveniment cu auto-reset
este setat i una sau mai multe funcii ateapt pentru a fi deblocate atunci primul fir
de execuie ce ateapt evenimentul este deblocat, iar imediat evenimentul este
resetat; celelalte funcii ce ateapt s fie deblocate vor rmne n continuare blocate.
Deci, n acest caz (al evenimentelor cu auto-reset) numai un singur fir de execuie se
va debloca i va fi exe cutat. n cazul utilizrii funciei PulseEvent cu un eveniment de
tip auto-reset modul de comportare este identic cu cel prezentat anterior (ca n cazul
utilizrii funciei SetEvent), diferena fundamental const doar n situaia n care nici
un fir de execuie nu ateapt s fie deblocat n acest caz evenimentul nu va rmne
n starea setat pn apare un astfel de fir de execuie ci va fi imediat resetat chiar
dac nu a deblocat nici un thread.
Concluzionnd, putem spune c funcia PulseEvent seteaz evenimentul, iar dac
nu exist nici un fir de execuie n ateptare sau nici un fir de execuie nu poate fi
deblocat imediat atunci PulseEvent reseteaz evenimentul trecndu-l ntr-o stare
inactiv i nu ateapt apariia unui fir de execuie ce poate fi deblocat de acel
eveniment.
Pentru o funcionare corect a aplicaiei dup eliberarea resurselor trebuie s
eliberm i resursele ocupate de handler-ele asociate fiecrui mesaj. Acest lucru se
realizeaz prin intermediul funciei CloseHandle.
Cozi de mesaje
Cozi de mesaje este un mecanism de sincronizare a unor fire de execuie care
este utilizat atunci cnd este necesar sincronizarea ntre cel puin 2 thread-uri i, n
plus, trebuie s existe i un anumit schimb de informaie ntre firele de execuie. Acest
mecanism de sincronizare este unul specific nucleului sistemului de operare.
n cadrul sistemului de operare Windows Embedded Compact ne putem imagina o
multitudine de modaliti prin care dou fire de execuie pot comunica date ntre ele.
De exemplu, aceast comunicare de date se poate realiza prin utilizarea regitrilor
sistemului de operare, a fiierelor i a bazelor de date ca s menionm trei din cele
mai utilizate metode.
Dar, atunci cnd cantitatea de date ce este necesar a fi transmis este redus
i n plus mai sunt necesare i sincronizri ntre cele dou fire de execuie se pot
utiliza aceste cozi de mesaje. Cozile de mesaje sunt optimizate pentru utilizarea
minimului de resurse sistem n procesul sincronizrii i n cel al transferului de date.
28

Din punct de vedere software o coad de mesaje este o list ordonat n care
diferitele mesaje pot fi adugate sau nlturate din list. Cozile de mesaje prin care se
realizeaz sincronizarea n Windows Embedded Compact sunt de tip FIFO (First In
First Out) sau FCFS (First Come First Server) n sensul c adugarea se face la
sfritul cozii n timp ce elementele se citesc i se elimin din coad de la nceputul ei.
O coad de mesaje poate fi dedicat unui fir de execuie sau poate fi o resurs
comun a mai multor fire de execuie. n mod similar mutex-urilor, semafoarelor i
evenimentelor, cozile de mesaje ce au un nume propriu pot fi utilizate i pentru
sincronizarea firelor de execuie ce aparin la procese diferite.
Cu ajutorul funciei CreateMsgQueue se creeaz o coad de mesaje ce poate avea
sau nu un nume asociat i creia i este asignat un hadler (identificator unic) prin
intermediul cruia se pot, fie, citi mesajele din coad, fie scrie mesaje n coad
funcie de valoarea TRUE sau FALSE a membrului bReadAccess a structurii de date
MSGQUEUEOPTIONS (structur a crei adres este utilizat drept argument n
cadrul acestei funcii). Prin intermediul unui handler asociat unei astfel de cozi se
poate realiza doar citirea sau doar scrierea ntr-o astfel de coad i nu ambele operaii
prin intermediul aceluiai handler. Dar, dac dispunem de un handler asociat cu o
coad de mesaje putem, prin intermediul funciei OpenMsgQueue, crea un alt handler
asociat aceleiai cozi pentru a realiza o alt operaie de scriere/citirea din ea
complementar celei anterioare. Pentru eliberarea resurselor asociate cu o coad de
mesaje i pentru nchiderea ei se folosete funcia CloseMsgQueue. n schimb, pentru
eliberarea resurselor ocupate de un handler asociat unei cozi de mesaje se va folosi
funcia standard CloseHandle.
Sincronizarea, n cazul utilizrii cozilor de mesaje, se face prin intermediul uneia
din funciile: WaitForSingleObject sau WaitForMultipleObjects. Pentru scrierea i
citirea unui anumit mesaj se folosesc funciile WriteMsgQueue i ReadMsgQueue. n
general se poate trimite doar o singur variabil de un anumit tip de dat (de exemplu
int, dword, char etc.). n momentul n care necesitatea ne impune s trimitem mai
multe variabile, le putem grupa pe acestea sub forma unei singure structuri de date pe
care s o scriem i, ulterior, s o citim ntr-o/dintr-o coad de mesaje.
Aplicaia 5.3: Realizai dou programe independente care s aib poziionate, fiecare
dintre ele, pe interfeele grafice cte un element de tipul Progress Control.
Implementai o modalitate de sincronizare a acestora prin intermediul
mecanismului de tip mutex astfel nct dup o derulare complet a primului
element de tip Progress Control, derulare executat sub controlul primei
aplicaii, s nceap derularea celui de al doilea element de tip Progress Control
sub controlul celei de a doua aplicaii, urmat din nou de o derulare a primul s.a.m.d.
n plus, derularea celui de al doilea element Progress Control va fi mai rapid
comparativ cu a primului. Ambele programe vor conine toate acele elemente
necesare crerii structuri mutex, deschiderii, ateptrii, prelurii, distrugerii acesteia
precum i acelea necesare nchiderii aplicaiei i pornirii derulrii celor dou
elemente de tip Progress Control.
Vizualizai prin intermediul aplicaiei Kernel Tracker modalitatea de rulare a
celor dou aplicaii create.
Rezolvare: Implementarea aplicaiilor anterior menionate le gsii n codul asociat
acestui capitol. Cele dou aplicaii sunt n directoarele Lent i Rapid i sunt
aproape complet funcionale. Implementai, n plus, doar codul i mecanismul
asociat nchiderii acestora de pe interfaa grafic.
29

Figura 5.9. Modalitatea de includere a componentei KITL

Pentru a fi capabili s utilizm aplicaia Kernel Tracker trebuie s includem n
imaginea sistemului de operare anumite componente capabile s comunice cu
aceasta i s i furnizeze toate informaiile necesare. n cazul nostru trebuie s
includem componenta KITL (Kernel Independent Transport Layer vezi Figura
5.9 i explicaiile asociate acesteia). Pentru a o include urmaii paii: Project
Property (sau putei ajunge direct n acest punct prin Alt+F7) Configuration
Properties (dublu click) Build Options i selectai Enable KITL (vezi Figura
5.9).

Figura 5.10. O imagine a dinamicii proceselor i firelor de execuie rulate la un

anumit moment de timp de procesor
Acum trebuie s reconstituim din noi imaginea sistemului de operare prin
urmtoarea secven de comenzi: Clean Solutions urmat de Build Solutions din

30

meniul principal Build. Introducerea componentei KITL determin o creterea

substanial a mrimii fiierului nk.bin (cu aprox. 17-18 Mb) i o rulare mai lent a
tuturor aplicaiilor datorit transferului continuu de date ntre placa de dezvoltare
(ntre nucleul sistemului de operare) i apicaia Kernel Tracker.
Dup ncrcarea noii imagini a sistemului de operare pe placa de dezvoltare i
stabilirea tuturor conexiunilor, trebuie doar s lansm n execuie aplicaia Kernel
Tracker. Pentru aceasta urmai paii: Target Remote Tools Kernel Tracker.
n fereastra nou deschis (Select a Windows CE Device) apsai butonul OK i
permitei derularea ntregului proces de conectare la platforma de dezvoltare.
Ateptai puin i vei obine o imaginie a dinamicii tuturor proceselor i a firelor
de execuie ce sunt rulate n acel moment aceast imagine trebuie s fie similar
cu cea prezentat n Figura 5.10. n partea stng se prezint toate procesele care
sunt active n timp ce n partea dreapt este prezentat o legend cu simbolistica
elementelor grafice.
Din Figura 5.10 se observ c fiecare proces este reprezentat prin intermediul
unei linii orzontale. Atunci cnd un fir de execuie, ce aparine unui proces, este
activ reprezentarea grafic a acelui proces se schimb ntr-o linie groas de culoare
verde, n caz contrar aceasta este o linie neagr subire. Deoarece sistemul are un
singur procesor (pe care ruleaz toate aplicaiile mai puin cele media care
ruleaz pe DSP), la un anumit moment de timp se poate executa doar un singur fir
de execuie. Prin intermediul liniilor subiri, verticale de culoare verde se
simbolizeaz dinamica execuiei, schimbarea contextului de lucru de la un fir de
execuie la altul.
Cea mai mare parte a proceselor sunt executate intervale scurte de timp. O
execepie de la aceast regul este procesul Idle cu identificatorul 0x00000000.
Acesta nu este un fir de execuie propriu-zis simboliznd doar acele momente cnd
procesorul nu lucreaz.
Dup cum se vede i din Figura 5.10 procesele Lent i Rapid se execut ntrun mod round-robin, cu alte procese, ce au aceeai prioritate dar consecutiv
datorit mecanismului de interblocare existent.

Figura 5.11. Detaliu al procesului de sincronizare ntre firele de execuie Lent i

Rapid
31

Din Figura 5.11 se observ c pe liniile proceselor i firelor de execuie sunt

plasai diferii markeri ce au propria simbolistic, simbolistic explicitat n partea
dreapt a ferestrei aplicaiei Kernel Tracker (vezi Figura 5.10), care ne furniz
informaii utile procesului de analiz i/sau de debug a unei aplicaii. n Figura
5.11 prin selectarea ultimilor doi markeri poziionai la sfritul perioadei de
execuie a firului aplicaiei Lente (deci atunci cnd acest fir elibereaz mutex-ul i i
permite firului de execuie Rapid s preia controlul asupra lui i s i deblocheze
funcionarea) se obin informaii legate de evenimentele importante, evenimente ce
in de procesele de sincronizare. Punnd un breack point n momentul semnalizrii
structurii mutex ncercai s identificai acele linii de cod semnalizate de marker-ii
prezentai n Figura 5.11. n mod similar proceselor, atunci cnd firele de execuie
sunt active sunt simbolizate cu o linie groas de culoare verde, cnd nu ruleaz cu o
linie de culoare neagr subire iar atunci cnd sunt blocate cu o linie ntrerupt de
culoare roie.

5.3.4. Sistemul de ntreruperi

Pentru preluarea datelor din exteriorul sistemelor, n vederea procesrii acestora,
exist dou metode distincte. n cadrul primei metode, sistemul interogheaz n mod
continuu (pooling) la anumite intervale de timp diferitele dispozitive periferice n
vederea prelurii datelor ce urmeaz s fie prelucrate. Aceast metod este una foarte
precis ce garanteaz preluarea datelor ntotdeauna la aceleai momente de timp, n
schimb ncarc computaional procesorul sistemului embedded. Cea de a doua
metod se bazeaz pe utilizarea unui sistem de ntreruperi cu ajutorul cruia n
momentul n care dispozitivul extern a obinut datele necesare, acesta genereaz o
ntrerupere pe care procesorul o gestioneaz, prelund ulterior, aceste date. Avantajul
fundamental al acestei metode este dat de o ncrcarea computaional redus a
procesorului, n schimbul imposibilitii determinrii exacte a momentului de timp
cnd aceste date se obin datorit latenelor existente n preluarea datelor i a
variabilitii (jitter) momentului exact de preluare a datelor, vezi Tabelul 4.1 i
Figura 4.3.
O cerere de ntrerupere hardware (IRQ interupt request) este un semnal electric
trimis de un dispozitiv, prin intermediul unei linii hardware ctre procesorul
sistemului embedded, semnaliznd faptul c un anumit eveniment extern a avut loc iar
procesorul trebuie s l gestioneze. O cerere de ntrerupere sistem (SYSINTR), de tip
software, este corespondentul software al unei ntreruperii hardware. Pentru tratarea
acesteia (a ntreruperii sistem SYSINTR) este responsabil OAL.
n cadrul sistemului de operare Windows Embedded CE manegment-ul unei
ntreruperi este compus din dou subrutine diferite: rutina de deservire a unei
ntreruperi ISR (interrupt service routine) i firul de execuie utilizat n deservirea
unei ntreruperi prescurtat IST (interrupt service thread).
Caracteristici ISR:

este o bucat de cod construit sau ncrcat n nucleul sistemului de

operare;
fiecare IRQ este asociat cu cel puin o ISR de exemplu, pentru
procesoarele ce suport:

32

multiple linii IRQ de ntrerupere hardware prin utilizarea

funciei HookInterrupt trebuiesc nregistrate n nucleul sistemului
de operare ISR pentru fiecare IRQ;
doar o singur linie de tip IRQ (precum procesoarele de tip ARM)
nucleul lanseaz ntotdeauna n execuie o singur procedur din
OAL dar, mai multe ISR instalabile trebuiesc nregistrate n mod
separat n nucleu pentru a gestiona diversele dispozitive externe ce
sunt conectate la procesor. Din aceast perspectiv putem spune
c avem mai multe ISR asociate cu o linie de ntrerupere.

dac o ntrerupere extern are loc, nucleul SO lanseaz imediat o ISR n

execuie cu ajutorul modului KISH (Kernel Interrupt Service Handler).
Acest modul lanseaz ISR n execuie foarte repede, fiind necesare n jur
de 10-12 instruciuni anterioare execuiei ISR;
una din operaiile fundamentale ale unei ISR este de a identifica
ntreruperea ce este activ i pe care o deservete i, ulterior, de a o
invalida;
ISR trebuie s fie foarte rapid, codul nu trebuie s depind de nici un
eveniment extern i nu trebuie s nglobeze mecanisme de sincronizare
(pentru a se evita blocarea acestui cod). Necesitatea unei viteze mari de
execuie este dat i de faptul c n timp ce ISR este executat cererile de
tip IRQ ce au aceeai prioritate precum i cele de o prioritate inferioar nu
pot fi deservite;
ISR notific nucleul ce IST trebuie executat prin intermediul unui
identificator logic asociat cu SYSINT;
Mai multe ISR pot fi nlnuite mpreun n cazul n care multiple
dispozitive hardware externe utilizeaz aceeai linie IRQ.

Caracteristicile sistemului Kernel Interrupt Service Handler (KISH) sunt:

poate lucru cu 64 de ntreruperi hardware externe;

funcie de prioritatea ntreruperii lanseaz n execuie ISR asociat cu IRQ
extern;
genereaz un eveniment ce este asociat cu o IST care va trata cererea
hardware.

Caracteristici IST:
execut cea mai mare parte a procesului de tratare a ntreruperii, efectund
toate acele activiti ce sunt specifice i necesare dispozitivului care a
generat ntreruperea;
este parte integrat a unui driver;
trebuie s execute cel puin urmtoarele aciuni:
la nceput:
s creeze un eveniment standard prin intermediul funciei
CreateEvent;
s nregistreze evenimentul n kernel i s l asocieze cu un
identificator logic asociat cu SYSINTR prin intermediul funciei
InterruptInitialize;
n mod continuu:

33

s atepte producerea evenimentul (prin intermediul funciei

WaitForSingleObject) eveniment ce este asociat cu ntreruperea
hardware;
s notifice nucleul sistemului de operare (kernel-ul) c tratarea
ntreruperii s-a finalizat prin intermediul funciei InterruptDone.
Este programat pentru execuie ca orice alt fir de execuie existent n
sistem, vezi subcapitolul 5.3.2.

Codurile existente n ISR i IST lucreaz n tandem astfel nct:

ISR gestioneaz toate acele activiti critice ce trebuie realizate ct mai iute
posibil;
IST se ocup de restul aciunilor de procesarea datelor implementnd
funcionalitatea real ce deservete cererea de ntrerupere.

Toate IRQ sunt validate

Toate IRQ
invalidate

Toate IRQ de
prioritate superioara
sunt validate

Toate IRQ sunt validate mai putin intreruperea care

este procesata acum

Toate IRQ sunt

validate

Fir
normal de
executie

IST

ISR

SYSINTR

Nucleul
SO

InterruptDone()

Generare
IRQ

OAL

Driver

Fir
normal de
executie

Kernel
ne
preemtiv

KISH

Timp de latenta pana

la executia ISR

Kernel
ne
preemtiv

KISH

Programator
(scheduler)

Programator
(scheduler)

Setare
eveniment

Timp de latenta
pana la executia IST

Figura 5.12. Procesul de tratare a unei ntreruperi

Apariia unei ntreruperi poate s apar n urmtoarele cazuri particulare:
1. nucleul sistemului de operare se gsete ntr-o zon de cod ce nu poate fi
ntrerupt caz similar celui prezentat n Figura 5.12;
2. nucleul sistemului de operare se gsete ntr-o zon de cod ce poate fi
ntrerupt;
3. se execut un fir de execuie ce a invalidat ntreruperile;
4. se execut un fir de execuie.
Reprezentarea grafic prezentat n Figura 5.12 este una semnificativ i
complet care n situaiile (2) i (4), prezentate anterior, determin ca cele dou
blocuri {kernel nepreemptiv} s fie nlturate, iar n timp ce n situaia (3)

34

ntreruperea va fi luat n considerare i tratat de Kernel Interrupt Service Handler

imediat ce firul de execuie valideaz ntreruperile.
n momentul apariiei unei ntreruperi, dac aceasta este validat se realizeaz un
salt imediat n Kernel Interrupt Service Handler chiar dac nucleul sistemului de
operare execut o poriune de cod ce nu poate fi ntrerupt. Kernel Interrupt Service
Handler lanseaz imediat ISR asociat. ISR localizeaz sursa care a generat
ntreruperea21 invalidnd-o pe aceasta (mascnd-o, pentru ca astfel sistemul s nu mai
accepte alte cereri similare de ntreruperi pn cea prezent nu este procesat) i
ntoarce un identificator unic nucleului sistemului de operare (tot ctre Kernel
Interrupt Service Handler) ce are drept scop indicarea driver-ului care va trata n
continuare ntreruperea. Dac ntreruperea a fost corect determinat identificatorul
ntreruperii este de forma SYSINTR_xxx sau SYSINTR_NOP n caz contrar.
Validarea tuturor ntreruperilor ce au prioriti superioare este de asemenea
responsabilitatea ISR.
Prin executarea a doua oar a KISH se va genera evenimentul, asociat cu IST,
pornindu-se de la identificatorul primit de la ISR (asocierea ntre SYSINTR_xxx i
evenimentul ce trebuie generat este realizat prin intermediul unui tabel), i se vor
valida toate celelalte cereri de ntreruperi mai puin cea care tocmai se proceseaz,
vezi Figura 5.12. Dac anterior nucleul sistemului de operare executa o poriune de
cod, intern lui, ce nu putea fi ntrerupt aceast poriune i continu execuia pn la
finalizarea ei.
Programatorul, existent n nucleului SO, determin momentul cnd IST, asociat cu
ISR, are prioritatea maxim i permite firului de execuie s proceseze ntreruperea
de ex. va executa diferite operaii I/O i va procesa datele primite. Dup procesarea
ntreruperii IST va atepta un nou eveniment asociat, care va determina o nou
procesare a altei ntreruperii hardware. Dup terminarea funciilor proprii IST
informeaz nucleul SO (prin intermediul funciei InterruptDone22) c a procesat
ntreruperea i IST este gata s proceseze o nou ntrerupere. Aceast informare a
nucleului SO este necesar i pentru ca nucleul s revalideze ntreruperea tocmai
procesat.
Revalidarea ntreruperii care a fost procesat trebuie s aib loc ct mai repede cu
putin deoarece celelalte dispozitive care ar utiliza aceeai linie de ntrerupere
hardware sunt blocate. Deoarece IST sunt fire de execuie din interiorul drivere-lor
acestea sunt prioritare, avnd prioriti mari (dar de valori sczute, vezi Tabelul 5.3),
executndu-se rapid cu preponderen naintea firelor normale de execuie.
Dup cum s-a prezentat anterior, exist posibilitatea ca un driver s instaleze o
ISR n momentul n care sistemul de operare se iniializeaz. Aceast facilitate este
utilizat i atunci cnd se lucreaz cu linii IRQ hard ce deservesc mai multe
ntreruperi asociate cu mai multe dispozitive hardware23. Pentru a putea instala noi
ISR trebuie s existe anterior un ISR nregistrat pe acea linie IRQ hardware i care s

21
22
23

Pentru cazul existenei mai multor dispozitive conectate la aceeai linie de ntrerupere, modalitatea
de manipulare a unei astfel de ntreruperi se va prezenta n paragrafele urmtoare.
Aceast funcie poate fi apelat de driver-ele ncrcate n spaiul nucleului (kernel-mode drivers) i
de cele ncrcate printr-un proces specializat udevice.exe (denumite user-mode drivers).
De exemplu, procesoarele de tip ARM utilizeaz aceast modalitate de deservire a ntreruperilor
generate de mai multe dispozitive deoarece nglobeaz doar dou linii hardware externe ce trebuie
s susin toate aceste dispozitivele. Aceste dou linii externe sunt: IRQ (pentru acele cereri de
ntrerupere ce nu sunt critice) i FIQ (fast IRQ pentru acele cereri de ntrerupere ce deservesc
subrutine critice din punct de vedere temporal).

35

suporte aceast facilitate. Aceste ISR instalabile sunt implementate n fiiere de tipul
DLL.

ISR1

ISR2

ISR3

ISR4

Intrerupere partajata de mai multe dispozitive hardware

USB
Flash Drive

Serial
port

Network
card

Keyboard

Figura 5.13. ntrerupere hardware ce deservete mai multe dispozitive

Mecanismul de funcionare i gestionare a mai multor dispozitive conectate la
aceeai linie de ntrerupere presupune existena unor ISR nlnuite care s identifice
sursa care a generat ntreruperea i s anune nucleul SO c ntreruperea respectiv
este gestionat sau nu de respectivul ISR. Dac unul din ISR, asociat cu linia de
ntrerupere, gestioneaz respectivul dispozitiv (ce a generat ntreruperea) atunci va
ntoarce ctre nucleul SO identificatorul logic al ntreruperii. n caz contrar ntoarce
identificatorul SYSINT_CHAIN ctre nucleul sistemului de operare semnalndu-i c
o alt ISR din lan gestioneaz dispozitivul, iar nucleul SO trebuie s continue gsirea
ISR potrivite.
Aplicaia 5.4: Pentru vizualizarea i nelegerea intuitiv a mecanismelor
implementate i utilizate n cadrul tratrii unei ntreruperi (de ctre sistemul de
operare Windows CE), realizai o analiz a procesului de tratare a unei ntreruperi
cu ajutorul utilitarului Kernel Tracker.
Rezolvare: Pentru a realiza aceast analiz trebuie s includei n imaginea sistemului
de operare componenta KITL i s includei i componenta necesar realizrii
operaiei de profiling (vezi Figura 5.9 se bifeaz Enable Profiling). Ulterior se
urmeaz toi paii prezentai n Aplicaia 5.3. n urma parcurgerii tuturor acestor
pai utilitarul Kernel Tracker va prezenta o imagine a proceselor i firelor de
execuie similar cu cea din Figura 5.14.
Comparnd imaginile prezentate n Figura 5.14 i n Figura 5.10 se observ
apariia, n plus, a firelor de execuie specifice ntreruperilor. Includerea
componentei Profiler determin prezentarea acestor informaii, dar impactul
colectrii tuturor acestor informaii i a trimiterii lor ctre aplicaia Kernel Tracker
va fi mult mai mare fiind cuantizat printr-o scdere substanial a vitezei de lucru a
sistemului (de exemplu, a timpului necesar pornirii acestuia dup o iniializare
reset).
n Figura 5.15 se observ c atunci cnd o ntrerupere are loc (SYSINTR 1, 18,
24 sau 25) ISR-ul este executat (zonele marcate cu [i] n Figura 5.15) urmat
imediat de IST asociat.

36

Figura 5.14. O imagine tipic a dinamicii proceselor i a firelor de execuie atunci

cnd se include i componenta Profiler n imaginea sistemului de operare

Figura 5.15. Imagine de detaliu a zonei ncercuite din Figura 5.14

Pentru o analiz mai detaliat a proceselor ce au loc n momentul generrii unei
ntreruperi n Figura 5.16 se prezint un detaliu, la o rezoluie temporal mai mare,
a zonei evideniate (prin intermediul unui dreptunghi de culoare roie) din Figura
5.15.

37

ISR

IST

Figura 5.16. Imagine de detaliu din Figura 5.14 a zonei ncercuit n rou

38

5.4. Instrumente utilizate n dezvoltarea i construcia sistemului de

operare
5.5.1. Instalarea mediului de dezvoltare i a platformei
Windows Embedded CE
Pentru a putea lucra n mod corespunztor cu mediul de dezvoltare Windows
Embeded CE 6.0, urmtoarele pachete software trebuie instalate n ordinea de mai jos
[Web 2009]:
1. Visual Studio 2005
2. Visual Studio 2005 SP1
3. Visual Studio 2005 SP1 Update for Vista (dac se lucreaz pe un calculator ce
ruleaz sistemul de operare Vista sau Windows 7)
4. Windows Embedded CE 6.0 Platform Builder
5. Windows Embedded CE 6.0 SP1 (pentru instalarea acestui service pack este
absolut necesar ca Windows Embedded CE 6.0 Platform Builder s fie
instalat)
6. Windows Embedded CE 6.0 R2
7. Windows Embedded CE 6.0 R3. Acest ultim update conine toate update-urile
existente pan la data de 31 august 2009 deci nu mai sunt necesare instalarea
urmtoarelor update-uri:
a. Windows Embedded CE 6.0 Product Update Rollup 12/31/2008
acest ultim update trebuie instalat n mod particular pentru fiecare
arhitectur utilizat, de exemplu:
i. Pentru ARM: WinCEPB60-081231-Product-Update-RollupArmv4I.msi
ii. Pentru x86: WinCEPB60-081231-Product-Update-RollupX86.msi, etc.
b. Ulterior se pot instala i update-urile lunare pe care compania
Microsoft le ofer gratuit:
1. Windows Embedded CE 6.0 Monthly Update (January 2009)
2. Windows Embedded CE 6.0 Monthly Update (February 2009)
3. Windows Embedded CE 6.0 Monthly Update (March 2009)
4. Windows Embedded CE 6.0 Monthly Update (April 2009)
5. Windows Embedded CE 6.0 Monthly Update (May 2009)
6. Windows Embedded CE 6.0 Monthly Update (June 2009)
7. Windows Embedded CE 6.0 Monthly Update (July 2009)
8. Windows Embedded CE 6.0 Monthly Update (August 2009)
9. Etc.
5.5.2. Structura de directoare i componentele utilizate n dezvoltarea
sistemului de operare Windows Embedded CE
Sistemul de operare Windows Embedded CE este o colecie de componente
sistem, librrii i aplicaii gndite s lucreze mpreun ca un tot unitar i plasate ntr-o
imagine a sistemului de operare ce se va ncrca i lansa n execuie ulterior de pe un
mediu de stocare existent n cadrul sistemului embedded (memorie flash, SD card,
USB flash etc.).
39

Pentru dezvoltarea imaginii sistemului de operare Windows Embedded CE, deci

pentru crearea fiierului NK.bin24, este utilizat o anumit structur de directoare
standard ce grupeaz i stocheaz diferitele componente ale nucleului sistemului de
operare, BSP-ul, diferitele componente i aplicaii realizate de alte companii ce vor fi
incluse n imaginea sistemului de operare, componente ale SO Windows Embedded
CE clonate i modificate, uneltele cu ajutorul crora se creeaz sistemul de operare, se
verific integritatea i buna funcionare etc. Toate aceste componente, prezentate
anterior i multe altele, se gsesc ntr-un director rdcin a crui nume este pstrat n
variabila _WINCEROOT. n mod implicit acest director este WINCE600.
Unul dintre conceptele fundamentale ale modului de organizare a platformei de
dezvoltare Windows Embedded CE este de a separa componentele dependente de
partea hardware (plasate n directoarele PLATFORM) de cele independente de hardul
sistemului (plasate n directoarele PUBLIC i PRIVATE). Evident c fa de aceste
directoare mai exist i altele ce au roluri specifice funcie conceptele ce stau n
spatele platformei Windows Embedded CE, astfel: (1) directorul CRC, n mod normal
exist n el un singur fiier denumit Crc.ini ce conine informaii despre fierele
instalate i care aparin Platform Builder-ului (component a mediului Microsoft
Visual Studio cu ajutorul creia construim imaginea SO Windows Embedded
Compact), OSDesigns, OTHERS i SDK.

(b)

(a)
(c)
Figura 5.17. (a) i (b) Dou instantanee a ferestrei Catalog Items View i (c) Tabul
Properties asociat cu componenta ActiveSync selectat
Selectarea diferitelor componente ale sistemului de operare se poate realiza n
mod grafic prin selectarea manual (de exemplu din fereastra Catalog Items View,
vezi Figura 5.17) sau automat (de ctre mediul de dezvoltare) a lor sau prin setarea
unor variabile globale ale mediului, variabile de tipul:
SYSGEN_[*]_[*]25 aceste variabile in de includerea componentelor
sistemului de operare care sunt independente de partea hardware,
BSP_[*]_[*]26 sau BSP_NO[*]_[*] variabile ce in de includerea sau de
excluderea unor componente n sistemul de operare care sunt dependent de
partea hardware pe care lucreaz SO,
24
25

fiier ce va fi ulterior ncrcat n memoria NAND a plcii de dezvoltare sau pus pe un SD card,
USB flash etc. n vederea lansrii n execuie a sistemului de operare
Prin [*] nelegndu-se orice combinaie de litere i/sau cifre ce au o anumit semnificaie n direct
corelaie cu respectiva component pe care aceast variabil o reprezint, de exemplu
SYSGEN_AS_BASE.

40

IMG[*] sau IMGNO[*] variabile ce in de imaginea sistemului (influeneaz

introducerea sau nu a unor componente de tipul KITL sau Kernel Debugger),
PRJ_[*] setri suplimentare ale proiectelor ce sunt incluse n imaginea SO.

Din Figura 5.17(a) i (b) se observ c diferitele componente ce pot fi incluse n

sistemul de operare se pot gsi n mai multe stri: neselectate (un ptrel gol interior),
selectate de ctre utilizator (un ptrel cu un check mark n el), selectate de ctre
mediul de dezvoltare (un ptrel verde n interiorul unui ptrat negru datorit
dependenelor existente ntre diferitele componente ale sistemului de operare, dac
utilizatorul selecteaz una dintre ele automat, pentru buna ei funcionare, mediul de
dezvoltare le introduce pe toate acelea de care aceasta se folosete pentru a funciona
corect) i excluse de ctre utilizator sau de ctre mediul de dezvoltare (notate cu un
x rou ntr-un ptrel negru). Tot din Figura 5.17 seciunile (b) i (c) se observ c
fiecare component are asociat o variabil unic, de exemplu ActiveSync are
asociat variabila SYSGEN_AS_BASE. Fie c selectm componenta n mod grafic
sau setm manual valoarea variabilei asociate ei la 1 rezultatul va fi similar,
componenta va fi introdus n imaginea sistemului de operare. n plus, exist
componente care nu permit selectarea lor n mod grafic ci doar prin intermediul
variabilei asociate. Productorul sistemului de operare sau al BSP-ului sunt cei care
specific ntotdeauna n documentaiile proprii aceste componente si variabilele
asociate lor.
Aplicaia 5.5: S se modifice o imagine a unui sistem de operare Windows
Embedded CE prin introducerea de noi componente i prin nlturarea acelora care
nu mai sunt necesare astfel nct noul sistem de operare obinut s fie capabil s
afieze interfaa cu utilizatorul, nu pe LCD-ul inclus n placa de dezvoltare
EVM_3530, ci pe un monitor cu intrare DVI (Digital Visual Interface). Totodat
noul sistem de operare va lucra i cu un dispozitiv extern de tip mouse conectat pe
intrarea USB.
Rezolvare:
n cadrul plcii de dezvoltare OMAP 3530 driver-ul elementului de afiaj
suport dou tipuri de dispozitive: LCD-ul, inclus pe placa de dezvoltare, i orice
tip de dispozitiv de afiare extern prevzut cu un conector DVI. Elementele de
afiare i rezoluiile asociate, suportate de driver-ul sistemul de afiaj al plcii de
dezvoltare OMAP 3530, sunt urmtoarele:

dispozitivul LCD de pe placa de dezvoltare: 480 x 640 la 60 Hz;

dispozitiv extern de afiare cu interfa DVI: 640 x 480 la 60 Hz;
dispozitiv extern de afiare cu interfa DVI: 640 x 480 la 72 Hz;
dispozitiv extern de afiare cu interfa DVI: 800 x 480 la 60 Hz;
dispozitiv extern de afiare cu interfa DVI: 800 x 600 la 56 Hz;
dispozitiv extern de afiare cu interfa DVI: 800 x 600 la 60 Hz;
dispozitiv extern de afiare cu interfa DVI: 1024 x 768 la 60 Hz;
dispozitiv extern de afiare cu interfa DVI: 1280 x 720 la 60 Hz.

De asemenea driver-ul elementului de afiaj ofer urmtoarele faciliti:

Windows GDI (Graphics Device Interface) este o colecie de funcii i

structuri de date ce controleaz afiarea textului i a elementelor grafice.

26

n mod similar cu afirmaia

BSP_DVI_1280W_720H.

de

mai

41

sus,

de

exemplu

BSP_DVI_ENABLE

sau

Funciile GDI sunt implementate pentru crearea i manipularea urmtoarelor

elemente grafice: creioane (pentru desenarea de linii sau curbe), pensule
(pentru umplerea contururilor nchise), fonturi (pentru afiarea textelor) i
imagini de tip bitmap. De asemenea, elementele de stil, de afiare, i cele
culoare pot fi utilizate i sunt specifice fiecrui element grafic. O aplicaie i
poate direciona ieirea ctre un anumit dispozitiv (care poate fi fizic de tipul
element de afiaj, imprimant sau logic de tip zon de memorie) prin crearea
unui device context asociat cu acel dispozitiv. Device context-ul este o
structur gestionat de GDI coninnd informaii despre dispozitivul respectiv
pe care se afieaz/manipuleaz date.
DirectDraw este o interfa API care mi permite manipularea hardware, n
vederea accelerrii, a imaginilor 2D, a lucrului cu texturi, implementnd
totodat tehnici de dubl buffer-are etc.
Dispozitiv hardware pentru accelerarea rotirii imaginilor afiate prin
intermediul motorului VRFB (Virtual Rotated Frame Buffer).
Pentru rotirea ecranului (funcie de poziia dispozitivului orizontal sau
vertical) se utilizeaz n mod standard o metod software sau un dispozitiv de
tip DMA. Utiliznd prima metod programatorul trebuie s dezvolte un modul
software capabil s realizeze rotirea coninutului ecranului naintea stocrii
acestuia n buffer-ul de cadre (frame buffer27). Aceast metod are un impact
negativ, foarte mare asupra performanelor sistemului deoarece de 56-72 de
ori pe secund sistemul trebuie s proceseze o mare cantitate de date,
proporional cu rezoluia de afiare i cu adncimea de culoare a cadrului.
Utilizarea mecanismelor de tip DMA elibereaz procesorul de aceast funcie
(rotirea imaginii) n schimb implic citiri i scrieri n memoria SDRAM care
sunt ineficiente i blocheaz n acele intervale de timp memoria SDRAM i
sistemul prin preluarea controlului asupra magistralelor de date i de adrese.
SoC-ul OMAP3530 ofer suport hardware necesar rotirii ecranului (cu 0,
90, 180 i 270 grade) prin intermediul unui sistem denumit Virtual Rotated
Frame Buffer (VRFB). Acest sistem este inclus n controlerul memoriei
SDRAM i astfel performanele globale ale unei operaii de rotire a ecranului
sistemului embedded sunt mult mbuntite.
Pentru o realizare ct mai rapid a cerinelor acestei probleme vom prelua un
sistem de operare a cror componente fundamentale au fost selectate anterior.
Deci, n primul pas vom copia structura de directoare existent n directorul
"WINCE600\OSDesigns\EVM_3530"
ctre
directorul
identificat
prin
"WINCE600\OSDesigns\EVM_3530_DVI".
n pasul doi, vom lansa n execuie mediul de dezvoltare Visual Studio prin
intermediul componentei Platform Builder, deschiznd fiierul EVM_3530.sln din
directorul "WINCE600\OSDesigns\EVM_3530_DVI\.
n urmtorul pas, al treilea, trebuie s includem n imaginea sistemului de
operare componenta ce gestioneaz modulul de ieire video DVI. Din pcate, n
varianta 6.15.00 a BSP pentru placa de dezvoltare EVM_3530, aceast
component nu poate fi selectat n mod grafic, n cadrul seciunii Catalog. Din
27

n accepiunea utilizat n cadrul acestui paragraf frame buffer este zona de memorie n care se
depoziteaz informaia dintr-un cadru (frame), informaie ce va fi utilizat de dispozitivul de afiare
pentru prezentarea acesteia utilizatorului. Termenul de framebuffer mai poate reprezenta un
dispozitiv de ieire care comand un element de afiaj (de ex. un monitor LCD) cu informaia
stocat ntr-o zon de memorie ce conine datele complete ale uni cadru.

42

acest motiv trebuie s setm n mod manual variabila asociat cu aceast

component variabil cu numele BSP_DVI_ENABLE. Pentru aceasta se
selecteaz tab-ul Solution Explorer, dnd click dreapta pe directorul EVM_3530
i alegnd opiunea Properties. Din partea stng se alege opiunea Environment
din directorul Configuration Properties iar n dreapta n subfereastra
Environment Variable se introduce variabila cu numele BSP_DVI_ENABLE
creia i se atribuie valoarea 1 aceste ultime dou opiuni se realizeaz prin
apsarea butonului New, vezi Figura 5.18.

Figura 5.18. O imagine cu interfaa mediului de dezvoltare

O dat selectat modulul DVI trebuie alese i setate rezoluiile pe vertical i
orizontal sau/i numrul de cadre. Compania Texas Instruments definete n
cadrul BSP-ului asociat plcii EVM_3530 urmtoarele variabile ce seteaz aceste
informaii:

BSP_DVI_640W_480H
BSP_DVI_640W_480H_72HZ
BSP_DVI_800W_480H
BSP_DVI_800W_600H
BSP_DVI_800W_600H_56HZ
BSP_DVI_1024W_768H
BSP_DVI_1280W_720H

n mod similar cu abordarea prezentat pentru variabila BSP_DVI_ENABLE se

alege una din variabilele anterioare, funcie de rezoluia dorit i de cea suportat
de monitor, i se pune valoarea acesteia pe 1.
Deoarece n cadrul acestei plci de dezvoltare nu pot rula simultan display-ul
LCD i sistemul DVI n cel de al patrulea pas se vor invalida touchpanel-ul LCDul i backlight-ul. Invalidai urmtoarele dou componente n Catalog Items View:
Third Party BSP TI_EVM_3530:ARMV4I Device Drivers Display
Backlight Driver
i
Third Party BSP TI_EVM_3530:ARMV4I Device Drivers Touch
Touch Driver

43

Funcie de versiunea BSP este posibil ca aceste dou componente s nu mai

poat fi selectate n mod grafic. n aceast situaie variabilele BSP_NOTOUCH i
BSP_NOBACKLIGHT vor fi puse pe 1. Aceste variabile pot fi setate n mod
similar cu procedura descris anterior sau pot fi puse pe 1 n cadrul fiierului
ti_evm_3530.bat
poziionat
n
structura
de
directoare
\WINCE600\PLATFORM\TI_EVM_3530\. O descriere mai complet a
scriptului ti_evm_3530.bat este prezentat n Anexa 1.
Deoarece display-ul senzitiv nu mai este activ pentru a interaciona cu interfaa
grafic a programelor i cu sistemul de operare trebuie activat mous-ul. Validai
urmtoarea opiune:
Third Party BSP TI_EVM_3530:ARMV4I Device Drivers USB
OMAP3530 USB OTG Driver

n pasul urmtor, al patrulea, trebuie reconstruit imaginea sistemului de operare

fiind recomandat o reconstrucie de tip Clean (se terg componentele construite
anterior28). Deci din meniul Build se aleg succesiv opiunile Clean EVM_3530 i
Build EVM_3530.
Deoarece o parte din iniializrile necesare pornirii sistemului de ieire DVI
sunt realizate n cadrul fazei de boot-are, prin intermediul fiierului XLDR, rezult
c inclusiv acest fiier trebuie ncrcat n memoria FLASH a plcii de dezvoltare
EVM_3530. Ultimul pas al acestei probleme ine de ncrcarea fiierelor
TIEVM3530nand.raw (ce include i fiierele XLDR i EBOOT) i, ulterior,
NK.bin. Dac ncrcarea fiierului NK.bin se poate realiza i prin intermediul
mediului Visual Studio, pentru a ncrca fiierul TIEVM3530nand.raw este
necesar n mod obligatoriu utilizarea utilitarului EVMFlash.exe.
Aplicaia 5.5: S se modifice o imagine a unui sistem de operare Windows
Embedded CE astfel nct prin rularea acestuia pe un sistem de dezvoltare ce are la
baz SoC OMAP3530 s se ofere posibilitatea codrii-decodrii fluxurilor de date
video pe DSP-ul inclus n cadrul acestui SoC. Ulterior s se fac o analiz a
cerinelor necesare (de ex. grad ocupare procesor, memorie utilizat etc.) n
decodarea diferite filmulee utiliznd diferitele codecuri, precum H.264, MPEG2
i MPEG4.
Rezolvare:
SoC-urile OMAP3525 i OMAP3530 (din cadrul familiei OMAP3) includ n
cadrul structurii lor un DSP de tipul TMS320C64X+. Acest DSP ofer suport
hardware n codarea i decodarea informaiei video fr a ncrca n mod
suplimentar procesorul ARM.
Pentru utilizarea codrii i decorrii hardware trebuie s includem n imaginea
sistemului de operare componentele software capabile de a realiza aceste procesri
pe DSP-ul TMS320C64X+. Aceste componente sunt selectate sau nu funcie de
starea urmtoarelor variabile:

28

BSP_H264_DECODE_FILTER

Se terg toate informaiile din urmtoarele directoare:

c:\WINCE600\OSDesigns\EVM_3530-Web\EVM_3530\Wince600\TI_EVM_3530_ARMV4I\cesysgen
c:\WINCE600\platform\TI_EVM_3530\target\ARMV4I\retail
c:\WINCE600\platform\TI_EVM_3530\lib\ARMV4I\retail
c:\WINCE600\platform\common\target\ARMV4I\retail
c:\WINCE600\platform\common\lib\ARMV4I\retail
c:\WINCE600\OSDesigns\EVM_3530-Web\EVM_3530\RelDir\TI_EVM_3530_ARMV4I_Release
c:\WINCE600\OSDesigns\EVM_3530-Web\EVM_3530\BacklightON\obj\ARMV4I\retail

44

BSP_MPEG4_DECODE_FILTER
BSP_MPEG2_DECODE_FILTER

n mod implicit aceste variabile sunt puse pe 1 n interiorul fiierului

ti_evm_3530.bat. n cazul n care aceste variabile au valoarea 0, n cadrul
imaginii sistemului de operare se vor include codec-urile oferite de compania
Microsoft. Aceste codec-uri vor realiza operaiile doar cu ajutorul procesorului
ARM.

Activitatea de background
a sistemului de operare

Regim
tranzitoriu

Decodarea continu a
fluxului video

Figura 5.19. Analiza a trei parametri n momentul lansrii n execuie a aplicaiei

Windows Media Player
Pentru a analiza ncrcarea generat de un anumit program se poate folosi
utilitarul Performance Monitor. Pentru ca acest utilitar s primeasc datele
necesare trebuie s includem n imaginea sistemului de operare componenta KITL
paii necesari includerii acestei componente au fost prezentai n Aplicaia 5.3.
Pentru lansarea n execuie a utilitarului Performance Monitor executai urmtorii
pai: Target Remote Tools Performance Monitor. Dup realizarea conexiunii
apsai butonul marcat cu semnul plus de pe interfaa grafic a aplicaiei i
45

adugai spre asaliz urmtorii parametri: Processor Time [%], Kernel Time [%] i
Memory Load.
n Figura 5.19 se prezint variaia celor 3 parametri, prezentai mai sus, anterior
lansrii n execuie a aplicaiei Windows Media Player i ulterior acestui moment.
Filmul care a fost deschis n momentul lansrii n execuie a programului Windows
Media Player a fost codat conform standardului MPEG 4, la o rat de 4 Mbps.
Din Figura 5.19 se observ c anterior lansrii n execuie a Windows Media
Player-ului curbele ce indic parametrii Processor Time i Kernel Time aproape se
suprapun, deci cel care ocup aproape n totalitate procesorul era nucleul SO. O
dat cu lansarea aplicaiei se observ c ntre parametrii Processor Time i Kernel
Time apare un ecart semnificativ dovad c Windows Media Player-ul ruleaz i
ocup o parte substanial din puterea procesorului. Simultan i Kernel Time crete
ca pondere datorit procesrii tuturor ntreruperilor ce in dispozitivele de stocare a
datelor (unde este depozitat fiierul AVI), de afiare i reproducere a semnalului
sonor.

Figura 5.20. ncrcarea procesorului i a memoriei de ctre aplicaia Windows Media

Player
n Figura 5.20 se observ gradul de ncrcare a memoriei i al procesorului n
momentul decodrii continue a fluxului de date video de ctre aplicaia Windows
Media Player prin intermediul codec-ului ce utilizeaz DSP-ul TMS320C64X+
46

inclus n SoC-ul OMAP3530. Se observ c ncrcarea medie a procesorului ARM

este n jur de 58%.
Includerea sau excluderea celei mai mari pri a componentelor sistemului de
operare Windows Embedded CE este realizat n mod automat de ctre mediul de
dezvoltare a sistemului de operare prin selectarea unui anumit ablon (template)
specific. n mod normal dup determinarea tipului de dispozitiv ce va fi construit,
trebuie s proiectm sistemul de operare capabil s gestioneze echipamentele
hardware nglobate n dispozitiv i s ofere suport aplicaiilor software ce vor rula pe
dispozitiv.
n cadrul etapei de proiectare a sistemului de operare, ntr-un prim pas, mediul de
dezvoltare ne ofer un numr de abloane care ne definesc cadrul general al
componentelor utilizate, preciznd un numr de componente predefinite ce vor fi
incluse n sistemul de operare pe care tocmai l construim n direct concordan cu
scopul final al dispozitivului hardware creat. Ulterior, n cel de al doilea pas, vom
selecta, sau nu, manual alte componente ale sistemului de operare, necesare aplicaiei
noastre, pe care le vom ngloba n imaginea final a sistemului de operare.
n Tabelul 5.4 este prezentat o descriere succint a diferitelor abloane
preexistente ce pot fi utilizate drept baz n dezvoltarea imaginii sistemului de operare
(run-time image).
n urma dezvoltri proiectului sistemului de operare prin selectarea grosier a
diferitelor componente, cu ajutorul abloanelor existente, i prin rafinarea manual a
rezultatului obinut n directorul asociat sistemului de operare (plasat n directorul
OSDesigns) sunt stocate aceste informaii.
Dar pentru construirea imaginii sistemului de operare nu se folosesc doar
informaiile stocate n directorul caracteristic proiectului sistemului de operare, fiind
folosite i multe alte componente existente sub form de cod sau sub form
precompilat n diferite locuri a structurii de directoare ce caracterizeaz mediul de
dezvoltare a sistemului de operare. n Tabelul 5.4 se prezint structura de baz de la
care se pornete crearea sistemului de operare ce caracterizeaz mediul de dezvoltare
a sistemului de operare Windows Embedded CE.
Tabelul 5.4. Structura de directoare a platformei de dezvoltare Windows CE
Director

Descriere

3rdParty

Este un director ce conine propriile componente dezvoltate (precum

cea prezentat n Aplicaia 5.3 pasul 2) sau pe cele ce au fost clonate
din directoarele PUBLIC sau PRIVATE.

OSDesigns

Acest director conine proiectele diferitelor sisteme de operare aflate

n diferite stadii de dezvoltare. Fiecare subdirector n parte conine
proiectul unui sistem de operare Windows Embedded CE individual. n
cadrul structurii de directoare fiierul cu extensia pbxml este acela care
conine baza de date cu toate componentele ce vor forma imaginea
viitorului sistem de operare. n cadrul directorului ce nglobeaz
proiectul unui SO exist un subdirector denumit RelDir (release
directory) ce poate conine att versiunea debug sau release a
sistemului de operare.

OTHERS

Conine un set larg de componente i instrumente grupate astfel:

ATL (active tamplate library) format din librrii, fiiere heder i

47

alte fiiere utilizate n operaiile de debug a aplicaiilor dezvoltate

cu ajutorul ATL;
DOTNETV2, DOTNETV3.5 conine fiiere executabile i dll-urile
pentru .NET versiunea 2.0 i 3.5 pentru arhitecturile instalate;
EDB conine module executabile ce susin standardul Enhanced
Database pentru fiecare arhitectur instalat;
SQLCE20 - subdirector ce conine librrile specifice fiecrei
arhitecturi pentru SQL Compact Edition;
VisualStudio conine un utiltar (SDAuthUtilDevice.exe - Smart
Device Authentication Utility), specific diferitelor platforme, ce
permite dezvoltarea programelor pentru platformele hardware ce
ruleaz Windows Embedded CE n cadrul mediului Visual Studio
fr a utiliza ActiveSync.

PLATFORM

Include toate componentele sistemului de operare care sunt

dependente de partea hardware a sistemului embedded. Fiecare
subdirector individualizeaz elementele specifice unei anumite
platforme hardware caracterizat de un numr de dispozitive externe
hardware i de un anumit SOC. Aceste componente sunt specifice
BSP-ului (board support packages), precum (OEM adaptation layer) i
drivere, sau alte drivere ce nu sunt specifice BSP-ului.
Poate conine i toate acele BSP-uri nou create sau clonate (i
ulterior modificate) din acelea existente.

PRIVATE

Director ce conine codul surs complet al nucleului sistemului de

operare (inclusiv diferitele servere precum HTTP). Acesta este un
director opional care va exista atta timp ct este acceptat licena
companiei Microsoft. Avantajul major al existenei codului nucleului
sistemului de operare este dat de posibilitatea modificrii acestuia cu
obligativitatea anunrii clienilor poteniali despre existena acestor
modificri.

PUBLIC

Director ce conine componentele sistemului de operare (interfaa cu

utilizatorul, internet explorer-ul etc.), componente ce sunt independente
de partea hardware a sistemului de dezvoltare sau a sistemului
embedded, i fiiere de configurare a acestora.
Cea mai mare parte componentelor din acest subdirector au fost
dezvoltate de compania Microsoft.

SDK

Conine utilitarele necesare cros-compilrii, compilrii i linkeditrii imaginii sistemului de operare pentru diferitele platforme
suportate (x86, ARM, SH4, MIPS).
De asemenea, alte utilitare necesare atingerii obiectivului construirii
imaginii sistemului de operare, se regsesc i n directorul %_
WINCEROOT%\PUBLIC\COMMON\OAK\BIN\I386.

48

Tabelul 5.5. Tipuri de abloane ale sistemului de operare oferite n Windows Embedded 6.0
ablon

Versiune
Digital media receiver

Bun de larg consum

(Consumer media device)

Custom device

Set-top box
Industrial controller

Dispozitiv industrial

Internet appliance

Gateway

Mobile handheld
Dispozitiv PDA
Enterprise Web Pad
IP phone basic
Telefon
IP phone advanced

Descriere
Ofer scheletul unui sistem de operare capabil s stocheze, gestioneze i redea diferite tipuri de formate
audio, imagini i video.
Sistemul de operare va oferi toate acele funcii specifice unui dispozitiv ce este conectat la un display,
televizor etc. pe care va prezenta informaii de tip multimedia preluate din internet. Interfaa cu
utilizatorul (shell-ul sistemului de operare) va fi standard n schimb browser va oferi toate acele funcii
i controale, pe interfaa cu utilizatorul, specifice unui televizor.
Nu sunt selectate implicit nici o component a sistemului de operare, permind utilizatorului s aleag
manual toate componentele necesare sistemului de operare.
Ofer suport pentru aplicaiile de control i/sau automatizri industriale ncepnd cu simple panouri de
control a unui utilaj i de interfaare cu el de tip HMI (human-machine interface) pn la aplicaii de tip
control logic programabil (PLC - programmable logic controllers). Printre componentele ce sunt
incluse n imagine: touch-screen, mouse, reea, manegment al puterii, servicii de criptografie etc.
Sistemul de operare este destinat punctelor de lucru staionare (monitor, mouse, tastatur) cu suport
dedicat aplicaiilor de tip internet susinute de un browser.
Sunt dispozitive ce ofer servicii ctre un numr de clieni (calculatoare sau alte dispozitive) de la o
singur conexiune de tip internet (dial-up sau WAN wide area network). n final aceste dispozitive
pot fi de exemplu rutere. Sistemul de operare trebuie s ofere suport i s includ componente pentru
Network Address Translator, Ipv4, Ipv6, firewall, web server (pentru administrare), conexiuni wireless
etc.
Dispozitive mobile cu interfaare de tip touch screen sau tastatur (precum telefoane mobile,
nregistratoare coduri de bare etc.). Sistemul de operare ofer suport pentru: acces la internet, email,
calendar, address book etc.
Funcionalitatea sistemului de operare include acele componente pentru suportul unui ecran cu o
rezoluie de 640 x 480 sau mai mare a unui dispozitiv portabil cu acces la internet. Interfaarea se
realizeaz prin mouse sau touch screen.
Sistemul de operare susine funcionalitile unui dispozitiv de tip telefon VoIP cu dou linii fr s
aib o interfa grafic (headless devices).
Sunt incluse componentele necesare unui telefon VoIP cu interfa grafic (care poate fi i de tip touch
screen), incluznd aplicaii de tip agend contacte, Windows Messenger i un browser de internet.

49

Small-footprint device

Windows Thin Client

Thin client

Enterprise terminal
Windows network
projector

n aceast situaie sistemul de operare este minimal i este dedicat acelor dispozitive pentru care
mrime imaginii sistemului de operare este critic. Acest ablon este dedicat aplicaiilor ce nu utilizeaz
un display i include componente legate i necesare modulului coredll.
n principal dispozitivele ce sunt construite cu componentele din acest ablon sunt terminale la care
accesul se face prin intermediul unor proceduri de tip remote-desktop, interfaa cu utilizatorul este de
asemenea una minimal. Sistemul de operare ofer suport pentru o conexiune la internet iar protocolul
de baz este Remote Desktop Protocol (RDP).
Sistemul de operare furnizeaz suport pentru dispozitivele de tip automat bancar, cas de marcat,
dispozitiv de schimb valutar automat, automat doze de suc etc.
Dispozitivele ce ruleaz un astfel de sistem de operare pornit de la un astfel de template permit preluare
ecranului unui calculator personal, prin intermediul unui protocol de tipul RDP i afiarea acestuia.
Dispozitivul final fiind unul de tip videopriector de reea.

50

5.5.3. Construirea sistemului de operare Windows Embedded CE

Bibliografie
[Web 2009] http://www.microsoft.com/downloads/details.aspx?familyid=B478949ED020-465E-B451-73127B30B79F&displaylang=en
[Hall, 2005] M. Hall, Windows CE 5.0 for real-time systems, Embedded Computing
Design, pp 37-41, Nov 2005
[Dekey, 2011] Sam Dekey, Making Windows NT a Real-Time Solution A Technical
Overview, National Instrument, descarcat de pe www.ni.com n 2011

51

Anexa 1.
Fiierul ti_evm_3530.bat este un fiier de configurare de tip script care permite
configurarea BSP conform necesitilor utilizatorului. Selectarea includerii sau nu a
diferitelor drivere asociate cu diferitele dispozitive hardware existente are un impact
major asupra funcionalitii sistemului, a performanelor acestuia ct i asupra
mrimii fiierului NK.bin.
Fiierul ti_evm_3530.bat este un fiier de tip .bat poziionat n directorul
%_WINCEROOT%\platform\ti_evm_3530 unde se gsesc i urmtoarele scripturi
pentru platformele susinute de acest BSP:

evm1_ti_evm_3530.bat pentru sistemul de dezvoltare TMDXEVM3503;

evm1_mdc_ti_evm_3530.bat pentru sistemul de dezvoltare TMDXEVM3503 ce
include i TI Multimedia Daughter Card;
evm2_ti_evm_3530.bat pentru OMAP35x Evaluation Module (EVM)
TMDSEVM3530 i
evm2_ti_evm_3730.bat
pentru
modulul
de
evaluare
AM/DM37x
(TMDXEVM3730).

n momentul n care se utilizeaz unul din sistemele de evaluare prezentate anterior

scriptul asociat se redenumete n ti_evm_3530.bat.
Multe din componentele existente n cadrul BSP nu pot fi selectate n mod grafic
prin intermediul opiunii Catalog din mediul Visual Studio, aceasta oblignd fie
modificarea fiierului ti_evm_3530.bat fie definirea strii asociate cu variabila
respectiv n mod grafic prin intermediul meniului Environment Variable n mod
similar cu modalitatea abordat n Aplicaia 5.5.
De exemplu o parte din variabilele care pot fi setate sau nu n vederea includerii
sau nu a drivere-lor asociate sunt urmtoarele:

set BSP_NOSPI1=
set BSP_NONAND=
set BSP_NONLED=
set BSP_NODMA=
set BSP_NOGPIO=
set BSP_NOTLED=
set BSP_NOSPI=
set BSP_NOTWL=
set BSP_NORTC=
set BSP_NOMCBSP=
set BSP_NOBACKLIGHT=
set BSP_NOTOUCH=
set BSP_NOKEYBD=
set BSP_NOAUDIO=
set BSP_NOSDHC=
set BSP_NODISPLAY=
set BSP_NOPWRKEY=
set BSP_NOBATTERY=
set BSP_NOUSB=
Analiza fiierului ti_evm_3530.bat permite de asemenea i o nelegere profund
a mecanismelor interne existente n cadrul BSP precum i a limitrilor acestuia. De
exemplu, se poate afla c atunci cnd Virtual Rotated Frame Buffer (VRFB) este
52

activat CODEC-urile oferite de TI vor funciona corect, n schimb cele existente nativ
n Windows CE nu vor funciona, iar pentru ca acestea s funcioneze corect
BSP_NOVRFB trebuie pus pe unu n acest mod sistemul hardware VRFB este
invalidat.

53