Pourquoi je préfère le RP2040
(dgroshev.com)- Le RP2040 de Raspberry Pi est un microcontrôleur destiné à être intégré dans des produits électroniques grand public ; il est peu coûteux et facile à obtenir en stock en grande quantité, ce qui réduit la charge liée au choix du composant au début du développement
- Raspberry Pi se concentre sur un composant unique plutôt que sur de nombreuses variantes, ce qui réduit l’optimisation fine des spécifications, mais permet de centraliser au même endroit questions, exemples, bibliothèques et outils
- Son prix d’environ 70 cents peut être défavorable pour optimiser le coût unitaire dans une production de masse, mais pour des projets comme Late Mate, la réduction des coûts de développement peut représenter un gain plus important
- Avec deux cœurs, 30 GPIO, l’USB, l’UART/SPI/I2C/PWM, davantage de RAM interne et l’absence de flash intégrée, sa configuration ressemble à un compromis suffisant et flexible
- Le PIO et un bootloader en lecture seule, ainsi qu’une conception évitant une protection firmware excessive, font du RP2040 un composant pratique adapté à des usages précis
Un écosystème né d’une stratégie à composant unique
- Le RP2040 est un microcontrôleur conçu par Raspberry Pi ; contrairement aux cartes Raspberry Pi, plus connues, il est destiné à être embarqué dans des produits électroniques grand public
- On trouve chez Mouser un stock immédiatement expédiable de plusieurs dizaines de milliers d’unités, pour un prix d’environ 70 cents
- Les fabricants de microcontrôleurs proposent en général de nombreux produits très proches, avec de légères différences
- Comme les produits physiques ont un coût de fabrication, dans la production de masse, économiser ne serait-ce qu’un centime par composant peut avoir un impact sur la rentabilité
- Cela crée une incitation à choisir un microcontrôleur aux performances juste dimensionnées pour le produit
- Raspberry Pi se concentre en pratique sur un seul composant avec le RP2040
- Cela réduit les options et la possibilité d’ajuster finement les spécifications
- En contrepartie, les questions StackExchange, billets de blog, retours d’expérience, issues GitHub, bibliothèques et outils s’accumulent tous autour du même composant
- Des projets comme Late Mate peuvent économiser davantage sur les coûts de développement que sur le coût des composants, ce qui fait de cette stratégie à composant unique un bon compromis
- La prise en charge de Rust est bonne, avec par exemple les exemples Embassy, et il existe aussi des exemples de firmware pour clavier, drone et robot de football
Un matériel suffisant et la flexibilité du PIO
- La conception du RP2040 relève moins d’une logique de spécifications maximales que d’un compromis généraliste suffisant et flexible
- Il fournit deux cœurs corrects, dont le second peut être utilisé si nécessaire
- Les 30 GPIO correspondent à un niveau moyen
- Il n’a pas de flash intégrée et consacre davantage de budget à la RAM interne, plus difficile à ajouter en externe
- L’ADC est convenable et il propose les périphériques classiques comme l’USB et l’UART/SPI/I2C/PWM
- Parmi les fonctions moins traditionnelles, on trouve le PIO
- PIO signifie Programmable Input/Output ; cela ressemble à deux petits coprocesseurs capables d’exécuter des E/S rapides avec un timing précis sans consommer de temps CPU
- Il est utilisé pour implémenter des protocoles de communication comme DShot ESC
- Pico-PIO-USB implémente une pile USB complète au-dessus du PIO et fournit ainsi un second contrôleur USB au RP2040
- Utilisé avec le DMA, il permet à des pilotes d’affichage de décharger complètement du CPU la communication avec l’écran et le tactile
Un bootloader anti-brick et des compromis côté sécurité
- Le RP2040 a une architecture impossible à briquer
- Il intègre un bootloader en lecture seule
- Il peut être mis à jour en le montant comme un périphérique de stockage de masse USB, puis en copiant le firmware sur ce « stockage »
- Son propre protocole USB simple est utilisé par picotool
- L’idée est qu’il est presque impossible de protéger le firmware contre un attaquant déterminé, et que tenter de le faire ajoute de la complexité ainsi qu’un coût pour l’expérience développeur ; le RP2040 évite donc toute mise en scène sécuritaire excessive
- Ces choix peuvent être vus comme le résultat d’un équilibre pragmatique tenant compte de la niche qu’occupe le RP2040 comme petit composant silicium
1 commentaires
Avis sur Hacker News
Le vrai héros du RP2040, c’est le PIO, qui lui donne des capacités difficiles à égaler pour des puces concurrentes comme l’ESP32.
C’est pour cela qu’on le retrouve un peu partout dans le hacking de consoles. En revanche, pour les usages sur batterie, ce serait bien que la V2 réduise la consommation en mode veille profonde.
La logique numérique vérifiable sur FPGA se passe généralement bien, mais les éléments analogiques sont beaucoup plus difficiles à ajuster finement, ce qui se traduit par une mauvaise consommation, un ADC médiocre, et l’absence de DAC interne ou d’amplificateur opérationnel. Le fait que la puce radio du Pico W soit aussi un composant standard séparé, et non une intégration complète comme sur l’ESP32, relève plutôt de cette logique.
C’est excellent pour implémenter des périphériques très basiques, mais il m’est arrivé plusieurs fois de commencer à construire quelque chose d’un peu plus complexe avant de me rendre compte que c’était trop lent et que l’espace manquait. Avec juste un peu plus de puissance, il pourrait assez facilement remplacer de petits usages de FPGA.
Quand on a besoin de beaucoup d’entrées-sorties, on ne regarde généralement pas l’ESP32. Les points forts de l’ESP32 sont son prix bas et le WiFi intégré. Il existe beaucoup d’autres microcontrôleurs avantageux même face au RP2040, mais la plupart ne visent pas le marché des hobbyistes.
Nous avons utilisé le RP2040 ces dernières années pour les badges électroniques[1] de la conférence de sécurité RVASec, et l’expérience de développement logiciel a été plutôt bonne.
Voici le dépôt GitHub du badge de cette année. Il existe un simulateur de badge uniquement logiciel qui permet de bricoler un peu sans le matériel, mais les fonctions multijoueurs, qui reposent sur la communication infrarouge entre badges, risquent d’être moins amusantes : https://github.com/HackRVA/badge2024
[1] Vidéo du badge 2023 : https://www.youtube.com/watch?v=KWZriUMNpLc
[2] https://rvasec.com/
Dire que « c’est le même microcontrôleur, avec seulement deux révisions de correction de bugs » n’est pas exact.
En réalité, c’est exactement le même microcontrôleur, avec seulement deux options de conditionnement. L’une est une bobine 7 pouces de 500 pièces, l’autre une bobine 13 pouces de 3400 pièces. Il suffit de regarder le « Ordering code » dans la fiche technique : https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
Si vous utilisez le SDK officiel, il n’y a guère besoin de vous soucier de la version. Les bibliothèques standard de haut niveau détectent la révision matérielle à l’exécution et activent ou désactivent les contournements nécessaires.
Le RP2040 a quasiment relancé à lui seul le marché assez niché des contrôleurs personnalisés.
Grâce à gp2040[1], un firmware open source pour gamepads, les gens peuvent acheter des fightsticks et contrôleurs leverless de qualité correcte pour bien moins cher que les produits de marques comme Victrix ou Razer. Comme c’est open source, la communauté des passionnés de contrôleurs fabrique aussi toutes sortes de PCB RP2040 adaptés à divers projets et idées de contrôleurs atypiques.
[1] https://gp2040-ce.info
Je me demande quelle part de tout cela peut vraiment être attribuée directement au RP2040. Des projets comme QMK0 utilisaient déjà depuis longtemps, pour les claviers DIY, une base de code techniquement assez similaire.
À première vue, GP2040 ne semble rien faire qu’un autre microcontrôleur un tant soit peu moderne ne pourrait pas faire. Le RP2040 a clairement été le catalyseur de l’adoption massive de GP2040, mais j’ai l’impression que quelque chose de similaire aurait été possible avec un Pro Micro.
Il ne faut pas oublier PhobGCC non plus. J’en suis le développeur principal, et il existe aussi des successeurs moins spécifiquement orientés GameCube comme ProGCC V3, GC Ultimate et Phizard.
Dire « à lui seul » me semble sous-estimer ce qui existait avant, comme les cartes Brook, par exemple la Zero-Pi[1]. Historiquement, ce n’est pas tout à fait exact.
[1] https://www.brookaccessory.com/detail/53169470/
Si vous pratiquez l’électronique en amateur mais ne voulez pas fabriquer ou concevoir vous-même des cartes en CMS, il existe énormément de cartes RP2040 bon marché et faciles d’accès.
J’ai essayé la Raspberry Pi Pico (5 $), et elle embarque le tout sur une bonne carte avec beaucoup d’entrées-sorties. Pour un peu plus cher, il y a aussi la version W avec WiFi.
Si vous acceptez d’avoir un peu moins d’entrées-sorties, vous pouvez commander une RP-2040 Zero. J’en ai acheté 6 sur AliExpress pour environ 12 $. Il n’y a que 23 broches d’E/S, mais il y a un bouton reset, de l’USB-C, et elle est toute petite (1,5 cm x 2,5 cm).
L’avantage de ces cartes, c’est que les outils de développement Raspberry Pi standards, MicroPython et C++ fonctionnent tels quels, et qu’on peut flasher facilement le firmware en USB.
Je recommande aussi pico ice. La majeure partie du prix de $30 vient de l’UP5K intégré, mais pour les projets embarqués qui nécessitent des opérations à l’échelle de la sous-microseconde, c’est une option relativement abordable qui permet d’utiliser des outils open source.
Je recommande fortement de regarder les différentes cartes de développement alternatives basées sur le RP2040. Le Pi Pico officiel est étonnamment médiocre, et presque toutes les cartes alternatives sont meilleures sur un point ou un autre.
Pas de reset, grand facteur de forme, seulement 2 Mbit de flash, du micro USB en 2024… ça fait un peu daté. Son seul vrai avantage, ou presque, est d’être largement disponible.
J’aime bien les petites cartes RP2040. J’ai réalisé quelques petits projets sur base d’Adafruit QT Py.
J’aimerais qu’il existe une version sans fil. Avec l’ESP32 QT, ça existe, mais en RP2040 je n’en ai pas vu.
Sauf si l’on a des contraintes d’espace vraiment extrêmes, je ne vois pas bien l’intérêt du 2040 Zero. Il a moins de fonctionnalités et coûte plus cher. Le Pico est déjà assez petit.
Cela dit, le Pico a une très bonne compatibilité des broches. Côté ESP, même s’il semble y avoir beaucoup de broches d’E/S, celles reliées à la flash interne, au bootloader, etc. réduisent vite l’ensemble à tout juste assez, si l’on a de la chance. Je me demande aussi pourquoi ces broches sont exposées. L’ESP32-CAM a 10 broches de données, mais en pratique seules 4 sont généralement utilisables.
La raison pour laquelle je suis passé de l’ESP32 au RP2040, c’est que c’était un composant plus stable et mieux documenté.
Ma seule inquiétude actuelle concernant le RP2040, c’est qu’il existe beaucoup de modèles ESP32 avec SPIRAM, alors que les cartes RP2040 avec SPIRAM ne sont pas si faciles à trouver. Honnêtement, l’environnement de développement C du RP2040 est tellement bon qu’on peut bien exploiter la mémoire disponible, mais pour un gros projet MicroPython, la SPIRAM est vraiment un atout majeur. À part ça, tout dans le RP2040 est excellent.
Dario Nieuwenhuis, l’une des personnes clés derrière Embassy, a fait une excellente présentation d’ensemble à RustNL : https://www.youtube.com/watch?v=H7NtzyP9q8E
JLC assemble des cartes RP2040 pour moins de $3 pièce par quantité de 5.
La comparaison revient à comparer des pommes et des pêches. Le RP2040 n’est qu’une puce, tandis que côté ESP32 il existe de nombreuses options avec toutes sortes de périphériques souhaités déjà intégrés.
On peut choisir entre antenne WiFi/Bluetooth, contrôleur de batterie lithium-ion, Ethernet, connecteurs pour écran ou caméra, etc.
Il y a aussi plusieurs choix de CPU, et lorsqu’on alimente le tout avec une pile bouton, le fait de consommer de l’énergie pour un deuxième cœur inutile ou pour le WiFi fait une différence.
Avec la variante C6, Espressif a de nouveau changé d’ISA, en passant du 8266 à l’ESP32 puis à une ISA basée sur RISC-V.
Au final, on compare un SoC de première génération à une lignée de SBC vieille de 10 ans.
Vous semblez confondre l’ESP32 devkit et l’ESP32 lui-même. Ce qui possède une antenne, un contrôleur de batterie ou n’importe quel connecteur est un devkit, ou au moins un module. L’ESP32 lui-même est un petit CI, comme le RP2040.
Par exemple, vous pensez sans doute à ce genre de devkit : https://docs.espressif.com/projects/esp-idf/en/latest/esp32s...
Cette carte elle-même repose aussi sur un module comme l’ESP32-S3-WROOM-1, et ce module regroupe le CI ESP32-S3 avec des éléments pratiques comme une antenne WiFi ou un connecteur.
L’équivalent côté RP2040 est le Raspberry Pi Pico, qui dispose aussi de petites commodités comme une variante WiFi. Il existe également des produits qui l’intègrent avec d’autres périphériques.
Ni le RP2040 ni la série ESP32 ne sont des SBC, et aucun des deux ne s’inscrit dans une lignée de SBC. Les SBC Raspberry Pi ont tous été basés sur Broadcom, tandis que le RP2040 est un CI nouvellement développé par Raspberry Pi et, à ma connaissance, il n’utilise pas non plus d’IP sous licence Broadcom.
Techniquement, c’est juste, mais le cœur du sujet est plutôt l’usage. Le RP2040 est vraiment un cas à part, et il est soudain devenu un excellent choix pour beaucoup de projets, non seulement pour les loisirs et l’éducation, mais aussi pour des appareils embarqués professionnels.
Vu ses possibilités pour le prix, une seule version de la puce couvre énormément de domaines. Pour moi, c’est ça, le progrès technologique.
Il est plus sûr de considérer que l’on parle dans les deux cas de la puce elle-même. Les deux peuvent être connectées à un chargeur de batterie, une caméra ou un réacteur nucléaire, mais ces périphériques n’ont absolument rien à voir avec cette comparaison.
Je me demande s’il existe une alternative non chinoise comparable à l’ESP en matière d’intégration de modules comme le WiFi. Même si cela coûte plus cher, ça m’irait.
J’ai des sentiments mitigés à propos du RP2040.
D’un côté, c’est une excellente puce pour les hobbyistes. Elle est bon marché, facile à trouver, simple à intégrer dans une carte, et fournit suffisamment de choses pour une application moyenne.
De l’autre, d’un point de vue professionnel, elle reste clairement un peu limitée. Les périphériques sont corrects, mais dès qu’on entre dans les détails, on se heurte facilement à des contraintes. L’interface XIP est excellente, mais elle ne prend pas en charge l’écriture, donc impossible d’ajouter une puce FRAM pour étendre la mémoire. L’interface PIO est remarquable, mais lorsqu’on veut implémenter des interfaces plus complexes, la limite de 2x32 instructions devient assez importante. Où sont les Timer/Counter ? Pas de tactile capacitif ? Seulement quatre broches analogiques ? Pas d’entrées tolérantes au 5 V ? Pourquoi n’y a-t-il pas d’entrée d’horloge rapide pour les modules PIO ? Pourquoi ne peut-on pas exécuter le bootloader avec l’oscillateur en anneau interne ? J’aurais aussi aimé avoir un PHY USB-C.
Les mauvaises performances ESD m’ont aussi surpris. Les Atmega ou STM32 supportent généralement quelques décharges électrostatiques occasionnelles, et la protection ESD sur les ports exposés à l’extérieur est surtout un plus. Avec le RP2040, si vous n’ajoutez pas de protection externe sur toutes les broches, vous finirez pratiquement par en voir certaines mourir en usage quotidien.
En résumé, c’est une puce sympa et excellente pour le hobby, mais ce ne serait probablement pas mon premier choix dans un environnement professionnel.
Je me demande ce que signifie exactement « PHY USB-C ». USB-C est un connecteur, et on peut faire passer par-dessus de l’USB 1.1/2.0/3.0/3.1. En pratique, le RP2040 n’est même pas capable d’alimenter correctement un PHY USB 2.0
Même un développeur amateur finit par se lancer dans des projets plus complexes, et c’est précisément là qu’il se heurte à ces limites
Je me demande dans quel type d’applications la FRAM a été la plus utile. La technologie elle-même a l’air vraiment intéressante, mais elle est si chère qu’il est difficile de bien voir quand l’utiliser plutôt qu’une combinaison SRAM ou PSRAM avec NAND
La macro Synopsys DesignWare SSI dans le RP2040 pourrait en fait, semble-t-il, servir avec de la PSRAM ou de la FRAM lisible/inscriptible. Mais la documentation abrégée de la fiche technique du RP2040 ne semble pas suffisante pour la configurer ainsi
Raspberry Pi a commencé à l’origine comme une organisation à but non lucratif dédiée à l’éducation
Le RP2040 est plutôt chouette, et je l’ai utilisé jusqu’ici dans une demi-douzaine de projets
Mais l’approche « un seul composant pour tout faire » ne me convient pas. Je préfère utiliser le plus petit microcontrôleur capable de faire ce dont j’ai besoin
Si j’essaie d’utiliser le microcontrôleur le moins puissant possible, ce n’est pas pour l’argent, mais pour le budget énergétique. La plupart de mes projets fonctionnent sur batterie, donc consommer le moins possible est un gros avantage
Cela dit, pourquoi utiliser un microcontrôleur à 1 $ si un modèle à 20 cents peut faire exactement la même chose ?
Utiliser un contrôleur moins puissant pour faire durer la batterie plus longtemps est une très bonne raison. Le prix plus bas est intéressant en théorie, mais dans les faits, pour un projet ponctuel, ça n’a presque aucune importance. Je ne me souviens même plus de la dernière fois où j’ai arbitré un achat pour quelques dizaines de cents, et la différence ne se ressent pas
J’aime le RP2040, mais je veux expliquer pourquoi je m’en suis écarté pour mon projet actuel
Premièrement, la controverse autour de PlatformIO m’a vraiment déplu. Je veux me ranger du côté des développeurs pénalisés par le chaos des outils
Deuxièmement, l’ESP32-S3 haut de gamme existe sous forme de module et peut en gros être posé sur un PCB avec seulement quelques condensateurs de découplage. Le RP2040 exige de placer soigneusement une dizaine de composants, dont un cristal. Les modules réduisent fortement la complexité d’implémentation et, grâce à la standardisation, diminuent aussi le risque que chaque ingénieur fasse des erreurs idiotes de placement de composants
Troisièmement, l’ESP32-S3 dispose de 14 broches GPIO configurables en tactile capacitif, alors que le RP2040 n’en a pas. La plupart des projets qui combinent RP2040 et tactile capacitif dépendent du MPR121, mais cet IC est en fin de vie, ce qui risque de provoquer beaucoup de redesigns urgents dans les prochains mois
Il est très probable que le RP2040 finisse par avoir un jour des versions plus puissantes ou moins puissantes, ainsi qu’une version sous forme de module. Ils ne pousseront sans doute pas les choses jusqu’à une situation à la STM ou PIC, mais la famille ESP32 ne paraît plus si étrange une fois qu’on s’y habitue
Espressif semble être dans la même situation que Pi vis-à-vis de PlatformIO[1]. Vu de l’extérieur, PlatformIO aurait essayé de demander à RPi et Espressif des frais annuels très élevés, après l’ajout d’un support initial et le début de son adoption par une partie de la communauté
C’est une situation étrange, mais PlatformIO donne l’impression d’avoir accumulé une position dominante en prenant en charge de nombreuses plateformes et en acceptant les contributions de la communauté, puis d’avoir essayé a posteriori d’extraire directement de la valeur auprès des fabricants. Ils ont aussi bloqué des PR communautaires qui ajoutaient de nouvelles révisions de cartes ou corrigeaient des bugs. Contexte : [2]
[1] https://github.com/platformio/platform-espressif32/issues/12...
[2] https://github.com/platformio/platform-raspberrypi/pull/36
Pour être juste, le RP2040 est conçu de manière à rendre le placement de ces composants vraiment facile. Il n’y a pratiquement qu’un seul agencement logique, et toutes les broches souhaitées sont facilement accessibles
Avec une excellente documentation en plus, on obtient presque un design drop-in à plusieurs composants : on l’intègre une fois et on n’a plus à y penser. Au début, ça paraissait un peu intimidant, mais l’implémentation réelle a été vraiment agréable
J’utilise le RP2040 depuis son lancement et je n’ai jamais utilisé PlatformIO ; je serais curieux de savoir comment vous l’utilisiez et ce qui était si mauvais
Développer en local avec cmake et le pico sdk, ou avec micropython, semble très simple ; je ne vois pas bien pourquoi y mêler PlatformIO
Je ne pense pas vraiment qu’en faire un module apporterait une valeur significative. Tout le monde veut un form factor légèrement différent, et la conception des circuits périphériques est tellement simple qu’un module aurait du mal à apporter un gain net
Le tactile est plutôt une fonctionnalité de niche isolée, et c’est même une bonne chose de ne pas l’avoir inclus. Pour cette fonction, il vaut mieux utiliser un autre IC, et si les gens restent accrochés à une pièce obsolète par paresse, ce n’est pas le problème de RPi. Ou alors on peut l’implémenter en logiciel
Sur ce point, je suis d’accord avec l’article d’origine, et je pense que la fondation a vraiment bien défini le produit
J’ai intégré pendant des décennies des puces Atmel, STM, TI, Ambiq, Nordic et autres dans des conceptions, et ce n’est pas comme s’il n’existait aucun moyen de résoudre ce problème. Le stagiaire à deux yards de moi est justement en train de se battre, pour son premier PCB, afin de placer les bons composants autour d’un STM. Pour quelqu’un qui a déjà fait un peu de ce travail, ce n’est pas un problème difficile
De toute façon, cette dizaine de composants, ce sont le circuit oscillateur/cristal, le maintien du reset, l’alimentation 3,3 V et une grosse quantité de condensateurs de découplage. L’accord d’antenne peut certes être difficile, mais si l’on peut utiliser une antenne puce, ce n’est pas si compliqué non plus
Tout cela est tellement standard que, lorsque j’ai regardé le schéma de l’Adafruit RP2040 Feather, j’ai au contraire été surpris de voir que beaucoup de parties semblaient reprises presque telles quelles des Feather précédentes. La différence entre le RP2040 Feather et le nRF52840 Feather se résume au microcontrôleur lui-même, aux cinq composants du circuit de timing complet pour le RP2040, et au circuit d’antenne pour la carte Nordic
Les modules sont très pratiques pour vendre au marché hobbyiste, mais si vous voulez vendre un vrai produit, il faut tout de même passer par la certification RF. Le coût peut baisser, mais il faut juger soi-même si le coût initial plus élevé lié à l’utilisation d’un module est compensé par les coûts de certification plus faibles. Au final, ce que l’on économise surtout, c’est l’étape d’accord de l’antenne, qui se traite généralement comme une variante de BOM plutôt que comme une grosse modification de routage
Comme il existe des dizaines de puces STM et PIC, c’est la même situation chez TI. Les clients veulent payer uniquement pour ce dont ils ont besoin, et les fabricants ont la capacité de production pour répondre à cette demande. Si les différences comptent, ce n’est pas un fardeau. C’est très comparable au fait de se plaindre que Home Depot vend trop de sortes de bois.