Quando mi avvicinai a Linux embedded, circa 15 anni fa, pensai quasi subito che compilare un intero sistema da zero (from scratch) è una delle attività più affascinanti per un programmatore di firmware. Ti dà la sensazione di conoscere tutte le parti del sistema, e di saperci mettere le mani.

Credo che, oggigiorno, il discorso sia analogo con i moderni microcontrollori (anche detti MCUs, Micro Controller Units). I produttori di solito rilasciano librerie sotto forma di SDK, o forniscono una versione customizzata di qualche sistema operativo real-time (RTOS). La mia opinione, e la mia esperienza, è che questi strumenti vadano considerati come una implementazione di riferimento per il chip, o per effettuare prototipazione rapida della propria applicazione, ma il più delle volte, per progetti professionali che debbano essere mantenuti nel lungo periodo, si dovrebbe preferire la creazione di una propria base di codice, per una serie di ragioni che non mi metto qui ad elencare. Questo non significa che bisogna reinventare la ruota e riscrivere tutto da zero; però un mix equilibrato di librerie di terze parti e di codice proprio è di solito meglio che prendere acriticamente un intero SDK dal produttore, senza alcuna analisi preventiva su di esso.

Comunque, anche se credi che userai sempre gli IDE e le librerie che ti vengono fornite con il SoC, vale ancora la pena di conoscere cosa sta realmente accadendo quando usi questi strumenti, cercando di imparare a sviluppare per lo meno i primi stadi del boot e un set minimo di driver che controllino che il chip e la scheda sono vivi: ad esempio, il settaggio del clock, la UART che scrive qualcosa, il controllo dei GPIO, e se possibile qualcos'altro ancora.

Queste le mie 10 ragioni per quanto appena detto:

1. Penso semplicemente che sia divertente: la prima volta che sono riuscito a far lampeggiare un LED con un GPIO su una board Olimex, senza usare alcuna libreria esterna, ero veramente esaltato.

2. Sarai un miglior programmatore firmware se hai un'idea precisa di come avviene il boot della CPU e di come il tuo binario è costruito a partire dai sorgenti.

3. Gli SDK talvolta sono pessimi; ho perso un sacco di tempo su una implementazione di un host USB di una libreria Atmel, che un mio cliente mi aveva costretto ad usare; non ottenni alcun aiuto nemmeno dopo aver inserito il problema nel sistema di bug tracking di Atmel.

4. Anche quando l'SDK o RTOS è fatto bene, prima o poi troverai un bug; se non hai idea di cosa sia un registro di un SoC, sei completamente perso, e sei costretto a implorare qualcuno di risolvere il bug.

5. Se tieni d'occhio l'occupazione di flash, e non vuoi un binario di 100k per un'applicazione che fa lampeggiare un LED, faresti meglio a capire come è composto il tuo binario, e possibilmente a ridurlo il più possibile.

6. Quando il tuo cliente, o il tuo capo, decideranno di cambiare famiglia di CPU, se hai semplicemente usato l'SDK senza troppi pensieri, ti ritroverai a dover riscrivere tutto; se invece il tuo codice è stato ben strutturato, e hai provato a relegare tutte le dipendenze legate al SoC in una parte separata, sarai in grado di riusare almeno una parte del codice.

7. Non tutte le feature dell'hardware sono realmente implementate nelle librerie degli SDK o nei driver RTOS; ad esempio, i timer e le funzionalità pwm/capture sono molto complesse, e spesso è più semplice leggere il datasheet e implementare secondo i tuoi bisogni, piuttosto che cercare di ottenere lo stesso chiamando le funzioni C dell'SDK.

8. Se dovessi avere il bisogno di integrare una libreria di terze parti, che magari confligge con l'SDK, il tuo lavoro sarà molto più semplice se hai una minima esperienza pregressa con la programmazione bare metal.

9. Ok, ora starai pensando: "bare metal è davvero troppo per me, ho programmato GUI su Windows fino a ieri". Qualunque siano le tue competenze, imparerai sempre qualcosa andando a fondo negli strati più bassi del codice sorgente: imparerai qualcosa sul C se conosci l'Assembly, o capirai meglio il Javascript se conosci il C. Quindi, sarai un migliore utilizzatore di sistemi RTOS se hai un'infarinatura sulla programmazione bare metal. A questo proposito ti consiglio di dare un'occhiata a BaTHOS e BaTHOS MCUIO.

10. Può essere che ora ti sia convinto a impiegare qualche giornata per apprendere qualcosa sul bare metal; ne hai parlato col tuo capo e lui (o lei) ti hanno risposto: "Niente da fare, voglio tutto quick and dirty, la scadenza è ieri". Se è così, faresti meglio a cambiare lavoro.