Aspettando Embedded World 2021 – Parte 5

Nota del redattore: la prima parte della serie di cinque blog che ci stanno accompagnando all'edizione 2021 di Embedded World è stata dedicata a una presentazione della manifestazione. Nella seconda parte, Randall ha fornito un ripasso delle nozioni sul linguaggio di programmazione in C. La terza parte si è concentrata su come la programmazione orientata agli oggetti possa contribuire a ridurre la complessità. La quarta parte ha illustrato come la buona progettazione si misuri sulla capacità di riconfigurazione al mutare dei requisiti senza bisogno di implementare di nuovo i componenti costitutivi. In questa quinta parte finale, ci si interroga sull'aumento incessante dello spazio richiesto dai sistemi operativi e si tocca l'argomento della scomposizione del sistema prima del discorso introduttivo di Randall a Embedded World 2021.

Nel mio ultimo post ho esposto il punto di vista di David Parnas in merito al fatto che un sistema dovrebbe nascondere le informazioni dietro l'interfaccia e che i sistemi dovrebbero essere scomposti in moduli in grado di accogliere il cambiamento. Ho anche citato un recente sostenitore di questo approccio, l'autore di Righting Software, Juval Löwy.

È un approccio diverso da quello che probabilmente va per la maggiore oggi, la scomposizione funzionale. Tuttavia vi sono buone testimonianze della superiorità dell'approccio di Parnas. Tra queste, il fatto che un sistema progettato per il cambiamento è un sistema più facile da capire. È più facile "groccare" un sistema di questo tipo e ricomporlo in nuove implementazioni. Mettendo a disposizione dei non esperti l'esperienza di altri, questo approccio gioca un ruolo fondamentale nell'accrescere il riuso. Offre anche l'opportunità di allargare i mercati degli ingegneri embedded dando impulso alla realizzazione delle loro visioni da parte di altri. Perciò la buona progettazione si misura sulla capacità di riconfigurazione al mutare dei requisiti senza bisogno di implementare di nuovo i componenti costitutivi. In questo modo, il cambiamento dei principali casi d'uso si traduce semplicemente nelle interazioni tra i componenti costitutivi progettati per casi d'uso e requisiti specifici.

Ma purtroppo questo approccio non è privo di punti deboli e di rischi, tra cui l'inefficienza e lo spreco. Più i sistemi crescono, più diventano naturalmente ingombranti. Vi consiglio di leggere l'interessante blog di un tal Nikita. Sono felice di segnalare che era ancora presente online verso la fine del 2020. Dice Nikita:

"Un sistema Android senza app richiede circa 6 GB. Fermatevi un attimo a pensare a quanto enorme sia questa quantità. Contiene per caso vari film in HD? Immagino si tratti principalmente di codice, ad esempio kernel, driver. Vi sono certo anche stringhe e risorse ma non occupano certo molto spazio. Viene da chiedersi quanti driver sono necessari per un telefonino.

Windows 95 occupava 30 MB. Oggi vi sono pagine web che pesano di più! Windows 10 è 4 GB, vale a dire 133 volte tanto. Ma è lecito chiedersi se le sue prestazioni siano di 133 volte superiori. Dal punto di vista funzionale, sono fondamentalmente le stesse. Certo, c'è Cortana, ma dubito che occupi 3970 MB. E a prescindere da questo, le prestazioni del sistema Android sono davvero il 150% di quelle di Windows 10?

Il chip M1 di Apple, come ha annunciato la casa madre nel novembre 2020, contiene 16 miliardi di transistor, un numero enorme per gli standard attuali. Anche i progettisti embedded hanno a disposizione alcuni enormi FPGA. Se è vero che l'hardware e i programmi per computer di uso comune sono diventati ingombranti, non va diversamente nell'ambiente embedded.

L'elaborazione di segnali digitali ha visto la luce già negli anni Sessanta del Novecento ed è stata utilizzata per i segnali radar. Ciò avveniva prima dell'avvento del microprocessore e della logica programmabile. Da allora, abbiamo adottato funzionalità sviluppate da altri: blocchi IP dai fornitori di FPGA e dai loro rivenditori a valore aggiunto e librerie software di tutti i tipi. Ciò ci ha reso più produttivi ma ha anche reso più voluminose le nostre soluzioni. Il punto è che non è detto che la vostra applicazione abbia bisogno di tutte le funzionalità incluse e probabilmente non sapete neppure tutte le funzionalità che comprende (ad esempio le suite di test integrate che il fornitore ha incorporato nel CI che state utilizzando). La strategia che ha preso piede, la più semplice, consiste nell'impacchettare funzionalità preconfezionate e inserirle nel prodotto finale. Non è remunerativo mettersi a realizzare una soluzione meno voluminosa perché l'implementazione di una soluzione prende più tempo.

Nel mio ultimo post ho citato l'osservazione di Löwy secondo cui un elefante e un topo in fondo condividono la stessa architettura. Questo mi ricorda che il mio DNA contiene gran parte delle genealogia di una banana (90%) e di un moscerino della frutta (95%). Anche se queste formule fanno parte di me, me ne scordo. È quello che sta accadendo ai sistemi embedded. Stiamo portando con noi il bagaglio extra rappresentato da funzionalità facilmente reperibili. L'architettura dei nostri sistemi embedded si avvale di framework che sembrano provenire da reparti IT (ad esempio Harmony di Microchip, xDAIS di Texas Instruments, MCUXpresso di NXP e altri).

Ho letto recentemente un articolo di Kevin Morris apparso su EE Journal in cui si affermava:

"Né Xilinx né Altera/Intel, nonostante si aggirino intorno all'80% della quota del mercato combinato degli FPGA negli ultimi due decenni, hanno spedito il maggior numero di dispositivi FPGA. Il primato va a Lattice Semiconductor con un margine non di poco conto. Il motivo è che, naturalmente, negli ultimi anni Lattice si è concentrata sui segmenti medi e bassi del mercato mentre le aziende produttrici di dispositivi a logica programmabile più conosciute hanno combattuto per la supremazia nel settore dei componenti più costosi come gli FPGA, gli FPGA-SoC e analoghi.

L'attenzione strategica per gli zoccoli a costo inferiore e di più vasta diffusione ha aiutato Lattice a vendere miliardi di FPGA all'interno di un'ampia varietà di sistemi, trasversali a numerosi segmenti di mercato. E, con l'ampliarsi delle possibilità offerte dagli FPGA, Lattice si è messa sulla scia delle due grandi aziende portando una tecnologia che solo pochi anni fa pareva riservata a un mercato di fascia alta in quello delle applicazioni con vincoli di costo molto maggiori, per poi virare in nuove direzioni grazie a soluzioni pre-ingegnerizzate che abbassano notevolmente il livello di esperienza richiesto per avvalersi della tecnologia degli FPGA".

Digitando "microcontroller" nella casella di ricerca di DigiKey appariranno oltre 87.000 dispositivi distinti. Digitando "FPGA" appariranno oltre 25.000 dispositivi. Guardate ora la Figura 1. Vi troverete le tipologie di microcontroller più acquistate dai consumatori. Si noti che il mercato di fascia bassa da 8 bit riserva le maggiori opportunità. In un presente popolato da ARM e RISC-V, potrete pensare che è sorprendente, ma corrisponde all'articolo su Lattice.

Figura 1: Popolarità dei vari tipi di microcontroller

La sfida che ci para davanti in quanto ingegneri embedded è quella di resistere alla tentazione di ingigantire la nostra funzione. Actel, ora Microsemi, che è una divisione di Microchip, aveva uno strumento chiamato "gate gobbler", che potremmo grosso modo tradurre come "divoratore di gate". Per quanto ne so esiste ancora. Grazie a questo strumento è possibile eliminare la logica superflua. Potremmo dover rispolverare strumenti del genere per consentire ai nostri utenti di recidere funzionalità non necessarie.

Nella mia presentazione a Embedded World illustrerò un esempio di scomposizione di sistema con l'approccio di Parnas e sosterrò che il mercato degli ingegneri embedded è ampio e in crescita. Spiegherò la prospettiva che consiste nel ridurre la complessità per utilizzare la funzionalità di un altro al fine di avvantaggiare sia i principianti sia gli esperti. È una prospettiva che ci riserva un futuro fantastico. Spiegherò anche che cosa hanno fatto le aziende che producono dispositivi a logica programmabile per provocare l'ostilità dei loro mercati e come è possibile correggere la situazione.

È importante che le aziende rendano i loro prodotti utilizzabili da parte del pubblico più vasto. Agli esordi della mia carriera, una delle case automobilistiche USA aveva fatto ricorso a licenziamenti di massa. Ricordo di aver letto un articolo in cui si sosteneva che vi fosse una buona probabilità che, tra la massa di licenziati, vi potesse essere qualche Edison, Ford e uno o due Leonardo da Vinci. Il prossimo Leonardo da Vinci inizierà la sua carriera in mercati ampi e non specializzati. Abbiamo bisogno di persone del genere per poter sfruttare la nostra esperienza.