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.
Rispondi quotando
Originariamente inviata da M.A.W. 1968
