Curs 2:

INTRODUCERE ÎN
SISTEMELE EMBEDDED

• Caracteristici ale EmS

• Clasificarea EmS
• Integrarea calculatorului în aplicaţie
• Modelul EmS şi niveluri de Software

1
 Caracteristici ale EmS
Caracteristici funcţionale:
1. Arhitectură specifică aplicaţiei, cu diverse
constrângeri dictate de aplicaţia ţintă
2. Funcţionare ca sisteme reactive şi real - time
Caracteristici ne-funcţionale:
3. Eficienţă energetică şi de gabarit
4. Cerinţe restrictive privind flexibilitatea şi
fiabilitatea în funcţionare (“dependable
systems”):
2
 1. Arhitectură specifică aplicaţiei
• Sunt sisteme eterogene (software, electronică analogică şi digitală,
componente mecanice, optice etc.)
• Resurse hardware limitate
– Arhitectură simplificată (set instrucţiuni, organizare)
– Frecvenţă redusă CLOCK procesor
– Dimensiune memorie
– Interfeţe seriale sincrone
– Memorie externă (flash-drive)
• Periferice de intrare – ieşire (interfaţa cu utilizatorul şi mediul)
specifice
• Set de funcţii particulare – firmware
– Comportare auto-adaptivă, auto-configurare, auto-restaurare a funcţionării
– Uneori este necesar (nucleu de) sistem de operare în timp real
• Sunt sisteme comunicative
– comunicare cu mediul înconjurător prin senzori şi actuatori,
– legare în reţea (EmS distribuite)

3
 2. Sisteme reactive şi real-time

• Sisteme reactive
• Funcţionare cu respectarea restricţiilor de timp (real time)
– Timp de execuţie predictibil
– Constrângeri RT sensibile la timp
– Constrângeri RT critice la timp
– Un răspuns garantat al sistemului trebuie să fie explicat fără a
folosi argumente statistice.
• Prelucrare multirată (audio/video, CD (44,1kHz)/DAT(48kHz)

4
 Prelucrare în timp real
Timp de
aşteptare
Timp de prelucrare

Eşantion

n n+1
Timp eşantionare

• Vom vorbi despre o aplicaţie în timp real doar

dacă timpul de aşteptare este ≥ 0

5
 3. Eficienţă energetică şi de gabarit

• Costuri
– Costuri de fabricaţie
– Costurile de proiectare (NRE – nonrecurring
engineering costs)
– Puterea
• Alimentare de la baterii
• Surse alternative de energie (radiaţie luminoasă, vibraţii,
mişcare etc.)
• Tendinţă: Sisteme autonome energetic
• Dimensiunile fizice
6
 4. Cerinţe restrictive privind flexibilitatea
şi fiabilitatea în funcţionare

• Fiabilitate / Siguranţa în funcţionare (Reliability)

• Mentenabilitate (maintainability)
• Disponibilitate (availability)
• Siguranţa (safety)
– NU: RESTART, INSTAL DRIVER, SAFE MODE, ABORT +
RETRY, Ctrl+Alt+Del.
• Securitatea (date şi utilizatori)
• Toleranţă la greşeli (revenirea din starea de eroare uşor de
făcut şi fără intervenţia utilizatorului)
• Timp de apariţie pe piaţă
• Personalizare (uneori)
7
 Clasificare a sistemelor embedded
• Clasificarea se poate face după criteriul ce se
referă la tipul de hardware utilizat.
Caracteristicile devin constrângeri la proiectarea
EmS
1. Sisteme construite cu hardware de uz general, sau
extrem de puţin hardware dedicat.
2. Proiecte SoB – System on a Board. (cu cantitate mare de
hardware dedicat)
3. Proiecte SoC – System on a Chip. (cu cantitate mare de
hardware dedicat)

8
 Clasificare a sistemelor embedded
1. Sisteme construite cu hardware de uz general, sau
extrem de puţin hardware dedicat.

• Efortul de proiectare HW este minimizat pentru lansarea

rapidă pe piaţă (suport hardware de dezvoltare cumpărat)
• Efort orientat spre dezvoltarea funcţiilor în SW, care
diferenţiază funcţiile produsului
• HW utilizează microprocesoare disponibile pe piaţă
• Exemplu: analiză semnale în spital: PC + hardware
achiziţie.

9
 Clasificare a sistemelor embedded

2. Proiecte SoB – System on a Board. (cu cantitate mare

de hardware dedicat)

• Microprocesoare de mare performanţă combinate cu logică

customizată (FPGA, ASIC) pe aceeaşi placă
• Interfeţe de IO specifice funcţiilor cerute
• Pot exista plăci multiple şi procesoare multiple
• Cantitate relativ mare de software
• Dimensiunea şi puterea consumată sunt neimportante pentru aplicaţie
• Un bun exemplu sunt routere produse de CISCO, unde se foloseşte o
combinaţie de custom ASIC şi microprocesoare extrem de rapide

10
 Clasificare a sistemelor embedded

3. Proiecte SoC – System on a Chip. (cu cantitate mare de hardware

dedicat)
• SoC pentru performanţe de viteză, fiabilitate, dimensiune, putere
• Eficente doar pentru număr mare de exemplare vândute
• Unul sau mai multe MP pe chip, memorie şi periferie integrată,
specifice aplicaţiei
• Costuri mari de dezvoltare
• Proiecte SOC pe bază de nuclee (Core based SOC design)
• Nuclee IP pre - proiectate şi pre – verificate: Procesoare, Memorii şi
controllere, Periferice şi controllere, Multimedia, DSP, controller
Ethernet
• Se fabrică ASSP (Application Specific Standard Products), ASIC full
custom design
• Exemple: MP3 players, camere digitale

11
 INTEGRAREA CALCULATORULUI ÎN
APLICAŢIE
Traductor Condiţionare de Conversie
semnal analogic AD Canal de
culegere şi
prelucrare

Sistem
testat, sau
Microcalculator
proces fizic

Canal de
control

Element Condiţionare Conversie

execuţie (amplif., filtrare) DA

operaţiile se desfăşoară continuu, ciclic ⇒ aplicaţii in timp real

12
 Initializare parametri si definire
porturi I/O

STRUCTURA Achizitie date din porturi de intrare

(citire - "READ")
TEMPORALĂ A
UNEI Executie program specific
(prelucrare date de intrare,
APLICAŢII ÎN conform algoritmului numeric)

TIMP REAL Transmitere date prelucrate prin

port de iesire (scriere - "WRITE")

DA Programul
trebuie reluat

Lansare alt program

specific STOP
13
 Funcţionalitate complexă
• Real-time / reactiv
• Multitasking în EmS ?
– De exemplu un termostat programabil ce controlează centrala
termică realizează cel puţin trei sarcini: (1) monitorizarea
temperaturii, (2) monitorizarea orei din zi, (3) supravegherea
tastaturii. Fire de cod (thread) separate.

14
Modelul EmS

Application software Layer

(Opţional)

System software Layer

(Opţional)

Hardware Layer
(Obligatoriu)

15
 Niveluri software

Applications Applications

Operating system Operating system

Firmware Firmware Application

Firmware

Hardware Hardware Hardware

Desktop Complex EmS Simple EmS

computer

bootloader
start-up programme

16
 Iniţializare EmS
• Programului de iniţializare la pornire (bootloader) este un program
special rulat la pornirea sistemului, programul fiind stocat în memorii
de tip ROM (inclus în firmware)
– Software înglobat în hardware = firmware
• Este un program specific pentru calculatoare desktop, dar există şi la
unele EmS
• Bootloader citeşte sistemul de operare (dacă există) de pe discul
magnetic, sau dintr-o reţea şi-l încarcă în memoria RAM
• Bootloader realizează iniţializarea componentelor calculatorului
integrat în aplicaţie

17
 Iniţializare EmS
• Dacă nu se foloseşte sistem de operare la pornirea
sistemului se rulează un program de iniţializare (start-up)
• Programul de start-up al EmS:
– dezactivează întreruperile
– iniţializează electronica
– testează calculatorul (RAM, CPU şi programele)
– porneşte codul aplicaţiei
• Multe EmS pot face revenire dintr-o stare de cădere pe
termen scurt a alimentării (fără auto-testele recente)
• Timpul de restart obişnuit este sub o zecime de secundă.

18
 Embedded Software

• Nivelurile software prezentate grafic în modelul EmS pot

avea poziţii diferite în ierarhie, în funcţie de sistem
• Categorii de embedded software:
– Software de sistem (pe baza căruia funcţionează aplicaţiile)
– Software de aplicaţie (defineşte funcţiile scop ale unui EmS)
• Exemple de programe de sistem:
– Device drivers – programe de control a dispozitivelor hardware
– Sistem de operare
– Middleware

19
 Device Drivers

• Cele mai multe componente hardware înglobate au nevoie

de un software pentru iniţializare şi administrare
• Componenta software care interacţionează direct şi
controlează componenta hardware este numită device
driver
• Aceste programe de control sunt organizate în biblioteci de
programe care iniţializează hardware şi intermediază
accesul la hardware pentru nivelurile superioare de
software
• Driver-ele sunt legătura dintre hardware şi nivelurile de
sistem de operare, middleware şi aplicaţii

20
 Device Drivers
Application software Layer Application software Layer
Application software Layer

System software Layer System software Layer

System software Layer
Middleware Layer Operating System
Layer

Device Driver Layer

Device Driver Layer Device Driver Layer

Hardware Layer Hardware Layer Hardware Layer

21
 Device Drivers

• Tipurile de componente hardware ce au nevoie de sprijin

din partea unor driver-e sunt diferite de la sistem la sistem
• Pot exista drivere pentru:
– funcţionalitatea procesorului la evenimente atipice
(driver de întreruperi)
– memorie (acces, alocare, administrare)
– iniţializare şi transferuri pe magistrală
– iniţializarea şi controlul interfeţelor de I/O (cum ar fi
reţea, grafică, intrări, stocare, I/O pentru depanare etc)

22
 Device Drivers
• Exemple de funcţii generale incluse în driver-e: iniţializare,
configurare, activare, dezactivare dispozitive hardware, acces pentru
citire / scriere la hardware
• Există şi multe funcţii specifice.
• Exemplu de funcţii necesare unui device driver pentru servirea
întreruperilor
1. Iniţializare hardware pentru întreruperi după alimentare, sau reset (controller
întreruperi, activare întreruperi etc. )
2. Configurare hardware de întreruperi la deconectarea alimentării (controller
întreruperi, dezactivare întreruperi etc.)
3. Funcţie de dezactivare întreruperi, care permite altor programe să dezactiveze
dinamic (în timpul funcţionării) întreruperile active (nu şi pentru NMI care nu
pot fi dezactivate)
4. Funcţie de activare întreruperi, care permite altor rutine să valideze dinamic
întreruperi inactive
5. Servirea întreruperii, codul propriu-zis al servirii întreruperii, care este executat
după apariţia întreruperii programului principal (această rutină poate avea
complexitate foarte diferită de la sistem la sistem, de la o rutină simplă ne-
imbricată, la rutine imbricate şi reentrante)
23
 Device Drivers
• Un program poate vedea o componentă hardware ca fiind
la un moment într-una din următoarele trei stări:
– Inactiv. Starea inactivă a hardware este interpretată ca:
• hardware deconectat (cere o funcţie de instalare)
• fără alimentare (cere o rutină de iniţializare) sau
• dezactivat (cere o rutină de validare).
– Ocupat
• Este o stare activă a hardware şi de aici nevoia de funcţii de
dezinstalare, oprire şi / sau dezactivare
• Hardware care este în stare ocupat prelucrează date şi aceasta poate
cere un anumit mecanism de eliberare
– Aşteptare
• Este o stare activă a hardware şi de aici nevoia de funcţii de
dezinstalare, oprire şi / sau dezactivare
• Hardware care este în starea de aşteptare, este eliberat de sarcini, ceea
ce permite, de exemplu, o cerere de tip achiziţie, citire sau scriere
24
 Device Drivers
• În unele cazuri distincţia dintre aceste niveluri de software este clară,
iar alteori codul driver-elor este integrat în alte niveluri
• În funcţie de tipul procesorului, diferite tipuri de software pot fi
executate în moduri diferite. Două din modurile cele mai comune de
execuţie sunt:
– modul supervizor
– modul utilizator (user)
• Cele două moduri diferă în principal prin modul în care software are
dreptul să acceseze componentele sistemului, în mod supervizor având
mai multe privilegii de acces decât în mod utilizator.

25
 Sisteme de operare Embedded

• Un sistem de operare (SO) este o componentă opţională a stivei

software specifică EmS
• Un SO poate fi utilizat pe orice procesor (ISA) către care SO respectiv
a fost portat
• Un SO poate să stea deasupra hardware, deasupra unui nivel device
driver, sau peste un pachet software de suport pentru o anumită placă
de dezvoltare (Board Support Package)
• SO constă dintr-un set de biblioteci software care servesc la două
scopuri principale într-un EmS:
– Să furnizeze un nivel de abstractizare pentru programele de la nivelul
superior SO, astfel încât acestea să fie mai puţin dependente de
hardware, făcând astfel mai uşoară dezvoltarea de software de tip
midlleware şi aplicaţie
– Să administreze resurse hardware şi software ale sistemului astfel ca
întregul sistem să funcţioneze eficient şi sigur.

26
 SO pentru modelul EmS
Application software Layer Application software Layer Application software Layer

System Software Layer System Software Layer System Software Layer

Operating System Layer Middleware Layer Operating System Layer

Middleware
Board Support Package Operating System Layer
Layer
Device Drivers
Device Drivers Device Driver Layer

Hardware Layer Hardware Layer Hardware Layer

27
 SO Embedded
• Nucleul (kernel) este componenta prezentă la toate SO
• Principale funcţiuni:
– Managementul proceselor. Modul în care SO administrează şi vede alte
programe în sistemul embedded (prin procese). O sub-funcţie tipic
întâlnită în cadrul managementului proceselor este administrarea
întreruperilor şi detecţia erorilor
– Managementul memoriei. Spaţiul de memorie al EmS este partajat de
toate procesele, astfel încât trebuie făcută administrarea accesului şi a
alocării spaţiului de memorie. Există subfuncţii care implementează un
sistem de securitate al memoriei
– Managementul sistemului de I/O. Dispozitivele I/O trebuie partajate către
diferitele procese, accesul şi alocarea. În cadrul sistemului de I/O trebuie
să existe şi un management al fişierelor ca metodă de stocare şi
administrare a informaţiilor sub formă de fişiere.

28
 SO Embedded
Embedded OS

Middleware (optional)

Kernel

Process Management Memory Management

I/O System Management

Device Drivers (Optional)

29
 Middleware
• Liniile de demarcaţie dintre middleware şi software de aplicaţie,
respectiv software de sistem sunt neclare
• Middleware (Mw) este intermediar între programe de aplicaţii şi
programe de sistem
• Mw este software care a fost extras din nivelul de aplicaţie din mai
multe motive:
– Ar putea fi că este deja inclus ca parte în SO de pe piaţă
– Permite astfel reutilizarea pentru alte aplicaţii
– Scade timpul şi costurile de dezvoltare prin cumpărarea sa
– Simplifică complexitatea aplicaţiei, prin centralizarea unor structuri
software care în mod tradiţional s-ar fi găsit redundant în nivelul de
aplicaţii
– Totuşi, introducerea nivelului de middleware, introduce timpi
suplimentari, care pot avea un impact mare asupra scalabilităţii şi
performanţei

30
 Middleware
• Un Mw de EmS este un nivel de software de sistem care stă deasupra
device-drivers, sau deasupra SO, iar uneori poate fi încorporat chiar în
SO
• Mw este un nivel de abstractizare utilizat în general la dispozitivele
embedded cu două sau mai multe aplicaţii, pentru a furniza
flexibilitate, securitate, portabilitate, conectivitate, intercomunicare şi /
sau mecanisme de interoperabilitate între aplicaţii
• Mw este un program de sistem pentru că furnizează funcţii mai multor
aplicaţii
• Mw este însă asemănător şi cu programele de aplicaţie, pentru că
depinde de funcţiile oferite de SO

31
 Middleware
Application Layer Application Layer

Application software
System Software Layer System Software Layer
Layer
Middleware Operating System System Software Layer

Middleware Middleware
Operating System

Device Drivers
Device Drivers Device Drivers

Hardware Layer Hardware Layer Hardware Layer

32
 Middleware
• Distincţia între Mw şi SO este neclară, pentru că unele funcţiuni
încorporate în trecut în software de tip middleware sunt în prezent
încorporate în SO
– Exemplul tipic este stiva TCP/IP pentru telecomunicaţii inclusă în prezent
în marea majoritate a SO.
• Cea mai mare parte a Mw se poate încadra într-una din cele două
categorii generale:
– Mw cu scop general, ceea ce înseamnă că sunt implementate într-o
varietate de dispozitive, cum ar fi protocoale de reţea, sistem de fişiere,
sau unele maşini virtuale cum ar fi JVM (iar ca poziţie se găsesc deasupra
nivelului device driver şi sub nivelul de aplicaţie)
– Mw specifice, ceea ce înseamnă că sunt specifice unei familii particulare
de EmS, cum ar fi un software bazat pe standard de TV digital, care stă
peste un SO sau peste JVM.

33