Migrazione verso sistemi embedded

Embedded è un campo LARGE che spazia da pochissime cose a cose che sono in realtà solo una macchina desktop in una scatola divertente.

Ho intenzione di andare con 3 categorie di sistemi embedded, per corrispondere con la mia esperienza, quindi farò alcune raccomandazioni.

I piccoli sistemi embedded sono gestiti da dispositivi di tipo microcontrollore. Non hanno alcun sistema operativo, programmatore, ecc. Ecc. Stai eseguendo codice in esecuzione direttamente sulla CPU e, in generale, avrai il ciclo principale che si avvia all'accensione e non esce mai. Ci sono molte opzioni per i microcontroller, che vanno da cose come il venerabile 8051 al PIC veramente piccolo e molti prodotti basati sui core ARM. Sono carini perché hai un controllo completo e diretto su ogni aspetto del funzionamento del sistema. Ovviamente, ciò significa anche che devi stare attento a cose come il tempismo e la latenza delle operazioni e quanto tempo puoi dedicare a una cosa prima di tornare al tuo ciclo principale.

I sistemi embedded medi sono cose più grandi e che avranno un SO embedded come il pSOS di Wind River (ci sono MOLTE scelte per questo, mi è capitato di aver usato pSOS una volta). Lo chiamo medium perché a questo punto NON si sta eseguendo un singolo ciclo principale e in realtà si dispone di uno scheduler. L'hardware potrebbe non essere molto diverso dalla fascia più alta del gruppo precedente, ma la presenza di un programmatore e di un'architettura di driver più formale migliora davvero la tua capacità di programmatore di fare le cose. Al rovescio della medaglia, potrebbe essere più difficile rispettare tempistiche molto strette perché è possibile introdurre facilmente più ritardi imprevisti dallo scheduler. Inoltre, bisogna fare attenzione che l'hardware funzioni in modo appropriato per il sistema operativo in uso, ad esempio non tutte le strategie di interrupt funzionano con tutti i sistemi operativi incorporati. Alla fine più grande di questo gruppo inserirò Windows CE, l'offerta integrata di Microsoft. Questo segmento si sta estinguendo in una certa misura poiché sempre più risorse di elaborazione stanno diventando disponibili per meno e meno soldi.

I grandi sistemi embedded sono ancora più grandi e gestiscono un sistema operativo che un utente desktop potrebbe riconoscere. Linux è comune qui, così come la versione embedded (o anche la normale!) Di MS Windows. C'è molto di questo in giro in campo medico (guarda un sacco di macchine ad ultrasuoni). Il vantaggio qui è che puoi eseguire un'installazione completa di Linux, con tutte le cose utili che un vero SO porta più su hardware molto piccolo e molto economico.

Ora, essendo la tua prima incursione in embedded, e dato che è medico (dove sospetto tu abbia margini per supportare budget di hardware ragionevoli), ti consiglio di usare qualche piccolo computer come un rasberry pi, un beaglebone o qualcos'altro basato su una moltitudine di core ARM là fuori. Esegui Linux su di esso e costruisci la tua app su questo. In effetti, probabilmente vorrai semplicemente lasciare il tuo dispositivo così com'è, metterlo in una scatola con il piccolo computer e comunicare via USB. Effettivamente, porta semplicemente la tua app esistente su Linux e vai.

Il termine sistema embedded è estremamente ampio e copre praticamente qualsiasi cosa, dal chip che controlla il tuo forno a microonde ai sistemi che forniscono informazioni sul traffico dinamico sul lato della strada. In generale, si dispone di un sistema incorporato se è presente un chip del computer che comunica con hardware appositamente costruito.

Ci sono approssimativamente tipi di rimorchio di sistemi embedded, che chiamerò qui come "piccoli" e "grandi" sistemi.

In un "piccolo" sistema embedded, di solito c'è molto poco disponibile in termini di risorse (RAM / ROM / Flash) e non ha OS di cui parlare. Di solito, tutto il software in esecuzione su tale dispositivo viene compilato in un unico grande eseguibile che include anche il kernel del sistema operativo. Questi kernel forniscono solo la pianificazione e le primitive di sincronizzazione delle attività.

In un "grande" sistema incorporato, si sta scrivendo un software da eseguire sotto il controllo di un normale sistema operativo (spesso Linux, ma non sempre). Come sviluppatore di software, di solito non c'è molta differenza con la scrittura di software per un ambiente desktop, tranne negli strumenti che si usano per compilare / distribuire / debug e che alcuni dei processi più pesanti (come X Windows) potrebbero non essere disponibili.

Se questo è il primo passo dell'azienda nel mondo embedded, consiglierei loro di cercare il più possibile l'hardware di magazzino che si adatta alle loro esigenze nel miglior modo possibile e per il quale esiste già un'implementazione del SO disponibile. Portare un sistema operativo sul nuovo hardware e sui driver dei dispositivi di scrittura non è il compito più semplice, specialmente per le persone che non hanno familiarità con lo sviluppo integrato.

I progettisti dell'hardware devono scegliere le opzioni hardware candidate che possono svolgere il lavoro. Quindi la squadra dovrebbe fare uno studio commerciale per selezionare l'opzione migliore da quei candidati per il tuo prodotto specifico.

Alcune categorie specifiche del software di questo studio commerciale sono:

• Supporto driver hardware OS
• Sfondo del programmatore
• Identificazione di requisiti "speciali" che avranno un impatto sulla selezione dell'OS / hardware. per esempio. Hai bisogno di multithreading, programmazione, mutex, supporto disco ecc.
• Hai già un codice per un particolare sistema operativo
• Qualunque altro fattore che puoi ottenere influisce sul tuo sistema operativo o sulla selezione della lingua.

Non scegli prima il tuo sistema operativo. Prima scegli il tuo hardware, ma quella selezione hardware deve considerare gli impatti del software. per esempio. Non vuoi scegliere hardware che richiede tutto il codice del driver personalizzato quando un pezzo equivalente di hardware con un'API semplice da usare è immediatamente disponibile.

Per quanto riguarda ciò che dovresti aspettarti dopo, tutto dipende dalle tue selezioni dallo studio commerciale. Se sei abbastanza fortunato da poter utilizzare l'hardware compatibile con Windows Embedded con driver compatibili con Windows, la tua curva di apprendimento sarà piuttosto piccola. Sarà molto simile allo sviluppo del desktop (almeno fino a quando non si inizierà l'integrazione con i dispositivi hardware, quindi alcune conoscenze hardware potrebbero entrare in gioco).

Se l'intento è quello di creare hardware a costo estremamente basso, potrebbe essere necessario scrivere codice che modifichi i singoli bit nei registri e sia necessario scrivere tutti i gestori di interrupt per i dispositivi collegati. Se non si dispone di una gran parte di hardware, questo non sarebbe per la tua squadra. Non puoi scrivere software driver affidabile se non capisci come deve funzionare l'hardware.

Direi che se hai il sistema operativo Windows incorporato completo, allora potresti essere in grado di fare il lavoro senza assumere nessuno. Linux probabilmente prenderebbe qualcuno con una certa esperienza, ma se hai un po 'di tempo libero puoi provarlo da solo per alcune settimane per determinare se pensi che ci sia bisogno. Qualunque scelta del sistema operativo con meno di uno dei due precedenti richiederà probabilmente qualcuno con esperienza, anche se è solo per farti andare avanti. Se scegli un pacchetto / sistema operativo per schede che richiede un pacchetto di supporto per schede personalizzato, trova sicuramente qualcuno con esperienza specifica nello sviluppo di BSP per quel particolare sistema operativo. È un'abilità molto di nicchia che può avere un enorme impatto sul prodotto se fatto male.