L’articolo scritto qui sotto è un fatto da un ex studente del nostro corso. In questo articolo ci racconta una esperienza singolare che gli è successa durante un’esperienza di laboratorio.
Da molti anni sono uno sviluppatore di software, principalmente nel firmware e ancora oggi mi piace molto lavorare su microcontrollori in C o assembly. Considero questo tipo di attività come il "vero" lavoro di programmatore. Nella mia carriera ho usato quasi tutto, linguaggi di scripting, assembly (da 6502 a Z80 a MPC860 a 68000, passando tramite PIC, AVR, MSP430, ST6 e altri microcontrollori), C, C ++, C #, java, Pascal, Python, Fortran, Cobol e chi si ricorda cos’altro, ho lavorato da piccole schede con microcontrollori a mainframe e applicazioni multi server.
Ma ancora oggi è solo quando sto usando C su una piattaforma embedded che mi sento bene e, soprattutto, mi sento di fare qualcosa di reale, un vero lavoro. Spesso penso al "perché" ho finito per amare così tanto da sviluppare il firmware, e forse c'è un aneddoto che può spiegarlo. Ero alle scuole superiori, specialità informatica, 1980, Italia; stavamo imparando come sviluppare software in assembly per un HP 2000A ed era il mio primo programma.
Non ricordo i dettagli, il programma era solo un esercizio, scrivere qualcosa in una posizione di memoria per poi recuperarla. Davvero qualcosa di banale, da manuale ma… non funzionava ed ero estremamente frustrato. Tutti i compagni di classe avevano il loro lavoro perfettamente funzionante mentre il mio non funzionava, non partiva nemmeno! Alla fine ho dovuto coinvolgere il professore che, naturalmente, esplorò tutte le possibili cause presumendo avessi fatto qualcosa di veramente stupido per rovinare un codice così semplice.
Giusto per contestualizzare, il programma era davvero breve ed era memorizzato in un piccolo mazzo di schede perforate; sì, le schede perforate, avete letto correttamente. Un programma in assembly su schede perforate. Mi fa sentire piuttosto vecchio ora... comunque, dopo un po' il professore mi guardò e mi disse che il codice era corretto e che avrebbe dovuto funzionare ma.... non era così. A quel punto iniziai con il professore la mia prima vera sessione di debug, coinvolgendo tutto, non solo il codice ma l'intero sistema. Impostammo ed eseguimmo test, cambiando parametri e impostazioni, studiando la documentazione del sistema HP e dopo ore trovammo il problema.
Il mio programma era stato impostato per l'avvio nella posizione 2000B (notazione HP, non ricordo l'effettivo indirizzo di memoria) e in quella specifica posizione un bit della memoria era "rotto". Un bit rotto? Sì, l'HP 2000A aveva la RAM costruita con toroidi, una tecnologia chiamata "Magnetic-core memory" (memoria a nuclei magnetici).
Fondamentalmente ogni byte della memoria era costruito attorno ad alcuni toroidi, ogni toroide era attraversato da 3 fili e poteva memorizzare il bit come stato magnetico; la posizione 2000B aveva una toroide rotto, ergo un bit era rotto! Il mio programma non aveva nessuna possibilità di iniziare! Eseguendo il debug del mio primo programma andando in profondità nell'hardware scoprii che il problema era l'hardware, non il software. Rimasi affascinato dalla scoperta. Iniziai a vedere il computer in un modo diverso rispetto a molte altre persone in quel momento. Comunemente si pensava che il computer fosse una "scatola nera onnipotente", sempre funzionante, sempre corretta e se qualcosa non funzionava era perché il software aveva un errore.
Nel mio caso il problema era l'hardware e non il software e vidi la quantità di conoscenza necessaria per individuare il problema, una conoscenza dell'intero sistema, non solo quella di scrivere solo del codice. Volevo imparare a farlo, volevo essere in grado di progettare sistemi, identificare errori hardware, non solo scrivere codice. Quel giorno nacqui come The Firmware Guy, qualcuno che scrive software senza mai presumere che l'hardware rispetti le tue aspettative o, ancora meglio, progettando l'hardware che esegue il software che progetto; qualcuno che deve sapere non solo come codificare ma conoscere anche l'hardware su cui è in esecuzione il codice, il sistema operativo, le periferiche, tutto.
Da quel giorno ho amato trattare con "sistemi hardware / software". Mi piace ancora progettare hardware e non solo software e mi piace sempre scrivere software sapendo in dettaglio l'hardware in cui il software deve girare e se qualcosa non funziona come previsto, non assumendo mai che il problema sia solo il codice. Il problema potrebbe essere l'hardware, potrebbe essere il compilatore o il sistema operativo o un bug in una periferica.
L'essenza dello sviluppo firmware.
Stefano R. Bodini
Come possiamo notare dopo la lettura di questo articolo le nostre esperienze in laboratorio sono molto diverse da quello che si faceva nel 1980. Come prima cosa nessuno di noi saprebbe programmare su una scheda perforata, ai giorni d’oggi siamo muniti di moltissimi IDE che ci permettono di comunicare con la macchina in tantissimi linguaggi di programmazione, non ci capiterà mai di programmare direttamente sull’hardware. La cosa che si avvicina di più all’accaduto è la progettazione di piccoli circuiti elettronici in telecomunicazioni, nella quale analizziamo componenti dell’elettronica digitale e analogica. Possiamo dire che non abbiamo più una manualità così elevata come un tempo; le esperienze di informatica di oggi si limitano a farci creare programmi senza andare ad indagare cosa accade realmente nell' hardware.
Federico Danda