Programmer
Préambule
Les précédents chapitres du livre ont exploré de nombreux aspects relatifs à l’utilisation d’une carte MicroPython.
Jusque-là, seules des informations d’ordre technique (le brochage de la carte) ou sur l’environnement de travail (utilisation de RShell, REPL, PuTTY, etc.) ont été abordées.
À ce stade de l’ouvrage, la session REPL n’a plus vraiment de secrets pour le lecteur et elle permettra de tester rapidement quelques lignes de code. Les outils nécessaires à un travail convivial (PuTTY, RShell, etc.) font également partie de la boîte à outils de l’utilisateur.
Les exemples de codes pourront être saisis sur une invite de commandes REPL ou codés dans un fichier Python qui sera transféré et exécuté sur la carte MicroPython en appliquant l’une ou l’autre des méthodes présentées précédemment (cf. Prise de contrôle).
Le seul point qui n’a pas encore été abordé est le chargement et l’exécution d’un script à la volée, technique abondamment utilisée par l’auteur et aussi la raison pour laquelle RShell est activement promu dans cet ouvrage (cf. la section Charger et exécuter un script à la volée).
Le présent chapitre va, lui, s’attarder...
Les bibliothèques MicroPython
C’est connu, la puissance du langage Python réside aussi dans sa philosophie « Batteries Included ! » (piles incluses). En effet, l’environnement Python est distribué avec de nombreuses bibliothèques standardisées et MicroPython ne fait pas exception à cette règle, mais avec quelques nuances.
En effet, les ressources disponibles sur un microcontrôleur sont très loin de ce qui est disponible sur un ordinateur. Ces limitations concernent surtout l’espace de stockage et la mémoire RAM disponible.
Par conséquent, toutes les bibliothèques standards de Python ne sont pas présentes dans le firmware MicroPython. Pour celles qui sont présentes sur MicroPython, seul l’essentiel des fonctionnalités est présent.
Les bibliothèques standards sont « micropythonifiées » pour ne retenir que les éléments fondamentaux (pas besoin de gérer les différents types de calendriers, la manipulation des dates et heures est amplement suffisante pour un microcontrôleur). Il est donc assez courant de parler de la « Micro-bibliothèque », aussi appelée « Micro-librairie » en traduction incorrecte de l’anglais « Micro-library ».
1. Le préfixe u
Par essence, les bibliothèques « micropythonifiées » ne contiennent que les éléments essentiels de la bibliothèque standard correspondante sur PC.
C’est entre autres le cas de la bibliothèque JSON et la raison pour laquelle le préfixe µ (micro) précède le nom de la bibliothèque.
Il est assez commun de remplacer le caractère µ par la lettre u en minuscule afin d’améliorer la compatibilité avec les systèmes informatiques (un héritage anglo-saxon).
Dans le cas de la bibliothèque JSON, la version micropythonifiée se nomme ujson (et non µjson).
Le préfixe u n’est pas une bizarrerie issue du monde MicroPython. Il est utilisé depuis des lustres dans les catalogues informatisés des distributeurs de produits électroniques (uF pour microFarad utilisé pour les capacités). Ce même préfixe...
Bibliothèques disponibles
MicroPython dispose déjà d’une grande quantité de bibliothèques. Certaines sont déjà présentes au sein du firmware (voir commande help(’modules’)), d’autres peuvent être téléchargées depuis le GitHub MicroPython (https://github.com/micropython/micropython-lib) puis déposées dans le système de fichiers MicroPython.
Les bibliothèques sont réparties en trois catégories :
-
bibliothèques standards et micropythonifiées,
-
bibliothèques propres à MicroPython,
-
bibliothèques spécifiques à la carte de développement.
1. Bibliothèques standards et micropythonifiées
Ces bibliothèques sont destinées à fonctionner sur tous types de cartes MicroPython. Bon nombre d’entre elles sont par ailleurs chargées dans le firmware.
La bibliothèque standard reprend les fonctions internes de Python (dir, help…) ainsi que les classes d’exception.
Il est possible de consulter la documentation de ces modules directement depuis http://docs.micropython.org/en/latest/library.
-
array : permet de gérer des tableaux de façon compacte tout en supportant de nombreux types de données comme des caractères, des entiers, des nombres décimaux...
-
cmath : offre des fonctions mathématiques permettant de travailler avec des nombres complexes (a + i b). À noter que cmath exploite le support en virgule flottante. De fait, ce module n’est pas utilisable sur des plateformes comme ESP8266 ou WiPy 1.
-
gc : permet de contrôler le ramasse-miettes Python (garbage collector en anglais). Cette bibliothèque contient également les fonctions mem_alloc() et mem_free(), très pratiques pour surveiller la consommation de mémoire.
-
math : sans surprise, cette bibliothèque offre le support des fonctions mathématiques comme sin(),cos(), logarithme, exponentiel, conversion radians/degrés, etc.
-
sys : permet d’accéder aux informations concernant le système. Cette bibliothèque permet d’obtenir la version de MicroPython, l’identification de la plateforme hôte (Linux ou Pyboard), les flux d’entrée/sortie/erreur (stdin, stdout et stderr) même sur un microcontrôleur....
Bibliothèque machine
La bibliothèque machine contient l’API standardisée orientée vers la portabilité du code Python. machine permet de contrôler les périphériques tels que les bus de données (I2C, SPI…), des broches d’entrées/sorties, etc. Grâce à l’API standardisée, le contrôle des périphériques est identique sur les différentes plateformes MicroPython.
L’API standardisée implique que la mise en œuvre des fonctionnalités matérielles reste identique au travers de toutes les plateformes estampillées « MicroPython ».
Les scripts exploitant l’API standardisée fonctionneront aussi bien sur la plateforme cible (ex. : Pyboard) que sur d’autres cartes MicroPython (comme Pyboard-D, WiPy, ESP8266, ESP32, LoPy, etc.).
Il est possible de consulter la documentation de la bibliothèque machine depuis le site micropython.org : http://docs.micropython.org/en/latest/library/machine.html
1. Limitation de la portabilité
La standardisation de la bibliothèque machine a cependant ses limitations.
En effet, il n’est pas possible de créer une API uniforme incluant toutes les spécificités de toutes les plateformes microcontrôleurs existantes sur le marché.
L’API standardisée de machine regroupe donc les fonctionnalités les plus communes des microcontrôleurs. Ce qui permet de couvrir presque tous les cas de figure et les besoins les plus courants.
C’est aussi la raison pour laquelle il existe généralement une bibliothèque spécialisée (pyb dans le cas de la Pyboard) prenant en charge les fonctionnalités avancées du microcontrôleur cible.
2. Quel intérêt pour la portabilité ?
Il semblerait tout à fait raisonnable de juger la portabilité comme « peu engageante » dans le cas de développement sur microcontrôleur. L’API standardisée n’autorise pas l’exploitation des fonctionnalités avancées de la plateforme cible alors que celle-ci est généralement sélectionnée pour ses caractéristiques avancées.
Il est d’ailleurs peu probable qu’un développement...
Bibliothèque pyb
Comme précisé précédemment, la bibliothèque pyb contient l’API historique des cartes Pyboard. Elle expose également les API pour les éléments non standardisés de l’API machine.
Lors du développement de pilotes matériels pour des capteurs, il est vivement recommandé d’utiliser l’API machine et ce en vue d’offrir une portabilité maximale vers d’autres plateformes MicroPython (ex : ESP32, WiPy, etc.).
Les classes les plus pertinentes sont affichées en gras dans le tableau ci-dessous.
Classe |
Description |
Accel |
Contrôle de l’accéléromètre présent sur la carte. |
ADC |
Convertisseur analogique vers numérique (permet de lire une tension analogique). |
CAN |
Bus de communication CAN (Controller Area Network). |
DAC |
Convertisseur numérique vers analogique (permet de produire une tension analogique). |
ExtInt |
Permet de configurer une broche d’entrées/sorties pour déclencher une interruption sur la base d’un événement externe. |
I2C |
Bus I2C (2 fils) autorisant la connexion de nombreux capteurs. |
LCD |
Contrôle de l’afficheur LCD pyskin. |
LED |
Contrôle des LED de couleur présentes sur la carte Pyboard. |
Pin |
Contrôle des broches d’entrées/sorties. Lecture et modification d’état. |
PinAF |
Bien... |
Bibliothèque os
Une autre bibliothèque importante est os car elle permet la manipulation du système de fichiers MicroPython depuis du code Python et donc aussi à distance via une session REPL.
La bibliothèque os contient les fonctions pour l’accès et le montage de systèmes de fichiers. La bibliothèque prend également en charge la déviation et la duplication du terminal MicroPython (REPL) ainsi que le générateur de nombres aléatoires urandom() et l’identification du système uname().
La fonction la plus utile de la bibliothèque reste listdir() permettant de lister les fichiers présents dans un répertoire depuis une session REPL.
Il est important de rappeler que le firmware MicroPython utilise la notion de système de fichiers par défaut (cf. MicroPython Pyboard - Système de fichiers MicroPython). La bibliothèque os exploite cette spécificité et applique son traitement sur le système de fichiers par défaut, donc la carte microSD si elle est présente et la mémoire flash dans le cas contraire.
La totalité du système de fichiers reste cependant accessible par l’intermédiaire des répertoires /, /sd et /flash.
Système de fichiers MicroPython
La section ci-dessous reprend les éléments importants de la bibliothèque...
Charger et exécuter un script à la volée
Il existe de nombreuses solutions pour éditer des lignes de codes MicroPython et les tester sur le microcontrôleur Pyboard.
Cependant, dès que les développements dépassent la centaine de lignes de code (ou le développement dans de multiples bibliothèques), ces outils montrent rapidement leurs limites.
Ce que l’expérience aura démontré, c’est que l’utilisation d’un outil comme RShell (cf. Prise de contrôle - RShell) permet à la fois de gérer le transfert de fichiers vers la carte Pyboard et le test du code à la volée depuis une session REPL.
Ainsi, durant le développement d’un pilote pour un capteur donné, le sous-répertoire examples/ sur PC contient un ou plusieurs scripts de test (ex. : test.py).
Le développement se fait sur PC, les fichiers sont copiés sur la carte avec RShell, y compris le fichier de test test.py.
Dans l’exemple suivant, c’est le code source du capteur de pression atmosphérique MPL115A2 qui sera exploité. Ce capteur est très facile à se procurer chez Adafruit Industries ou via son réseau de revendeurs. Ce code disponible sur le dépôt suivant : https://github.com/mchobby/esp8266-upy/tree/master/ncd-mpl115a2
Dépôt du pilote MicroPython...
Exploiter l’accéléromètre
Pour les utilisateurs ayant la chance de disposer de la Pyboard originale, celle-ci est déjà équipée d’un accéléromètre dont la bibliothèque est présente dans le firmware MicroPython (cf. MicroPython Pyboard - Présentation de la Pyboard).
L’accéléromètre permet de détecter les accélérations et décélérations (les chocs), mais également la position de la carte par rapport au centre de gravité terrestre.
Utilisation de l’accéléromètre de la Pyboard.
L’accéléromètre est branché sur les broches X9 et X10, donc le bus I2C(2) de la Pyboard (cf. MicroPython Pyboard - Brochage de la Pyboard).
Accéléromètre MMA7660 présent sur la Pyboard
L’accéléromètre est pris en charge par la classe Accel de la bibliothèque pyb. Elle est très simple à tester depuis une session REPL en utilisant le code suivant :
>>> import pyb
>>> import time
>>> acc = pyb.Accel()
>>> while True:
... print( 'x: %3i | y: %3i | z: %3i' % (acc.x(), acc.y(), acc.z()) )
... time.sleep(0.5)
...
x: 1 | y: -1 | z: 22
x: 2 | y: -1 | z: 22
x: 2 | y: -1 | z: 23
x: 3 | y: 0 | z: 22
x: 2 | y: 0 | z: 22
x: 1 | y: -2 | z: 22
x: 1 | y: -1 | z: 22
x: 3 | y: 7 | z: 20
x: 9 | y: 14 | z: 14
x: 11 | y: 18 | z: 9
x: 8 | y: 16 | z: 14
x: 4 | y: 5 | z: 23
x: -9 | y: -2 | z: 19
x: -13 | y: -1 | z: 15
x: -3 | y: 4 | z: 20
x: 14 | y: 0 | z: 19
x: 11 | y: -3 | z: 22
x: 2 | y: -1 | z: 23 ...
Entrées/sorties
La présentation des broches de la carte (cf. MicroPython Pyboard - Brochage de la Pyboard), mettait en avant les fonctionnalités multiples que chacune d’entre elles peut avoir (SPI, I2C, CAN, UART, PWM, IO).
Parmi ces fonctionnalités, c’est l’usage en entrée/sortie qui est le plus simple à mettre en œuvre, mais aussi le plus intéressant lors d’un premier contact. L’usage en entrée/sortie est également mentionné IO ou très communément GPIO (General Purpose Input Output = entrée/sortie à usage général).
Utilisé en entrée, le niveau logique de la broche devient flottant et son état est fixé par une source de tension externe (un montage). Configurée de la sorte, la broche peut détecter le niveau logique haut (3,3 V) ou bas (0 V) appliqué sur elle. Il est donc possible de détecter l’activation d’un bouton ou d’un capteur.
Utilisée en sortie, la broche contrôle pleinement son niveau logique qui peut être placé au niveau haut (3,3 V) ou au niveau bas (0 V). De la sorte, la broche peut être utilisée pour commander une LED, un relais, des moteurs (par l’intermédiaire d’un pont-H), etc. Une broche en sortie ne peut fournir qu’une très faible puissance. Tout périphérique de puissance (ex. : moteur) nécessitera la mise en place d’une électronique de puissance/commande adéquate.
Tolérance 5 V et ses pièges
La carte MicroPython Pyboard utilise un microcontrôleur en logique 3,3 V. La plupart de ses entrées sont tolérantes 5 V. Il est donc tentant d’utiliser du matériel issu du monde Arduino Uno (logique 5 V) pour le brancher directement sur la Pyboard.
Ce faisant, le risque est d’oublier que « la tolérance 5 V est une exception » et de négliger de prendre les précautions adéquates lors du passage sur une vraie plateforme 3,3 V (sans tolérance 5 V).
Pour cette raison, et à moins de concevoir un produit, il est vivement recommandé d’ignorer la tolérance 5 V de la Pyboard et de l’utiliser comme un microcontrôleur en logique 3,3 V. Au mieux, la tolérance 5 V permettra...
Identification et mode des broches
Il est possible d’identifier le mode de fonctionnement des broches en interrogeant la classe Pin.board. La représentation de l’objet ainsi obtenue dans la session REPL nous apprend que la broche Y9 est utilisée en entrée (mode=Pin.IN).
>>> Pin.board.Y9
Pin(Pin.cpu.B10, mode=Pin.IN)
Il est également possible d’obtenir une vue complète de toutes les broches du microcontrôleur à l’aide de deux lignes de code.
>>> from machine import Pin
>>> for name in dir( Pin.board ):
... print( '%-10s : %r' % (name, Pin(name)) )
...
X1 : Pin(Pin.cpu.A0, mode=Pin.IN)
X2 : Pin(Pin.cpu.A1, mode=Pin.IN)
X3 : Pin(Pin.cpu.A2, mode=Pin.IN)
X4 : Pin(Pin.cpu.A3, mode=Pin.IN)
...
X17 : Pin(Pin.cpu.B3, mode=Pin.IN, pull=Pin.PULL_UP)
X18 : Pin(Pin.cpu.C13, mode=Pin.IN)
X19 : Pin(Pin.cpu.C0, mode=Pin.IN)
SW : Pin(Pin.cpu.B3, mode=Pin.IN, pull=Pin.PULL_UP)
LED_RED : Pin(Pin.cpu.A13, mode=Pin.OUT)
LED_GREEN : Pin(Pin.cpu.A14, mode=Pin.OUT)
LED_YELLOW : Pin(Pin.cpu.A15...
Les timers
Les timers sont des éléments matériels indépendants capables d’égrainer le temps et de mesurer des durées ou compter des événements, générer un signal, transférer des données (DMA), etc.
L’idée maîtresse est qu’un timer peut horodater l’exécution d’une tâche à intervalle régulier, mais là n’est pas sa seule fonction.
La caractéristique fondamentale d’un timer est sa fréquence. Par exemple, un timer avec une fréquence de 25 Hertz peut appeler une fonction de rappel (dite fonction callback) 25 fois par seconde. Autrement dit, avec une période de 1/25 = 0,04 sec = 40 ms.
Le timer peut être utilisé pour remplir une grande variété de tâches, nombre d’entre elles ont été abordées dans le chapitre consacré à la carte MicroPython Pyboard (cf. MicroPython Pyboard, Brochage avancé et timers).
Les précédents points de ce même chapitre mettaient déjà en avant l’usage des timers dans les situations suivantes :
-
l’acquisition de signal analogique (cf. section Entrée analogique),
-
la production de signal analogique (cf. section Sortie analogique),
-
la production de signal PWM (cf. section Sortie PWM),
-
le contrôle de servomoteurs (cf. section Sortie Servo).
Ces points mettaient en lumière la relation matérielle entre les timers et les différentes broches de la Pyboard comme l’indiquent les graphiques ci-dessous, graphiques déjà rencontrés à plusieurs reprises dans l’ouvrage.
Association broche avec timer et canal
Le choix d’utiliser un timer doit satisfaire aux contraintes imposées par le matériel. En règle générale, un timer exploité pour une tâche matérielle ne peut pas servir à une autre tâche horodatée. Par exemple, si le timer 2 est utilisé pour générer un signal PWM sur la broche Y10, celui-ci ne pourra pas être utilisé pour appeler une fonction de rappel toutes les 10 ms (1/10 ms = 1/0,010 = 100 Hertz) ou pour générer un signal PWM sur la broche X2.
La réalité est plus nuancée, mais il est inutile...
Bus I2C
Préambule
Cette section sur le bus I2C est relativement chargée en informations techniques (de vulgarisation et avancées).
Le lecteur doit savoir que sa compréhension ne représente pas un frein rédhibitoire à la poursuite de son apprentissage. Rien n’empêche de revenir plus tard sur ce chantier si cela est nécessaire.
Le chapitre suivant, qui exploitera nombre de composants I2C, s’appuiera sur des bibliothèques, ce qui simplifiera la mise en œuvre des exemples.
Introduction
Le bus I2C (I2C) est un bus de données deux fils permettant de transférer des données entre plusieurs composants. Généralement méconnu des débutants qui se concentrent sur la manipulation des broches du GPIO, le bus I2C devient vite un incontournable une fois découvert.
En effet, un bus I2C :
-
est simple à connecter : il n’utilise que deux signaux, à savoir horloge (SCL=Serial Clock) et données (SDA=Serial Data),
-
est prévu pour plusieurs capteurs : les signaux SDA et SCL passent de capteur en capteur. Chaque capteur dispose d’une adresse unique sur le bus (adresse de 0 à 127), ce qui permet au microcontrôleur de dialoguer avec un périphérique en particulier,
-
est universel : ce bus est supporté par tous les microcontrôleurs. S’il n’y a pas de support matériel, le bus I2C peut être émulé de façon logicielle (dit Bit-Banging I2C),
-
est supporté par de nombreux constructeurs : une vaste gamme de composants et capteurs électroniques supportent cette norme, composants que l’on retrouve en breakout sur des produits Adafruit Industries, Olimex, Pololu, SparkFun, etc.
L’intérêt d’un tel bus est qu’il permet d’ajouter des capteurs et composants sans consommer plus de broches sur le microcontrôleur comme le montre l’illustration ci-dessous reprenant différentes extensions connectées sur le bus I2C (GPIO, capteur de température, écran OLED et EEPROM).
Bus I2C
Les résistances pull-up présentes sur le bus feront l’objet d’un point spécifique dans ce chapitre.
La carte MicroPython Pyboard dispose de deux bus I2C matériel.
Bus I2C de la carte MicroPython Pyboard
Les deux...
Bus SPI
Le bus SPI (Serial Peripheral Interface) est un bus de données 4 fils à très haut débit exploité sur de très courtes distances (< 25 cm). Ce bus est généralement exploité par des périphériques gourmands en bande passante comme les afficheurs graphiques (écran TFT) qui nécessitent parfois des transferts de données de plusieurs centaines de kilo-octets par seconde ! Le bus SPI est également utilisé pour l’acquisition de données où un débit soutenu est nécessaire (ex. : capture signal, oscilloscope).
Comme pour le bus I2C, la topologie prévoit un leader (le microcontrôleur, appelé « maître ») et un ou plusieurs suiveurs (périphériques, appelés « esclaves »). Le microcontrôleur reste donc toujours le maître du bus.
Bus SPI
Le bus SPI dispose de deux canaux : un canal pour l’envoi de données vers le périphérique (MOSI) et un canal de réception (MISO) pour les données envoyées par le périphérique. Ce qui permet une communication simultanée dans les deux sens (communication en duplex).
Il s’agit toujours d’un bus série, le signal d’horloge (SCLK ou SLK) du bus cadencera l’émission des informations bit à bit sur MOSI et MISO. Par défaut, la fréquence d’horloge est fixée à 328 125 bauds (328 125 bits/s), ce qui représente un débit de 40 Kio/s.
Sur la Pyboard, le débit maximal du bus SPI(1) est fixé à 42 Mb/s = 5 Mio/s (SCK à 42 MHz). Le bus SPI(2) est fixé à 21 Mb/s (SCK à 21 MHz), soit 2 Mbit/s (2 000 000 bauds), information impossible à confirmer au moment de l’écriture de ces lignes.
Sur une Pyboard-D, le débit par défaut est fixé à 468 750 bauds. Le bus SPI(1) est limité à 15 Mb/s tandis que le bus SPI(2) peut atteindre 30 Mb/s.
Enfin, il n’y a pas de mécanisme d’adressage au sein du protocole SPI, une ligne SS supplémentaire par périphérique est utilisée pour l’activation dudit périphérique....
Interface UART
Les interfaces UART (Universal Asynchronous Receiver Transmitter) sont souvent appelées port série par abus de langage. L’UART est un dispositif matériel destiné à réaliser la liaison entre le microcontrôleur et une interface de type série.
Chaque UART expose une broche d’émission (TX) et une broche de réception (RX).
Les différents UART présents sur la Pyboard.
1. La trame série
Un UART envoie les données en série (bit à bit) sur la ligne à une vitesse donnée exprimée en bits par seconde (dits bauds). Le protocole série prévoit également différents bits : bit de démarrage, bit de parité et bit d’arrêt pour sécuriser le trafic.
Trame type d’un octet transmis sur une liaison série
Afin de pouvoir interpréter correctement les données reçues sur la ligne série, il est important que l’émetteur et le récepteur partagent la même configuration (vitesse, bit de parité et bit de stop) car, contrairement aux bus I2C et SPI, il n’y a pas de signal d’horloge transporté avec les données.
La trame comprend les éléments suivants :
-
Un bit de démarrage (start bit) toujours à 0.
-
Les bits de données, qui peuvent varier entre 5 et 9 bits, généralement de 8 bits.
-
Le bit de parité, qui peut être présent/absent, avec parité paire/impaire. Le bit de parité est généralement absent.
-
Le/les bits d’arrêt (stop bit), qui peuvent être au nombre de 1, 1,5 ou 2 bits de stop. Cette valeur est généralement de 1 bit d’arrêt.
Il existe de nombreuses configurations possibles, mais la plus populaire reste la configuration 8N1 (8 bits de données, pas de parité, 1 bit de stop).
De nos jours, le débit de transmission peut largement dépasser 115 200 bauds, mais il n’est n’est pas rare de trouver des périphériques série préconfigurées avec 9 600 bauds 8N1, référence tout droit venue des années 1980 où les modems pouvaient enfin dépasser les 2 400 bauds !
2. Configurer une ligne série...
Horloge RTC
Les amateurs des plateformes Arduino savent à quel point il peut être frustrant de ne pas avoir une horloge temps réel sur un microcontrôleur.
Certes, tous les microcontrôleurs savent égrainer le temps avec une précision plus ou moins bonne, mais, une fois éteint, seul un dispositif RTC (Real Time Clock = horloge temps réel) est capable de continuer ce décompte alors que le microcontrôleur est hors tension.
Il faut bien entendu que l’horloge RTC dispose d’une pile (souvent une pile bouton) capable d’assurer une durée de vie de plusieurs années.
Grâce au dispositif RTC, dès sa remise sous tension, le microcontrôleur est capable de savoir quelle heure, minute, seconde de quel jour, mois, année il est précisément. Cela est très pratique en cas de redémarrage après une coupure de courant ou simplement après le réveil faisant suite à une mise en veille prolongée.
Par chance, la carte MicroPython Pyboard dispose d’une horloge temps réel et la classe RTC de la bibliothèque pyb permet d’y accéder facilement. Il ne lui manque qu’une pile pour survivre à un cycle d’alimentation.
Alimenter l’horloge RTC avec une pile bouton
Fixer l’heure
Avant de pouvoir lire l’heure sur une horloge RTC, il est nécessaire d’initialiser...
Poursuivre l’exploration
Ce chapitre est déjà très long et certains points n’ont pas encore été abordés.
Assurément, il serait intéressant de se pencher sur les technologies suivantes :
-
CanBus,
-
DMX.
1. Interface CAN
MicroPython Pyboard dispose de deux interfaces CAN pour la communication CanBus (cf. MicroPython Pyboard - Brochage de la Pyboard). Celles-ci permettent à la carte Pyboard de communiquer sur un bus CAN par l’intermédiaire de transceiver MCP2562 ou MCP2551 (cf. MicroPython Pyboard - Les fonctions alternatives).
Ne disposant ni de matériel CanBus ni d’expérience pertinente dans ce domaine, il est difficile de compléter cette section avec un contenu adéquat et didactique. Ce sera peut-être l’occasion d’une future révision.
Pour les lecteurs intéressés par CanBus, voici quelques références dignes d’intérêt sur ce sujet.
-
Le projet Railuino de Joerg Pleumann destiné aux réseaux ferroviaires miniatures. Internet regorge de source d’informations sur le sujet. https://code.google.com/archive/p/railuino/
-
Le projet Mechanic permettant de connecter un Arduino sur le bus CAN d’un véhicule automobile. https://code.google.com/archive/p/mechanic/
-
Le livre « The Car Hacker’s Handbook » de Craig Smith...