5 modi in cui un livello di astrazione hardware può trasformare i tuoi progetti

Giacobbe del Benin | 05 giugno 2023

Gli sviluppatori di software embedded hanno in genere evitato gli HAL (Hardware Abstraction Layer) sostenendo che riducono le prestazioni e aumentano la complessità del codice. Sfortunatamente, quando gli sviluppatori adottano un HAL, un HAL fornito dal fornitore spesso non astrae l'hardware e garantisce comunque uno stretto accoppiamento con l'hardware. Dopotutto, un vero HAL astratto consentirebbe a uno sviluppatore di utilizzare qualsiasi fornitore in un batter d'occhio. Tuttavia, esistono molti modi in cui l'utilizzo o lo sviluppo del proprio HAL può influire sul software. In questo post esploreremo cinque modi sorprendenti in cui un HAL può trasformare i tuoi progetti software e liberare velocità e valore che non pensavi fossero possibili.

In genere ho scoperto che gli sviluppatori hanno spesso un fornitore di microcontrollori preferito. Di solito si tratta del fornitore per cui hai scritto per primo il software incorporato o che conosci. Ho i miei preferiti proprio come chiunque altro, ma può essere pericoloso scrivere il tuo software in base al loro HAL o alle librerie software. Ad esempio, cosa fai se all'improvviso non riesci a procurarti i loro microcontrollori? Dovresti selezionare un nuovo fornitore e poi riscrivere, testare e forse anche certificare il tuo prodotto. Non è veloce né economico! Anche se potresti pensare che ciò sia improbabile, è successo durante il COVID e molte volte prima.

L'uso di un buon HAL ti consentirà di scrivere codice applicativo più portabile e riutilizzabile che sia indipendente dall'hardware. Questa è una trasformazione enorme per molti team integrati. Ad esempio, potresti eseguire il codice utilizzando il fornitore A e, modificando un flag nella build, compilare per il fornitore B. L'indipendenza dall'hardware ti offre la flessibilità di utilizzare qualsiasi hardware desideri ed elimina la dipendenza dal fornitore del microcontrollore.

Se ti piace l'idea di utilizzare l'HAL fornito dal fornitore, va bene purché esamini diverse funzionalità essenziali. Innanzitutto, l'HAL deve essere un vero HAL. Ciò significa che devi avere un'interfaccia definita che interrompa la dipendenza dall'hardware. Ne abbiamo discusso nel mio blog intitolato "Scrittura di Hardware Abstraction Layers (HAL) in C." Vedo spesso "HAL" che non sono altro che funzioni con l'implementazione. Ciò non obbedisce al principio di inversione delle dipendenze ed è altrettanto difficile aggiornare il codice. Successivamente, l'HAL dovrebbe essere definito separatamente dall'implementazione. Infine, dovresti essere in grado di sostituire rapidamente la funzione chiamata dall'interfaccia. Se non hai queste tre cose, non hai l'indipendenza dall'hardware; hai una dipendenza dall'hardware!

La chiave per ottenere valore e trasformare lo sviluppo del software inizia con l'utilizzo di un HAL. L'HAL consente inoltre ulteriori trasformazioni come l'abilitazione di unità automatizzate e test di integrazione. Gli sviluppatori embedded spesso hanno difficoltà con i test unitari perché scrivono codice che tocca l'hardware. Ciò significa che devi eseguire i test sul microcontrollore. Quando hai un HAL adeguato, sì, devi comunque testare i tuoi driver sulla destinazione, ma tutto il codice dell'applicazione viene improvvisamente liberato! Il codice dell'applicazione può ora essere sottoposto a test unitario e di integrazione su una macchina host indipendente dall'hardware.

Rimuovere l'hardware dall'equazione e spostare i test sull'host avvantaggia gli sviluppatori. Innanzitutto, è più veloce. Non devi preoccuparti di tutti quei lenti cicli di cancellazione e scrittura da parte. In secondo luogo, non devi preoccuparti di quanto sarà grande il tuo cablaggio di prova o di quanti test hai. Invece di provare ad adattare il codice e i test sul microcontrollore, devi prima testare tutto il codice dell'applicazione sul tuo host. Successivamente, il passaggio ai test fuori target ti consente di utilizzare l'integrazione continua e persino la distribuzione continua, se lo desideri. Il risultato sarà l’individuazione dei bug prima e più velocemente, la riduzione dei costi e il miglioramento della qualità.

Quando si elimina l'hardware dall'equazione utilizzando un buon HAL, è possibile lasciarsi alle spalle qualsiasi implementazione. Ciò significa che puoi avere un'implementazione per il tuo obiettivo, il tuo sistema di test e un ambiente di simulazione! In molti casi, gli sviluppatori di software embedded devono iniziare a scrivere software prima che l'hardware sia disponibile. Quindi, anche se possiamo utilizzare le schede di sviluppo per iniziare, con un buon HAL possiamo invece eseguire simulazioni sul codice della nostra applicazione!