La Raspberry Pi Pico se démarque des productions habituelles de la fondation. En effet, cette petite carte s’inscrit dans la même catégorie que nos Arduino. Notamment, elle n’est pas conçue pour fonctionner avec Linux. En ce qui concerne le format, elle se rapproche d’un Arduino Nano. Elle possède une largeur légèrement supérieure (21mm au lieu de 18mm) et également une longueur un peu plus importante (51mm au lieu de 45mm). La figure 1 ci dessous montre la carte recto et verso.

Figure 1 : La Raspberry Pi Pico.

En ce qui concerne le prix, on trouve la Pico en France, chez Kubii par exemple, pour à peine plus de 4€ alors qu’un clone chinois d’Arduino Nano est aujourd’hui à environ 7€, voire plus. On est donc dans le même format de carte que l’Arduino Nano, pour un prix plus faible qu’un clone et pour une qualité de fabrication meilleure ! La figure 2 montre la différence de taille entre l’Arduino Nano et la Raspberry Pi Pico. Notez également que la carte est livrée sans broches soudées, il faudra donc sortir le fer pour la placer sur une breadboard.

Figure 2 : Comparaison Arduino Nano et Raspberry Pi Pico

Les caractéristiques de la Raspberry Pi Pico

Le micro-contrôleur

Le micro-contrôleur embarqué sur la carte, le RP2040, est également une création de la fondation Raspberry Pi et est disponible séparément. Ce micro-contrôleur intègre 2 cœurs de calcul ARM Cortex M0+ fonctionnant à 133MHz [1] et possède 264ko de RAM ainsi que les périphériques suivants :

• 2 interfaces série (UART) ;
• 2 interfaces SPI ;
• 2 interfaces I²C ;
• 16 canaux PWM 16 bits ;
• 1 contrôleur USB ;
• 8 machines à état PIO (nous verrons plus loin de quoi il s’agit) ;
• 4 canaux ADC 12 bits dont l’un est utilisé pour le capteur de température interne ;
• 1 timer 64 bits auquel sont adjointes 4 alarmes 32 bits ;
• 30 broches d’entrées sorties ;

Un DMA [2] est également disponible.

En revanche il ne contient pas de mémoire flash pour le stockage du programme, ni d’EEPROM, et une mémoire flash externe doit être adjointe pour stocker le programme. Le RP2040 accède à cette flash externe via une interface SPI quadruple dédiée.

Mon regret est l’absence de bus CAN. Il faudra, le cas échéant, ajouter un MCP2515.

Côté capacité électrique, on est en deçà des AVR (voir à ce propos Que peut-on alimenter avec un Arduino). En effet, la somme des courants fournis par les sorties ne doit pas dépasser 50mA et la somme des courants drainés ne doit, également, pas dépasser 50mA. Ceci est à comparer aux 200 mA de l’AVR 328P qui équipe l’Arduino Nano. De même, alors que pour l’Arduino Nano, nous avons 20 mA par broche autorisé, pour le Pico, 12 mA est un maximum. On constate d’ailleurs que le courant des amplificateurs de sortie est réglable : 2mA, 4mA, 8mA et 12mA sont possibles. En réglant à 12 mA et en fournissant 10mA, la tension de sortie s’établit à 3,1V. En drainant 10mA, la tension de sortie s’établit à 0,15V.

Par conséquent, pour piloter un grand nombre de LED, il faudra passer par une amplification, par exemple avec un ULN.
Ce micro-contrôleur étant disponible séparément, une multitude de cartes l’utilisant est apparue. Nous n’allons pas les lister et nous concentrer sur la carte proposée par la Fondation Raspberry Pi.

La Raspberry Pi Pico

La Raspberry Pi Pico comprend donc un micro-contrôler RP2040 équipé d’un quartz 12MHz, dont la fréquence est multipliée en interne, un régulateur de tension buck-boost [3] 3,3V, une flash externe de 2Mo, une LED et une prise micro-USB. La petite carte possède 2 rangées de 20 broches, sur lesquelles sont disponibles les alimentations et les entrées/sorties, plus 3 broches pour connecter un debugger (voir figure 3).

Figure 3 : Brochage de la Raspberry Pi Pico.

On constate que les positionnements des interfaces série, des SPI ou des I2C sont programmables. Ces 3 bus ont une allocation par défaut (GP0 et 1 pour l’UART, GP16 à 19 pour le SPI et GP4 et 5 pour l’I2C) mais peuvent être déplacés ailleurs au besoin. Sur les 30 broches du GPIO (General Purpose I/O), 4 ne sont pas disponible en sortie de la carte, ce qui laisse tout de même 26 broches à l’utilisateur.

On note la présence de 3 broches colorées en rouge : VBUS, VSYS et 3V3(OUT), et de 2 broches colorées en rose : 3V3_EN et RUN.

• VBUS est la tension venant de l’ordinateur hôte via l’USB. Donc normalement 5V ;
• VSYS est la tension d’entrée du régulateur, de 1,8V à 5,5V. VSYS reçoit VBUS via une diode Schottky. Pour alimenter en même temps le Pico via l’USB et une alimentation séparée, il faudra ajouter un peu d’électronique. C’est indiqué à la section 4.5, pages 19 à 21 de la documentation ;
• 3V3(OUT) est, comme son nom l’indique, la sortie 3,3V du régulateur. Elle peut être utilisée pour alimenter de l’électronique extérieure dans les limites du raisonnable ;
• 3V3_EN est une entrée du régulateur qui peut, en tirant ce signal à 0, être coupé ;
• RUN est tout simplement le RESET. Il est tiré à l’état haut par une résistance interne du micro-contrôleur. Pour faire un reset du Pico, il suffit de tirer cette entrée à 0.

Le régulateur en lui même fournit jusqu’à 800 mA, c’est à dire presque autant que le régulateur linéaire qui équipe l’Arduino Nano. Toutefois, comme il ne s’agit pas d’un régulateur linéaire mais d’un régulateur à découpage, il a un bien meilleur rendement, environ 90%. Par conséquent il y a fort à parier, qu’en pratique, il soit capable de délivrer plus de courant sans chauffer que le régulateur linéaire d’un Arduino Nano.

Le support Arduino

Le portage du logiciel Arduino sur Raspberry Pi Pico nous est offert par un citoyen états-unien, Earle F. Philhower, III, que je remercie chaleureusement au passage, comme tout ceux qui contribuent à l’Arduino. Le développement est très actif puisque Earl publie une mise à jour tous les 10 jours environ. Le support est classique : on ouvre les préférences de l’IDE, on clique sur l’icône de fenêtre à droite du champ intitulé « URL de gestionnaire de cartes supplémentaires » et on ajoute dans la liste, l’URL suivante :

https://github.com/earlephilhower/arduino-pico/releases/download/global/package_rp2040_index.json

Après avoir validé, on déroule le menu « Outils », on va sur « Type de carte » puis on sélectionne le sous-item « Gestionnaire de carte ». Dans la case de recherche, on tape « pico ». 3 items s’affichent, le bon est celui intitulé « Raspberry Pi Pico/RP2040 », le nom de l’auteur susnommé est affiché juste en dessous.

Il est temps d’essayer de téléverser Blink.

Le processus défini par la Fondation Raspberry Pi pour téléverser un programme dans la mémoire flash de la Raspberry Pi Pico n’est pas celui qui prévaut avec l’IDE Arduino. Ici, lorsque l’on branche la Pico sur l’USB, aucun port série n’apparaît dans le menu de l’IDE. En revanche, la Pico s’identifie comme un disque USB. Le téléversement consiste donc à déposer le fichier exécutable dans un format ad-hoc sur ce disque et le Pico le copie ensuite dans la flash. Bien évidemment, c’est l’IDE qui va se charger de cette copie. Il reste que disposer d’un connexion série permet à l’IDE d’effectuer un reset.

Pour le premier téléversement, l’opération est particulière. Il faut brancher le Raspberry Pi Pico sur l’USB en maintenant le bouton poussoir blanc de la carte enfoncé puis relâcher le bouton. Aucun port n’apparaît encore mais le téléversement est possible comme en atteste la capture d’écran de la figure 4 et Blink fonctionne. Une fois qu’une sketch a été téléversé, l’infrastructure logicielle qui y est incluse fait apparaître un port série dans le menu de l’IDE. À partir de là, il ne sera plus nécessaire de maintenir le bouton enfoncé quand on connecte la Pico à l’USB et le comportement sera conforme à l’habitude.

Figure 4 : Téléversement de {Blink} sur la Pico

Quelques essais

Servomoteur

Pour motoriser mes signaux mécaniques, j’ai acheté des servos ultra-micro chez Hobbyking. Il s’agit de ce modèle. Conçus pour les modèles réduits d’avions ultra-légers, ils possèdent des dimensions très réduites : 13 x 20 x 6mm et une masse de 1,9g seulement. Le moteur étant très petit, la tension d’alimentation doit être comprise entre 2,8V et 4,2V. C’est l’occasion de tester avec l’alimentation 3,3V du Pico. L’exemple utilisé est Sweep qui est disponible dans le menu « Exemples > Servo(rp2040) ». Il compile avec succès et fonctionne de manière satisfaisante comme en atteste la vidéo ci-dessous.

Contrôleur CAN MCP2515 et bibliothèque ACAN

Cette bibliothèque et ce composant ont été présentés dans « La bibliothèque ACAN (1) ». Le branchement se fait, par exemple, sur les broches par défaut du SPI0. À noter que le Chip Select (CS) peut être géré automatiquement par le matériel au lieu de l’abaisser et de le remonter à coups de digitalWrite. Toutefois, si la bibliothèque SPI du Pico permet de choisir si le CS est géré automatiquement ou à la main, ce n’est pas pris en compte par ACAN2515 qui effectue une gestion manuelle. Le sketch d’essai est LoopBackDemo dans les exemples de ACAN2515. La broche du CS est changée en 17. L’interruption est laissée sur 3, sachant que chaque broche numérique peut servir d’entrée d’interruption externe sur le Pico. Ici aussi le test est un succès.

Figure 5 : Essai du Raspberry PI Pico avec le module CAN Locoduino

Deux caractéristiques originales

Le microcontrôleur RP2040 présente au moins deux caractéristiques originales que nous allons évoquer.

L’exécution parallèle

La première est de disposer de deux cœurs de calcul. Par défaut, le cœur 1 n’est pas démarré et le code tournera sur le cœur 0. Mais Earle a prévu de pouvoir utiliser les deux cœurs et donc d’exécuter deux programmes en parallèle. Pour cela, il suffit de définir deux fonctions, setup1 et loop1 qui s’exécuteront sur le cœur 1 tandis que setup et loop s’exécutent sur le cœur 0.

Il est également possible, a partir d’un cœur, de suspendre l’exécution de l’autre cœur en utilisant la fonction rp2040.idleOtherCore() et de la reprendre avec rp2040.resumeOtherCore(). Notez que suspendre trop longtemps le cœur 0 peut causer le gel de l’USB car c’est le cœur 0 qui sert les interruptions de l’USB.

Enfin, des fonctions permettent la communication entre les deux cœurs via une file d’attente bloquante : rp2040.fifo.push (bloque si la file est pleine), et rp2040.fifo.pop (bloque si la file est vide) ou non bloquante rp2040.fifo.push_nb (retourne false si la file est pleine, true si l’écriture est un succès), et rp2040.fifo.pop_nb (retourne false si la file est vide, true si la lecture est un succès. De plus, rp2040.fifo.available retourne le nombre d’éléments dans la file.

Pour l’instant, il n’y a pas de fonctions de gestion de sémaphores, par exemple, pour permettre la mise en œuvre de sections critiques. Pour plus d’informations, voir la documentation en ligne.

Les PIO (Programmable Input Output)

Le RP2040 dispose de 2 PIO comprenant chacun 4 machines à états programmables pour un total de 8. On peut voir ces machines à états comme des processeurs très simples qui interagissent avec les interruptions et les entrées/sortie. On peut donc écrire un programme pour chacun de ces processeurs.

C’est bien évidemment technique, ça nécessite de programmer dans un assembleur comprenant 9 instructions. Je ne vais pas entrer plus dans les détails mais ces PIO permettent d’écrire des programmes, certes rudimentaires (32 instructions, en tout, pour les 4 machines à état d’un PIO), mais qui s’exécutent en parallèles des cœurs Cortex M0+. Ceci permet de respecter des timings extrêmement fins pour, par exemple, mettre en œuvre des interfaces dont le micro-contrôleur ne dispose pas nativement, ou bien des détections de séquences de signaux sophistiquées.

Par exemple, la bibliothèque Servo sur la Pico utilisent les PIO (on peut donc connecter 8 servos). Par conséquent, la génération de l’impulsion de commande n’est jamais perturbées par les interruptions du micro-contrôleur.

Les performances

Pour évaluer les performances relatives à celles de l’Arduino Nano, j’ai utilisé, comme je l’avais fait pour les cartes Teensy, l’Arduino Speed Test Benchmarking Program. Je ne vais pas faire un compte rendu détaillé sous forme de graphique. Il faut retenir que les performances se situent, à 125MHz, entre la Teensy 3.2 overclockée à 72 MHz et la Teensy 3.6 à 180MHz, ce qui n’est pas inattendu. L’Arduino Nano est donc battu dans toutes les catégories avec des gains allant d’un facteur 3 à un facteur 173 !

En ce qui concerne la mémoire disponible, on a également un avantage certain puisque le Pico dispose de 132 fois plus de mémoire SRAM et de 64 fois plus de mémoire Flash pour le programme. À titre d’exemple j’ai compilé quelques programmes pour Arduino Nano et pour Raspberry Pi Pico afin de voir comment les empreintes mémoire augmentent avec la taille du sketch.

Concernant la taille de flash nécessaire, on constate sur les exemples testés que le passage d’un sketch vide à Blink nécessite 480 octets sur le Nano et 680 octets sur le Pico. Pour RightLeft on a respectivement 5570 et 6232 et pour Arduino_Speed_tests 20266 et 13344 (les calculs sur des nombres flottants et des nombres 32 bits nécessitent plus d’instructions sur un AVR que sur un ARM). On voit que, hormis le ticket d’entrée du sketch vide, les occupations mémoire programme se valent et que les 2Mo de flash ne seront pas sacrifiées par des instructions machines plus gourmandes en taille. Concernant la taille de SRAM, Blink nécessite 0 octets supplémentaires pour le Nano et 28 pour le Pico, RightLeft nécessite 443 octets sur le Nano et 744 sur le Pico et Arduino_Speed_tests, 229 et 56 respectivement. Ici aussi on est dans les mêmes ordres de grandeur.

Conclusion

Difficile de trouver des défauts à cette carte étant donné son prix, inférieur à celui d’un clone de Nano, comparable à celui d’un clone de Pro Mini, alors que la qualité de la fabrication est supérieure. Ses performances sont, de plus, supérieures en tous points. Sur les tests effectués, le fonctionnement est très satisfaisant.