Intendo come e perché i sistemi operativi in tempo reale sono in grado di rispettare le scadenze senza mai mancarle? O è solo un mito (che non mancano le scadenze)? In che modo sono diversi da qualsiasi SO normale e cosa impedisce a un normale SO di essere un RTOS?Come funzionano i sistemi operativi in tempo reale?
Le scadenze di riunione sono una funzione dell'applicazione che si scrive. RTOS fornisce semplicemente servizi che ti aiutano a rispettare le scadenze. Puoi anche programmare su "bare metal" (senza RTOS) in un grande ciclo principale e rispettare le scadenze.
Inoltre, a differenza di un sistema operativo più generale, un RTOS ha un insieme molto limitato di attività e processi in esecuzione.
Alcuni dei servizi di un RTOS fornire:
basata sulla priorità Scheduler
La maggior parte degli RTOS ha tra 32 e 256 possibili priorità per singole attività/processi. Lo scheduler eseguirà l'attività con la massima priorità. Quando un'attività in esecuzione dà la CPU, il prossimo più alto compito prioritario corre, e così via ...
Il compito massima priorità nel sistema avrà la CPU fino a quando:
Come sviluppatore, è compito tuo assegnare le priorità del compito in modo tale che le scadenze vengano rispettate.
System Clock routine di interrupt
L'RTOS in genere fornire una sorta di clock di sistema (ovunque da 500 US a 100ms), che consente di eseguire le operazioni time-sensitive. Se si dispone di un orologio di sistema 1ms e si ha bisogno di eseguire un'attività ogni 50 ms, di solito c'è un'API che consente di pronunciare "In 50 ms, svegliarmi". A quel punto, il compito sarebbe dormire fino a quando l'RTOS non lo riattiva.
Si noti che il solo fatto di essere svegliati non assicura che verrà eseguito esattamente in quel momento. Dipende dalla priorità. Se un'attività con una priorità più alta è attualmente in esecuzione, è possibile che si verifichi un ritardo.
deterministico Comportamento
L'RTOS va a grande lunghezza per garantire che se si dispone di 10 attività, o 100 attività, non prendere più per cambiare contesto, determinare ciò che il prossimo più alto compito prioritario è, ecc ...
In generale, l'operazione RTOS tenta di essere O (1).
Una delle aree principali per il comportamento deterministico in un RTOS è la gestione degli interrupt. Quando viene segnalata una linea di interrupt, RTOS passa immediatamente alla routine di servizio di interrupt corretta e gestisce l'interrupt senza ritardi (indipendentemente dalla priorità di qualsiasi attività attualmente in esecuzione).
Si noti che la maggior parte degli ISR specifici dell'hardware verranno scritti dagli sviluppatori sul progetto. RTOS potrebbe già fornire ISR per le porte seriali, l'orologio di sistema, forse l'hardware di rete, ma tutto ciò che è specializzato (segnali di pacemaker, attuatori, ecc.) Non farebbe parte di RTOS.
Questa è una generalizzazione grossolana e, come per tutto il resto, esiste una grande varietà di implementazioni RTOS. Alcuni RTOS fanno le cose in modo diverso, ma la descrizione di cui sopra dovrebbe essere applicabile a una grande porzione di RTOS esistenti.
"Questa attività verrà eseguita fino al completamento" suona come Windows 3.1! Quindi vuoi dire che gli RTOS non sono preventivi? –
No, se si è la priorità più alta che si esegue fino a quando non si arrende volontariamente, OPPURE un compito con priorità più alta di quello che si è pronti, in quel momento la priorità alta (vecchia) viene annullata. Chiarirò nel testo principale. Grazie! – Benoit
Non è che siano in grado di rispettare le scadenze, è piuttosto che hanno scadenze fisse mentre in un normale sistema operativo non esiste una tale scadenza.
In un normale sistema operativo, l'utilità di pianificazione non è molto rigida. Questo è il processore che eseguirà così tante istruzioni al secondo, ma a volte potrebbe non farlo. Ad esempio, un'attività può essere anticipata per consentire l'esecuzione di una priorità più alta (e potrebbe essere per un tempo più lungo). In RTOS il processore eseguirà sempre lo stesso numero di attività.
Inoltre, in genere è previsto un limite di tempo per le attività da completare dopo il quale viene segnalato un errore. Questo non succede nel normale sistema operativo.
Ovviamente ci sono molti più dettagli da spiegare, ma quanto sopra sono due degli aspetti importanti del design che sono usati in RTOS.
In pratica, è necessario codificare ciascun "task" in RTOS in modo che terminino in un tempo limitato.
Inoltre, il kernel assegnerà una quantità specifica di tempo a ciascuna attività, nel tentativo di garantire che determinate cose siano avvenute in determinati momenti.
Si noti che questo non è un compito facile da fare comunque. Immagina cose come le chiamate alle funzioni virtuali, in OO è molto difficile determinare queste cose. Anche un RTOS deve essere accuratamente codificato in relazione alla priorità, potrebbe richiedere che alla CPU venga assegnato un task ad alta priorità entro x millisecondi, operazione che potrebbe essere difficile a seconda del modo in cui funziona lo scheduler.
"Fondamentalmente, devi codificare ogni" attività "in RTOS in modo che possano terminare in un tempo limitato" - quindi è l'applicazione che dovrebbe essere chiamata in tempo reale e non il sistema operativo. –
Cosa succede quando un'attività finisce fuori tempo? –
l'attività viene preventivamente forzata e riavviata nella successiva sezione temporale. Un buon RTOS solleva un errore o informa che ciò si è verificato. – Spence
Ciò che è importante sono le applicazioni in tempo reale, non il sistema operativo in tempo reale. Solitamente le applicazioni realtime sono prevedibili: sono stati eseguiti molti test, ispezioni, analisi WCET, prove, ... che mostrano che le scadenze sono rispettate in qualsiasi situazione specificata.
Accade che RTOS aiuti a fare questo lavoro (costruendo l'applicazione e verificando i suoi vincoli RT). Ma ho visto applicazioni in tempo reale in esecuzione su Linux standard, basandosi più sulla potenza dell'hardware che sulla progettazione del sistema operativo.
Un RTOS fa delle garanzie molto severe su cose importanti, come i tempi di manutenzione degli interrupt, la latenza di commutazione delle attività, ecc. Le applicazioni in tempo reale NON sono possibili senza un corretto RTOS. –
Sto solo parlando di quello che ho visto. E più spesso, i problemi in tempo reale sono risolti da enormi frequenze della CPU e un notevole margine di tempo. – mouviciel
Non ho utilizzato un RTOS, ma penso che questo sia il modo in cui funzionano.
C'è una differenza tra "hard real time" e "soft real time". È possibile scrivere applicazioni in tempo reale su un non-RTOS come Windows, ma sono 'soft' in tempo reale:
Come applicazione, potrei avere un filo o un timer, che chiedo l'O/S per correre 10 volte al secondo ... e forse l'O/S lo farà, il più delle volte, ma non c'è garanzia che sarà sempre in grado di ... questa mancanza di garanzia è il motivo per cui si chiama "soft" . Il motivo per cui l'O/S potrebbe non essere in grado è che un thread diverso potrebbe mantenere il sistema occupato a fare qualcos'altro. Come applicazione, posso aumentare la priorità del mio thread ad esempio HIGH_PRIORITY_CLASS, ma anche se faccio questo O/S non ha ancora API che posso usare per richiedere una garanzia che verrà eseguito in determinati orari.
Un O/S in tempo reale 'difficile' (immagino) ha API che mi consentono di richiedere fette di esecuzione garantite. Il motivo per cui RTOS è in grado di fornire tali garanzie è la volontà di interrompere i thread che richiedono più tempo del previsto/di quanto consentito.
Non è solo la pianificazione: il sistema operativo deve assicurarsi che non avvengano cose casuali come la raccolta dei rifiuti o la deframmentazione dello spazio degli indirizzi di memoria, in modo da sapere che malloc() tornerà sempre senza ritardo, quindi (per esempio) l'aeroplano il pilota automatico sta controllando non si bloccherà. –
E presumibilmente anche interruzioni hardware. – ChrisW
vostro RTOS è stato progettato in modo tale che essa può garantire tempi per eventi importanti, come la gestione interrupt hardware e svegliare i processi che dormono esattamente quando hanno bisogno di essere.
Questo momento esatto permette al programmatore di essere sicuro che la sua (diciamo) pacemaker sta per emettere un impulso esattamente quando è necessario, non pochi decine di millisecondi più tardi, perché il sistema operativo era occupato con un'altra operazione inefficiente.
Di solito è un sistema operativo molto più semplice di un vero e proprio Linux o Windows, semplicemente perché è più semplice analizzare e prevedere il comportamento del codice semplice. Non c'è nulla che fermi un sistema operativo completo come Linux che viene utilizzato in un ambiente RTOS e ha estensioni RTOS. A causa della complessità della base di codice, non sarà in grado di garantire i tempi fino a una scala più piccola di un OS più piccolo.
Lo scheduler RTOS è anche più rigido di un programma di pianificazione generale. È importante sapere che lo scheduler non cambierà la priorità delle attività perché è in esecuzione da molto tempo e non ha utenti interattivi. La maggior parte del sistema operativo ridurrebbe la priorità interna di questo tipo di processo per favorire programmi interattivi a breve termine in cui l'interfaccia non dovrebbe essere vista in ritardo.
Potrebbe essere utile leggere l'origine di un tipico RTOS. Ci sono diversi esempi open-source là fuori, e le seguenti collegamenti fruttati in un po 'di ricerca rapida:
A RTOS commerciali che è ben documentato, disponibile in modulo di codice sorgente e facile da usare è µC/OS-II. Ha una licenza molto permissiva per uso educativo e (una versione leggermente datata di) la sua fonte può essere associata a un libro che descrive la sua teoria dell'operazione usando l'implementazione reale come codice di esempio. Il libro è MicroC OS II: The Real Time Kernel di Jean Labrosse.
Ho usato μC/OS-II in diversi progetti nel corso degli anni e posso consigliarlo.
... beh ...
Un sistema operativo real-time cerca di essere deterministica e rispettare le scadenze, ma tutto dipende dal modo in cui si scrive l'applicazione. Puoi fare un RTOS in tempo reale se non sai come scrivere codice "corretto".
Anche se si sa come scrivere il codice corretto: È più che altro cercare di essere deterministici che essere veloci.
Quando parliamo determinismo è
1) evento determinismo
Per ciascuna serie di ingressi successivi stati e le uscite di un sistema sono noti
2) determinismo temporale
... è noto anche il tempo di risposta per ogni serie di uscite
Ciò significa che se si verificano eventi asincroni come i nterrupts il tuo sistema è strettamente parlando non più deterministico temporale. (e la maggior parte dei sistemi usa gli interrupt)
Se vuoi davvero essere un sondaggio deterministico tutto.
... ma forse non è necessario essere al 100% deterministico
"Se vuoi davvero essere un sondaggio deterministico, tutto". - Cosa succede se si perde un evento di priorità più alta tra i cicli di sondaggio? Questo non renderà la risposta del sistema operativo non in tempo reale per quegli eventi? –
Ovviamente lo farà, ma hai fatto la tua analisi e assicurato che tutti gli eventi al di fuori del sistema operativo rientrino in determinati limiti temporali (qualcosa come un server sporadico per i tuoi input). In una condizione di errore (cavo rotto) dovresti comunque buttare via gli eventi. Ciò che si assicura tramite il polling e l'assenza di interrupt è che il fatto che si usi l'interrupt non è più un determinismo degradante. –
Stai cercando di dire che questo è effettivamente un compromesso tra latenza e determinismo? IMO il modello "eventi con limiti ben definiti" ha esito negativo quando si dispone di una gerarchia di eventi (ad esempio eventi prioritari). Non vi è alcun motivo per cui un evento totalmente non correlato debba rispettare i limiti temporali di un evento/attività a bassa priorità (LP). L'attività LP deve essere preceduta anche se l'evento HP si verifica in t0 + dt. Dove dt è un periodo infinitamente piccolo di tempo e t0 è il momento in cui è iniziato il task LP. –
La risposta libro di testo/intervista è "deterministico prelazione". Il sistema è in grado di trasferire il controllo entro un periodo di tempo limitato se un processo con priorità più alta è pronto per essere eseguito (nella coda di pronto) o viene richiesto un interrupt (generalmente input esterno alla CPU/MCU).
In realtà non garantiscono il rispetto delle scadenze; ciò che fanno che li rende veramente RTOS è quello di fornire i mezzi per riconoscere e affrontare i superamenti delle scadenze. I sistemi RT "rigidi" generalmente sono quelli in cui la mancanza di una scadenza è disastrosa e si richiede un qualche tipo di arresto, mentre un sistema RT "soft" è quello in cui è opportuno continuare con funzionalità degradate. In entrambi i casi, un RTOS consente di definire le risposte a tali superamenti. I sistemi operativi non RT non rilevano nemmeno i sovraccarichi.
"In pratica, è necessario codificare ciascun" task "in RTOS in modo che terminino in un tempo limitato."
Questo è effettivamente corretto. RTOS avrà un tick di sistema definito dall'architettura, ad esempio 10 millisec., Con tutte le attività (thread) progettate e misurate per essere completate entro determinati orari. Ad esempio, nell'elaborazione di dati audio in tempo reale, in cui la frequenza di campionamento audio è di 48 kHz, esiste una quantità nota di tempo (in millisecondi) in cui il prebuffer diventa vuoto per qualsiasi attività a valle che elabora i dati. Pertanto, l'utilizzo di RTOS richiede il dimensionamento corretto dei buffer, la stima e la misurazione del tempo necessario e la misurazione delle latenze tra tutti i livelli software del sistema. Quindi le scadenze possono essere soddisfatte. Altrimenti le applicazioni mancheranno le scadenze. Ciò richiede l'analisi dell'elaborazione dei dati nel caso peggiore nell'intero stack e una volta che il caso peggiore è noto, il sistema può essere progettato per, diciamo, il tempo di elaborazione del 95% con il 5% di tempo di inattività (questa elaborazione potrebbe non verificarsi mai in qualsiasi utilizzo reale, poiché l'elaborazione dei dati nel caso peggiore potrebbe non essere uno stato consentito all'interno di tutti i livelli in qualsiasi momento).
esempio diagrammi di temporizzazione per la progettazione di un tempo di vera e propria rete di sistema operativo app sono in questo articolo a EE Times, MERCE HOW-TO: Migliorare la qualità della voce in tempo reale in un design telefonia VoIP basati http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design
In RTOS i parametri più importanti che dovrebbero essere presi in considerazione sono le latenze più basse e il determinismo del tempo. Che fa piacevolmente seguendo determinate politiche e trucchi.
Mentre in GPOS, insieme alle latenze accettabili, i parametri critici sono il throughput elevato. non puoi contare su GPOS per il determinismo temporale.
RTOSes hanno attività molto più leggere di processi/thread in GPOS.
È anche importante notare la differenza tra un sistema "in tempo reale" morbido e un sistema "reale" in tempo reale. – Thomas