Questo topic prosegue il discorso iniziato qui. Abbiamo la nostra amata PCB "morta" oppure abbiamo a che fare con una MCU in cui il bootloader non è (ancora) installato. Sappiamo che ci sono diversi ISP programmer che possiamo usare: ma quale scegliere? A volte abbiamo sotto agli occhi tutto quello che ci può servire... e spesso non ce ne accorgiamo. Qui di seguito vedremo come utilizzare un Arduino Uno al nostro scopo. Questa piccola board infatti è un po' come un piccolo coltellino multiuso e può essere utilizzata per eseguire diversi compiti compreso quello di comportarsi come un ISP programmer. Avremo quindi bisogno di: un Arduino Uno una breadboard pin di collegamento di varia lunghezza 3 LED di colori diversi (opzionali) 3 resistenze da 220 Ohm (opzionali) [image: 1677435098175-kbpedia_arduino_uno.jpg] Il processo che seguiremo è molto semplice: Arduino verrà programmato per comportarsi come un ISP programmer, nello specifico un AVRISP - ovvero una sorta di clone di un programmer, ora fuori commercio, distribuito direttamente da Atmel fino a qualche anno fa. Collegheremo Arduino con una breadboard dove sarà posizionata la nostra MCU - nel mio caso un ATmega32A. [image: 1677435566272-kbpedia_arduino_uno_isp.jpg] La programmazione di Arduino è banale, basta richiamare uno sketch già pronto negli esempi: File » Examples » 11.ArduinoISP » ArduinoISP Lo sketch è ben commentato e per chi volesse ne consiglio un'attenta lettura. Arduino ha già un'interfaccia ISP - proprio vicino al suo ATmega328P - ma nel nostro caso utilizzeremo dei PIN specifici: 10 - RST (giallo) 11 - MOSI (verde) 12 - MISO (arancione) 13 - SCK (blu) [image: 1677436140514-kbpedia_arduino_uno_isp_pin.jpg] Per avere dei feedback durante l'utilizzo di Arduino come ISP è possibile utilizzare anche dei LED, così collegati: 7 - programmazione (verde): lampeggia quando vengono trasferiti dati 8 - errore (rosso): si accende quando ci sono errori 9 - heartbeat (blu): segnala il funzionamento del programmer Nel mio esempio ho utilizzato dei banali LED da 5 mm con delle resistenze di sicurezza pari a 220 Ohm. I LED sono assolutamente opzionali: il sistema funziona anche senza. [image: 1677438703902-kbpedia_arduino_uno_isp_pin2.jpg] Tornando alla programmazione dello sketch: con un Arduino Uno non c'é bisogno di fare alcuna modifica ma per sicurezza è meglio togliere il commento alla riga 81 che diventa quindi: #define USE_OLD_STYLE_WIRING La define USE_OLD_STYLE_WIRING serve infatti per dichiarare i PIN 11, 12 e 13 e il loro utilizzo. Nel codice volendo possono essere modificate altre define e customizzare così i PIN utilizzati: #define PIN_MOSI 11 #define PIN_MISO 12 #define PIN_SCK 13 #define RESET 4 #define LED_HB 7 #define LED_ERR 6 #define LED_PMODE 5 Prendiamo infine nota del clock della seriale che viene impostato a 19200 alla riga 142: #define BAUDRATE 19200 A questo punto siamo pronti per verificare il codice - lo sketch è già rilasciato perfettamente funzionante quindi non dobbiamo aspettarci delle sorprese - e caricarlo su Arduino: se abbiamo utilizzato i LED quello di hearbeat (nel mio caso quello blu) dovrebbe iniziare a lampeggiare lentamente, segnalando che la board è pronta per ricevere comandi. È quindi arrivato il momento di fare i collegamenti verso la MCU. È sufficiente recuperare il datasheet relativo per controllare la posizione dei PIN: [image: 1677437354439-kbpedia_atmega32a_pin.jpg] I PIN che ci interessano sono: 6 - MOSI - da collegare al PIN 11 di Arduino con il cavo verde 7 - MISO - da collegare al PIN 12 di Arduino con il cavo arancione 8 - SCK - da collegare al PIN 13 di Arduino con il cavo blu 9 - RST - da collegare al PIN 10 di Arduino con il cavo giallo 10 - VCC - da collegare alla +5V di Arduino con il cavo rosso 11 - GND - da collegare al GND di Arduino con il cavo nero [image: 1677437689292-kbpedia_atmega32a_spi.jpg] Fatti i collegamenti è tutto pronto: è possibile utilizzare il programma avrdude per testare la corretta comunicazione con la nostra MCU. Possiamo quindi lanciare il comando: avrdude -c avrisp -p m32a -P /dev/ttyACM0 -b 19200 Facciamo però attenzione ai parametri che utilizziamo: -c indica il tipo di programmer che stiamo utilizzando, nel nostro caso un Arduino programmato per comportarsi come un AVRISP -p indica la MCU che vogliamo programmare, nel mio esempio una ATmega32A -P indica la porta seriale a cui è collegato il nostro Arduino -b indica la velocità di trasmissione seriale e deve essere allineata con quanto indicato nello sketch caricato su Arduino In caso di corretta comunicazione dovremmo avere un output simile a questo: ~$ avrdude -c avrisp -p m32a -P /dev/ttyACM0 -b 19200 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9502 (probably m32a) avrdude done. Thank you. Arrivati a questo punto siamo pronti per programmare la nostra MCU, caricando ad esempio un bootloader. In un prossimo post vedremo come ottenere lo stesso risultato con un programmer dedicato, nel caso specifico USBasp.

Atmel Corporation è un noto produttore di microcontrollori (MCU) fondato nel 1984 e recentemente acquisito da Microchip Technology (2016). È decisamente rilevante per il nostro hobby poiché la serie di microprocessori AVR a 8-bit è praticamente onnipresente sulle PCB delle tastiere meccaniche custom - basti pensare allo ATmega32U4, quasi uno standard de facto. [image: 1661702211148-prove_ikki_aurora_019.jpg] I microprocessori AVR sono generalmente classificati in famiglie e tra queste quella che per noi è sicuramente la più importante prende il nome di «megaAVR», e contrassegna tutti i chip della serie «ATmega». Gli ATmega sono microcontrollori dotati di una discreta memoria interna (flash, da 4 a 256 KB), ampia gamma di PIN (da 28 a 100) e un set esteso di istruzioni: possono raggiungere i 32 MHz e un massimo di 1 MIPS per MHz. I processori AVR sono disegnati per l'esecuzione efficiente di codice compilato scritto in linguaggio C e il codice viene eseguito direttamente dalla memoria flash interna - e solo da quella. Per programmare il microprocessore viene normalmente utilizzata un' interfaccia dedicata che prende il nome di ISP - In-System Programming - oggi comunemente accessibile tramite interfaccia a 6 PIN: VCC: tensione positiva di alimentazione RST: reset GND: massa MISO: Master Input Slave Output MOSI: Master Output Slave Input SCK: Serial Clock [image: 1676139259201-isp_spi.jpg] Esiste anche una versione a 10 PIN con più linee di massa per aumentare l'isolamento da interferenze. Tale interfaccia è di tipo seriale (SPI - Serial Peripheral Interface) con un clock che coordina trasmissione e ricezione (che possono avvenire in contemporanea, full-duplex), e la loro velocità. [image: 1676140573265-isp_spi_pcb.jpg] Il bus seriale viene utilizzato mediante un apposito hardware, di norma identificato con il termine generico di ISP programmer: sono dispositivi generalmente economici, alcuni costano addirittura una manciata di Euro. Sono progettati per essere collegati al PC per mezzo della classica interfaccia USB e al bus ISP/SPI con i classici 6 PIN: lato PC è necessario avere un software capace di riconoscere via USB il programmer collegato e pilotarlo per accedere all'interfaccia ISP/SPI. [image: 1676140545903-usbasp.jpg] Nel mondo delle tastiere meccaniche custom, come abbiamo già ricordato, moltissime PCB sono equipaggiate con MCU ATmega: nella memoria flash interna viene salvato e poi mandato in esecuzione un firmware appositamente compilato - un esempio fra tutti: QMK - che permette alla tastiera di funzionare correttamente. Tra le operazioni più comuni che un appassionato di tastiere meccaniche si trova a svolgere vi è proprio la modifica della configurazione di QMK (ad esempio per aggiungere/modificare layer), la ricompilazione del firmware e il caricamento di quest'ultimo sulla PCB. Ma quindi si rendere necessario armeggiare con ISP programmer, collegare cavi, ecc.? Per fortuna... no. O quasi mai. Insomma: dipende. Ma andiamo con ordine. Per aiutarci nelle operazioni di aggiornamento firmware, nella memoria flash della MCU è di norma presente un software appositamente studiato per poter esporre via USB un accesso diretto all'interfaccia ISP, permettendo di accedere in scrittura/lettura non solo alla memoria flash ma anche alla EEPROM. Tale programma viene identificato con il termine generico di USB DFU (Device Firmware Update) bootloader e come accade per ogni altro software, ne esistono versioni diverse: la maggior parte dei chip ATmega dotati di interfaccia USB escono dalla fabbrica con a bordo un bootloader preinstallato. Grazie al DFU bootloader le operazioni di aggiornamento firmware sono molto semplici: è sufficiente avere la nostra tastiera collegata al PC tramite cavo USB e nulla di più. Può però capitare in certe circostanze di danneggiare il contenuto della flash interna alla MCU - evento raro, ma possibile - e di trovarsi quindi in uno scenario di brick: il processore non ha più accesso al firmware da caricare ed eseguire, e si trova quindi incapace di eseguire qualunque operazione. Di fatto la nostra tastiera è... morta. In questi casi può tornare utile ricordare quanto abbiamo fin qui riassunto: è possibile utilizzare l'interfaccia ISP/SPI per ri-caricare nella flash della MCU il bootloader, e riutilizzare infine quest'ultimo per scrivere nuovamente il firmware. Per fare questa operazione dovremo dotarci di un ISP programmer e premunirci di effettuare i collegamenti diretti all'interfaccia dedicata a 6 PIN: è di sicuro un'operazione più delicata ed invasiva rispetto al consueto aggiornamento firmware. Si renderà necessario smontare la nostra tastiera ed accedere direttamente alla PCB: come se non bastasse... di norma i PIN di collegamento non sono direttamente esposti e molto probabilmente si renderà necessario saldare un header per permetterne l'accesso. La procedura per utilizzare un ISP programmer è abbastanza semplice... ma può creare qualche antipatico grattacapo, specie quando si è alle prime armi. Non mi ero mai interessato più di tanto a questo mondo finché insieme a @AngryBard non ci si è trovati a sbatterci la testa: nel corso del GB per la Mysterium TKL, infatti, ci siamo trovati ad avere tra le mani delle MCU ATmega32A... senza bootloader. In un prossimo post vedremo come poterne venire a capo, utilizzando strumenti diversi.