- Le RP2040 avait pour grands points forts le PIO, le DMA et l’overclocking, mais pour certains projets il fallait passer au STM32H7 à cause des limites de performances CPU, de RAM, de GPIO, de ressources PIO et de l’absence de QSPI PSRAM ; le RP2350 comble largement ces manques
- Le RP2350 propose deux cœurs Cortex-M33F, la prise en charge du flottant, des instructions personnalisées pour accélérer les calculs en double précision, 2 fois plus de RAM, ainsi qu’une option de cœur RISC-V, et il a été utilisé de façon stable à 300 MHz sur plusieurs projets
- Le PIO peut utiliser ses FIFO comme de la mémoire avec lecture/écriture arbitraire, et grâce aux 3 PIO, aux interruptions entre PIO et au DMA amélioré, il devient même possible d’implémenter un esclave Sony Memory Stick et un esclave SDIO
- Le QSPI PSRAM prend en charge la lecture, l’écriture et le cache ; des tests mémoire qui finissaient par se bloquer ou crasher sur STM32H7 ont continué à tourner sur RP2350, et ajouter 16 Mo de RAM sur une carte artisanale à 2 couches est devenu simple
- Le premier projet RP2350 montré publiquement, le badge DEFCON 32, a fait tourner un émulateur Game Boy et PalmOS, tandis que les RP2354A/RP2354B apportent 2 Mo de flash intégrée, le même pinout et une variante étendue à 80 broches GPIO
Ce qui manquait au RP2040 et les améliorations espérées
- Le RP2040 était un microcontrôleur utilisé dans de nombreux projets, avec notamment comme points forts le PIO, un DMA bien conçu et une forte capacité d’overclocking
- La combinaison PIO + DMA a servi à implémenter :
- des pilotes d’affichage avancés
- des cartes se comportant comme un bus système complet avec RAM et ROM
- des configurations connectées à un processeur MC68328
- Les limites du RP2040 concernaient surtout les ressources de périphériques et l’extensibilité mémoire :
- un mode de transfert permanent pour le DMA sans gaspiller d’autres canaux
- davantage de canaux DMA
- plus de registres pour stocker des variables temporaires dans les state machines PIO
- davantage d’unités PIO
- plus de 32 emplacements d’instructions par PIO
- davantage de GPIO
- La fréquence élevée servait surtout à masquer les faiblesses des cœurs Cortex-M0+, et l’auteur estime qu’un meilleur cœur, comme un Cortex-M4F, aurait été plus avantageux pour les calculs en flottant ou les charges SIMD légères
- La prise en charge du QSPI PSRAM ainsi qu’une quantité de RAM plus élevée faisaient aussi partie des principales attentes
Comparaison avec l’expérience du QSPI RAM sur STM32H7
- Dans certains cas d’usage, il a fallu utiliser un STM32H7 à la place du RP2040, mais cela a laissé une forte méfiance vis-à-vis des bugs du STM32H7 et de la façon dont STMicro gérait ses errata
- Avec le support du QSPI RAM sur STM32H7, les problèmes suivants sont apparus :
- sans cache, certaines écritures étaient perdues
- avec le cache activé, des écritures parasites aléatoires apparaissaient autour de certaines écritures d’un octet
- en exécutant du code depuis la PSRAM, toute la puce finissait par se figer après des dizaines de milliards d’accès, au point que même le débogueur ne pouvait plus s’y connecter
- Ces problèmes ont été signalés avec démonstration à l’appui, mais la réponse de STMicro a été jugée insuffisante
- Des contournements ont été trouvés, mais ils consommaient 7 à 10 % de performances, réduisant l’intérêt de la puce
Les améliorations réellement apportées par le RP2350
- Pendant l’année écoulée, l’auteur a utilisé des échantillons de RP2350 avec l’aide de Raspberry Pi, a remonté des bugs et fait des propositions, tout en constatant comment les cas d’usage du RP2040 s’amélioraient
- Les performances CPU et de calcul ont fortement progressé :
- 2 cœurs Cortex-M33F
- prise en charge du flottant
- des instructions personnalisées qui accélèrent les calculs en double précision au-delà du support habituel de simple précision du Cortex-M33F
- les opérations en double précision ne sont pas sur un seul cycle, mais tournent autour de 2 à 3 cycles par opération
- des cœurs RISC-V sont aussi disponibles, mais les projets réels ont utilisé les Cortex-M33
- Sur plusieurs projets, le RP2350 a fonctionné sans problème à 300 MHz
- La RAM a été portée à 2 fois celle du RP2040
Évolutions du PIO et du DMA
- Le PIO du RP2350 peut utiliser ses FIFO comme de la mémoire avec lecture/écriture arbitraire, ce qui simplifie des configurations auparavant difficiles faute de variables temporaires
- Le nombre de PIO dans la puce passe à 3
- Il devient possible d’envoyer des interruptions entre PIO, ce qui permet la synchronisation inter-PIO et des montages plus complexes
- La combinaison du PIO amélioré et du DMA a déjà été utilisée dans des projets concrets pour implémenter :
- un esclave du protocole Sony Memory Stick : les appareils le reconnaissent comme un vrai Memory Stick
- un périphérique esclave SDIO : les appareils testés le reconnaissent comme un périphérique SDIO
- Le DMA a lui aussi été renforcé sur la durée des transferts et le contrôle des adresses :
- possibilité de faire des transferts infinis sans utiliser d’autre canal
- davantage de modes d’ajustement de l’adresse mémoire à chaque accès
- en plus des options du RP2040 (« même adresse » ou « incrément de la taille d’accès »), on peut désormais décrémenter ou incrémenter selon d’autres pas
Prise en charge du QSPI PSRAM
- Le RP2350 prend en charge le QSPI PSRAM, en lecture comme en écriture
- Un cache est également fourni et fonctionne correctement
- Des tests mémoire qui finissaient par se bloquer ou crasher sur STM32H7 ont continué à tourner sur RP2350, sans perte de données ni blocage de la puce
- Les combinaisons possibles sont les suivantes :
- 1 flash + 1 PSRAM
- 2 flash
- 1 flash de boot + 2 PSRAM à l’exécution
- Une configuration avec VTOR, SP et PC tous placés en PSRAM, recevant des interruptions tout en exécutant massivement des instructions LDM/STM vers la PSRAM, a aussi fonctionné sans problème
- La configuration tient en 3 lignes de code C, et il devient simple d’ajouter 16 Mo de RAM sur une carte artisanale assemblée à la main en 2 couches
- La carte d’évaluation RP2350 initiale, la Pi Pico 2, n’avait pas d’empreinte PSRAM ; la PSRAM a donc été ajoutée en montage dead-bug, tout en fonctionnant à pleine vitesse
Atouts conservés et expérience de développement
- En passant du RP2040 au RP2350, la qualité de conception et de documentation des périphériques a été conservée
- Les périphériques sont jugés conformes à ce qui est annoncé
- Le SDK est clair et concis, sans nécessiter le téléchargement d’outils volumineux de type Cube/HAL
- Le code n’est pas un enfer de macros et fonctionne bien
- La carte de développement RP2350 de Raspberry Pi est compatible rPiPico, ce qui a permis de porter facilement plusieurs projets sur la PiPico 2
Premier projet RP2350 public : le badge DEFCON 32
- L’un des premiers projets RP2350 rendus publics est le badge DEFCON 32
- Le matériel a été développé par Entropic Engineering, et le firmware est un portage de uGB, un minuscule émulateur Game Boy
- Les 2 cœurs se partagent les rôles :
- un cœur utilise les instructions SIMD du Cortex-M33 pour mettre à l’échelle l’écran Game Boy en 1,5x
- l’autre gère l’émulation, l’interface utilisateur et le reste des tâches
- Les jeux Game Boy valides fonctionnent jusqu’à 2 Mo, et des jeux plus gros deviennent possibles avec une puce flash de plus grande capacité
- Le jeu Game Boy préinstallé a été créé par l’équipe DEFCON
- Sur ce badge, la puce est cadencée de façon conservatrice à 125 MHz
- il y avait peu de temps pour les tests, la production est passée de 10 à 28 000 unités sans étape intermédiaire, et il n’y avait pas de plan B
- l’horloge maximale de l’écran était de 62,5 MHz, et comme c’est une state machine PIO qui l’alimente, l’horloge de l’écran devait être un multiple entier de l’horloge système
Exécuter PalmOS et le firmware
- Le même matériel du badge DEFCON 32 peut aussi exécuter la version complète de PalmOS via le projet rePalm
- Le badge de base n’intègre pas de PSRAM, mais PalmOS fonctionne quand même
- la mémoire est juste, mais l’infrarouge, la carte SD, de petits jeux, memo pad, l’audio, etc. fonctionnent
- En ajoutant une puce PSRAM AP Memory de 64 Mbit, il devient possible d’utiliser une seconde image et, avec plus de mémoire, de charger des jeux ou de lire des MP4 en temps réel via TCPMP
- Les images firmware sont disponibles dans la documentation ; il suffit de les placer sur la carte SD sous le nom
FIRMWARE.BIN, puis de choisirfirmware updatedans le menu du boutonFNpour les charger - La restauration du firmware d’origine est possible depuis n’importe quel ordinateur via USB et le protocole UF2, et l’image d’origine est elle aussi disponible dans le même document
RP2354 et davantage de GPIO
- La conclusion est qu’il devient possible de replanifier des projets STM32H7 autour du RP2350
- À ceux qui soulignent que le RP2350 nécessite une flash SPI externe, il existe des variantes avec flash intégrée : RP2354A et RP2354B
- Les RP2354A/RP2354B incluent 2 Mo de flash dans le boîtier
- Leur pinout est identique à celui des RP2350A/B
- Il existe aussi une variante en boîtier 80 broches offrant davantage de GPIO
Déclaration d’intérêts
- Aucun paiement ni compensation n’a été reçu pour cet article
- L’auteur n’a pas été sollicité pour l’écrire et n’a reçu aucune validation préalable
- L’accès anticipé au RP2350 n’était pas conditionné à des propos positifs en public ni à des déclarations particulières
1 commentaires
Avis de Hacker News
Ces dernières années, j’ai développé un pilote de moteur brushless basé sur le RP2040, et cette annonce me rend vraiment impatient
Le module de pilotage peut gérer jusqu’à 53 V, 30 A en continu et 50 A en crête. Récemment, j’ai séparé le pilote dans un module distinct ; c’est utile pour les robots agricoles et important aussi pour tester le pilote pendant l’amélioration de la conception. Cette révision semble assez stable, donc je pourrais bientôt créer avec le RP2350 un pilote 1 moteur intégré sur carte unique à bas coût. Avec le RP2040, la boucle tournait à 8 kHz, ce qui suffit pour les gros moteurs de traction de robots agricoles, mais certains pilotes hautes performances utilisant le flottant atteignent des fréquences de boucle de 50 kHz
La carte exécute SimpleFOC, et il a été question sur le forum de créer une conception phare. Mais comme il faut une commande sensorless et la prise en charge du flottant, la nouvelle variante RP2350 au grand brochage, avec 8 broches ADC, permettrait de mesurer 3 signaux de courant et 3 tensions de pont pour faire un pilote sensorless correct. Il faudra quelques mois avant que la conception soit prête, mais pour les dernières nouvelles, il suffit de consulter le dépôt Git ou mon profil Twitter
https://github.com/tlalexander/rp2040-motor-controller
https://twitter.com/TLAlexander
J’aime vraiment le fait d’utiliser des pièces de vélo pour les pieds et les roues
Il existe déjà des MCU dédiés avec des périphériques spécialisés, des notes d’application et des exemples de code pour le contrôle BLDC avec ou sans capteur ; à mon avis, le RP2040 n’est pas une puce bien équipée pour cette tâche
Ça me rappelle l’époque où, enfant, je démontais des petites voitures pour en sortir le moteur et avais l’impression d’avoir accompli quelque chose
J’avais du mal à imaginer utiliser le RP2040 dans un vrai produit, mais le RP2350 corrige une bonne partie de mes griefs, au point de me donner envie de l’essayer
Le RP2040 avait aussi beaucoup de qualités. TBMAN est un concept élégant, et il s’overclocke incroyablement bien. PIO est vraiment innovant et a beaucoup de valeur pour les nombreuses entreprises qui cherchent à remplacer des composants de type 8051 par un cœur Arm sous forme de carte fille
Mais à chaque point fort correspondait aussi une frustration. Il a une fréquence digne d’un DSP, mais ni FPU ni division entière matérielle. Intégrer l’USB DFU dans la ROM de démarrage sur un MCU sans protection mémoire n’est pas non plus souhaitable. Dans des SDK tiers comme Zephyr, la prise en charge de PIO est extrêmement limitée, ce qui réduit son utilité dans les grands projets
Le RP2350 règle presque tous ces problèmes, ce qui me rend très enthousiaste. Cela dit, s’il faut implémenter des périphériques courants comme CAN ou SDMMC avec PIO, on part tout de suite avec un handicap. La flexibilité est excellente, mais quand il faut lancer rapidement un produit, je n’ai pas envie de manipuler un langage d’assemblage spécialisé. Au final, fournir des bibliothèques de périphériques logiciels prêtes à l’emploi pour des fonctions courantes comme SD/MMC, MII ou Bluetooth HCI faciliterait l’intégration avec Zephyr et autres, et élargirait beaucoup le champ d’utilisation de la puce
Le niveau de finition pourrait être meilleur, mais on est assez proche d’une forme « prête à l’emploi »
PIO est un gros atout, et je suis content que la nouvelle version renforce encore cette direction. Des pilotes PIO pour divers périphériques comme CAN ou WS2812 sont déjà développés par la communauté, ce qui se rapproche de ce que j’espérais
Le fonctionnement autonome de périphériques, les amplificateurs opérationnels, les comparateurs et les timers capture/comparaison, c’est pareil. Zephyr essaie de fournir une interface commune comme un système d’exploitation de bureau, mais cela colle mal à l’embarqué. Sur desktop, le plus petit dénominateur commun suffit souvent ; dans l’embarqué, on choisit souvent une plateforme précisément pour ces fonctionnalités non communes
Nous avons choisi le RP2040 en partie pour sa philosophie de conception, mais aussi beaucoup parce qu’il était facile à approvisionner après la pénurie de puces
En pratique, il y a des « exemples », et ce serait mieux si ce genre de choses était proposé comme support de premier niveau
Les caractéristiques sont disponibles ici : https://www.digikey.ca/en/product-highlight/r/raspberry-pi/r...
Basé sur le RP2350 conçu par Raspberry Pi au Royaume-Uni, double Arm M33 à 150 MHz avec FPU, 520 Kio de SRAM, fonctions de sécurité comme démarrage signé, OTP, SHA-256, TRNG, détecteur de glitch et Arm TrustZone for Cortex-M, double processeur RISC-V Hazard3 optionnel à 150 MHz, fonctionnement basse consommation, 3 PIO v2 et 12 machines d’état pour la prise en charge de périphériques personnalisés, prise en charge de la PSRAM, interface de flash QSPI XIP externe plus rapide, 4 Mo de flash QSPI embarquée, GPIO tolérant 5 V, SDK C/C++ open source et prise en charge de MicroPython, compatibilité logicielle Pico 1/RP2040, programmation par glisser-déposer via périphérique de stockage de masse USB, module castellé soudable directement sur une carte porteuse, même empreinte et compatibilité de broches que le Pico 1, 26 GPIO multifonctions dont 3 entrées analogiques, température de fonctionnement de -20 °C à +85 °C, tension d’entrée de 1,8 VCC à 5,5 VCC
En regardant plus tard, la section 14.8.2.1 mentionne deux types de broches numériques, « Standard Digital » et « Fault Tolerant Digital », et les broches FT Digital semblent tolérer le 5 V
C’est un grand jour pour l’équipe Pigweed
Une partie du travail a été mentionnée dans l’annonce principale du RP2350/Pico 2 [1], mais ces derniers mois nous avons travaillé sur un nouveau SDK de bout en bout [2] construit au-dessus de Bazel [3], qui prend en charge à la fois le RP2040 et le RP2350. Cela inclut aussi l’upstream du support de Bazel dans le Pico SDK. Le nouveau « Tour of Pigweed » [4] montre plusieurs fonctionnalités de Pigweed — builds hermétiques, tests unitaires sur appareil, communications centrées sur RPC, tests d’usine sur bureau — fonctionnant ensemble dans une seule base de code. Les questions sont les bienvenues sur Discord [5]
[1] https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new...
[2] https://opensource.googleblog.com/2024/08/introducing-pigwee...
[3] https://blog.bazel.build/2024/08/08/bazel-for-embedded.html
[4] https://pigweed.dev/docs/showcases/sense/
[5] https://discord.gg/M9NSeTA
Voir tout intégré de façon hermétique et le workflow se résumer à une seule commande Bazel, ça fait une vraie différence
C’est surprenant que l’annonce de Pigweed n’en parle pas du tout
J’aimerais qu’on laisse Java en dehors de l’écosystème des microcontrôleurs
C’est la première fois que je vois une conception où l’on peut choisir entre des cœurs Arm et des cœurs RISC-V sur le même die
Je me demande quel impact cela aura sur le prix et la consommation. Les cœurs Hazard3 sont optionnels, et au démarrage on peut choisir d’exécuter à 150 MHz soit la paire de cœurs Arm Cortex-M33 incluse, soit la paire de cœurs Hazard3. Plus audacieux encore, on peut aussi faire tourner un cœur RV et un cœur Arm ensemble
Hazard3 est une conception open source, et sa documentation est publique. C’est une machine RV32IMACZb* légère, en exécution séquentielle à 3 étages, qui prend en charge l’ISA RISC-V de base 32 bits, avec multiplication et division matérielles, instructions atomiques, manipulations de bits, etc.
Eben Upton explique : « C’est sélectionnable au démarrage. Chaque port entrant dans la fabrique de bus peut être relié, via un mux, soit à un M33 soit à un Hazard3. Si vous voulez faire le geek, vous pouvez même en exécuter un de chaque »
Source : https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
La surface réellement occupée par le cœur d’instructions est généralement assez faible par rapport aux périphériques ou à la mémoire interne
Cela permet de valider à la fois la technologie et l’acceptation du marché à un coût bien inférieur à celui d’un nouveau tape-out de puce séparée
C’est vraiment chouette de pouvoir choisir RISC-V, entièrement open source, si on le souhaite. Le cœur RV sera probablement plus lent que le M33 en performance par cycle, et je m’attends à ce que le M33 obtienne de meilleurs scores de benchmark. C’est parce que Hazard3 a un pipeline à 3 étages, même si le M33 en a aussi un. J’ai hâte de voir les benchmarks
Article d’actualité officiel : https://news.ycombinator.com/item?id=41192341
Page produit officielle : https://news.ycombinator.com/item?id=41192269
Doom a été porté sur le RP2040 : https://kilograham.github.io/rp2040-doom/
Le RP2350 semble même capable de faire tourner Quake. Certains changements donnent presque l’impression d’avoir été conçus pour cet objectif. Il dispose d’une FPU, de deux cœurs à 150 MHz, d’une possibilité d’overclocking au-delà de 300 MHz, et prend en charge jusqu’à 16 Mo de PSRAM avec pagination matérielle en lecture/écriture.
Le fait que la carte de développement utilise du micro-USB n’est pas terrible. Même en 2024.
À part ça, elle est excellente, et c’est exactement le produit qu’il faut pour concurrencer les grands acteurs établis.
C’est bien que les produits modernes soient tous en USB-C, mais il reste aussi beaucoup de câbles micro-USB, donc le fait que les Pico et Pico 2 officiels soient en micro-USB n’est pas si gênant. C’est appréciable d’avoir le choix du port selon le projet.
La puce d’interface doit elle aussi être plus complexe, donc probablement plus chère. Sur AliExpress, on trouve encore beaucoup d’appareils bon marché en micro-USB, et il doit encore y avoir de la demande. Selon la clientèle, on peut même fabriquer un produit grand public directement à partir de la carte de développement.
Il est un peu surprenant qu’une jeune entreprise qui semble orientée grand public ait intégré autant de sécurité dans son deuxième microcontrôleur.
Au début, je trouvais difficile de faire confiance à la sécurité à cause de son manque d’expérience. Mais les microcontrôleurs sécurisés de fournisseurs « expérimentés » ont eux aussi beaucoup de bugs de sécurité connus, et surtout, on les a déjà vus tenter de dissimuler ce genre de problèmes. Faire auditer deux fois l’architecture de sécurité, proposer une bug bounty de 10 000 dollars et concevoir une carte destinée au glitching, à la manière d’un badge DEF CON, montre un engagement assez sérieux en matière de sécurité. Je suis aussi curieux de voir comment fonctionne le Redundancy Coprocessor. Cela dit, je ne serais pas surpris que quelqu’un parvienne à en casser au moins une partie.
Il faut comprendre « orientée grand public » en termes de perception ; du point de vue des ventes et de l’approvisionnement, l’entreprise semble avoir surtout donné la priorité aux utilisateurs industriels.
Je n’ai pas encore trouvé l’annonce officielle ni la fiche technique, mais d’après cet article, cela ressemble à un grand bond en avant par rapport au RP2040.
Il semble inclure 2× Cortex-M33F, un DMA amélioré, davantage de PIO et mieux optimisés, la prise en charge de PSRAM externe, une variante avec 2 Mo de flash interne et 80 broches, une RAM doublée à 512 Kio, ainsi que quelques cœurs RISC-V. Peut-être pour la basse consommation.