Differenza tra programmazione "embedded" e programmazione normale: un chiarimento

[web_man]

Buongiorno,
secondo voi quali sono in linea di principio le differenze tra il programmare per sistemi embedded e programmare "normalmente"?. Mi spiego meglio: spesso vedo annunci di lavoro inerenti la ricerca di figure che abbiano un paio di anni di esperienza in "C embedded". Uno come me che ha lavorato nello sviluppo GUI in C++ (per PC), potrebbe tranquillamente qualificarsi come sviluppatore embedded? oppure secondo voi sono richieste conoscenze particolari (tipo chesso' uso di strumentzione elettronica o simili..). In fondo alla fine non si tratta di usare sempre il linguaggio C/C++ o Python con una particolare libreria/framework (come puo' essere Qt per lo sviluppo GUI, oppure nel secondo caso una libreria che "dialoga" con l'hardware)?

grazie per i chiarimenti.

[linoma]

Si dopo che hai acquisito esperienza la differenza è minima . Considera che se devi testare alcune parti del codice ti ritrovi anche senza debugger. E qui purtroppo senza conoscenze specifiche nn vai da nessuna parte, forse nn ti aiuta neanche google.

[MItaly]

Be' insomma, un po' di differenze ci sono... lavorare con un AVR che ha 2 KB di memoria flash in tutto e 16 MHz di clock è tutto un altro discorso che scrivere applicazioni GUI Qt, per quanto tu possa lavorare in C++ in entrambi i casi... Oltre al fatto che spesso lavorando embedded non hai pezzi considerati fondamentali (ad esempio, potresti non un sistema operativo sotto, o l'allocazione dinamica, il grosso della libreria standard, le eccezioni, le vtable potrebbero portare via troppo spazio, ...), dover lavorare con concetti di basso livello (impostare l'hardware modificando bitmask in registri, gestire gli interrupt, lavorare direttamente con le porte hardware), dover gestire hardware "strano" (senza le astrazioni del sistema operativo) e protocolli tipicamente hardware (I2C, SPI, ...), ... insomma, è un mondo abbastanza diverso.

[M.A.W. 1968]

Poiché, come forse noto a taluni lettori e amici (che saluto), mi occupo professionalmente di progettazione di sistemi embedded critici da più di venti anni, ritengo di poter fornire qualche utile indicazione. Per evitare noiose ripetizioni, mi prendo la libertà di autocitarmi da altri forum, nei quali sono attivo, ovviamente nella speranza di non violare le regole della casa.

Ritengo innanzi tutto fondamentale chiarire cosa intendiamo tra addetti ai lavori per "sistema embedded". Esiste una definizione accettata largamente dall'intera comunità, sinteticamente richiamata in questo post. Questo perché non solo la divulgazione e le riviste mainstream, ma perfino molte aziende piccole e medie che operano ai margini del settore non hanno le idee ben chiare in proposito.

In secondo luogo, per rispondere alla tua domanda senza alcuna pretesa di esaustività (occorrerebbero diversi tomi per rispondere compiutamente, in effetti), le differenze sono notevoli e possono essere abissali. Dipende dall'azienda, dal mercato, dal tipo di lavoro e da numerosi altri parametri. Molti studenti e sviluppatori hanno purtroppo in mente idee platoniche estremamente limitate del mondo embedded (esperienze DIY o scolastiche con microcontroller PIC, ST o Atmel di base, al più epifenomeni del mondo MIPS e ARM reincarnati sotto forma di softcore, eccetera), che però non catturano se non in modo insignificante la meravigliosa e terrificante complessità di tale galassia. Basti pensare che esistono più di diecimila (10.000) fornitori di chip programmabili del genere che ci interessa - che siano MCU, CPU, System-On-Chip (SoC), softcore ossia IP per logiche programmabili, e via discorrendo. Si parla di centinaia di miliardi di semiconduttori programmabili in campo, per un totale di circa cinquanta miliardi di sistemi embedded attualmente funzionanti sul pianeta e nelle immediate vicinanze, con un turnover di circa sei miliardi di device all'anno. Tutti dati banalmente riscontrabili sulla prima rivista industriale di settore che vi capita in mano. Sono numeri astronomici, che fanno apparire davvero striminzito il mondo dei PC e dei server.

Il range dei dispositivi embedded, e più propriamente delle architetture di calcolo dedicate, è di una vastità sconcertante per chi è abituato al mondo sostanzialmente monadico di PC e affini: si passa da architetture a 4 bit con una manciata di locazioni di program memory e altrettante di RAM (nei core embedded predomina incontrastata l'architettura Harvard, con memorie fisicamente separate per dati e programmi, al contrario dell'architettura Von Neumann, che invece contraddistingue anche i PC tradizionali) passando per gli 8-bit di datapath che dominano il mercato, e si arriva non solo ai 32 e 64 bit - presenti comunque in quantità molto limitate sul venduto - ma anche e soprattutto a DSP, System-On-Chip, fino a piattaforme del tutto esotiche, parallele, transazionali, eccetera.

A questa enorme variabilità delle piattaforme hardware corrisponde quella negli strumenti di sviluppo. I linguaggi, di norma, annoverano unicamente l'Assembly della piattaforma target ed il relativo cross-compilatore C dedicato che solo in parte implementa lo standard C'89, con rarissime e spesso poco significative estensioni C'99, ADT e poco altro. Esistono altresì compilatori Embedded C++, sebbene la loro diffusione sia limitata, e linguaggi dedicati come Ada o Eiffel in contesti RTOS a domini separati.

A proposito di sistemi ed ambienti operativi, se molti sistemi embedded sono piattaforme systemless governate da un singolo firmware binario, esistono numerose altre soluzioni (es. realtime executive, ancora un singolo binario ma che include anche un kernel in tempo reale e può essere a sua volta caricato da un semplce loader o ospitato da un completo SO, come nel caso di ROMDOS con RTE tipo AMX, CMX, SMX, RTXos eccetera).
In molti mercati si usano completi sistemi operativi proprietari o commerciali in tempo reale come descritto ad esempio dalle Posix PSE54, certificati per utilizzi "hard realtime" critici e totalmente diversi dai sistemi mainstream: dunque microkernel (l'unica eccezione di largo mercato è, in pratica, VxWorks) con differenti set di primitive, politiche di scheduling, IPC dedicata ad altissima efficienza e molto altro che richiede una notevole mole di impegno e studio. Il più noto di tali sistemi, anche fuori dalla comunità specialistica, è probabilmente QNX, ma ve ne sono a dozzine: sono oltre duecento quelli certificati o certificabili citati nelle buyer's guide più complete, per non parlare dei numerosi sistemi proprietari sviluppati inhouse, certificati al solito presso terze parti indipendenti ma utilizzati esclusivamente dai loro creatori.

Il metodo di lavoro, sebbene molto evoluto rispetto ad appena venti anni fa (un rituale basato su EPROM e cancellatori UV, oppure costosissimi emulatori di memorie...), richiede poi il costante ricorso a supporti hardware dedicati, che includono sistemi di emulazione fisica del microcontroller (ICE, In-Circuit Emulator), loader e debugger residenti ed in generale richiedono - se non una vera e propria capacità progettuale a livello hardware, sempre preferibile per uno sviluppatore embedded - almeno una estesa familiarità con strumentazione che quasi sempre risponde ad un binomio di elevata sofisticatezza e costo notevole.

Ho parlato di certificazioni, anticipando il presente punto: alcuni mercati, dall'avionica all'aerospaziale, dal ferroviario al militare al biomedicale, all'energetica, sono infatti normati da leggi nazionali ed internazionali che si rifanno a norme tecniche delle quali il 99,9% dei programmatori mainstream ignora perfino l'esistenza, ma dalla cui conoscenza non è possibile prescindere nei settori più critici dell'embedded. Si veda ad esempio, per una prima idea in merito, questo post.

Naturalmente è impossibile fornire indicazioni generiche (una piccola società che sviluppa SCADA e automazione industriale su schedine semicustom, ad un livello appena superiore ai soliti PLC è distante anni luce dalle esigenze di un progettista automotive in una multinazionale...), ma forse un assaggio di bibliografia pensata per un target entry level farà bene. Si consideri inoltre che per motivi pratici ho volutamente lasciato fuori tutta la parte relativa ai metodi formali, la cui conoscenza e uso quotidiano fanno parte delle richieste per la progettazione sia software che hardware nei settori più rigidamente normati (e, anche qui, essi fanno largamente la differenza rispetto ai programmatori mainstream).

Questa, telegraficamente, può essere una primissima introduzione ad un universo complesso, articolato e purtroppo poco conosciuto.

[oregon]

Poiché, come forse noto a taluni lettori e amici (che saluto)

Ciao e ben trovato da queste parti ...

[paolino_delta_t]

Concordo con M.A.W. Purtroppo i dirigenti di molte aziende medio/piccole non hanno la più pallida idea di cosa si nasconde dietro il termine embedded. Pertanto lo usano a sproposito.

Giusto per portare un esempio chiarificatore, nel ramo embedded ti potresti ritrovare a lavorare con una cosa del genere http://www.marvell.com/network-proce...-architecture/

Bye bye Von Neumann!!

[M.A.W. 1968]

Giusto per portare un esempio chiarificatore, nel ramo embedded ti potresti ritrovare a lavorare con una cosa del genere http://www.marvell.com/network-proce...-architecture/

Bye bye Von Neumann!!

L'architettura proposta dal geniale Von Neumann, nella quale dati e programmi condividono la medesima memoria fisica, aveva chiaramente senso negli anni Quaranta e Cinquanta dello scorso secolo, quando è stata concepita. Garantiva in particolare la grande economicità e la flessibilità necessarie ai primi tentativi militari di general purpose computing, contro la relativa rigidità del concetto elaborato parallelamente ad Harvard - che richiedeva un preciso dimensionamento iniziale delle quantità di memoria fisica da destinare rispettivamente a dati e programmi.
In realtà, nonostante i limiti realizzativi e tecnologici, anche nel secondo caso era previsto fin dall'inizio un certo grado di modularità e configurabilità, ma non sottilizziamo: si trattava comunque di operazioni fisiche da eseguire sui banchi di memoria, fattibili praticamente solo a macchina spenta, al limite con una sorta di hot swap semiautomatico, ma non certo in modo dinamico e a runtime come nella VN.

Al giorno d'oggi, dopo oltre mezzo secolo, l'architettura VN così pervasivamente implementata nei PC ha mostrato ampiamente tutti i suoi limiti, che è difficile perfino elencare compiutamente senza rischiare omissioni rilevanti: non solo risulta prestazionalmente perdente contro i concetti (geniali) del parallel computing e delle piattaforme embedded, che negli ultimi anni le architetture mainstream tentano malamente di emulare, ma è fonte di una quantità enorme di problemi di robustezza e sicurezza (facile accesso allo stack ed alla memoria riservata in genere, eseguibilità dei dati, self-morphing...) che moderni SO e CPU tentano di arginare con limiti e partizionamenti di tipo logico, ma che su altre architetture sono semplicemente risibili come minacce, perché fisicamente infattibili (e di fatto prive di reali omologhi di pari pericolosità).

Basti solo pensare che su tutte le architetture Harvard, implementate anche nelle economicissime MCU con le quali giocherellano legioni di amatori (PIC, ST, AVR, H8/300, etc...) il caricamento contemporaneo di istruzione (dalla program memory) e dato (dalla RAM dati o file register) consente di raddoppiare senza sforzo le prestazioni rispetto alla classica CPU Von Neumann corrispondente (es. 8086): in talune architetture denominate Super Harvard (tipici ad esempio i DSP SHARC) tali concetti sono poi portati all'estremo, ed è possibile partizionare ulteriormente le memorie creando aggregazioni nelle quali i dati vengono interpretati con larghezza di parola variabile, facendo così coesistere segmenti a 16 o 32 bit con altri a 80 bit, il tutto gestito in hardware senza ricorso a farraginoso microcodice e garantendo l'esecuzione di ogni istruzione in un singolo ciclo di clock. La biodiversità del mondo embedded è semplicemente impressionante anche per chi ci lavora da una vita.

[web_man]

Grazie a tutti per avermi chiarito le idee. In generale per programmare dei dispositivi embedded sono richieste conoscenze specifiche e piu' focalizzate sul dispositivo rispetto al programmare per PC. Ma in generale sono conoscenze che dipendono tantissimo dal contesto, proprio perchè il mondo embedded è estremamente variegato; quindi es: se programmi un PIC dovrai impararti il set delle istruzioni assembly, mentre se prendi una schedina Raspberry e ci installi Linux.. a quel punto diventa quasi come un PC e puoi sviluppare sopra il SO senza che quasi te ne accorgi che stai sviluppando per emebdded.
Oggi vedo che negli annunci di lavoro del settore "embedded" chiedono molto conoscenze dei microprocessori ARM; informandomi vedo che molti di questi hanno dei tool di sviluppo che rende possibile programmarle in C/C++, per altro alcune hanno processori e memorie che come prestazioni non sono molto lontani da quelli dei PC normali, per cui anche il discorso delle "risorse limitate" e le conoscenze particolari che tale situazioni renderebbe necessarie vale sporadicamente secondo me, idem per il discorso dei contesti "critici" che vanno trattati come situazioni molto molto particolari..
Perchè alla fin fine si tratta sembre di scrivere software no? Cioe' non è come ad esempio progettare dell'hardware, dove devi
applicare delle conoscenze particolari derivate dall'elettronica (calcolo dei valori delle resistenze per avere il guadagno giusto ecc.ecc) o mi sbaglio?
Quindi secondo me a meno che l'annuncio di lavoro non richieda conoscenze particolare (esempio : conoscenza dell'assembly o protocolli come potrebbe essere SPI o I2C) di fatto un programmatore C++ generico potrebbe andare benissimo per un progetto embedded a patto di lavorare focalizzandosi sulle specifiche del dispositivo, non è cosi'?

[vbextreme]

Quindi secondo me a meno che l'annuncio di lavoro non richieda conoscenze particolare (esempio : conoscenza dell'assembly o protocolli come potrebbe essere SPI o I2C) di fatto un programmatore C++ generico potrebbe andare benissimo per un progetto embedded a patto di lavorare focalizzandosi sulle specifiche del dispositivo, non è cosi'?

Come già detto dall'illustre MAW che saluto, sono due mondi separati.
Hai mai programmato microcontrollori ad uso hobbistico?
Per mia esperienza di c++ ne ho visto realmente poco,ho sempre programmato in assembly e con i pochi "potenti" chip che mi sono capitati per le mani l'ho fatto con un mix di c & assembly.
Insomma come già ripetuto qui l'assembly è di casa,il perchè è semplice detto, nell'embemed all'80% dei casi ti serve sapere il tempo di esecuzione del codice e l'unica maniera per sapere realmente quanto tempo impieghi per fare una determinata cosa è l'assembly.
Ma non solo,sempre come accennato ogni chip implementa certe caratteristiche differenti che si possono sfruttare appieno solo con la programmazione assembly da parte di un professionista.

[M.A.W. 1968]

Proviamo a chiarire, in modo più mirato, i numerosi dubbi residui.

...se prendi una schedina Raspberry e ci installi Linux..

I vari Raspberry, Arduino, eccetera non sono sistemi embedded in senso stretto, secondo la definizione comunemente accettata dagli addetti ai lavori. Non possono essere direttamente applicati nella maggioranza delle situazioni industriali, a causa del tipo di progettazione (principalmente per la mancanza di protezioni specifiche contro sovratensioni e interferenze EMI) ma anche per la loro genericità e semplicità strutturale. Peraltro i sistemi operativi mainstream, eccettuando alcune scarsamente diffuse verticalizzazioni (nelle quali, in sostanza, un microkernel realtime "ospita" il goffo, ingombrantissimo e lento SO in un task segregato), sono per definizione del tutto inadatti agli utilizzi embedded propriamente detti, e compaiono semmai al termine di una catena SCADA o comunque con ruoli di mera interfaccia non critica.

Oggi vedo che negli annunci di lavoro del settore "embedded" chiedono molto conoscenze dei microprocessori ARM; informandomi vedo che molti di questi hanno dei tool di sviluppo che rende possibile programmarle in C/C++, per altro alcune hanno processori e memorie che come prestazioni non sono molto lontani da quelli dei PC normali

Vedi sopra. La maggioranza di codesti sistemi è "embedded" solo nella fantasia di talune PMI e di qualche giornalista. Si è molto discusso, negli anni passati, se anche generici apparati di rete e telecomunicazioni (che impiegano largamente ARM a 32 bit e altri core assimilabili a quelli in uso nel mainstream) possano o meno rientrare nella definizione di sistema embedded, principalmente sulla base dell'analisi dei rischi nel loro impiego. L'orientamento generale è negativo in tale senso, anche a causa della sostanziale mancanza di un coerente quadro di norme tecniche di riferimento.
In ogni caso, si tratta di applicazioni talora cost-sensitive, ma ai margini del mercato embedded.
Anche in tali settori, peraltro, occorre un background verticale molto specifico, se l'applicazione è minimamente seria.

idem per il discorso dei contesti "critici" che vanno trattati come situazioni molto molto particolari..

Al contrario. Dev'essere ben chiaro che i sistemi critici sono numericamente la schiacciante maggioranza di quei 50 miliardi di device attualmente in campo, e costituiscono il vero e proprio core del mercato embedded. Qualsiasi altra cosa è decisamente marginale.
La criticità di cui si parla può essere quella della banale ma diffusissima automazione industriale nelle classi SIL2 e 3 secondo la EN62061, quindi praticamente tutte le macchine automatiche capaci di infliggere un danno Se di livello 3 o 4 (risp. un danno permanente o la morte dell'operatore), passa dai sistemi automotive (ABS, centralina di iniezione...) dove l'unità di misura sono i milioni di pezzi, e arriva tranquillamente ai sistemi di controllo del traffico aereo e navale, al complesso e articolato mondo ferroviario, all'energetica e al nucleare, alla sterminata galassia del biomedicale, fino all'aerospaziale, al petrolchimico e ai sistemi militari...

Perchè alla fin fine si tratta sembre di scrivere software no?

Non è così banale... occorre conoscere comunque l'assembly e il comportamento del cross-compilatore (ribadisco: dialetti C con innumerevoli estensioni proprietarie, e compatibili quasi unicamente con ISO/IEC 9899:1990), l'ottimizzazione, la RPC, la strutturazione ottimale dei task (a maggior ragione nel classico caso del "big loop") e tutti gli altri dettagli dell'eventuale RTOS sotteso, in qualsiasi forma si presenti, dal classico Posix 1003-13 PSE 53 e 54 fino ai basilari realtime executive. Inoltre occorre andare ben oltre la banale stesura del software: anche laddove non si parla di progettazione e verifica formali, occorre comunque un lavoro di progettazione estremamente accurato, un sistema di testing e verifica che garantisca caratteristiche funzionali e di adeguatezza. Inoltre ovviamente occorre adeguarsi alle norme di codifica in uso nel settore: le quali, tanto per fornire un'idea di primo impatto, sovente proibiscono categoricamente l'allocazione dinamica e molti altri idiomi comuni nella programmazione mainstream. Peraltro le idiosincrasie dei cross-compiler fanno in modo che alcuni peccati veniali della programmazione C/C++ mainstream (ad esempio, l'abuso dell'operatore modulo, il mancato utilizzo di tecniche booleane, eccetera) divengano colli di bottiglia inaccettabili in una qualsiasi applicazione embedded. In breve, occorre adottare un punto di vista molto diverso rispetto alla banale programmazione con risorse spropositate consentita dai PC mainstream: un punto di vista che richiede profonda consapevolezza ed esperienza, certo non improvvisabili.

Tutto ciò, con ogni evidenza, non può certo essere specificato dall'annuncio di lavoro. E' un background che si dà per scontato, come è scontato che un geometra sappia usare un teodolite o che un perito elettronico conosca la legge di Ohm. Tra l'altro, come già accennato, gli autori degli annunci hanno sovente un'idea assai vaga e fantasiosa di cosa sia o non sia un sistema embedded vero e proprio: idea fumosa generalmente riassumibile in "tutto ciò che non somiglia a un PC da scrivania". D'altro canto, ci sono installatori e produttori che - pur operando da sempre nel settore - fanno confusione perfino con la definizione di PLC, attribuendo tale etichetta in modo indiscriminato a praticamente ogni genere di dispositivo di controllo elettronico...

Per la cronaca, si può definire PLC un apparato commerciale o custom, modulare o meno, vettoriale o no, se e solo se nativamente programmabile con almeno uno dei linguaggi della norma EN 61131-3: LD, FBD, ST, IL, SFC. Sottolineo nativamente, perché esistono librerie (anche realtime) denominate SoftPLC che consentono di emulare un PLC e interpretare/eseguire codice scritto in uno dei summenzionati linguaggi su piattaforme diverse, a partire da PC industriali e schede SBC varie.
Dunque qualsiasi altro aggeggio elettronico industriale, inclusa ogni piattaforma che ospita un SoftPLC, non è un PLC ed è sbagliatissimo definirlo tale!