Equipé d'un moteur 5V (CN459-60067 BN026Y18), d'un disque optique et d'un encodeur à quadrature optique, je voulais savoir s'il était possible de l'utiliser avec MicroPython.
Le disque optique
La photo haute résolution du disque optique permet de relever plusieurs informations utiles.
Le disque présente 50 interstices transparents entre deux numéro successif. Le disque étant numéroté de 1 à 12, cela représente 600 pulsations par tour (ce que reprend l'une des références sur le disque).
Les autres références/informations sur le disque ne renvoi malheureusement que vers les imprimantes HP.
L'encodeur optique
Pour sa part, l'encodeur optique est monté sur une plaquette fixée directement sur le support métallique. Cet encodeur contient un LED (émetteur de lumière) ainsi que deux capteur photo-sensibles. Le décalage entre les deux capteurs permet d'identifier le sens de rotation du moteur.
Le connecteur 4 contacts est utilisé pour:
la masse
l'alimentation 5V (déduit de la résistance utilisée pour la LED).
Deux signaux à quadrature.
Les signaux
Quelques mesures rapides permettent de savoir que le capteur produit une tension de sortie (pas besoin de résistances pull-up ou pull-down).
Maintenant que le brochage est identifié, il ne reste plus qu'à branché un oscilloscope sur les deux canaux de sorties.
Notez le décalage entre les deux signaux entre marche avant et marche arrière!
L'oscilloscope nous informe aussi que la fréquence des pulsations est de 24.4 KHz (soit 24400 fois par seconde). La période est de 1/24400 soit 41µSec (temps en deux impulsions sur un même canal).
Brancher sur Raspberry-Pi Pico
Les signaux de sortie étant étant en 5 volts (ou presque), il faut utiliser un pont diviseur de tension pour ramener la tension sous 3.3V.
Bibliothèque et code d'exemple
D'autre part la période de 41µSec nécessitera un code particulièrement rapide pour ne pas rater d'impulsion. Une section de code en PIO permettra de suivre suivre la cadence... même sous MicroPython!
La bibliothèque adéquate est disponible dans le dépôt esp8266-upy ( esp8266-upy/LIBRARIAN/rp2lib ). rp2qenc.py contient le code PIO et la classe PIO_QENC permettant d'utiliser un encodeur à quadrature autonome sur un Pico. La classe PIO_QENC permet de compter (ou décompter) un compteur permettant de connaître le nombre de tour moteur (valeur signée encodée sur 32 bits).
Le code permettant de lire le compteur est relativement simple.
from machine import Pin
from time import sleep_ms
from rp2qenc import PIO_QENC
pinA = Pin(15, Pin.IN, Pin.PULL_UP)
pinB = Pin(16, Pin.IN, Pin.PULL_UP)
qenc = PIO_QENC(0, (pinA, pinB))
print('starting....')
for i in range(120):
print('iter %3i : Quadrature value = %i' % (i,qenc.read()) )
sleep_ms(500)
qenc.sm_qenc.active(0)
print('stop')
La refusion (reflow en anglais) est un procédé permettant de réaliser la soudure de composants montés en surface (CMS, SMD en anglais) placés sur la carte. C'est ma refusion de la pâte à soudé (aussi appliqué sur la carte) qui soude les composants. Plus de détails ici sur Wikipedia.
Le profile de refusion
Il n'est pas question de placer la carte, les composants et la pâte de refusion sur une surface étant déjà 250°C! Il faut y aller "en douceur" si je peux m'exprimer ainsi.
Il faut donc suivre ce que l'on appelle un "profile de refusion" visant à:
éviter un choc thermique trop brutal,
de permettre au composant de monter un peu en température
permettre au flux contenu dans la pâte de fondre et de se répandre sur la carte
d'éviter que les composants ne grillent parce qu'il restent trop longtemps à une température trop élevée.
Voici une liste de tuple (t°_finale, temps_alloué_sec) décrivant les différentes phases détaillées ci-avant. Le refroidissement venant après la dernière phases.
La première phase est donc 150°C en 90 sec. La dernière est 245°C pendant 30 sec (le maintient à la température de refusion).
Du code pour le peuple
Le code est bien entendu disponible sur le dépôt GitHub Plancha-CMS. Le script main.py assure le traitement d'un profile par l'appel de la méthode profile_heating( profile ) qui accepte le profile en paramètre (voir PROFILE_SN0 ci-avant).
Petit rappel
La mise en oeuvre du profile de chauffe s'appuie sur un contrôleur PID qui, lui, contrôle la température de la semelle chaque seconde et applique la correction nécessaire (voir les précédents articles sur Plancha-CMS).
Traitement d'une phase
Pour chacune des phases, le temps alloué en divisé en intervalles de 5 secondes, ce qui permet de calculer la rampe de température à suivre pour atteindre la température finale désirée. Le PID est donc informé, toutes les 5 secondes, de la nouvelle température à atteindre. Cela permet d'éviter les trop brusques montées en température de la semelle.
Avec des intervalles de 5 secondes, le contrôleur PID dispose de 4 à 5 itérations pour effectuer l'asservissement de la température.
En admettant que la température de la semelle est à 22°C (t° de la pièce) lors du démarrage de la première phase (150,90) du profile, soit (atteindre 150°C, en 90Sec) , nous pouvons déduire:
Nous aurons 90 / 5 = 18 itérations de 5 secondes pour cette phase.
Une différence de température de 150°C - 22°C = 128°C à combler
Soit 128°C / 18 itérations = une augmentation de 7.11 °C toutes les 5 secondes.
La fin de la première phase atteinte, il ne reste plus qu'a passer immédiatement à la suivant, donc (180,90), et procédé à l'identique... sauf que cette fois, la température de départ est 150°C (T° de fin de la phase précédente).
Contrôler l'exactitude de la régulation.
Voici les informations PID produites par l'exécution de profile_heating( PROFILE_SN0 ) :
On constate que la première colonne est remise a zéro toutes les 5 secondes (à chaque fois que le PID est informé d'une nouvelle température. La deuxième colonne est la T° a atteindre, la troisième colonne est la température de la semelle.
Les données importées dans une feuille de calcul permet de générer un rendu sous forme de graphique. La première colonne (les itérations PID, chaque seconde) est remplacée par une valeur incrémentée permettant ainsi d'obtenir un écoulement du temps linéaire et globale sur la totalité de la régulation.
Rendu dans le graphique, il est possible de voir les escaliers des différentes consignes attribuées au PID (en bleu) et le suivit de température de la semelle (en rouge).
Phases de la refusion et température de la semelle
La courbe de refusion est excellente (même si elle présente un retard de 5 à 10 degrés). Il y manque la phase de maintient à 245°C qui n'était pas encodée dans le script Python.
Après une légère adaptation du code, il est maintenant possible de relever une courbe de refusion complète... et le résultat est plutôt satisfaisant :-)
Refusion SN0 -> refusion de SnCu à 245°C
Auto-critique:
1. il serait plus approprié d'avoir un pointe a 245°C qui dure plus longtemps. 2. le retard systématique entre la consigne et la température est probablement causée par le déplacement de la sonde de température du dessous de la semelle au dessus de la semelle. Ce qui aurait sensiblement modifié les paramètres PID. 3. Adapter les paramètres pour répondre au point 2 pourrait fort bien corriger le point 1.
Peut-être vous souvenez-vous du projet "Plancha-CMS", un projet MicroPython au long cours sur-lequel je me penche de temps à autre. Le dernier article date de mai 2023 avec un dernier dernier opus technique en Août 2021.
Interface Homme-Machine
Dans l'article de mai 2023, j’envisageai l'usage d'un écran OLED graphique. Quand j'ai repris mon projet ce Week-end, j'ai finalement opté pour un afficheur 2x16 I2C et un encodeur rotatif+click I2C... c'est que je voulais avancer vite.
Sur l'image ci-dessus, il est possible de constater:
La finalisation de l'interface utilisateur
La connexion USB vers l'ordinateur (pour finaliser le développement)
La présence du bouton Reset (et du plus discret switch RUN_APP)
Le repositionnement du thermocouple sur le dessus de la plancha.
Securité avant tout
La Plancha-CMS dispose déjà d'un arrêt d'urgence qui s'avère essentiel durant le développement.
J'ai cependant ajouté quelques sécurités complémentaires:
Arrêt forcé du relais SSR au démarrage du microcontrôleur.
Définition d'une température critique (CRITICAL_T = 380).
La température est constamment surveillée par le contrôleur PID, contrôleur qui fonctionne en toute indépendance grâce à un Timer! C'est donc l'endroit idéal pour renforcer la sécurité. Si la température lue par le PID atteint CRITICAL_T alors:
le contrôleur PID est arrêté
le relais SSR est désactivé
le microcontrôleur est réinitialisé (pour assurer de l'arrêt du code).
Interface utilisateur
Le menu principal est simple a appréhender, il suffit d'utiliser l'encoder et de cliquer pour sélectionner la fonctionnalité. Les LEDs vertes de l'encodeur indique simplement qu'il n'y a pas de tâche en cours d'exécution.
Le menu prévoit 3 fonctionnalités:
Pre-Heat: préchauffage à la température sélectionnée par l'utilisateur. Affichage de la T° en temps réel. Maintenue de la température; cliquer pour sortir de la chauffe et entamer la phase de refroidissement par air forcé (jusqu'à T° < 35°C). Le refroidissement peut être interrompu à tout moment (en cliquant).
Cool: Refroidissement par air forcé avec affichage de la température. Interruption manuelle en cliquant.
Solder:en cours de développement - Processus de soudure en suivant un profil de refusion.
Processus de Préchauffage
Si l'utilisateur sélection l'entrée Pre-Heat alors il à la possibilité de sélectionner la température de préchauffe souhaitée (à l'aide de l'encodeur rotatif).
Une fois la température sélectionnée... il faut encore confirmer la pré-chauffe (au cas où la sélection serait une erreur utilisateur).
Une fois confirmé, la température est configurée sur le contrôleur PID et affichée en temps réel sur l'écran.
L'utilisateur peut quitter le processus à tout moment en cliquant l'encodeur rotatif.
Le script affiche également des informations sur la connexion USB-Serie, de quoi reconstituer un graphique de la montée en température à l'aide d'une feuille de calcul.
Dans le projet Steam Belgian Knife (sbk.education), il y a l'utilisation d'une cellule de charge comme capteur de pesée ou de capteur force. La cellule de charge est l'élément principale d'une balance électronique.
L'une des application envisagées est la mesure de la poussée d'une fusée à eau (sur un banc d'essai). Cela ne sera malheureusement pas possible et nous verrons pourquoi
A propos de la cellule de charge
La cellule de charge est un élément mécanique prévu pour tolérer une déformation en fonction de la force qui y est appliquée. Cette force résulte soit de la pesée d'un objet, soit d'un effort appliqué directement sur la cellule de charge (au bon endroit et dans la bonne direction).
La cellule de charge est composé d'un pont de Wheatstone, pont constitué de 4 résistances dont l'une d'entre elles est solidaire de la cellule de charge. Lorsqu'une force déforme la cellule de charge, la résistance est également déformée et sa valeur change sensiblement. Cela modifie l'équilibre du point de Wheatstone et modifie la tension de sortie d'un ordre de grandeur de l'ordre de quelques millivolts.
Cellule de charge
Les différences de tensions est tellement faible qu'il faut faut employer un amplificateur. Le plus connu est le hx711, un amplificateur 24 bits qui prend en charge l'alimentation et la mesure d'une cellule de charge.
HX711 avec MicroPython
Le HX711 dispose d'une bibliothèque Arduino mais comme vous le savez c'est avant tout l'utilisation avec MicroPython qui nous intéresse.
Pour commencer, voici comment brancher le capteur sur un Raspberry-Pi Pico.
Une fois le fichier hx711.py copié dans sur la carte MicroPython, il est possible d'exécuter l'un des programmes de test.
La tare
Les gauches de contraintes et cellules de charges n'ont pas vraiment de "point Zero". Ces capteurs sont plus ou moins contraint au repos... et passent dans un autre état de contrainte lorsqu'une masse/force est appliquée.
Il faut donc effectuer une tare qui lit l'état du capteur au repos et mémorise la valeur comme point Zero. Les autres mesures se feront donc par rapport à ce point Zéro.
C'est exactement que fait une balance électronique lorsqu'elle est activée! Sa première opération consiste à réaliser une série de mesures pour déterminer le "point zéro" de repos (elle "tare"). C'est pour cela que l'affichage du "0" n'est pas immédiat sur une balance électronique.
Dans la bibliothèque la méthode HX711.tare() permet de réaliser cette opération.
test.py : mesure brute
ce simple programme de test qui affiche la valeur lue sur la cellule de charge.
from hx711_gpio import HX711
from machine import Pin
import time
pin_OUT = Pin(12, Pin.IN, pull=Pin.PULL_DOWN)
pin_SCK = Pin(13, Pin.OUT)
hx711 = HX711(pin_SCK, pin_OUT, gain=128)
hx711.tare()
while True:
print( "---------------------------------" )
# Raw value of load cell. Not scaled, no offset compensation
print( "read: ", hx711.read() )
print( "get_value: ", hx711.get_value() )
time.sleep_ms( 500 )
Ce script retourne des "valeurs brutes". Après avoir étalonné mes masses de test, j'ai effectué un relevé des "valeurs brutes" retournée par la fonction get_value().
Remarque: je me serais attendu à une erreur plus petite sur le poids de 1 Kg.
Si l'on reporte les valeurs dans un graphique, nous pouvons voir qu'il y a une belle relation proportionnelle.
En appliquant la règle de trois, entre les masse et get_value(), ma cellule de charge de 5Kg présente un rapport d'échelle de 404.4715 (le facteur d'échelle est calculée pour une mesure en grammes).
test_unit.py : mesure en gramme
Lorsque le facteur d'échelle est identifié (ex: 404.4715), il est possible d'obtenir la valeur de la mesure directement en grammes si e facteur d'échelle à été calculé pour une cellule de 5000 grammes (un gamme de valeur de 0 à 5000).
Dans l'exemple ci-dessous, set_scale() est utilisé pour mentionner le facteur d'échelle. A partir de ce instant, la valeur retournée par get_unit() sera la masse (en grammes).
from hx711_gpio import HX711
from machine import Pin
import time
pin_OUT = Pin(12, Pin.IN, pull=Pin.PULL_DOWN)
pin_SCK = Pin(13, Pin.OUT)
hx711 = HX711(pin_SCK, pin_OUT, gain=128)
hx711.tare()
hx711.set_scale( 404.4715 ) # 5000gr Gauge with 128 bit gain. Output unit will be in grams
while True:
print( "get_units: %s gr" % hx711.get_units() )
time.sleep_ms( 500 )
La constante de temps!
Avez-vous déjà remarqué qu'une balance réagit relativement vite mais qu'il faut quelques secondes pour que la mesure soit stabilisée (surtout sur les balances de précision).
Ce même comportement s'applique aussi aux cellules de charges de cet article. La valeur augmente rapidement mais requière un certain laps de temps avant de se stabiliser près de la valeur finale.
J'ai ajouté un script plot_value.py qui attend la présence d'une masse pour effectuer une rafale de mesures toutes les 200ms jusqu'au retrait de la masse. En reportant les données dans un tableur, puis un graphique de l'évolution de la mesure en fonction du temps.
Qu'il faut environ 4 secondes pour obtenir la valeur finale.
Que la section droite de la courbe présente une courbure à partir 2/3 de la valeur finale (très intéressant!).
Suivez la démonstration suivante
A partir de la valeur finale connue (400000), on calcule la valeur à 66% (soit 266666). Le report de cette valeur de 266666 sur le tracé coupe la courbe de lecture là où celle-ci décolle de la tangente (ligne verte).
Encore mieux, il faut à peine 1077ms pour atteindre 66% de la valeur finale.
Ces 1077ms (ou 1.077 sec) est la constante de temps, temps minimal qu'il faut attendre pour avoir une idée raisonnable de la valeur finale.
Lecture rapide
En faisant une mesure à 1.077sec après que la mesure décolle du Zéro, nous obtenons une valeur indicative qu'il faut multiplier par 1.66 pour estimer le poids/force finale.
Il suffit d'attendre 3 secondes de plus pour lire la valeur finale et éventuellement corriger la valeur finale.
Incompatibilité avec la mesure de poussée
Rappelez vous, en début d'article, nous parlions d'un banc d'essai pour mesurer la poussée d'une fusée à eau.
Il faut savoir que la majorité de la poussée se produit durant les premiers 1/500 de seconde du lancement (cf. Planète Sciences > Fusée à eau, un superbe document).
Avec une constante de temps de 1.077 sec pour l'obtention d'une mesure approximative... durant le lancement d'une fusée à eau il sera impossible d'effectuer plus d'une mesure avec la cellule de charge!
Il faudra se tourner vers un dynamomètre dont le temps de réponse est de l'ordre de la milliseconde pour effectuer des mesures pertinentes avec une fusée à eau.
Note: pour une fusée à combustible solide, la poussée dure plusieurs secondes (une dizaine), de sorte que la constante de temps à un impact moins important sur la mesure (mais quand même pas négligeable). La cellule de force sera appropriée dans ce cas.
Conclusion
La cellule de charge est un excellent outil permettant de mesurer force statique ou une masse.
Ce capteur ne conviendra pas pour la mesure de force dynamique (comprenez: qui change rapidement).
Note: il me faudra aussi poursuivre la documentation du pilote HX711 qui reste très embryonnaire. Note 2: la documentation du pilote HX711 est maintenant complétée.
Je reprend ci-dessous quelques captures de la vidéo où l'on retrouve des informations utiles pour d'autres projets similaire (merci Kevin pour ce partage).
Composition générale de l'interface
Les différentes icones de la barre d'outils (toolbar) propose les fonctionnalités décrites ci-dessous
L'icone sélectionnée dans la Toolbar (barre à outil) est affiché en négatif!
Les ressources/icones graphiques sont disponibles sous forme de fichier BPM, un format facile à lire pour un microcontrôleur
La documentation sur les animations est aussi instructive. Je me suis demandé quel pouvait être l'intérêt d'une séquence REVERSE mais a bien y réfléchir, cela permet de déplacer Baby à un endroit puis, plus tard, de revenir à sa position initiale.
Kevin prend le temps de présenter les concepts utilisés et les éléments de programmation exploités.
Amélioration possibles
Je vois quand même quelques possibilités d'amélioration (électronique et logiciel).
Prévoir de l'autonomie (avec un Accu Lipo) et recharge
Prévoir du son (du moins un minimum).
Diminuer la quantité de fichiers BPM (regrouper les ressources dans un fichier commun)
Envisager des personnages différents (et comportements différents)... d'où l'intérêt de regrouper les ressources.
Clarifier les relations entre état psychologique et paramètres vitaux (état émotionnel, actions et leurs conséquences). J'ai trouvé ce point un peu confus dans l'implémentation de Kevin.
Le Trinkey est une mini-clé USB produite par AdaFruit et équipée d'un microcontrôleur RP2040 (le
même que le Raspberry Pico) ainsi que de 8 Mio de mémoire Flash QSPI.
Le TrinKey permet de créer des rapidement des solutions simples et efficaces... branchez là et le projet qu'elle contient est prêt à l'emploi.
Le TrinKey est un produit qui m'excite beaucoup, j'aime l'idée d'avoir une clé USB compacte que l'on peut adapter à ses besoins. Son connecteur I2C permet de chaîner capteur I2C et actionneur mais il est aussi possible de détourner ce connecteur pour exploiter les deux GPIOs ou un UART.
Le récent déploiement d'USBDevice permet maintenant d'écrire des pilotes USB en MicroPython... une autre raison de trouver le TrinKey vraiment très attractif.
Le projet Amethyst, tel était son nom avant de devenir RP2350, a débuté presque en même temps que celui du RP2040. Le projet Amethyst visait déjà à anticiper les améliorations nécessaires du RP2040.
Suivez le fil de cet article... il se pourrait que vous découvriez d'autres informations croustillantes!
Ce second microcontrôleur créé par le fondation Raspberry-Pi et baptisé RP2350 est basé sur Cortex-M33 double coeurs à 150 Mhz épaulé par une mémoire flash de 4 Mio (QSPI). Le RP2350 dispose aussi d'une mémoire RAM de 512 Kio (presque le double du Pico original).
Ce nouveau microcontrôleur est non seulement plus rapide mais il dispose aussi d'une vraie unité de calcul en virgule flottante double précision. Le RP2350 dispose également d'un support DSP pour le traitement de signal... tout en restant 100% compatible avec le Pico original (logiciel et matériel).
L'augmentation de fréquence d'horloge de 133 MHz à 150 MHz améliore
aussi le temps d'accès à la RAM et à la mémoire Flash mais le gain en
performance va bien au delà des quelques 11% apportés par l'augmentation de
fréquence d'horloge. En effet, une série Cortex-M3 est tellement plus performant qu'une série Cortex-M0.
Côté GPIOs, il y a aussi une surprise:
Les GPIOs sont tolérant 5V ... un grand pas pour le monde rétro!
Les 6 bus
(2x I2C, 2x SPI, 2x UART) qu'il est possible de localiser à de très
nombreux emplacements sur les GPIOs grâce au Bus Fabric.
24 canaux PWM.
toujours 3 entrées analogiques @ 12 bits (500.000 échantillons par seconde). (A noter que la résolution réelle est de 9.5 bits pour rester au dessus du bruit)
16 canaux DMA (pour automatiser des transferts entres périphériques internes et la RAM).
Si
la carte ne dispose toujours pas de lecteur pour carte SD, l'interface SDIO est toujours disponible. Il est toujours possible de réaliser une sortie VGA mais c'est
le nouveau périphérique TMDS qui permettra de créer plus facilement une sortie HDMI/DVI-D qui a attiré mon attention. Le périphérique TMDS est le résultat immédiat du bloc HSTX (High Speed data Transmission) destiné à la transmission de données à haut débit.
Rien n'a changé du côté du support USB et nous avons toujours une fiche micro-USB (là où certains acteurs auraient préférés de l'USB-C même s'il est plus coûteux).
Cortex M33 ou Risc-V
L'une
des grandes nouveautés du RP2350 est la possibilité d'utiliser soit les
2 coeurs ARM Cortex M33, soit deux coeurs RISC-V (ou un coeur de chaque
type).
La sélection des cores utilisés est opéré par la séquence de
boot du Pico 2 qui est capable de détecter l'architecture utilisée dans
le binaire utilisateur (celui qui doit être exécuté après le boot).
RISC-V est un jeu d'instruction en standard ouvert qui fait des émules depuis quelques années. Plus récemment, c'est le déploiement des premiers ordinateurs RISC-V qui fait le buzz. Une technologie qu'il ne faut vraiment plus ignorer! A voir sur riscv.org
La fondation ouvre ainsi la porte des MCU RISC-V avec l'implémentation Open-Source Hazard3(Dépôt GitHub).
Hazard3 prend en charge les spécifications RV32IMAC, une belle occasion de découvrir et tester le monde RISC-V sans devoir acheter un produit spécifique. Le fichier readme de Hazard3 inclus une documentation assez précise... incluant des notes pour mettre en place la chaîne de compilation.
A noter que Hazard3 est le fruit du travail personnel de Luke Wren, l'un des ingénieurs impliqués dans le projet Raspberry-Pi.
MicroPython dispose par ailleurs d'une implémentation RISC-V qui peut être testé sur le Pico 2 comme en témoigne cette vidéo (YouTube)
Mes impressions Avec cette proposition double architecture, il est fort a parier que la fondation explore le potentiel de RISC-V pour une future lignée de microcontrôleur, voire aussi de processeurs. Avec les travaux de Luke Wren, la fondation démontre aussi qu'elle dispose d'un savoir faire en interne... et ce n'est pas rien. Moi qui voulais explorer RISC-V et ses possibilités... voila que cela est servi sur un plateau :-)
Consommation réduite en mode veille
L'une des grosses critiques du Pico original concernait le mode veille (deepsleep) qui consommait une courant de l'ordre de 1 à 2 milliampère. Bien qu'apparemment faible, cela limite la durée de vie d'un projet sur batterie à quelques semaines.
Le Pico 2 dispose d'un tout nouvel étage d'alimentation basé sur un hacheur DC/DC très performant.
Le Pico 2 en mode veille réduit la consommation à moins de 10 µA, ce qui permet d'envisager une durée de vie de plusieurs mois sur batterie.
A noter qu'il est possible de maintenir la RAM interne sous-tension (dit "rétention mode") au prix d'un courant de veille plus important.
RAM en accès concurrent
Les 512 Kio de RAM sont répartis en 10 banques à accès concurrent! Cela signifie que chaque coeur peut accéder à son propre espace RAM en toute indépendance.
Cela autorise un périphérique tierce (ex: ADC, HSTX, PIO) à effectuer des transferts vers une banque mémoire sans être entravé par un autre processus. C'est aussi pour cela que le Pico 2 dispose de 16 canaux DMA!
Cette possibilité d'accès concurrent aux différentes banques permet ainsi d'éviter des temps d'attente imposés par une RAM monolithique ne supportant les accès concurrents. Même si cela n'est pas vraiment neuf, il s'agit là d'une optimisation importante pour maintenir de hautes performances.
Support pour RAM QSPI / PSRAM externe
Le bus QSPI (Quad SPI) est un bus SPI avec 4 lignes de données, ce qui permet de transférer plusieurs bits en un seul cycle d'horloge. Ce type de bus est déjà utilisé sur le Pico original pour accéder à la mémoire Flash.
Le microcontrôleur RP2350 apporte également le support de PSRAM externe déjà très populaire avec les plateformes ESP32. Cela permet d'augmenter la quantité de RAM disponible sur le microcontrôleur jusqu'à atteindre 8 Mio.
A noter que le SparkFun Pro Micro RP2350 propose une carte avec 8Mio de PSRAM et 16 Mio de mémoire Flash.
Il faut cependant garder à l'esprit qu'une telle RAM est accédé par l'intermédiaire d'un bus série (même 4 bits à la fois) et qu'elle inévitablement plus lente que la RAM interne du MicroContrôleur.
Mes impressions Le RP2040 atteignait déjà la puissance d'un Pentium, puissance que l'on dépasse allégrement avec le RP2350. Avec une PSRAM externe, le support USB et le périphérique TMDS (que nous verrons plus tard) il devient évident qu'il est possible de créer un ordinateur rétro type Pentium à partir d'un Pico RP2350. Il va être possible de créer de puissant émulateurs avec un tel MCU.
XIP: amélioration accès à la mémoire Flash
L'accès à la mémoire flash dispose d'une plus grande bande passante grâce à une technique de cache double-banked (word stripping).
Le support de l'interface XIP (eXecute In Place) permet au MCU d'exécuter des instructions directement depuis la mémoire Flash sans nécessiter de cycle d'horloge supplémentaire. Il me semble que cette technique est déjà exploitée par MicroPython depuis un bon moment.
Les temps de transferts sont également améliorés avec des modes accélérés (burst) en lecture/écritures, translation d'adresse et "odd clock divisors" (qui me paraît encore obscure).
Mes impressions La présence d'un Burst Mode est particulièrement pratique pour tous les projets exploitant un système de fichiers en Flash. Je pense plus particulièrement à MicroPython / CircuitPython.
Améliorations PIO
Cette section cache une petite pépite!
PIO (Programmable IO) est un langage de bas-niveau offre de vrais avantages concernant le traitement de données et manipulations des entrées/sorties en bas niveau. PIO offre des machines à état fini (StateMachine) associé à un GPIO et à une programme PIO (qui manipule le GPIO). Le programme sera exécuter à une fréquence entre 2000 Hz et 125.000.000 Hz (125 MHz). PIO permet d'envisager la réalisation d'application "time-critical" comme, par exemple, une sortie VGA, HDMI, transfert haut debit.
Le RP2350 se voit accompagné d'un 3ieme bloc PIO, ce qui porte le nombre processus PIO à 12 machine à état! ... Soit 12 mini-processus autonomes indépendants des coeurs.
Non seulement les PIO profitent de l'augmentation de fréquence à 150 MHz (contre 133 Mhz) mais le RP2350 dispose d'instructions PIO supplémentaires.
Le nouveau périphérique HSTX (High Speed Transfert) permet de créer une sortie DVI (TMDS) avec un faible impact sur le système... laissant ainsi beaucoup de ressource disponibles pour le projet. Il est ainsi possible de créer une sortie VGA à 60 Hz sans overclocking produisant deux pixels en sortie par tick.
Le seul autre endroit où j'en ai entendu parlé est sur cette vidéo d'Adafruit Industrie qui semble avoir capté le potentiel de ce périphérique.
Architecture sécurisée
La grande nouveauté du RP2350 est l'apport d'une architecture sécurisée. Si celle-ci intéressera surtout les professionnels, elle apporte aussi ses avantages aux monde des Makers.
RP2350 inclus la fonctionnalité "ARM TrustZone-M" qui permet d'isoler du code et ses données du reste de l'application à l'aide de 8 SAU (Secure Attribut Unit). Voir TrustZone technology for Armv8-M Architecture sur arm.com .
Les applications industrielles utiliseront cette fonctionnalité pour verrouiller leur firmware ou garder les éléments importants à l'abri des yeux indiscrets.
Les Makers pourrons utiliser cette fonctionnalité pour y cacher des jetons de connexion (Tokens) des clés d'accès aux API (API Keys), clé WiFi et des informations privées.
Ainsi, si le projet se perd dans la nature, il n'y a aucun risque pour les données sensibles qu'il transporte.
L'architecture sécurisée inclus:
Secure boot : pour empêcher l'exécution de code non autorisé sur le RP2350
Encrypted boot : pour empêcher la lecture non autorisée du code et des données.
Isolated execution : code sécurisé et code non-sécurisé peuvent être exécutés en même temps. Le code sécurisé a accès à la zone non-sécurisée (mais pas l'inverse!)
Cette architecture sécurisée est possible grâce aux éléments suivants:
8Kio de Mémoire antifuse OTP (one-time-programmable) permettant la configuration de clé de stockage (avec blocage matériel ou logiciel).
Signature du boot (optionnel). Cette vérification est effectué par ma Mask ROM du microcontrôleur (donc non modifiable/non attackable) avec l'empreinte de la clé (fingerprint) stocké dans la mémoire OTP!
Un stockage OTP protégé pour la clé de décryption du boot (optionnel)
Voici une petit vidéo de Aaron Christophel qui cherche le meilleur point d'attaque pour injecter une impulsion électromagnétique en vue d'extraire le firmware d'un LPC2388. C'est la méthode de Glictching qui est ici utilisée. Cette analyse débouche sur une seconde vidéo où le firmware est extrait de la carte.
A propos de la mémoire OTP AntiFuse
OTP (One Time Programmable) est une mémoire de type ROM que l'on peut programmer une seule fois. Elle peut être utilisé pour y stocker des clés.
La mémore OTP offre une excellente résistance aux attaques car il n'est pas possible de lire les bits à l'aide d'un microscope à balayage (oui, il y a des moyens dans l'espionnage industriel).
Comme le montre l'image ci-dessous, une mémoire eFuse OTP traditionnelle, il est très facile de lire le bit (s'il est à 1 ou à 0) puisque la section de métal est vaporisée sur le fusible.
Les AntiFuse OTP fonctionnent différemment car on brûle volontairement le la jonction d'un "transistor" (son substrat) créant ainsi une voie d'écoulement permanente pour le courant! La différence ici, c'est qu'il n'est pas possible d'identifier les jonctions non-altérée des jonctions en court-circuit.
C'est à la vue de tous... mais pas lisible :-) Il semblerait que ce type de jonction soit aussi beaucoup plus difficile à manipuler avec les techniques usuelles d'espionnage industriel.
Le microcontrôleur RP2350 existe en deux versions A et B (30 GPIOs et 48 GPIOs). Le MCU équipant le Pico 2 est le RP2350A qui expose 30 GPIOs sur un composant en QFN60 (10x10mm) avec une mémoire Flash externe de 4 Mio (contre 2 Mio Pico original).
Ces révisions ne concernent pas vraiment le Pico 2 mais les Makers disposés à créer leurs propres cartes!
Là où les choses deviennent intéressantes:
Le RP2350B dispose aussi de 8 entrées analogiques!
Le RP205xA & B seront disponibles avec 2 Mio de mémoire Flash QSPI stacked-in-package (c'est à dire empilé au dessus microcontrôleur).
Ces nouvelles variantes portent les références RP2354A and RP2354B (avec le dernier chiffre 4 indiquant la quantité de mémoire Flash empilé sur le microcontrôleur.
Nouveau SDK 2.0
La sortie du nouveau RP2350 et du Pico 2 coïncide avec la sortie du SDK 2.0. Rien de vraiment étonnant puisqu'il faut pouvoir supporter les nouvelles fonctionnalités du RP2350.
Il y a de nouvelles options CMake font leurs apparitions pour le support RP2350.
Le SDK inclus la configuration du boot OTP et la programmation des clés. Le SDK couvre également l'exécution de sécurisé (Secure Code).
Enfin, le SDK Python prend en charge le RP2350 ainsi que le support WiFi, Bluetooth, Ethernet pour le Pico 2.
Le Pico 2 Wireless est d'ores et déjà annoncé pour la fin de l'année 2024. Ce dernier utilisera le même module que pour le Pico original.
En attendant, il semble que Wiznet dispose déjà de cartes RP2350 à base de ses Chip Ethernet W5100S, W5500, W6100.
Le langage RUST est devenu très populaire ces dernières années. Très similaire au C, RUST est surtout réputé pour sa fiabilité d'exécution (plus d'info en Français ou en Anglais).
Cela signifie que des carte Pico 2 et le SDK étaient disponibles pour ajouter le support RP2350 à Rust. Une preuve, s'il en faut, que la fondation prend Rust très au sérieux!
Intégration MicroPython
Est-il vraiment nécessaire de préciser qu'il existe une version MicroPython / CircuitPython disponible le jour même de la sortie du Pico 2 et du RP2350 ?
Les amateurs de MicroPython seront heureux d'apprendre qu'une nouvelle bibliothèque qwiic-serlcd-i2c vient d'être ajoutée à notre dépôt esp8266-upy
Qu'est ce que SerLCD?
SerLCD de SparkFun est un afficheur LCD série propulsé par un microcontrôleur
ATmega328P. SerLCD permet d'ajouter un afficheur Cristaux Liquide 16x2
RGB dans votre projet. Le microcontrôleur gère l'écran et les
communications séries!
Les afficheurs SerLCD peuvent communiquer de trois façon différentes:
série, I2C et SPI. L'afficheur est équipé de d'un connecteur Qwiic
(aussi appelé StemmaQT), ce qui l'intègre dans l'écosystème Qwiic qui
simplifie les raccordements grâce à sa connexion universelle.
Outre son connecteur Qwiic/StemmaQt, l'intérêt de SerLCD réside dans son support du bus I2C (il n'a donc besoin que des signaux SDA et SCL) et que l'adresse I2C est modifiable de façon logicielle.
La bibliothèque
Cette dernière -nommée serlcd.py- est disponible sur le dépôt dans le sous-répertoire qwiic-serlcd-i2c.
Elle doit être copiée sur votre plateforme MicroPython avant de pouvoir l'utiliser.
Si vous utilisez mpremote, l'installation peut se faire très simplement à l'aide de la commande suivante:
Pour pouvoir utiliser cet afficheur, il suffit d'utiliser son connecteur Qwiic/StemmaQt avec un câble adaptateur JST-SH 4 . Le raccordement est super simple.
En guise d'exemple, voici le raccordement sur un Raspberry Pico... simple non?
Connexion
.png)
