Storicamente la programmazione di un microcontrollore avviene tramite un apposito dispositivo detto programmatore. Lo scopo di questo dispositivo è quello di trasferire fisicamente il programma che abbiamo realizzato (e precedentemente compilato) nella memoria del microcontrollore (tipicamente una EEPROM). Si tratta di dispositivi specifici per il tipo di microcontrollore per il quale devono essere usati e, in taluni casi, possono avere dei costi non indifferenti!
A livello industriale o in un laboratorio di un centro di ricerca l’impatto, in termini economici, di questi dispositivi può non essere particolarmente rilevante ma nel settore degli hobbisti, dove il budget è più ridotto, l’impatto esiste eccome. Non parliamo poi dell’ambito universitario in cui le risorse sono sempre ridotte al minimo!
Aldilà del mero aspetto economico sono sorte nel tempo altre necessità pratiche che hanno contribuito a rendere questo tipo di soluzione tutt’altro che vantaggiosa. Pensiamo, ad esempio, ai casi di manutenzioni perioche che prevedano aggiornamento del firmware: ogni operatore deve portare con sè un programmatore per poter eseguire il lavoro. Non particolarmente comodo ma fattibile. Nel caso in cui il microcontrollore non sia fisicamente raggiungibile la questione si complica ulteriormente. In questi casi è necessario “smontare” l’intero apparato per poter raggiungere il microcontrollore e collegare fisicamente il programmatore. Per evitare questo sarebbe quindi necessario rendere sempre raggiungibile l’interfaccia del programmatore: decisamente scomodo laddove non fattibile per questioni di sicurezza.
Esiste un modo alternativo per gestire l’aggiornamento del firmware? Qual’è il problema principale? Ovviamente il modo esiste: il limite da superare è quello di attivare, in qualche maniera, le interfacce di comunicazione del microcontrollore per consentire il trasferimento del software compilato. A seconda del tipo di microcontrollore e del modello del fornitore possono essere disponibili interfacce diverse. Quelle più note sono UART, SPI, I2C. In ambito industriale, in particolare nel settore automotive, si usano altre interfacce come ad esempio CAN.
Per fare questo si utilizza un bootloader: un software che consente di attivare una modalità “aggiornamento del firmware” predisponendo le interfacce disponibili alla ricezione del programma e al suo corretto salvataggio nella memoria del microcontrollore. Il vantaggio è che una volta disponibile il bootloader è sufficiente operare come segue:
- collegare il PC col software compilato al microcontrollore
- attivare la modalità di aggiornamento
- trasferire il firmware dal PC al microcontrollore usando software apposito
Questo tipo di operatività è molto più semplice rispetto a quella necessaria utilizzando un programmatore: l’interfaccia UART può essere collegata ad una seriale RS232 o ad una porta USB rendendo il tutto molto più comodo. Se l’interfaccia è di tipo CAN bastano addirittura due fili.
Va detto che il bootloader utilizzato, oltre a essere specifico del microcontrollore, cambia anche in base al tipo di interfaccia. L’interfaccia usata infatti può prevedere anche l’invio di segnali specifici, la questione è un po’ più complessa del collega e passa i dati. Una volta identificato il bootloader per il microcontrollore/interfaccia bisogna inserirlo nel microcontrollore (indovinate un po’ : usando un programmatore). Il bootloader sarà salvato nella zona di memoria letta in fase di avvio dal microcontrollore. Questo essenzialmente per far si che esso sia il primo software che viene letto quanto il microcontrollore viene avviato (da cui il nome) e per poter pilotare quindi l’attivazione della modalità di aggiornamento piuttosto che l’esecuzione di firmware già caricato in precedenza.
In genere lo schema prevede che, a seguito del reset, il bootloader attivi le interfacce e attenda l’arrivo del firmware da aggiornare per un certo tempo. Se i dati arrivano il bootloadeer li scrive e poi avvia il nuovo firmware appena trasmesso. Se non arrivano dati, ed è presente un firmware, esso viene eseguito. Va da sé che il bootloader deve scrivere il firmware ad una locazione di memoria ben precisa in modo da poter gestire l’aggiornamento/esecuzione del firmware e da non sovrascrivere sé stesso!
Questo per sommi capi è lo scopo ed il funzionamento di un bootloader. Immagino la successiva domanda sarà : “…e quindi?”. Per un progetto personale (e per contenere i costi) mi sono trovato a dover gestire un microcontrollore privo di bootloader. In un prossimo articolo, mostrerò come caricare un bootloader su un microcontrollore (addirittura senza usare un programmatore!!).