Raspberry Pi RP2040 : mains

La sortie de la carte Raspberry Pi Pico de la Raspberry Pi Foundation avec le microcontrôleur RP2040 a fait de grandes vagues ces derniers mois dans la communauté des créateurs. Beaucoup ont démontré comment les deux périphériques de machine d'état d'E/S programmables (PIO) peuvent être utilisés pour créer des générateurs vidéo DVI et d'autres périphériques numériques.

Parallèlement à cet enthousiasme, cela soulève la question de savoir si tout cela entraînera un bouleversement majeur pour ceux d'entre nous qui utilisent STM32, SAM et d'autres MCU basés sur Cortex-M. Le RP2040 serait-il peut-être une option valable pour certains de nos projets ? Le RP2040 étant un MCU à double processeur Cortex-M0+, il semble juste de le comparer aux offres de l'un des poids lourds actuels de l'espace MCU ARM 32 bits : ST Microelectronics.

Le pipsqueak de la Fondation Raspberry Pi a-t-il réussi à montrer aux ingénieurs de ST comment procéder, ou les premiers devraient-ils revoir certaines de leurs hypothèses ? Et à quel point sera-t-il difficile de porter du code de bas niveau de STM32 vers RP2040 ?

Pour faire court, après que le RP2040 ait attiré mon attention, j'ai pensé qu'il pourrait être intéressant d'essayer de porter mon framework STM32 basé sur C++ sur ce nouveau MCU. Pas tellement pour les doubles cœurs Cortex-M0+, cependant, car j'ai des MCU double cœur STM32H7 (M4 et M7) qui battront facilement le bourrage d'un RP2040 avec plus d'E/S à revendre. Ce qui m'a le plus intrigué, c'est ce périphérique de machine d'état (PIO) du RP2040 qui semblait mériter un examen plus approfondi.

Sur la base de mon expérience avec STM32, j'ai pensé que je pourrais rapidement porter certains fichiers, créer une nouvelle branche d'architecture « RP » dans le projet et me lancer dans la course. Cortex-M est Cortex-M, n'est-ce pas ? La procédure habituelle avec un nouveau MCU basé sur ARM consiste à obtenir les fiches techniques, le manuel de référence et les fichiers du périphérique CMSIS. Après cela, on peut facilement adapter le code de bas niveau pour utiliser la nouvelle disposition de dénomination et de registre des périphériques, tandis que les périphériques de niveau principal (SysTick, NVIC, etc.) restent les mêmes.

Peut-être naïvement, j'avais passé commande d'une carte Raspberry Pi Pico avant même de vérifier la prise en charge CMSIS ou de jeter un coup d'œil au manuel de référence. À ma grande surprise, j'ai découvert que la prise en charge de CMSIS ou même l'interopérabilité avec le reste de l'écosystème Cortex-M n'étaient pas encore sur le radar. Néanmoins, le fichier SVD pour le MCU RP2040 est fourni dans le « Pico SDK », qui peut être utilisé pour générer l'en-tête du périphérique. Grâce aux efforts de Chris Hockuba pour amorcer CMSIS avec le RP2040, j'ai finalement trouvé une solution fonctionnelle ensemble.

Avec un projet STM32, quelques éléments sont requis pour faire fonctionner un projet sans système d'exploitation sur un MCU cible. Ceux-ci incluent le code de démarrage qui effectue une configuration de base de l'environnement ainsi que la table vectorielle pour les gestionnaires d'interruptions. Il existe également le script de liaison pour garantir que tous les bits se retrouvent au bon décalage de mémoire. Tout cela est assez minime, le MCU chargeant au démarrage l'image du micrologiciel à partir de la ROM Flash à l'adresse par défaut.

Le premier obstacle avec le RP2040 est de comprendre son processus de chargeur de démarrage en chaîne. Tout comme les disquettes amorçables d'autrefois ou un disque dur/SSD dans un PC, la ROM Flash QSPI externe est traitée essentiellement comme un périphérique de démarrage potentiel par le MCU. Le chargeur de démarrage de première étape est intégré au MCU dans la ROM de démarrage, adresse 0x0000 0000, qui au démarrage vérifie l'interface QSPI pour essayer d'en charger 256 octets. Celui-ci sera vérifié pour une correspondance de hachage CRC32 valide et considéré comme étant le chargeur de démarrage de deuxième étape s'il correspond.

Il y a beaucoup de choses que ce chargeur de démarrage de deuxième étape pourrait faire et certaines sont nécessaires. Qu'il suffise de dire pour l'instant que comparé à certains clones STM32 célèbres – tels que les clones GigaDevices I-can't-believe-it-not-a-genuine-STM32 – qui utilisent également des ROM SPI, tout ce processus avec le RP2040 est pas aussi intuitif, bien documenté ou transparent qu’il pourrait l’être, avec de nombreuses pierres d’achoppement.

Il m'a fallu pas mal de recherches dans la fiche technique du RP2040 et de questions pour comprendre comment le gestionnaire d'horloge périphérique du STM32 correspond à l'architecture du système RP2040. Il s'avère que la version du RP2040 s'appelle RESETS et fonctionne essentiellement à l'envers : vous devez désactiver la condition de réinitialisation sur un bloc pour activer l'horloge correspondante. Pour activer l'horloge GPIO, vous devez basculer le bit 8 dans RESETS_RESET (PADS_BANK0).