Cosa fa un ingegnere di sistemi embedded?

Più o meno come gli ingegneri di software desktop, scrivono codice per risolvere problemi e implementare sistemi.

A differenza degli ingegneri di software desktop, hanno spesso bisogno di:

-- Trattare con nuovo hardware/silicio, che può essere difettoso. Ho lavorato su sistemi in cui, a causa di difetti dell'hardware, scrivere un byte in memoria e poi rileggerlo mi dava un valore diverso. Trovi il problema, lo mandi agli ingegneri dell'hardware, e aspetti che loro facciano una correzione.

-- Rollano il loro sistema operativo, o almeno configurano un sistema operativo per conformarsi al design dell'hardware e alla mappa della memoria del tuo sistema. Gli ingegneri di software desktop si aspettano che venga fornito un sistema operativo e non si preoccupano di come quel sistema operativo prende vita, o della mappa di memoria dell'hardware su cui gira. Queste sono spesso cose di cui un ingegnere embedded deve occuparsi, ad un certo livello o ad un altro. Ho avuto a che fare con questo a diversi livelli; una volta ho avuto la grande gioia di progettare e implementare il mio sistema operativo multitask cooperativo per una scheda personalizzata per la quale non esisteva alcun sistema operativo. Altre volte, è stata solo una questione di configurazione di Linux incorporato. In entrambi i casi, avrete bisogno di conoscere il vostro hardware per fare bene il lavoro.

-- Preoccupatevi dei dispositivi. A volte, l'hardware è nuovo o personalizzato per il progetto. Altre volte, è pronto all'uso, ma non esistono driver per il vostro sistema operativo. Sui sistemi desktop, il sistema operativo stesso fornisce il supporto necessario, ma è molto più probabile che abbiate bisogno di rollare il vostro in un sistema embedded, specialmente se l'hardware è nuovo.

-- Affrontare i limiti di memoria/risorse. I sistemi embedded possono avere, e spesso hanno, risorse di memoria e CPU limitate, a causa di vincoli di business, o del packaging/ambiente in cui devono essere distribuiti. La frammentazione della memoria può essere un problema grave. A seconda del design/dispositivo, a volte è necessario utilizzare schemi di allocazione della memoria personalizzati in sostituzione di quelli forniti dal fornitore del compilatore per affrontare questi vincoli.

-- Prestare molta attenzione ai problemi di affidabilità, sicurezza e correttezza. I sistemi embedded usati nel sistema frenante della vostra auto, o nei sistemi avionici del Boeing 777, non possono fallire, perché delle vite dipendono da questo. Questo spesso significa che gli ingegneri embedded passano attraverso livelli di specifiche, test/QA, revisioni del codice, e così via a cui normalmente non si sottopongono gli sviluppatori di applicazioni desktop. I sistemi potrebbero avere componenti ridondanti che indipendentemente calcolano o ottengono risultati o leggono sensori, e usano qualche euristica come il voto per derivare un risultato finale che viene riportato al resto del sistema.

-- Osservare i vincoli del tempo reale. Gli sviluppatori di sistemi embedded spesso hanno vincoli più stretti per quanto riguarda la velocità con cui i sistemi che implementano rispondono agli eventi o impartiscono comandi per attivare i controlli. Spesso, il comportamento corretto, e le vite, possono dipendere dal rispetto di questi vincoli temporali. Mentre la comunicazione tra un client/server su TCP/IP può essere ritentata fino a quando non viene completata con successo con al massimo una latenza osservata da parte dell'utente, le applicazioni embedded in tempo reale fallirebbero in circostanze simili. Le comunicazioni non devono essere perse e le latenze devono essere minime. I comandi per far muovere gli alettoni di un Boeing 777 in risposta al comando del pilota devono essere altamente reattivi all'input dei piloti.

-- Sviluppare una strategia di debug. Nella mia esperienza, lo sviluppo e il debug dei sistemi embedded possono essere una sfida. In alcuni casi, per me, ha significato accendere dei LED o capovolgere dei bit nella RAM video per rilevare che il mio codice ha raggiunto un certo punto di esecuzione. Molte volte la prima cosa che uno sviluppatore farà è far funzionare un driver per la porta seriale, e implementare printf in modo che le istruzioni di registrazione/traccia possano essere emesse dalla porta seriale. Più idealmente (e probabilmente) uno sviluppatore embedded userà JTAG, in-circuit-emulation, Nexus, o altri meccanismi forniti dal design hardware/toolchain per eseguire il debug dei sistemi embedded.