Messages

16

Composants / Re : Re : Raspberry PI Pico : Difficultés de mise en œuvre.

« le: août 16, 2024, 04:10:23 pm »

Et cerise sur le gateau, Jean-Luc a prévu que l'horloge du MCP2515 soit alimenté par une PWM à 16Mhz générée directement pas le Pico. C'est ce que j'ai fait et cela fonctionne !

J'ai piqué le code à Pierre Molinaro 

La programmation de la PWM sur le Pïco est très différente de ce que l'on utilise sur un Arduino, et je craignais d'avoir là aussi à passer beaucoup de temps.

En fait côté Arduino, elle n'est pas différente. On a analogWrite comme d'habitude. C'est juste qu'ils y a quelques limitations par choix de conception. Le logiciel Arduino-Pico repose sur le SDK de Raspberry Pi mais comme il est plus simple, il est aussi moins riche que le SDK .

Côté Arduino, la fréquence est réglable via analogWriteFreq mais la fréquence est limitée à 1MHz maximum (bizarrement j'ai regardé le code et c'est 10MHz, je vais signaler la divergence). En effet, plus on monte en fréquence et plus la résolution de la PWM diminue. À 1MHz on a 64 pas d'après la doc et je suppose que Earle a préférer garder un nombre de pas suffisant pour la majorité des applications.

De ce que je comprends dans le code, analogWriteFreq sert à régler la fréquence mais seulement pour les analogWrite futurs. Les PWM déjà actives ne sont pas touchées. Autrement dit, la fréquence demandée est juste stockée dans une variable. C'est analogWrite qui programme la fréquence demandée en même temps qu'il règle le rapport cyclique. On peut donc avoir des PWM à des fréquences différents à conditions qu'elles soient sur des lices différentes.

Le Pico a 8 slices avec 1 compteur 16 bits et 2 PWM par slice. Le GPIO 22 est sur le slice 3A. Sur le slice 3B on a le GPIO 23. Donc sur le GPIO 23 on a potentiellement aussi une PWM à 16 MHz (si on le programme comme étant une PWM). Sur le Pico, le GPIO23 n'est pas exposé et sert à choisir le mode de fonctionnement de l'alimentation. Il n'y a donc pas lieu de mettre une PWM dessus.

Autrement dit, si on ne touche pas au GPIO22 et au 23, on peut faire ce que l'on veut avec les autres PWM sans affecter la fréquence du MCP2515 mais ça reste à vérifier.

Merci, merci encore !

C'est avec plaisir ! 

17

Composants / Re : Re : Raspberry PI Pico : Difficultés de mise en œuvre.

« le: août 16, 2024, 02:33:20 pm »

Tu ne voudrais pas publier ton code pour que je galère moins, parce que là je n'ai testé qu'à vide. Je ne sais pas encore si ça fonctionne vraiment une fois relié aux composants !!!

Voici.

Pour mon réseau j'ai fait un module qui regroupe un Pico, un 2515/2562, ma connectique CAN et une alimentation. Ça peut encore évoluer. Notamment je voudrais exposer les 5 broches GPIO du 2515. Je compte utiliser ce module sur toutes les cartes (aiguilles, signaux, remises, etc).

Qui dit module, dit bibliothèque, que voici (c'est du WIP) :

18

Composants / Re : Raspberry PI Pico : Difficultés de mise en œuvre.

« le: août 16, 2024, 02:00:24 pm »

Ouais

10, 11, 12, 13 c'est SPI1, pas SPI.

19

Composants / Re : Raspberry PI Pico : Difficultés de mise en œuvre.

« le: août 16, 2024, 01:36:24 pm »

Non, je te disais que la première fois seulement il faut appuyer sur BOOTSEL. Ensuite il suffit de télécharger normalement.

20

Composants / Re : Raspberry PI Pico : Difficultés de mise en œuvre.

« le: août 16, 2024, 11:37:23 am »

« No drive to deploy. »

Le chargement d'un sketch ne se fait pas par la ligne série sur Pico.

Quand tu branches le Pico, un disque USB nommé RPI-RP2 se monte et le fichier résultant de la compilation, un .uf2 est copié sur le disque du Pico. C'est comme ça que le flashage s'effectue.

De base, il faut que BOOTSEL soit enfoncé quand le Pico est mis sous tension. C'est ce qu'on doit faire la première fois que l'on flash le Pico avec le logiciel Arduino-Pico. Une fois chargé un sketch Arduino, ça se fait tout seul normalement.

J'ai le même phénomène que toi si coolterm est connecté au Pico. Essaye de le quitter pour voir ?

21

Composants / Re : Raspberry PI Pico : Difficultés de mise en œuvre.

« le: août 16, 2024, 09:47:11 am »

Salut Christophe

Ça va pas beaucoup t'aider mais j'ai copié-collé ton code et :

MacBook Air M1 sous Sonoma 14.6.1.

IDE 1.8.19 -> OK
IDE 2.3.2 -> OK
Coolterm 2.0.0 -> OK

22

Composants / Re : servo numerique et plaque tournante

« le: août 14, 2024, 09:43:23 pm »

Un demi tour me satisferait largement.

Toutes les manœuvres ne seront peut-être pas possibles.

Par exemple sur mon dépôt (voir dessin attaché), une locomotive entrant en marche avant par la voie en bas à gauche pourra être retournée pour sortir par une des 4 autres voies si le servo est au minimum sur cette voie et pivote dans le sens trigonométrique. cette configuration interdit de parquer la locomotive en marche arrière dans la rotonde.

23

Composants / Re : Re : servo numerique et plaque tournante

« le: août 14, 2024, 09:21:15 pm »

c'est pas plutôt en radian, soit 0,03° ?

Exact oui 

24

Composants / Re : servo numerique et plaque tournante

« le: août 14, 2024, 05:26:57 pm »

Bonjour,

Est il possible d'utiliser des servos numériques pour animer une plaque tournante ?

je pense à la résolution angulaire et à la répétabilité des déplacements.

Un pont tournant doit permettre de faire un tour complet, ce que ne permet pas un servo.

Je ne suis pas sûr que la résolution angulaire et la répétabilité soient suffisantes. Un servo numérique a certes une électronique à base de micro-contrôleur mais le capteur de position reste un potentiomètre sauf peut-être sur des servos industriels de prix exorbitant.

Sur un pont en H0 qui fait 200 mm de rayon, on doit pouvoir positionner l'extrémité du pont à 0,1mm près. ça donne un angle de atan(0,1/200) = 0,0005° 0,03°

25

JMRI et Arduino / Re : JMRI et MQTT

« le: août 10, 2024, 10:58:35 pm »

Oui, nos lecteurs auront rectifié d'eux-mêmes 

26

JMRI et Arduino / Re : JMRI et MQTT

« le: août 06, 2024, 02:19:44 pm »

Pourquoi publier l'occupation des cantons en boucle ? C'est sur qu'en cas de crash la reprise est facilitée.

Elle est plus que facilitée. Si on devait faire un parallèle avec l'électronique numérique, c'est la différence entre la logique combinatoire et la logique séquentielle. En combinatoire, l'état des sorties est fixé via l'état des entrées. En combinatoire, l'état est fixé par l'historique. En cas de dysfonctionnement, retomber au vol sur un état valide n'est pas assuré de manière simple.

Comme MQTT, surtout en WiFi, n'est pas d'une grande fiabilité, n'envoyer que les changements d'état dégrade encore le système.

27

Trucs & astuces / Re : exmples dans fonctions

« le: août 05, 2024, 10:10:04 am »

Bonjour,

Désolé j'avais pas vu ce message.

Difficile de répondre. Mettez le sketch que vous utilisez ci-dessous.

Cordialement

28

JMRI et Arduino / Re : JMRI et MQTT

« le: août 05, 2024, 09:36:28 am »

Bonjour,

Comme mentionné par Christophe, j'utilise MQTT mais pour une fonction annexe : l'éclairage du réseau. C'est une fonction purement cosmétique qui a le droit de ne pas être tip-top en ce qui concerne la sûreté de fonctionnement.

J'utilise également MQTT depuis plusieurs années pour de la domotique (distribution des consignes de température des radiateurs + data logging).

À mes yeux, son principal défaut est d'avoir besoin d'un serveur MQTT qui est le point central de concentration et de distribution des messages. À début, j'avais un serveur MQTT (Mosquitto) sur un Raspberry Pi Zéro. J'avais également installé le service de multicast DNS (Avahi) pour pouvoir adresser le serveur avec un petit nom (mqtt.local). Il s'est trouvé que la configuration manquait de longévité : au bout de quelque jours, la connexion est perdue et il faut redémarrer le RPi. En passant sur un Mac, j'ai eu zéro problème de tout l'hiver.

Ensuite, si tu parles de MQTT, tu penses IP et probablement WiFi. On peut se poser la question des performances. Si on a une trentaine d'ESP32 (gestion des cantons + centrale) sur la box internet de la maison + le serveur MQTT, que les ESP32 rapportent l'occupation des cantons avec une période courte et que cette info arrive sur le PC pour être ensuite envoyé vers la centrale, quel va être le délai de bout en bout entre la détection et le changement de vitesse du train (mini, maxi, moyen + écart type) ? Va-t-il être compatible avec le pilotage des trains ? Je n'ai pas la réponse. J'avais fait quelques essais qui m'avaient dissuadé de me reposer sur MQTT pour des choses plus tendues côté latence. Tu peux consulter mes réflexions dans cet article : https://www.locoduino.org/spip.php?article300

29

Bus CAN / Livre « CAN et CAN FD »

« le: juin 12, 2024, 03:06:53 pm »

Bonjour à tous

Pierre Molinaro sort un livre chez Elektor : CAN et CAN FD. . Tout sur les protocoles et leur mise en œuvre avec Arduino

C'est un livre qui est destiné aux amateurs et aux enseignants et qui va vraiment dans les entrailles du bus et qui couvre beaucoup d'aspects pratiques.

https://www.elektor.fr/products/can-et-can-fd

Je vous le conseille bien évidemment

30

Débuter / Re : Re : Problème sur pilotage aiguillages par arduino via I2C

« le: avril 27, 2024, 05:15:41 pm »

Bonjour,

effectivement j'avais loupé cette info ! c'est peut-être un miracle de ne pas avoir tout fait cramer alors.

Comme les transistors MOS de sortie du MCP23017 ont une résistance lorsqu'ils conduisent, ça limite aussi le courant et le résultat est que la tension chute quand on demande trop. Ce qui explique que les relais ne commutent pas. Ça a dû chauffer un peu ceci dit.

dans ce cas je peux peut être raccorder les relais aux ULN2803 ? comme ça ça limite le courant dans les MCP23017 et je fais le même montage au niveau de l'alimentation de l'ULN que pour mes aiguillages branchés en direct.

Tout à fait. L'ULN est fait pour ça. Il ne demande qu'1 mA en entrée côté MCP23017 et supporte 500mA par sortie (toujours maximum absolute rating) et un total de 2,5A.