Vue normale

Raspberry-Pi 5: API MicroPython pour Python

 Bonjour à tous,

Tout récemment, je voulais utiliser un module RFM69 sur un Compute Module 5 (autrement dit l'équivalent d'un Raspberry-Pi 5) faisant fonctionner un logiciel écrit Python.

Une API MicroPython sous Python

Ecrivant de nombreux pilotes pour MicroPython (Python pour MicroContrôleur), je me suis dit qu'il devait être possible de réutiliser le code MicroPython du RFM69 sous Python sans devoir réécrire tout-ou-une-partie du code pour qu'il fonctionne sur Raspberry-Pi.
 
Le problème, c'est que Python n'a aucune idée de ce qu'est l'API MicroPython (celle utilisée par MicroPython pour accéder directement à la couche matérielle).
 
Il existe cependant des moyens d'accéder au matériel depuis Python mais c'est sans aucun rapport avec l'API exposée MicroPython.

L'idée c'est de recréer l'API MicroPython sous Python pour permettre l'utilisation du RFM69 depuis Python:
 

Le module RFM69

L'image ci-dessous se présente le module RFM69HCW 433MHz . Ce module permet de transmettre des données sur un réseau numérique utilisant le ondes-radios comme medium de transfert. C'est un peu le protocole internet appliqué à la radio.

RFM69HCW 433MHz

Comme le Pilote est développé sous le précepte "Plateform Agnostic Driver" de sorte à pouvoir fonctionner indépendamment de la plateforme MicroPython cible.

esp8266-upy - Plateform Agnostic Micrpython Driver

Ce module se branche sur un bus SPI, il est donc possible de le connecter sur GPIO d'un Raspberry-Pi 5 (ou du Compute Module 5).

Source: Raspberry-pi.ovh

Brancher RFM69 sur GPIO

Les connexions suivantes sont établies entre le module RFM69 et le GPIO Raspberry-Pi.

La broche CS (chip select) est branchée sur le GPIO 25 alors qu'il existe les broches CE0 (GPIO8) et CE1 (GPIO7). 

Le problème ici est que CE0 et CE1 sont automatiquement gérés par le système d'exploitation alors que sous MicroPython, c'est le code utilisateur qui gère l'état du signal CS.

Dans le cas présent, la gestion automatique de CE0 et CE1 empêche l'utilisation du burst_read sur le module RFM69 raison pour laquelle le GPIO25 est utilisé comme signal CS (ce signal étant contrôlé par le code utilisateur).

Prototype

Compatibilité avec Python

Commençons par récupérer la bibliothèque MicroPython du RFM69 depuis le dépôt esp8266-upy pour y ajouter l'encodage du fichier (important pour Python).

Ajout de l'encodage dans le bibliothèque RFM69

Récupérer l'exemple test_config.py utilisé pour tester la communication avec le module RFM69. Nous y ajoutons également l'information d'encodage dans le fichier.

Couche de compatibilité Python --> MicroPython

Création des fichiers machine.py et micropython.py pour accueillir les classes Pin & SPI ainsi que la déclaration de la fonction const()


Le script le plus intéressant est hack_time.py car celui-ci permet d'ajouter les fonctions MicroPython (ticks_ms, ticks_diff, sleep_ms, etc) manquantes dans Python.

#!/usr/bin/python
# -*- coding: utf-8 -*-
""" hack_time.py : mimic the MicroPython alike specific methods """
import time

def _sleep_us( us ):
	time.sleep( us*0.000001 )

def _sleep_ms( ms ):
	time.sleep( ms*0.001 )

def _ticks_ms():
	return int(time.time()*1000)

def _ticks_diff( v1, v2 ):
	return v1-v2

time.sleep_us = _sleep_us
time.sleep_ms = _sleep_ms
time.ticks_ms = _ticks_ms
time.ticks_diff = _ticks_diff

Il ne reste plus qu'a adapter le script d'exemple pour créer l'instance du bus SPI (sur le RPi) et passer le tout à la bibliothèque MicroPython originale.

#!/usr/bin/python
# -*- coding: utf-8 -*-

from machine import SPI, Pin
import hack_time
from rfm69 import RFM69

# Machine.py for Raspberry-Pi 5
spi = SPI( 0 )
nss = Pin( 25, Pin.OUT, value=True )  # Do not use the RPI CE0/CE1, it is not compatible with the Burst_Read of RFM69
rst = Pin( 18, Pin.OUT, value=False )

rfm = RFM69( spi=spi, nss=nss, reset=rst )
rfm.frequency_mhz = 433.1
....

Le bus SPI est rattaché au bus matériel SPI0 & CE0. 

Une broche Enabled (nss) alternative est utilisé avec le GPIO25 pour contrôler les transactions du bus SPI. La broche CE0 du GPIO est donc ignorée.

Enfin, le GPIO 10 est utilisé pour réinitialisé le module RFM69.

Au final, la création de l'instance RFM69 et le restant du code (y compris la bibliothèque RFM69) est identique entre MicroPython et Python (sur RPi5).

L'exécution de l'exemple sur le Raspberry-Pi 5 produit le résultat attendu (identique lorsqu'il est exécuté sur un Pico).

test_config.py : exécution de la bibliothèque
MicroPython RFM69 sur Raspberry-Pi 5

Ressources

  • MicroPython-API-for-Python experiment is published on GitHub.


Pico-2-Explorer : ce que des clients en pensent

Bonjour à tous,

Je profite de l'occasion pour faire suivre quelques commentaires clients concernant le Pico-2-Explorer et sa documentation.

Pico-2-Explorer disponible chez MC Hobby

 Merci à Christian H. pour son retour

Pico explorer est idéal pour commencer la programmation tout y est bien expliqué, je n'ai eu aucun problème. Merci beaucoup.

Merci aussi à Paul L. pour son retour

Très intéressant

Le Pico-2-Explorer à venir découvrir chez MC Hobby

Pico-2-BB : Garder un maximum de place sur le breadboard

Bonjour à tous,

Aujourd'hui, j'aimerais vous parler d'une idée pour faciliter le prototypage avec le Raspberry-Pi Pico.

Le meilleur adaptateur breadboard pour Pico

Constat avec le Pico

Lorsque le Pico est inséré directement sur un breadboard (demi-taille, le plus courant):

  • Une grande partie du breadboard est occupé par le Pico.
  • Il reste deux rangs de connexion pour le prototypage. 
  • Il n'y a pas de distribution d'alimentation sur les rails d'alimentation.
  • Il n'y a toujours pas de bouton Reset

 Pour faire un prototypage rapidement c'est convenable mais dès que cela se complique un peu, on manque rapidement de place.

Pico-2-Breadboard

Le Pico-2-Breadboard permet de brancher un Pico/Pico2/Pico-Wireless/Pico2-Wireless sur un breadboard en apportant une foule d'avantages.

Pico-2-Breadboard

 Il a l'air de rien vu comme ça mail il y une intense réflexion autour de la conception de cette carte.
Cette carte est d'ailleurs réalisée en 4 couches afin de pouvoir réaliser le routage.

Encombrement minimum

Pico-2-Breadboard

Pour commencer, la disponibilité des GPIO n'utilise que la moitié du breadboard MAIS EN PLUS il n'utilise qu'un seul rang sur le breadboard.
Cela laisse quatre rangs pour réaliser les connexions de prototypage.

Les rails d'alimentation son automatiquement alimentés:

  • +5V et GND sur le rail supérieur. En provenance du connecteur USB.
  • +3.3V et GND sur le rail inférieur. En provenance du régulateur du Pico.
 A noter que la tension d'alimentation et polarité sont indiqués sur la sérigraphie.

Interface utilisateur

Une interface utilisateur minimale permet de se concentrer directement le coeur du prototypage (souvent un capteur à tester).

Interfaces du Pico-2-Breadboard

L'interface utilisateur est composée des éléments suivants:
  • Bouton Reset: pour redémarrer rapidement le Pico. Ce dernier est bien séparé des deux boutons utilisateurs pour éviter de se tromper.
  • Boutons utilisateurs: branchés respectivement sur les GPIO 16 et 17, il force le potentiel d'une broche à la masse via une résistance de 100 Ohms. Il faudra donc activer la résistance pull-up avec
    btn = Pin(Pin.board.GP16, Pin.PULL_UP)
    Remarque: la résistance est utilisée pour éviter un court-circuit franc si la broche était configurée en sortie (lorsque le bouton est pressé).
  • LEDs utilisateurs: une LED rouge est branchée sur GP14 (en haut, comme sur un feu tricolore) et une LED verte sur le GP15. 
    Avec la LED du Pico, cela fait 3 LEDs pour réaliser une interface... même rudimentaire.

Connecteurs Qwiic/StemmaQT et Grove

Le dessous de la carte Pico-2-BB qui est déporté hors du breadboard.
Cela a permit de placer des cavaliers de configuration et deux connectiques populaires.
Connecteurs et configuration du Pico-2-Breadboard

Connecteur Grove et Qwiic/StemmaQT
 
Ces deux connecteurs sont branchés sur le même bus I2C(1) connecté sur les GP6 & GP7. C'est d'ailleurs pour cette raison que la mention des libellés est sda et scl sur le connecteur GPIO central.
 
Le connecteur Qwiic/StemmaQT permet de brancher facilement des capteurs I2C produit par Adafruit Industries ou SparkFun. C'est vraiment très pratique pour connecter un afficheur LCD ou OLED!
 
Le connecteur Grove (de SeedStudio) permet de brancher des capteurs I2C SeedStudio exploitant une alimentation et une logique 3.3V.
Je peux recommander les capteurs I2C et extension I2C de M5Stack qui utilisent exclusivement une logique 3.3V.
 
Remarques:
  1. Un cavalier permet de configurer la tension d'alimentation du connecteur Grove sur 5V.
    Il suffit de sectionner la piste entre la pastille centrale et la pastille 3V3.
    Enfin, souder ensemble les pastilles centrales et 5V.
  2. Peut importe la tension sur le connecteur Grove, les signaux logiques restent en 3.3V
  3. Rien n'empêche d'utiliser les GP6 et GP7 en entrée/sortie mais c'est aussi se priver d'une interface I2C sur-laquelle il est possible de connecter de multiples périphériques.

Cavalier de configuration des LEDs

Il est possible d'utiliser les GPIO des LEDs en entrée/sortie pour autre chose que contrôler les LEDs utilisateurs. Pour libérer la broche de l'influence de sa LED utilisateur, il suffit de sectionner la piste présente entre les pastilles JP_Green (LED verte) et JP_Red (LED rouge). 
 
Remarque:
  1. Les GPIOs des boutons utilisateurs peuvent être librement utilisés à d'autres fins. Il n'y aura pas de perturbation pour autant que l'utilisateur ne presse pas le bouton correspondant au GPIO.

Où acheter

Le Pico-2-BB ("Pico to Breadboard" ou encore "Pico 2 Breadboard") est disponible chez MCHobby.

❌