Raspberry Pi RP2040: mani

Il rilascio della scheda Raspberry Pi Pico della Raspberry Pi Foundation con microcontrollore RP2040 ha suscitato grande scalpore negli ultimi mesi nella comunità dei maker. Molti hanno dimostrato come, soprattutto, le due periferiche della macchina a stati I/O programmabile (PIO) possano essere utilizzate per creare generatori video DVI e altre periferiche digitali.

Oltre a questa eccitazione, solleva la questione se tutto ciò causerà grossi sconvolgimenti per quelli di noi che utilizzano STM32, SAM e altri MCU basati su Cortex-M. L’RP2040 potrebbe forse essere un’opzione valida per alcuni dei nostri progetti? Dato che l'RP2040 è un MCU con doppio processore Cortex-M0+, sembra giusto confrontarsi con le offerte di uno degli attuali pesi massimi nello spazio MCU ARM a 32 bit: ST Microelectronics.

Il pipsqueak della Raspberry Pi Foundation è riuscito a mostrare agli ingegneri della ST come si fa, o i primi dovrebbero rivedere alcune delle loro ipotesi? E quanto sarà difficile trasferire il codice di basso livello da STM32 a RP2040?

Per farla breve, dopo che l'RP2040 ha attirato la mia attenzione, ho pensato che sarebbe stato interessante provare a trasferire il mio framework STM32 basato su C++ su questo nuovo MCU. Non tanto per i doppi core Cortex-M0+, però, dato che ho in giro MCU dual-core STM32H7 (M4 e M7) che batteranno facilmente l'imbottitura di un RP2040 con più I/O da risparmiare. Ciò che più mi ha incuriosito è stata questa periferica della macchina a stati (PIO) nell'RP2040 che sembrava degna di uno sguardo più attento.

Sulla base della mia esperienza con STM32, ho pensato che avrei potuto trasferire rapidamente alcuni file, creare un nuovo ramo dell'architettura "RP" nel progetto e partire per le gare. Cortex-M è Cortex-M, giusto? La procedura abituale con un nuovo MCU basato su ARM consiste nell'ottenere le schede tecniche, il manuale di riferimento e i file del dispositivo CMSIS. Successivamente è possibile adattare facilmente il codice di basso livello per utilizzare la nuova denominazione delle periferiche e il layout dei registri, mentre i dispositivi di livello core (SysTick, NVIC, ecc.) rimangono gli stessi.

Forse ingenuamente, avevo effettuato un ordine per una scheda Raspberry Pi Pico prima ancora di verificare il supporto CMSIS o di dare un'occhiata al manuale di riferimento. Con mia sorpresa, ho scoperto che il supporto CMSIS o addirittura l’interoperabilità con il resto dell’ecosistema Cortex-M non erano ancora sul radar. Tuttavia, il file SVD per l'MCU RP2040 è fornito nel "Pico SDK", che può essere utilizzato per generare l'intestazione del dispositivo. Per gentile concessione degli sforzi di Chris Hockuba nel bootstrap di CMSIS con l'RP2040, alla fine ho trovato una soluzione funzionante insieme.

Con un progetto STM32, sono necessari alcuni elementi per far funzionare un progetto bare metal su un MCU di destinazione. Questi includono il codice di avvio che esegue alcune impostazioni di base dell'ambiente nonché la tabella vettoriale per i gestori di interrupt. C'è anche lo script del linker per garantire che tutti i bit finiscano nel giusto offset di memoria. Tutto questo è abbastanza minimo, con l'MCU all'avvio che carica l'immagine del firmware dalla Flash ROM all'indirizzo predefinito.

Il primo ostacolo con l'RP2040 è comprendere il suo processo di bootloader concatenato. Proprio come accadeva con i floppy disk avviabili di un tempo o con un HDD/SSD in un PC, la Flash ROM QSPI esterna viene trattata essenzialmente come un potenziale dispositivo di avvio dall'MCU. Il bootloader di prima fase è integrato nell'MCU nella ROM di avvio, indirizzo 0x0000 0000, che all'avvio controlla l'interfaccia QSPI per provare a caricare 256 byte da essa. Verrà verificata la presenza di una corrispondenza hash CRC32 valida e, se corrisponde, si presuppone che sia il bootloader di seconda fase.

Ci sono molte cose che questo bootloader di seconda fase potrebbe fare e alcune sono necessarie. Basti dire per ora che rispetto ad alcuni famosi cloni STM32 - come i cloni GigaDevices Non posso credere che non sia un vero e proprio STM32 - che utilizzano anche ROM SPI, l'intero processo con l'RP2040 è non così intuitivo, ben documentato o trasparente come potrebbe essere, con molti ostacoli.

Mi ci è voluto un bel po' di scavare nel datasheet dell'RP2040 e chiedere in giro per capire come il gestore dell'orologio periferico in STM32 si associa all'architettura del sistema RP2040. A quanto pare, la versione dell'RP2040 si chiama RESETS e funziona sostanzialmente al contrario: è necessario disattivare la condizione di ripristino su un blocco per abilitarne l'orologio. Per abilitare l'orologio GPIO, è necessario attivare/disattivare il bit 8 in RESETS_RESET (PADS_BANK0).