Bonjour.
Pour un petit projet Electronique, j'aurais besoin de contrôler deux modules via UART. Aujourd'hui, pour tester, j'utilise mon PC avec des convertisseurs USB/serie (enfin … pour le moment je n'en utilsie qu'un mais j'en aurai besoin de deux pour gérer les deux modules).
A terme ces deux modules seront utilisés avec un microcontroleur (AVR ou ARM, je n'ai pas encore tranché), mais pour le moment, j'utilise Ruby sur mon PC pour me familiariser avec les modules, et valider fonctionnellement les idées que j'ai en tête (c du prototypage rapide).
Pour valider le concept, je souhaiterais pouvoir utiliser une carte de développement suffisamment "puissante" pour y déployer et exécuter une appli Ruby (pas de mode graphique, juste du texte). En gros, une carte avec un OS + un environnement ruby. Parmi les cartes pseudo candidates, j'ai de suite pensé à la raspberry pi zero. J'intègrerais cette carte avec les deux modules dans un boitier et testerais "pour de vrai" le truc pour savoir si je répond à mon besoin, puis je porterai toute les dfonctionnalités sur une carte un peu plus light (rpi Nano est un bon candidat - mais je lorgne aussi sur une base Micro Bit ou un CPU AVR "nu").
J'ai vu dans les spécifications techniques du RPi Zero que le SOC disposait d'une mini-uart et d'une uart "standard". Cependant lorsque je regarde les broches GPIO, je ne vois qu'une seule interface UART disponible.
Avez-vous déjà utilisé deux UART sur un RPi zero, hors ajout de convertisseur USB/SPI ou autre ?
A priori j'ai l'impression que ce n'est pas possible, mais peut-être je me trompe ?
Merci d'avance.
Cordialement.
# (re)configuration logicielle
Posté par Cyril Brulebois (site web personnel) . Évalué à 3.
Jetons un œil à la doc sur la console série.
Cela confirme bien deux consoles sur le Pi Zero. Note la distinction entre primary UART et secondary UART.
En utilisant les device tree overlays, il est possible de changer la configuration de différents pins, et donc de récupérer la main sur une console série qui ne serait pas activée par défaut.
Attention aux différences entre UART et mini-UART cependant, en fonction des besoins, ça peut ou peut ne pas convenir.
Debian Consultant @ DEBAMAX
[^] # Re: (re)configuration logicielle
Posté par totof2000 . Évalué à 1.
Merci pour l'info. Le pire c'est que j'avais l'info devant mes yeux mais je ne l'ai pas vue ( j'étais resté sur la partie hardware : https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#schematics-and-mechanical-drawings ). Merci aussi pour l'info sur les device tree overlays. J'avais vu tout ça il y a quelques années maintenant, mais je ne savais plus vraiment ou trouver, tu m'as permis d'économiser beaucoup de temps de recherche.
Pour la mini uart, j'avais bien vu la doc du chipset, et la mise en garde par rapport aux différences avec une UART classique. En tout cas je devrais pouvoir tenter sans perdre trop de temps.
A vue de nez, en jouant avec le débit d'un des modules ça devrait le faire, au moins pour le prototypage (pas besoin des lignes de contrôle matérielles). Et ppur le fait que l'UART soit calée sur l'horloge CPU, je devrais m'en accomoder (les échanges devraient être sur de courtes trames).
[^] # Re: (re)configuration logicielle
Posté par Cyril Brulebois (site web personnel) . Évalué à 2.
Aucun souci, ça n'est pas forcément évident comme gymnastique. J'ai notamment en tête l'énorme table sous « 5.3. Alternative Function Assignments » du BCM2711… il m'avait fallu un peu de temps pour vraiment comprendre ce qu'il se passait. Je joue avec ça sur d'autres modèles, et ça m'arrive de fabriquer des DTBO. D'ailleurs, j'ai quelques articles à publier sur le blog de ma boîte, mais il me reste à les écrire…
Debian Consultant @ DEBAMAX
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.