Quando è necessario un sistema operativo in Embedded System Design?

Ho scritto un sacco di codice bare metal per i processori PIC e x86. Qualcuno può dirmi come e quando dovrei avere bisogno di un sistema operativo? Al contrario, quale applicazione o situazione può essere gestita anche senza un sistema operativo?

La mia regola empirica è che dovresti considerare un sistema operativo se il prodotto richiede uno o più dei seguenti: uno stack TCP / IP (o altro stack di rete complesso), una GUI complessa (forse una con oggetti GUI come windows ed eventi ) o un file system.

Se hai fatto un po 'di codifica bare metal, probabilmente hai familiarità con l' architettura del programma super-loop . Se i requisiti del firmware del prodotto sono abbastanza semplici da essere implementati con un super-loop che è mantenibile (e si spera in qualche modo estendibile), probabilmente non è necessario un sistema operativo.

Con l'aumentare dei requisiti software, il super-loop diventa più complesso. Quando i requisiti software sono così tanti che il super-loop diventa troppo complesso o non può soddisfare i requisiti in tempo reale del sistema, allora è tempo di considerare un'altra architettura.

Un'architettura RTOS consente di dividere i requisiti software in attività. Se fatto correttamente, questo semplifica l'implementazione di ogni attività. E con la definizione delle priorità delle attività un RTOS può semplificare il rispetto dei requisiti in tempo reale. Un RTOS non è tuttavia una panacea. Un RTOS aumenta la complessità complessiva del sistema e ti apre a nuovi tipi di bug (come i deadlock). In alternativa a RTOS potresti prendere in considerazione un'architettura di macchina a stati basata su eventi (come QP ).

Se il tuo prodotto ha una rete, una GUI complessa e un file system, potresti essere nel punto in cui dovresti considerare i sistemi operativi con funzionalità complete come VxWorks, Windows o Linux. I sistemi operativi completi includeranno i driver per i dettagli di basso livello e ti permetteranno di concentrarti sulla tua applicazione.

Dipende molto dalla tua definizione di "sistema incorporato". Alcuni potrebbero affermare che se non si tratta di una programmazione bare metal, non è incorporata (il che preclude la tua domanda), ma non sarei d'accordo con questo - direi che qualsiasi sistema progettato per svolgere solo una funzione, cioè, per eseguire solo una specifica 'applicazione', potrebbe essere chiamato un sistema incorporato.

Detto questo, dovrebbe essere abbastanza facile immaginare situazioni che trarrebbero beneficio dai servizi di un sistema operativo completo. Ad esempio, dove lavoro è abbastanza comune trovare persone che costruiscono apparecchiature di prova su una suite di progettazione di strumentazione che gira su finestre. Questi sistemi sono configurati per l'avvio nella configurazione della stazione di prova e bloccare l'utilizzo generale (per prevenire il danneggiamento della stazione) e sono quindi probabilmente sistemi integrati.

Tuttavia, acquistare semplicemente moduli I / O standard, collegarli a un PC montato su rack e creare una configurazione in una GUI potrebbe non qualificarsi come progetto di sistema incorporato per alcuni. Per una situazione un po 'meno standard, prendere in considerazione un controller di processo personalizzato con un FPGA, per il quale si desidera eseguire una registrazione dei dati di fantasia. È possibile incorporare un sistema di processore soft-core (con un BSP esistente) ed eseguire un linux in tempo reale per eseguire uno stack di rete (per la registrazione e NTP ecc.) E fare tutto il resto in logica.

La mia (molto vaga) regola empirica è se hai bisogno di più di un thread di controllo (diciamo almeno un dispositivo che coinvolge un protocollo o una macchina a stati più qualcos'altro da fare), quindi alcuni software OSish ti semplificheranno la vita

Una vecchia domanda ma commenterò comunque.

Anche se non hai stack di rete o simili, nel momento in cui hai bisogno di un programmatore di attività poiché hai abbastanza processi nella tua applicazione integrata, potresti considerare un RTOS. Scrivere un semplice programmatore di multitasking cooperativo basato su timer non è così difficile, ma assicurarsi che un processo bloccato non blocchi il resto dell'applicazione e che può richiedere del tempo per ottenere il risultato giusto. È necessario implementare un sistema prioritario con un qualche tipo di disposizione per bloccare i processi in coda se non sono stati completati.

RTOS ti offre anche cose come la protezione della memoria e simili che rende molto più facile tenere traccia di alcuni gaffes comuni nel codice C ma i semplici microcontrollori potrebbero non essere in grado di gestire una protezione della memoria complessa. Ad esempio MSP430 consente di separare codice e dati ad alto livello, ma non esiste un controllo dell'accesso alla memoria a grana fine.

Un sistema operativo colma effettivamente il divario tra hardware e software applicativo (tramite il driver del dispositivo). In altre parole, fornisce una piattaforma di livello relativamente alto per il programmatore che alla fine riduce la complessità del codice. Inoltre, il sistema operativo fornisce una piattaforma forte e flessibile per l'esecuzione dell'applicazione.