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

[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'?

[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!