Che materia stai cercando?

Anteprima

ESTRATTO DOCUMENTO

Scheduling per il real-time

• Tempi di risposta

– Una soluzione alternativa per realizzare un kernel con diritto di

preemption consiste nel proteggere le modifiche alle strutture

dati del kernel mediante i tipici meccanismi di sincronizzazione

• Es. Semafori

– In tal modo il kernel può essere interrotto praticamente in ogni

momento, poiché i dati del kernel in corso di aggiornamento,

data la protezione, non possono comunque essere modificati da

altri processi

• Ovviamente tale soluzione porta a un codice delle chiamate di

sistema meno snello, poiché in ogni momento deve essere garantita

la correttezza delle strutture dati in caso d'interruzione

– Aiuto: kernel rientrante

Sistemi Embedded 2010/2011 49

Scheduling per il real-time

• Tempi di risposta

– Un codice è detto rientrante se è progettato in modo che una

singola copia del codice in memoria possa essere condivisa ed

eseguita contemporaneamente da più processi

• Affinché una routine o comunque una parte di codice sia rientrante

deve soddisfare questi requisiti

– Nessuna porzione del codice possa essere alterata durante

l'esecuzione

– Il codice non deve richiamare nessuna routine che non sia a sua volta

rientrante

– Il codice deve usare solo variabili temporanee allocate sullo stack

» Il codice non deve modificare né variabili globali né aree di memoria

condivisa né impiegare variabili locali statiche

• Se una data porzione di codice non rispetta queste regole, non è

possibile farla eseguire da più processi contemporaneamente senza

regolarne l'accesso tramite semafori o sezioni critiche

Sistemi Embedded 2010/2011 50

Scheduling per il real-time

• Tempi di risposta

– Una volta compreso il panorama delle scelte circa il

funzionamento dei kernel, e come questi influenzino la

complessità e i tempi di risposta del SO, si può focalizzare

l'attenzione sul sistema embedded nel quale è inserito

• Come detto più volte, la reattività agli eventi è una delle

caratteristiche salienti di un sistema embedded

– Un fattore cruciale è il tempo di reazione, ovvero il tempo che

intercorre fra il manifestarsi dell'evento e l'esecuzione del codice

che lo deve gestire

• A partire dall'evento esterno, che si traduce normalmente in

un'interruzione verso il processore, si hanno diversi ritardi prima che

sia eseguito effettivamente il processo real-time

Sistemi Embedded 2010/2011 51

Scheduling per il real-time

• Tempi di risposta

– Latenza nella risposta ad un evento

Sistemi Embedded 2010/2011 52

Scheduling per il real-time

• Tempi di risposta

– Il ritardo che si verifica nel caso di una interruzione dipende dal

tempo trascorso dalla notifica del segnale alla CPU, l'avvio e

l'esecuzione della routine per la sua gestione (ISR)

• In tale frangente si deve terminare l'istruzione corrente,

comprendere di quale interruzione si tratti, salvare lo stato del

processo in esecuzione e solo allora eseguire il codice della ISR

– Il tempo necessario all'avvio della ISR, non la sua esecuzione, è

la latenza relativa all'interruzione ed è cruciale che sia

minimizzato

Sistemi Embedded 2010/2011 53

Scheduling per il real-time

• Tempi di risposta

– Per tale motivo si deve cercare di contenere il più possibile

l'intervallo di tempo in cui le interruzioni sono disabilitate

• Come accade durante l'aggiornamento delle strutture dati del SO

– Ovviamente tale obiettivo incrementa la complessità nel progetto delle

funzioni di sistema operativo, poiché è necessario identificare e gestire

con precisione le parti di codice che possono essere interrotte

– La maggior parte dei SO-RT riduce i tempi in cui le interruzioni

sono inibite, ma per applicazioni hard real-time spesso è

necessario anche garantire i tempi massimi di risposta alle

interruzioni, per assicurare un comportamento deterministico

Sistemi Embedded 2010/2011 54

Scheduling per il real-time

• Tempi di risposta

– Con riferimento sempre alla figura precedente, l'altra

componente della catena dei ritardi è la latenza relativa al

dispatch

• Il tempo necessario per bloccare un processo e avviarne un altro

– La tecnica più comunemente utilizzata per ridurre la latenza di

dispatch consiste nell'adottare kernel con diritto di preemption

• Nella fase detta di conflitto, infatti, si devono prelazionare i processi

in esecuzione nel kernel e ottenere da parte dei processi a bassa

priorità le risorse necessarie per eseguire il processo RT

– Nei sistemi UNIX commerciali (Solaris), la latenza del dispatch con

preemption inibita supera i 100~ms, mentre con preemption abilitata

scende sotto il millisecondo

Sistemi Embedded 2010/2011 55

Scheduling per il real-time

• Tempi di risposta

– Un altro problema che può influenzare la latenza relativa al

dispatch è il fenomeno dell'inversione delle priorità

• Si supponga che un processo a elevata priorità debba leggere o

modificare i dati del kernel a cui accede un diverso processo che ha

priorità inferiore

– Se, come spesso accade, i dati del kernel sono protetti da un semaforo,

il processo a priorità più elevata di trova a dover attendere che i dati

siano rilasciati da un processo di priorità inferiore

• Quello che può accadere è che un processo con priorità intermedia

divenga attivo quando il processo a elevata priorità attende che

quello a bassa priorità rilasci il semaforo

– Tale processo potrebbe prelazionare quello a bassa priorità, ritardando

ulteriormente l'accesso alla risorsa da parte del processo a priorità più

elevata

Sistemi Embedded 2010/2011 56

Scheduling per il real-time

• Tempi di risposta

– Per ovviare a tale eventualità, si può ricorrere a un protocollo di

ereditarietà delle priorità

• Secondo tale approccio, i processi che posseggono risorse richieste

da un processo a priorità più elevata, ereditano temporaneamente

tale elevata priorità finché detengono la risorsa, in modo da evitare

l'inserimento di altri processi nella catena di attesa, dopodiché

ritornano alla priorità di partenza

– Tale meccanismo genera run-time overhead, in quanto lo scheduler

deve controllare le priorità di tutti i task che posseggono le risorse

richieste dal task RT

Sistemi Embedded 2010/2011 57

Scheduling per il real-time

• Tempi di risposta

– Una soluzione alternativa è chiamata priority ceiling

• La priorità viene assegnata direttamente alla risorsa ed è pari alla

massima priorità tra i task che possono accedere ai tale risorsa

• Ogni task che accede alla risorsa assume provvisoriamente la

priorità della risorsa stessa

– Spesso chiamata priorità istantanea

• Priority ceiling genera solo compile-time overhead

Sistemi Embedded 2010/2011 58

Scheduling per il real-time

Classi di algoritmi

Sistemi Embedded 2010/2011 59

Scheduling per il real-time

• Classi di algoritmi

– Statici basati su tabelle

• Tali algoritmi effettuano un'analisi statica delle possibili deadline di

allocazione dei processi alla CPU

– Il risultato è uno scadenzario che definisce il momento in cui lanciare un

processo

– Statici con pre-rilascio e priorità

• In questo caso non viene compilato uno scadenzario, ma i risultati

dell'analisi sono usati per scegliere le priorità da assegnare ai task

nell'ambito di un comune scheduler con pre-rilascio basato su priorità

– Dinamici basati su pianificazione

• La realizzabilità di uno scheduling è determinata a tempo di esecuzione

– Un processo in arrivo nel sistema viene accettato per l'esecuzione solo se è

possibile soddisfare i suoi vincoli temporali (e quelli dei rimanenti)

» Uno dei risultati è un piano da usare per decidere quando allocare tale processo

– Dinamici best effort

• E’ una soluzione che non prevede alcuna analisi di fattibilità

– Il sistema cerca di rispettare tutte le deadline e rimuove ogni processo in

esecuzione che non riesce a rispettare le scadenze

Sistemi Embedded 2010/2011 60

Scheduling per il real-time

• Lo scheduling best-effort, nonostante sia quello meno

promettente, è invece uno degli approcci più utilizzati in

molti sistemi in commercio

– Quando arriva un task, il sistema gli assegna una priorità legata

alle sue caratteristiche

• Tipicamente legata alle deadline

– E’ frequente poi che i task considerati siano aperiodici,

caratteristica che rende difficile ogni analisi di tipo statico

• Non si ha la certezza di rispettare le deadline di terminazione di un

task finché effettivamente non si verificano tali eventi

– Per tale motivo è pratica comune sovradimensionare la disponibilità di

risorse per aumentare le chance di rispettare i vincoli temporali

– L'unico vantaggio di tale approccio è la sua semplicità implementativa,

che in ambito commerciale è una caratteristica per nulla trascurabile

Sistemi Embedded 2010/2011 61

Scheduling per il real-time

RMS e EDF

Sistemi Embedded 2010/2011 62

Scheduling per il real-time

• Rate Monotonic Scheduling

– L'algoritmo di scheduling RMS pianifica l'esecuzione di task

periodici assegnando opportunamente delle priorità di

esecuzione

• I parametri caratteristici di ogni task periodico sono il tempo di

esecuzione C richiesto a ogni periodo T e la deadline periodica che

possiamo considerare coincidente con il periodo di esecuzione

stesso

– A ogni occorrenza del task deve essere garantita la disponibilità di un

tempo di CPU pari a C (Carico= C/T)

• Ovviamente non è possibile per un sistema soddisfare un insieme di

n task per cui la somma delle richieste di potenza di calcolo sia

superiore al 100% della CPU

– Nell'ipotesi di non poter aumentare la potenza di calcolo o il numero di

processori, condizione necessaria ma non sufficiente

Sistemi Embedded 2010/2011 63

Scheduling per il real-time

• Rate Monotonic Scheduling

– L'algoritmo RMS assegna delle priorità statiche ai processi sulla

base del loro periodo, dando la priorità più elevata a quelli che

hanno periodo più breve

• Fra i task nello stato pronto viene pertanto servito quello con priorità

maggiore

– Se si grafica la priorità dei processi in funzione della loro frequenza si

ottiene una funzione monotona crescente

– Per garantire che i vincoli temporali di ogni task siano rispettati,

ma sempre sotto le ipotesi sui task, condizione necessaria e

sufficiente è

Sistemi Embedded 2010/2011 64

Scheduling per il real-time

• Earliest Deadline First

– Lo scheduling EDF, pur avendo molte varianti, attribuisce le

priorità dinamicamente, sulla base delle deadline

• La priorità alta è assegnata al task con la deadline più ravvicinata

– Ogni processo pronto deve notificare al sistema la propria deadline,

che provvederà a modificare le priorità vigenti per tenerne conto

» No periodicità dei processi e no allocazione costante di CPU

– A livello teorico l'algoritmo EDF sembra il migliore per rispettare

le deadline raggiungendo elevati sfruttamenti della CPU

• Vale comunque la relazione precedente nel caso di task periodici

– Nella pratica si osservano significativi overhead

Sistemi Embedded 2010/2011 65

Scheduling per il real-time

• RMS vs EDF

– Normalmente è più facile realizzare un sistema stabile

ricorrendo a RMS rispetto ad altre soluzioni

• Nelle condizioni più critiche, a causa per esempio di errori o picchi

improvvisi di richiesta di CPU, le deadline dei task più critici devono

essere comunque garantite

– L’importante è attribuire ai task critici priorità sufficientemente elevate

– Diversamente, con uno scheduling EDF, dove le priorità dei task

cambiano da un periodo all'altro, è sicuramente più oneroso

garantire che i task critici rispettino le loro deadline

– Indipendentemente dalle scelte di scheduling, un problema

cruciale è la determinazione e l'accuratezza nel modellare le

capacità di calcolo necessarie per l'esecuzione dei task, che

mutano per semplici variazioni dell'applicazione e con

l'architettura di calcolo

Sistemi Embedded 2010/2011 66

Real Time Operating Systems

Sistemi Embedded 2010/2011 67

RTOS

• In questa sezione viene riportata una breve rassegna di

come le esigenze di real-time siano state affrontate in

sistemi commerciali per applicazioni di fascia alta ed

embedded

– Il sistemi operativi, soprattutto i RTOS, sono solo un elemento di

un più complesso sistema real-time

• I loro obiettivi sono quelli di fornire un ambiente comodo per riuscire

a sviluppare efficacemente l'applicazione, gestendo al meglio le

risorse, ma soprattutto rispettando i vincoli temporali imposti

• L'obiettivo principale è gestire gli eventi critici in modo

rapido ed efficiente

Sistemi Embedded 2010/2011 68

RTOS

• I sistemi operativi per applicazioni real-time e in generale

embedded enfatizzano i seguenti aspetti principali,

rispetto a quanto già presente nei convenzionali sistemi

operativi

– Determinismo

– Risposta

– Controllo utente

– Affidabilità e operatività fail-soft

Sistemi Embedded 2010/2011 69

RTOS

• Il determinismo e la prontezza nella risposta danno la

misura di quanto il sistema sia in grado di far fronte ai

tempi imposti dagli eventi esterni

– Altre caratteristiche, non meno importanti, vengono considerate

solo dopo avere la certezza che il sistema operativo scelto e

l'hardware su cui viene eseguito sono in grado perlomeno di

rispondere rispettando i vincoli real-time

• In generale i sistemi operativi moderni per applicazioni

real-time pongono sempre maggiore attenzione

all'ottenere rapidi cambi di contesto fra thread o processi

e al tempo di risposta alle interruzioni esterne

Sistemi Embedded 2010/2011 70

RTOS

• Lo scheduling è di norma fortemente semplificato (FIFO)

ed è comune la preemption e l'uso delle priorità

– Gli intervalli in cui le interruzioni sono disabilitate vengono

minimizzati

• Sono previste primitive per la gestione di allarmi speciali

e timeout da utilizzare per la gestione di azioni

temporizzate

– Esistono primitive per ritardare task, metterli in pausa e far

ripartire l'esecuzione sotto il controllo dell'utente

• La granularità nella gestione del tempo è molto più fine e accurata

rispetto a un sistema operativo tradizionale

Sistemi Embedded 2010/2011 71

RTOS

• Queste caratteristiche devono comunque essere legate

a piccole dimensioni del codice (footprint)

– Per tale motivo viene dato ampio spazio alla configurabilità del

sistema, in modo da potere caricare solo alcune parti del SO

• Spesso non è disponibile neppure il gestore della memoria virtuale o

un gestore della memoria di massa associato a un file system

Sistemi Embedded 2010/2011 72

RTOS

• Sistemi operativi considerati

– UNIX/Linux

– Windows

– VxWorks

– Windows CE

– Free software

Sistemi Embedded 2010/2011 73

RTOS

UNIX/Linux

Sistemi Embedded 2010/2011 74

RTOS

UNIX/Linux

• Esaminiamo un approccio all'introduzione del real-time in

UNIX che riguarda l'estesione di soluzioni esistenti a

livello di scheduler

• Lo standard POSIX.1b per i sistemi UNIX-like ha

introdotto alcune estensioni ai meccanismi di scheduling

per la programmazione (soft) real-time dei thread

– La gestione tradizionale dei processi nei sistemi UNIX avviene

mediante un insieme di code a priorità variabile, ove ogni coda è

gestita con politica round-robin

• Esistono inoltre alcune classi di code, legate ai processi kernel, che

hanno priorità superiore a quelle utente

Sistemi Embedded 2010/2011 75

RTOS

UNIX/Linux

• Oltre a tali politiche tradizionali di gestione della CPU,

sono state aggiunte altre due classi di scheduling

– SCHED_FIFO, SCHED_RR

– SCHED_OTHER

• I thread appartenenti alla classe SCHED_OTHER sono

eseguiti usando le tradizionali politiche di scheduling

UNIX, solo se non vi sono altri thread delle due classi

real-time pronti per l'esecuzione

– Le modifiche così introdotte sono abbastanza semplici e

consentono di definire comportamenti concorrenti con buone

caratteristiche di predicibilità

• Non è richiesta alcuna modifica allo scheduler UNIX esistente

Sistemi Embedded 2010/2011 76

RTOS

Windows

Sistemi Embedded 2010/2011 77

RTOS

Windows

• A partire da NT fino alla versione XP, le strategie di

scheduling di Windows e in particolare le priorità, sono

state riorganizzate in modo da migliorare le

caratteristiche di risposta in ambiente sia interattivo sia

per applicazioni di tipo server

– Scheduler è con preemption e basato su 32 priorità

• Sono identificate due classi di priorità, ciascuna

contenente 16 livelli diversi

Sistemi Embedded 2010/2011 78

RTOS

Windows

• Ogni classe è gestita in modo differente

– I livelli da 31 a 16 sono quelli legati alle applicazioni in tempo

reale, dove tutti i thread hanno priorità fissate e ogni livello è

gestito con politica round-robin

– Le classi rimanenti di livello più basso (da 15 a 0) sono a priorità

variabile

• I thread iniziano a partire da un livello assegnato che però può

cambiare durante la vita del processo, a seconda della durata e

dell'utilizzo delle risorse del thread

Sistemi Embedded 2010/2011 79

RTOS

Windows

• I motivi per cui le priorità variano sono molteplici

– Essa diminuisce se il thread viene interrotto dalla scadenza del

quanto di tempo, oppure aumenta se viene sospeso in attesa di

un evento I/O

– Inoltre, per evitare che alcuni thread attendano indefinitamente

prima di accedere alla CPU, lo scheduler esamina la lista dei

thread e aumenta la priorità di quelli che sono in attesa da più

tempo

• Questa scelta risolve anche il problema dell'inversione delle priorità

Sistemi Embedded 2010/2011 80

RTOS

VxWorks

Sistemi Embedded 2010/2011 81

RTOS

VxWorks

• VxWorks, prodotto da Wind River, è forse il più famoso

sistema operativo per applicazioni real-time

– Viene usato in prodotti per ambito automotive e di controllo

industriale, ma la notorietà è forse dovuta al suo utilizzo da parte

della NASA nelle sonde spaziali

• La struttura del sistema è basata su microkernel

– Tale scelta è legata a motivi di efficienza e flessibilità

• Il microkernel offre le funzionalità strettamente necessarie,

soprattutto alla gestione dei processi, mentre le funzionalità

accessorie sono rese disponibili da librerie esterne

– Kernel molto compatto, utilizzabile anche in sistemi con limitate risorse

di calcolo e memoria

Sistemi Embedded 2010/2011 82

RTOS

VxWorks

• Architettura di VxWorks

Sistemi Embedded 2010/2011 83

RTOS

VxWorks

• Il numero di architetture di calcolo supportate è

vastissimo

– Per tale motivo lo sviluppo del codice del sistema operativo

prevede una parte indipendente dall'architettura hardware e la

presenza di moduli software di specializzazione, il cosiddetto

BSP, fornito normalmente dal produttore della board

• In questo modo lo sviluppo del sistema operativo è in buona parte

indipendente dalla specifica piattaforma su cui dovrà funzionare, e

le operazioni di porting sono affrontabili in tempi brevi

Sistemi Embedded 2010/2011 84

RTOS

VxWorks

• Nel gergo di VxWorks non esiste una distinzione fra

processi e thread, vengono entrambi considerati unità di

esecuzione chiamate task

– Per ogni task viene creato un contesto che comprende

• I registri della CPU

• Lo stack per le variabili dinamiche e le chiamate di funzione

• Le convenzioni per lo standard input, output e gli errori

• Un timer per i ritardi e uno per i time slice

• Un gestore per i segnali

Sistemi Embedded 2010/2011 85

RTOS

VxWorks

• Il normale approccio allo scheduling di VxWorks è

basato sulle priorità con diritto di preemption

– Configurabile per funzionare anche con politica round-robin

– Sono disponibili 256 livelli di priorità, compresi quelli più elevati

(valori più bassi) legati alle applicazioni real-time

• I task con le priorità più elevate vengono eseguiti per primi e, nel

caso di task con la stessa priorità, l'esecuzione è in round-robin

• I task con priorità più bassa possono essere interrotti da quelli di

priorità più elevata

Sistemi Embedded 2010/2011 86

RTOS

VxWorks

• Il microkernel di VxWorks è concepito per gestire

efficientemente le interruzioni

– L'obiettivo è limitare le latenze relative alla interruzione e al

dispatch, per rispettare eventuali vincoli hard real-time

• VxWorks mette a disposizione delle routine per agganciare

direttamente il codice (scritto in C) alle routine di risposta a

interruzione, senza la necessità pertanto di ricorrere alla

programmazione in assembler

– Tali routine consentono di connettere il codice C ai vettori d'interruzione

e di gestire i livelli d'interruzione dei processori

» Per minimizzare il tempo di risposta, le ISR sono eseguite all'esterno del

contesto di esecuzione dei task (e tutte usano lo stesso stack), in modo da

evitare i ritardi della commutazione di contesto

Sistemi Embedded 2010/2011 87

RTOS

VxWorks

• La comunicazione fra i processi può sfruttare una serie

completa di meccanismi predefiniti

– Strutture dati condivise

– Semafori

– Code di messaggi

– Pipe

– Segnali

Sistemi Embedded 2010/2011 88

RTOS

VxWorks

• La condivisione della memoria consente quindi di usare

anche strutture dati complesse

– Per la protezione dei dati condivisi si possono usare i semafori,

che in VxWorks prevedono un meccanismo di ereditarietà delle

priorità per evitare il fenomeno dell'inversione delle priorità

• Oltre allo scambio di messaggi fra task, esiste la

possibilità di usare le pipe

– Tale meccanismo, in genere più rapido e con minore overhead

rispetto a un messaggio, ha una semantica analoga a una coda

FIFO di tipo bloccante, dove la condivisione avviene tramite

l'accesso a un file speciale detto appunto pipe

Sistemi Embedded 2010/2011 89

RTOS

VxWorks

• La gestione della memoria viene affrontata in modo

approfondito da parte di VxWorks

– Per esempio esiste la possibilità di gestire l'allocazione e il

rilascio di blocchi di memoria di dimensione arbitraria

appartenenti a memory pool, ma il supporto alla memoria

virtuale è forse l'aspetto di maggior rilievo

• Esistono due livelli di memoria virtuale

– Il livello base consente il controllo della cache, ovvero le applicazioni

possono imporre che alcune pagine non risiedano in cache

– Il secondo livello richiede il caricamento del componente VxVMI che

fornisce la protezione di segmenti destinati al codice, la gestione

esplicita delle eccezioni e una interfaccia verso una eventuale MMU

Sistemi Embedded 2010/2011 90

RTOS

VxWorks

• Per la messa a punto del sistema, Wind River fornisce

una serie di strumenti di sviluppo e analisi

– Sono molte le informazioni di carattere statistico che possono

essere memorizzate e analizzate con i tool di sviluppo e di

ottimizzazione disponibili

• E’ possibile per esempio impostare dei timer per ottenere statistiche

di esecuzione su gruppi o su una singola subroutine

• Vi sono inoltre utility per monitorare l'utilizzo della CPU, arrivando a

sapere per ogni task quanto tempo di CPU è stato impiegato, la

frazione spesa per le interruzioni e il tempo d'inattività della CPU

Sistemi Embedded 2010/2011 91

RTOS

Windows CE

Sistemi Embedded 2010/2011 92

RTOS

Windows CE

• Microsoft WindowsCE è un sistema operativo real-time a

32 bit progettato per incontrare le esigenze dei cosiddetti

intelligent hardware device, caratterizzati da risposta

deterministica agli interrupt

– Il sistema operativo CE è programmabile con API

sostanzialmente identiche alle Win32 API di Windows per PC,

scelta che dovrebbe facilitare la migrazione da Windows a

Windows CE delle applicazioni

• Il sistema è disponibile almeno per quattro differenti architetture di

processore: x86, ARM, MIPS, SHx

– Inoltre sono incluse molte funzionalità di rete come TCP/IP (anche lo

standard IPv6), WinSock2, WinInet e servizi LDAP, DCOM, SOAP,

UPnP, NAT, IPv6 routing, DNS Proxy, firewall, DHCP e così via

Sistemi Embedded 2010/2011 93

RTOS

Windows CE

• La principale caratteristica del kernel è il supporto a real-

time preemptive multitasking, o più precisamente

multithreading

– Infatti, l'unità base di scheduling in Windows è il thread, non

l'intero processo, implementato nello spazio kernel

• Relativamente al supporto real-time sono da segnalare

– ISR installabili in modo flessibile, multimedia timers, API per il

DMA e opportuni agganci all'interno del kernel per il profiling e il

debugging delle applicazioni

• WinCE usa uno scheduler basato su quanti di tempo e priorità, dove

la priorità è rappresentata da un valore intero di un byte

Sistemi Embedded 2010/2011 94

RTOS

Windows CE

• Livelli di priorità dello scheduler

Sistemi Embedded 2010/2011 95


PAGINE

106

PESO

283.22 KB

AUTORE

Atreyu

PUBBLICATO

+1 anno fa


DESCRIZIONE DISPENSA

Vengono trattati i seguenti argomenti. Sistemi operativi: caratteristiche generali; sincronizzazione e comunicazione. Gestione del processore. Esigenze dei sistemi real-time. Scheduling per il real-time: tempi di risposta; RMS e EDF;
RTOS: Real Time Operating Systems; UNIX/Linux; Windows; VxWorks; Windows CE; Free software.


DETTAGLI
Corso di laurea: Corso di laurea magistrale in ingegneria delle telecomunicazioni
SSD:
Università: L'Aquila - Univaq
A.A.: 2011-2012

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher Atreyu di informazioni apprese con la frequenza delle lezioni di Sistemi embedded e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università L'Aquila - Univaq o del prof Pomante Luigi.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Sistemi embedded

Programmazione concorrente
Dispensa
Sistemi Embedded
Dispensa
SystemC
Dispensa
Real-time and embedded operating systems
Dispensa