LOCODUINO
Discussions Générales => Discussions ouvertes => Discussion démarrée par: hinano70 le novembre 07, 2020, 10:33:58 pm
-
Bonjour
Je veux commander une quarantaine de cantons en PWM avec plusieurs PCA9685. Lorsqu'une loco change de canton, les 2 signaux de commande sont identiques pour éviter un court-circuit. Ca marche très bien si 2 cantons successifs sont reliés au même PCA9685. Mais si je les relie à 2 PCA9685 différents, il y a un court-circuit. J'ai mis du temps à trouver la raison : les signaux PWM doivent être déphasés entre PCA différents !
J'ai vu qu'on pouvait utiliser une horloge externe qui règlerait ce problème de désynchronisation et qu'on pouvait la "piloter" avec la fonction : setExtClk ()
http://adafruit.github.io/Adafruit-PWM-Servo-Driver-Library/html/class_adafruit___p_w_m_servo_driver.html (http://adafruit.github.io/Adafruit-PWM-Servo-Driver-Library/html/class_adafruit___p_w_m_servo_driver.html)
Mais à partir de là, je coince ! Mon circuit est commandé avec un Arduino Méga, où puis-je récupérer un signal d'horloge et qu'en faire avec le PCA9685 ?
Il y a bien une broche EO, mais je ne sais quoi en faire...
Merci pour votre aide ....
J'ai oublié de dire qu'il y a derrière les PCA des ponts en H L298N sur chaque alimentation de canton et que malheureusement je n'ai pas commandé tous les PCA9685 en même temps et chez le même fournisseur
-
Bonsoir,
J'ai la même configuration : PWM généré par PCA9685 et un L298N pour chaque section. Sauf que j'ai (beaucoup) moins de 16 sections et donc un seul PCA9685, pour l'instant en tous cas.
Sans avoir donc l'expérience de ce qui peut se produire dans votre cas, je pense toutefois que le problème n'est pas un problème de désynchronisme.
Ce problème existe, on le constate si l'on utilise les ports d'un Arduino, les ports PWM sont distribués sur plusieurs timers non synchrones. Mais sauf erreur de polarisation des ponts H, ça ne peut pas conduire à un court-circuit ; l'effet se limite à une accélération transitoire de la motrice au moment où elle s'alimente en même temps sur deux sections différentes : les "ondes" de PWM se superposent (leur temps "1") ce qui se traduit par une augmentation de la tension moyenne.
Ce problème a été traité (et résolu !) par "Jean-Luc", un des pionniers de ce site et je n'ai pas fait l'effort de fouiller pour vous fournir le lien du sujet mais vous pourriez y arriver avec cette info. Je ne me souviens pas mais je ne crois pas qu'une horloge externe était nécessaire. (Peut-être qqn d'autre saura-il retrouver le lien facilement ?)
-
Merci
Cela m'a permis de trouver ça :
https://www.locoduino.org/spip.php?article203 (https://www.locoduino.org/spip.php?article203)
"Dans un prochain article nous attaquerons le problème de la synchronisation des PWM entre les cantons qui pourront donc être commandés par des Arduino séparés."
C'est tout à fait ce qu'il me faut, mais je n'ai pas trouvé l'article.
Je suis tombé la dessus: http://forum.locoduino.org/index.php?topic=36.0 (http://forum.locoduino.org/index.php?topic=36.0). Je n'ai pas tout compris, il y a une bibliothèque à télécharger https://dl.dropboxusercontent.com/u/67740546/SyncPWM.zip (https://dl.dropboxusercontent.com/u/67740546/SyncPWM.zip) mais le lien ne fonctionne plus !
Chez moi, ça devrait être plus simple puisque je n'ai qu'un seul Méga qui commande tout (pour l'instant)
-
Le problème est que les PCA9685 possèdent leur propre horloge et que celles-ci ne sont pas synchro.
Je viens de parcourir le datasheet https://www.nxp.com/docs/en/data-sheet/PCA9685.pdf (https://www.nxp.com/docs/en/data-sheet/PCA9685.pdf) (c'est assez obscur pour moi), mais on voit bien qu'il y a possibilité de mettre une horloge externe, mais j'ai beau retourner dans tout les sens le shield, il n'y a pas de pin supplémentaire. Aïe ! Mauvais signe :
external clock input[2] ---> [2]This pin must be grounded when this feature is not use
Dommage ! Plus loin on trouve
To use the EXTCLK pin, this bit must be set by the following sequence:1. Set the SLEEP bit in MODE1. This turns off the internal oscillator.2. Write logic 1s to both the SLEEP and EXTCLK bits in MODE1. The switch is now made. The external clock can be active during the switch because the SLEEP bit is set.This bit is a ‘sticky bit’, that is, it cannot be cleared by writing a logic 0 to it. The EXTCLK bit can only be cleared by a power cycle or software reset.EXTCLK range is DC to 50 MHz
Je ne comprends pas tout, mais il semble que la solution était là. Encore fallait-il que je sois capable d'accéder aux registres !!!
Il me reste une solution : si les décalages de phase sont faibles (j'en doute vu ce qui se passe entre 2 : l'alim disjoncte, avec 2 autres les trains broutent aux changement de canton) je peux décaler les signaux PWM: pwm3.setPWM(N°, 0, vitesse) ---> pwm3.setPWM(N°, 0+x, vitesse+x)
Toutes les remarques pouvant m'aider sont les bienvenues !
-
En fait décaler un signal par rapport à un autre est ridicule !
J'ai utilisé un oscillo pour visualiser les signaux PWM. Ils glissent l'un par rapport à l'autre (les horloges étant légèrement décalées) ce qui ne génère pas de court-circuit au passage du train en juxtaposant les signaux dans 2 cantons consécutifs. Je ne me l'explique pas ! Par contre les trains broutent (signaux en phase, décalés, en phase ....). J'ai eu des problèmes de court-circuit en alimentant les 2 cantons consécutifs avec 2 disjoncteurs différents (faits avec des MAX471 + relais...)
Il me reste donc à m'arranger pour mettre les jonctions entre cantons alimentés par des PCA9685 différents dans les parties cachées, mais avec 35 cantons, ça va être dur !
Il y a peut être des modules équivalents au PCA9685 ?
-
Bien, on est donc d'accord, le court-circuit ne pouvait pas venir d'un désynchronisme.
Le broutage... NON PLUS ! quasi sûr que c'est un problème de définition de variable : attention les PCA 9685 codent les PWM sur 12 bits, soit 4096 valeurs ; Arduino sur 8 => une PWM Arduino doit donc être multipliée par 16. Et la variable ne doit pas être un byte sinon ça déborde... et ça broute.
(je n'ai pas compris "décaler un signal par rapport à un autre est ridicule !" ??)
-
Bonjour,
je crains qu'il ne soit pas possible de synchroniser les timers des PCA9685
l'entrée EXTCLK est faite pour faire marcher un PCA9585 à une fréquence customisée
si on a la même entrée EXTCLK pour deux PCA9685, ils fonctionneront à la même vitesse, sans glissement, mais ils ne seront pas synchronisés, car il est impossible de faire démarrer les 2 timers pile poil au même moment ...
ce décalage fait que si un engin se trouve à cheval sur 2 cantons, les 2 signaux pwm peuvent s'ajouter, et dans le pire des cas, 2 signaux à 50% peuvent donner du 100% (s'ils sont complètement déphasés)
je vais encore creuser un peu, mais jai peu d'espoir de trouver une solution avec PCA9685
autrement, je vois cette solution :
utiliser 4 arduinos ; le premier génère une impulsion de synchronisation qui fait chez les 3 suivants une raz des timers logiciels (softPwm)
-
Merci pour les réponses.
Le problème n'est pas un problème de décalage, mais un problème de fréquences très légèrement différentes. J'imagine qu'il doit y avoir une sorte de battement lorsque les 2 signaux de fréquences différentes se superposent ce qui fait "brouter" les trains (arrêt-avance-arrêt-...).
trimarco232 m'a donné l'idée de faire un RAZ au moment du changement de canton, mais les battements ont une période inférieure à la durée du passage de l'un à l'autre donc j'ai peur de ne pas régler le problème. Ce qui risque de se passer avec 3 Arduino ayant chacun leur propre horloge.
Pour répondre à simontpellier,le codage des PWM doit bien être de 0 à 4095, vitesse étant un byte et je limite la vitesse à 200 :
if ((millis() - lastTime) > VitesseDelay)
{
if (vitesse < consigne) {vitesse += 1;} // phase d'accélération marche avant.
else if (vitesse > consigne) {vitesse -= 2;} // phase de décélération marche avant.
if (pin1<16) pwm3.setPWM(pin1, 0, 20*vitesse); //pin1=pwm
else if (pin1<32) pwm4.setPWM(pin1-16, 0, 20*vitesse);
else if (pin1<48) pwm5.setPWM(pin1-32, 0, 20*vitesse);
else pwm6.setPWM(pin1-48, 0, 20*vitesse);
lastTime = millis();
-
pwm3.setPWM(pin1, 0, 20*vitesse);
pardon d'insister... quand je vois ce 20*vitesse, et vu que je me suis fait piéger de la même façon avec des "broutages" bien mystérieux...
si pour une raison ou une autre (que je peux bien sûr pas deviner mais qui se planque dans le code) la variable "vitesse" dépasse 200, alors 20*vitesse dépasse 4096
=> jusqu'à 4096 ça roule (vite !)
=> au dessus , par débordement ça fait 20*vitesse - 4096 et ... ça s'arrête d'un coup
-
Le "broutage" a lieu uniquement au changement de canton, lorsque l'alimentation du train se fait par l'intermédiaire de 2 sections alimentées par 2 PCA9685 différents. Aucun problème lorsque le train est à cheval sur 2 sections alimentées par le même PCA9685. J'ai 2 endroits où j'ai le problème, la cause est la même. Je vais essayé de changer la fréquence d'un des PCA9685 pour qu'il n'y ai plus de battements avec 2 fréquences trop proches.
-
Je viens d'essayer avec des fréquences de 60 et 73 (60 et 80 donnent de moins bon résultats)
pwm5.begin();
pwm5.setPWMFreq(60);
pwm6.begin();
pwm6.setPWMFreq(73);Il y a un ralentissement mais plus de broutement. C'est plus tolérable ! Il faut que je répartisse mes alimentations de sections dans les parties visibles pour limiter les changements de PCA9685, avec 36 sections, ça ne va être simple !
-
Bonsoir,
merci pour ces retours, c'est instructif car ... ça peut servir un jour !
pour l'instant, faute d'expérience, j'avoue que je commence tout juste à "conceptualiser" le phénomène : je "vois" bien des créneaux de PWM qui se juxtaposent aux moment où une motrice se sert sur deux sections à la fois (ça je l'ai vu de mes propres jolis yeux), mais jusque là ça ne peut produire qu'une accélération momentanée... mais si le décalage temporel entre ces deux sources est EN PLUS non constant dans le temps, alors l'effet cumulatif est lui aussi variable et ça peut faire bizarre! Or n'est ce pas précisément ce qui doit se produire immanquablement si les deux fréquences en plus de ne pas être synchrones ne battent pas à la même cadence ?
Mais je raisonne "à blanc" ; en tous cas je ne vois toujours pas comment ça peut se traduire par un broutage ou un ralentissement.
Sauf...
que lorsqu'une motrice fait le pont sur deux sections, c'est aussi un pont électrique et il y a un retour d'une section sur l'autre et donc d'un PCAmachin sur l'autre... l'explication et la solution n'est elle pas à regarder par là ?
J'attends la suite avec grand intérêt
-
Bonjour,
J'ai équipé plusieurs réseaux (analogiques) comme ça (avec un PWM par canton), mais sans PCA9685 ni Arduino, juste un PC (dont l'un est en cours de remplacement par un Arduino).
Effectivement, si on ne synchronise pas les signaux traction, le train accélère lors qu'il est à cheval sur deux cantons.
Personnellement je synchronise le signal sur le secteur (100Hz), parce qu'en plus de synchroniser les cantons entre eux, ça simplifie l'alimentation primaire, qui n'a plus besoin d'être régulée ni même filtrée.
Comme le PC/Arduino gère les accélérations et ralentissements progressifs, il faut aussi synchroniser les vitesses au moment du changement de canton (ça correspond le plus souvent au démarrage devant un signal qui vient de s'ouvrir).
Avec les PCA9685, et d'après ce que je comprends de la datasheet, même en utilisant la même horloge, les PWM risquent de ne pas être synchrones: ça dépendra de l'instant du chargement (parce qu'il y a un prescaler entre l'horloge et les registres de sortie). Mais bien sûr c'est à tester.
Par ailleurs, si on utilise des ponts en H en sortie, il y a un autre facteur à prendre en compte: ce que font les L298 pendant la phase de non-alimentation. Ils peuvent être soit en sortie ouverte, soit en sortie à zéro, c'est à dire en court-circuit, et le résultat n'est pas le même sur les trains, à moins d'avoir des diodes en sortie.
Cordialement.
-
Chez moi, c'est plutôt un ralentissement, peut être est-ce parce que la jonction est dans une zone de ralentissement où le temps d'alimentation est d'environ 1/3. Je vais tester un rapport 1/2.
Mes cantons sont toujours alimentés ainsi :pwm3.setPWM(pin1, 0, 20*vitesse); la vitesse variant de 1 à 200. A l'arrêt la vitesse est 1, l'alimentation est insuffisante pour faire avancer le train, mais suffisante pour charger un condensateur au travers d'une diode et qui se décharge dans les LEDS des lumières (loco + wagons).
Le gros avantage des PCA9685, c'est qu'on peut en mettre autant qu'on veut en parallèle. Je les utilise aussi pour alimenter les servomoteurs qui commandent les aiguillages, pour alimenter les feux de signalisation : il est très facile de faire varier la luminosité des LEDS en faisant varier le duty-cycle.
Je viens de tester un rapport de 1/2 du PWM, c'est beaucoup mieux. Cela me donne une possibilité supplémentaire pour juxtaposer les cantons alimentés par des PCA9685 différents. La discussion fait progresser les choses ! Merci aux contributeurs.
-
Bonsoir INANO70
STP aurais-tu un fichier pour tester, je suis curieux
Marcel
-
Voici un programme de principe qui devrait fonctionner, je ne l'ai pas testé, et un schéma (j'espère ne rien avoir oublié) du circuit. J'utilise un Méga2560.
#include <Wire.h>
#include <Adafruit_PWMServoDriver.h>
Adafruit_PWMServoDriver pwm1 = Adafruit_PWMServoDriver( 0x40 );// cantons alim 12V
Adafruit_PWMServoDriver pwm2 = Adafruit_PWMServoDriver( 0x41 );// cantons alim 12V
byte vitesse = 80;
byte pin0Driver1 = 0; // pin0 du pwm1 : PCA9685 N°1
byte pin0Driver2 = 0; // pin0 du pwm2 : PCA9685 N°2
void setup() {
pwm1.begin();
pwm1.setPWMFreq(60);
pwm2.begin();
pwm2.setPWMFreq(60);
pwm1.setPWM(pin0Driver1, 0, 20*vitesse);
pwm2.setPWM(pin0Driver2, 0, 20*vitesse);
//on peut aussi utiliser 2 pins de chaque PCA9685 pour pouvoir inverser le sens de circulation
}
void loop() {
}
Si on utilise le même PCA9685 pour alimenter les 2 cantons, pas de problème, si on en utilise 2, c'est là que le passage d'un canton à l'autre ne se fait pas correctement.
A essayer : différentes vitesse (0 à 200) et des fréquences différentes.
-
- Les 0V des ponts H et de l'Arduino sont ils reliés ?
- peux tu tester ce branchement qui est plus orthodoxe même si on peut en effet envoyer la PWM sur les gachettes :
"Les pins IN 1 e IN 2 nous servent à contrôler le sens de rotation du moteur 1, et les pins IN 3 et IN 4, celui du moteur 2. Ces pins fonctionnent:
IN 1 -> HIGH; IN 2 -> LOW: le moteur tourne dans un sens.
IN 1 -> LOW; IN 2 -> HIGH: le moteur tourne dans le sens inverse.
Et c’est pareil pour les pins IN 3 et IN 4 du moteur 2.
Pour contrôler la vitesse de rotation des moteurs on doit retirer les cavaliers des pins ENA et ENB. On les connecte à deux sorties PWM de la plaque Arduino de façon qu’on puisse envoyer une valeur entre 0 et 255 pour gérer cette vitesse des moteurs. Avec les cavaliers installés, les moteurs tourneront toujours à la même vitesse."
-
Oui, tous les 0V sont reliés ensemble.
La solution que j'ai trouvée pour les ponts en H me paraissait plus intéressante car elle me fait gagner un fil (2 au lieu de 3 pour les cantons à double sens), mais je vais tester...
-
J'ai déconnecté 2 cantons pour les connecter comme indique Simontpellier pour tester. Pas de tension ! Est-ce parce que tous les autres cantons sont encore commandés par les In1 et In2 ? Si il faut que je déconnecte tout pour essayer, ça va être galère ! Et je ne pense pas que ça règle le problème de désynchronisation des horloges. J'avais regardé à l'oscillo les signaux envoyés aux rails, ils étaient très propres en commandant sur IN1 et In2..
-
Bonjour,
non bien sûr le branchement "orthodoxe" ne resynchronisera pas les horloges mais le problème décrit N'EST PAS un problème de désynchronisme.
A nouveau, deux PVM désynchronisées, dont les créneaux sont donc décalés, ne pourront que s'ajouter à raison de ce décalage. Jamais se soustraire !! Les à coups et ralentissements rapportés sentent très fort le couac électrique. Le dernier test va aussi dans ce sens
Bon courage
-
héhé ! peut-être une solution là ?
https://www.pjrc.com/teensy/td_libs_ShiftPWM.html
- des PWM à volonté et synchronisées de fait !
- mais avec tout de même une limite, par le taux de rafraîchissement, inversement proportionnel au nombre de PWM ;
- un investissement à prévoir car une teensy c'est pas le même prix qu'une Arduino. Mais comme ça pédale beaucoup beaucoup plus vite, le taux de rafraîchissement ne devrait pas être un problème et il devrait même y avoir de la marge.
A bon entendeur
-
(...)
A nouveau, deux PVM désynchronisées, dont les créneaux sont donc décalés, ne pourront que s'ajouter à raison de ce décalage. Jamais se soustraire !!
Bonjour,
à condition toutefois, comme évoqué par JPM06, que les drivers ne soient pas commandés en low side pendant les crénaux bas du pwm ; cela expliquerait le broutage, et risque par ailleurs de détruire les composants, et les moteurs des locomotives
-> il convient par conséquent de bien maîtriser le principe de commande des drivers
-
héhé ! peut-être une solution là ?
https://www.pjrc.com/teensy/td_libs_ShiftPWM.html
- des PWM à volonté et synchronisées de fait !
- mais avec tout de même une limite, par le taux de rafraîchissement, inversement proportionnel au nombre de PWM ;
- un investissement à prévoir car une teensy c'est pas le même prix qu'une Arduino. Mais comme ça pédale beaucoup beaucoup plus vite, le taux de rafraîchissement ne devrait pas être un problème et il devrait même y avoir de la marge.
A bon entendeur
petit calcul sans prétention
on part sur :
40 sections, soyons fous, ce qui fait 5 registres du type 74hc595
une fréquence pwm de 20 kHz, pour sortir du spectre audible
128 crans de vitesse, valeur bien admise en MF
les régistres doivent être rafraîchis à une fréquence de 128x 20 000 = 2.56 mHz
pour chacune des 40 sections il faut 3 signaux provenant du contrôleur : 1 signal data, et 2 signaux d'horloge ; je vous fais grâce du latch à la fin, cela fait 120 signaux
pour respecter les délais, ces 120 signaux doivent être envoyés à la fréquence de 2.56 mHz, ce qui représente, pour les signaux, une fréquence de 300 mHz
autant dire tout de suite que ça craint à tous les niveaux
- le contrôleur ne peut sans doute pas faire pédaler ses sorties à cette vitesse, même s'il utilise un périphérique spécialisé
- les registres, même en technologie 74vhc, ne suivront pas
- le signal d'horloge, même à faible distance, ne sera pas assez raide (dans la loupe des timings) pour garantir un décalage sans perte de bit
à vos méditations, et à votre disposition pour eb discuter
on va faire un petit calcul
-
ah oui c'est intéressant, j'ai médité ! Et le calcul est imparable.
Mais deux questions sur les données de départ du calcul :
- 128 * 20 000 : je n'ai pas regardé la librairie mais si pour faire du 50%, par exemple, elle envoie 64 bits à 1 puis 64 bits à 0 par période! est-ce que ça ne serait pas franchement bestial... à moins que ça soit la seule solution ?? (personnellement je pratique les 74HC595 pour allumer/éteindre des led, avec un 1 ou un zéro... juste quant-il faut...)
- 128 * 20 000 : les 20kHz m'interrogent beaucoup et depuis longtemps, cad un peu plus d'un an que je découvre tout ça. Parce que mon (petit) réseau tourne avec un code dans lequel j'ai copié/collé : pwm.setPWMFreq(60) (Hz) (gamme de fréquence qu'utilise également Hinano ce qui fait que j'ai moins peur de la question vraiment trop stupide !)
Le post précédent également... m'ouvre des horizons insoupçonnés : la piqure de rappel du post de JPM06 me fait entrevoir le pb de la phase de non alimentation. Jamais rencontré dans aucun tuto web.
... comment fait-on pour "bien maîtriser le principe de commande des drivers" ?
-
concernant les messages à envoyer pour rafraîchir les rapports cycliques :
en effet, si pour un canal tu fais du 50% (valeur 64/128), tu envoies un 0 à 0 µs, puis un 1 à 25 µs, c'est assez cool
le souci, c'est si tu dois envoyer 65 sur le canal suivant, il va te faloir enchaîner en 1/(128*20000) Hz, et là ça coince, parce qu'on ne dispose que de 390ns pour renseigner les 40 cases du régistre à décalage, car l'inconvénient de ces registres est justement qu'il faut tout renvoyer à chaque fois
concernant les 60 Hz : c'est quelque chose de subjectif, cela fonctionne très bien ainsi, mais le bruit peut gêner, d'où l'idée de le déplacer à une fréquence non audible - sans doute que 10 000 Hz ça le fait aussi - ; si on peut se contenter des 60 Hz, le montage devient jouable
concernant les drivers, le risque c'est quand la locomotive est en train de passer d'une section vers une autre, et qu'un des drivers tire vers le 12v et l'autre vers le 0v : on a un court-circuit dans la locomotive ! il ne faut donc pas que le 2ème driver tire vers 0v quand son pwm est à 0, mais qu'il laisse sa sortie en l'air
il faut donc s'assurer dans la commande (le raccordement à l'arduino) du driver, que le niveau bas du pwm correpond à une sortie haute impédance et pas au forçage à 0v de la sortie ; consulter pour cela la documentation du driver, ou dis-moi quels sont tes driver, et je te dirai comment les raccorder
-
Bonsoir,
... c'est juste, c'est une erreur d'avoir raisonné comme si chaque registre était seul !
J'ai regardé la librairie ShitPVM. Un gros code ! A méditer là aussi. Et capable de s'auto-adapter aux processeurs tant Arduino que Teensy suivant le cas, mais... totalement orienté LEDs et pas utilisable en l'état pour conduire des moteurs. Dommage.
Mais l'idée des registres à décalage demeure et au moins pour l'exercice, peut-être pour un futur usage, je compte m'y coller.
La fréquence...
j'ai écouté un son de 60hz pur... c'est pour moi de l'infra-son à l'extrême limite de l'audible... définitivement, donc question réglée ! (sauf si c'est une fréquence qui devait se révéler incompatible avec le projet d'ajouter une mesure de fcem, en vue d'un asservissement de vitesse)
Et pour ce qui est des drivers, grand merci pour la proposition ! L'audit me sera précieux car à défaut de connaissances théoriques tout repose sur les infos disponibles sur Locoduino et web.
J'utilise des L298N, trois (...6 sections électriques), pilotés sur les pin "enable" par un PCA9685 et sur les gâchettes de polarisation par 2x6 bascules de registres 74HC595, en opposition deux par deux ; la branche "out" est donc toujours forcée à zéro. Aucun problème à ce jour puisque je n'ai pas (encore) dû utiliser plus d'un PCA9685.
Peut-être dire aussi que je n'actualise les pins des drivers que tous les 40millisecondes et que j'ai même testé beaucoup plus long sans rien remarquer en ce qui concerne la fluidité des accélérations/ralentissements.
Merci par avance !
-
Bonsoir,
si tu commandes le L298N par les entrées enable, c'est bon
-
j'ai réfléchi ... ! ... ?
il y a sans doute une solution beaucoup plus simple, tout dépend de la capacité de vos systèmes à la mettre en oeuvre, mais on est quand-même sur le forum locoduino, ça doit être possible !
l'idée, c'est de s'attaquer à la racine du problème, cad. à la transition entre deux pca9685, qui sont on l'a vu, forcément désynchronisés
on va prendre par exemple, pour fixer les idées, 31 sections, donc 2 pca :
- le 1er pca commande les sections 1 à 16, le 2ème pca commande les sections 16 à31
- donc la section 16 peut être, au choix, commandée par le 1er ou par le 2ème pca
- quand le train passe de la section 15 à la section 16, la section 16 est commandée par le 1er pca (pas par le 2ème) : la transition entre la section 15 et la section 16 se fait nickel
- quand le train passe de la section 16 à la section 17, la section 16 est commandée par le 2ème pca (plus par le 1er) : la transition entre la section 16 et la section 17 se fait chrome
- le choix duquel des 2 pca pour la section 16 se fait par un simple "ou câblé", avec 2 diodes et une résistance de pull down de 470R ; la sortie correspondante du pca qui ne commande pas la section 16 est simplement mise à 0%
que vous en pense-t-il ?
-
Bonsoir,
je n'ai pas réfléchi ... ! ... !
A ça en tous cas. Néanmoins l'approche paraît très pragmatique. Et qu'il me semble voir un néanmoins au néanmoins, qui est que la transition n'est jamais ni instantanée ni irréversible...
cependant j'ai réfléchi aux fréquences PWM et là c'est la panade complète!
Mais auparavant : cette idée que tu as suggérée (puis retirée ??) de registres 74HC595 pilotés en SPI rapide. J'ai fait un test, rapide également : 8 bits balayés en boucle, avec un NANO à la manœuvre ça fait pas mieux que 10microsec par bit ! et ça sans aucun code en parallèle sinon un comptage des loop. Un MEGA ferait probablement pas mieux. Et puis... le SPI natif, normalement c'est le bus CAN qui l'utilise ! Mais imaginons, car un "shiftPWM" est quand même une idée intéressante. Sauf que ce petit essai indique que si on pourrait peut-être émuler quelques PWM à 60Hz, une seule à 20kHz ne serait même pas possible ou en tous cas pas sans un processeur 100x plus rapide !
Et j'y arrive : l'ultra-panade PWM !
car entre 60Hz, "ma" fréquence, et les 10kHz, 20Kz du "petit calcul", et pourquoi pas 30kHz tant qu'à y être !! le gap est tellement énooorme que ça interroge. Et donc j'ai interrogé, relu, Locoduino : les timers, les PWM, (et même, sur le site de Jean-Luc survolé des articles sur les pertes Joule quand les PWM ne sont pas au carré). Or c'est précisément 30Kz qui est recommandé !! et on lit aussi que les 480hz des PWM Arduino standards sont "bien trop bas pour la bonne santé de nos moteurs". De quoi paniquer de les faire fonctionner en 60!
J'ai donc tenté de régler plus haut, x2, x4, x8... jusque 1kHz.
Le constat : plus c'était haut et plus les démarrages étaient tardifs et laborieux, et la vitesse max (à cran de PWM identique) basse. A 1000Hz, c'était injouable.
Alors idée aussi sotte que grenue : essayer l'inverse. Moins de 60 Hz !
Et là miracle ... des motrices (Fleischmann), qui démarraient un peu difficilement sur un lancement brusque et saccadé ont accepté de partir sur des ralentis de rêve (comme le faisaient assez bien les minitrix, plus tolérantes), avec plus de couple donc ? au point de pouvoir faire en silence, et attelées, un tour de réseau sans arrêt ni accroc à 7kmh constants (à l'échelle !), c'est bluffant. L'optimum ? 40Hz.
Qui pourrait expliquer tout ça ? Please !!
-
Aujourd'hui, essais plus sérieux.
En résumé rapide : avec 5 74HC595 en cascade, soient 40 PWM pilotées, la fréquence d'une PWM ajustable sur 100 crans est de 150Hz.
C'est proportionnel : avec un seul, le MEGA fait 730 loop/s.
Je suis impatient de comparer avec ce que fera la Teensy 3.5 que j'attends.
Mais il semble donc que ça puisse être exploitable si des fréquences dans cette gamme peuvent être acceptables ? (et même ??...) et une solution aux problèmes de désynchronisme.
Voici le code d'essai (si des amateurs ont envie de le booster ?)
/* ARDUINO MEGA */
const int SS_PIN = 53; // SS(slaveSelect)/slave - pin 14 (DS / Serial Data Input) on the 74hc595
//const int SCK_PIN = 52; // horloge ... inutile ?
const int MOSI_PIN = 51; // MOSI (Master Out Slave Inv- The Master line for sending data to the peripherals) - pin 12 (ST_CP / Storage Register Clock Input (latch)) on the 74hc595
const int8_t number_of_74hc595 = 1;
const int8_t numOfRegisterPins = number_of_74hc595 * 8;
boolean pin74hc[numOfRegisterPins] = { 0 };
// pseudos PWM à simuler - pour chaque PWM, le tableau donne le cran entre 20 et 120
uint8_t PWM[40] = { 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0 };
/*---------------------------------------------------------------------------------------------------------------*/
void setup() {
Serial.begin(115200);
pinMode(SS_PIN, OUTPUT);
pinMode(MOSI_PIN, OUTPUT);
Serial.println("74HC595 test_vitesse");
}
void writeRegisters() { // attention : spécifique à l'attribution des 3 PINs du SPI
PORTA &= ~_BV(PB2); // pin 51
for (int8_t i((number_of_74hc595)*8-1) ; i>=0 ; i--) {
if (pin74hc[i]==0) /*=>*/ PORTA &= ~_BV(PB0); // pin 53
else /*=>*/ PORTA |= _BV(PB0);
}
PORTA |= _BV(PB2);
}
void setRegisterPins() { //Place les pins du 74HC595 à l'état HAUT ou BAS
for (uint8_t i(20) ; i<121 ; i++) {
for(uint8_t engine(0) ; engine<numOfRegisterPins ; engine++) {
pin74hc[engine]=i<PWM[engine];
}
writeRegisters();
}
}
void loop() {
setRegisterPins();
count++;
if (millis() > 1000) {
Serial.print(count);Serial.print("Hz");
Serial.end();
}
}
Deux images des pulses : A 50Hz, les créneaux sont bien propres, à 700Hz ça reste correct
(https://i44.servimg.com/u/f44/11/73/62/86/captur13.jpg)
(https://i44.servimg.com/u/f44/11/73/62/86/captur14.jpg)
à comparer avec une sortie d'un PCA9685 ! (à 40Hz. Ça ne ressemble que de loin à une PWM, pourtant ça marche toujours aussi bien)
(https://i44.servimg.com/u/f44/11/73/62/86/captur11.png)
En conclusion (provisoire), après avoir branché ces signaux sur les boosters, pas de doute ça fonctionne parfaitement. Différents essais dans la fourchette de fréquence permise par le montage, 50Hz / 700Hz, montrent à nouveau que c'est à 50Hz que la conduite est la plus souple et puissante. A noter aussi que la dégradation en augmentant la fréquence est beaucoup moins forte qu'avec les PCA9685, mais il faut se souvenir que ces derniers sont prévus pour commander des servos à 60Hz.
-
Bonjour,
merci pour le partage
pour mieux faire tu peux :
1) utiliser le spi hardware du méga, le but c'est que les hc595 soient renseignés sans monopoliser la cpu
2) utiliser le hardware d'un timer pour générer le latch, en mode ctc, et avec une interruption au front montant pour lancer le nouveau remplissage des hc595 - qui sera pris en comte au prochain front montant ; le but c'est d'avoir un découpage automatique et rigoureusement on time du découpage des crans du pwm, et toujours sans intervention de la cpu
je n'ai pas forcément été clair, fais moi le savoir
c'est quel modèle de teensy que tu attends ? (on peut multiplier la fréquence du pwm par le nombre de spi hardware du mcu)
-
Bonsoir,
et merci pour la réponse !
J'avoue que non, tout n'est pas bien clair mais ça tient à moi. Je n'ai par exemple pas idée de ce qu'est un SPI hardware, pas plus que lent ou rapide)
Mais... on est tout de même assez bien synchronisés puisque pour cadencer le SPI des 74HC j'ai utilisé un timer (le 2), avec un réglage de la fréquence PWM par bascule du registre TCNT2
(mais pas en mode CTC... erreur ?
Je joins le code. Que j'ai pu greffer dans mon code principal sans occasionner le moindre souci ni ralentissement. Et avec un cahier des charges respecté :
- 40 PWM possiblement générées
- 125 pas de réglage (avec un talon à 53, valeur empirique personnelle, ce qui donne une plage de réglage effective entre 53 et 178 et par conséquent un pas de réglage plus fin)
Ainsi régulée, la fréquence "shiftPWM" est totalement indépendante du nombre de 74HC pilotés, du moins dans la limite du "cahier des charges" et dans la plage 30Hz-100Hz (et peut-être au delà ?)
Voici le code. Les variables consigne PWM sont fixes et auraient aussi bien pu être déclarées comme constantes... dans la réalité, c'est bien sûr au code de les déterminer en temps réel.
/* ARDUINO MEGA */
const int SS_PIN = 25; // SS(slaveSelect)/slave - pin 14 (DS / Serial Data Input) on the 74hc595
const int MOSI_PIN = 26; // MOSI (Master Out Slave Inv- The Master line for sending data to the peripherals) - pin 12 (ST_CP / Storage Register Clock Input (latch)) on the 74hc595
const int MISO_PIN = 29; // MISO (Master In Slave Out - The Slave line for sending data to the master) - pin 11 (SH_CP / shift register clock input) on the 74hc595
const int8_t number_of_74hc595 = 1;
const int8_t numOfRegisterPins = number_of_74hc595 * 8;
boolean pin74hc[numOfRegisterPins] = { 0 }; // data-table, matching with the state of the 74HC595 ouputs
// pseudos PWM à simuler - pour chaque PWM, le tableau donne le cran entre 20 et 120
uint8_t PWM[40] = { 54, 64, 105, 94, 70, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0 };
byte tcnt = 192; // le timer commute tous les (256-tcnt) cycles
/*
avec PRESCALER à 32 (TCCR2B = 0b00000011)
tcnt=126 => 30Hz (les valeurs de tcnt sont empiriques faute de linéarité dans les valeurs de fréquence obtenues)
tcnt=160 => 40Hz
tcnt=180 => 50Hz
tcnt=192 => 60Hz
tcnt=208 => 80Hz
tcnt=218 => 100Hz
*/
byte cran = 0;
void setup() {
Serial.begin(115200);
pinMode(SS_PIN, OUTPUT);
pinMode(MOSI_PIN, OUTPUT);
pinMode(MISO_PIN, OUTPUT);
bitClear (TCCR2A, WGM20); // WGM20 = 0
bitClear (TCCR2A, WGM21); // WGM21 = 0
TCCR2B = 0b00000011;
TIMSK2 = 0b00000001; // Interruption locale autorisée par TOIE2
}
void writeRegisters() {
PORTA &= ~_BV(PA4); // pin 26
for (int8_t i((number_of_74hc595)*8-1) ; i>=0 ; i--) {
PORTA &= ~_BV(PA7); // pin 29
if (pin74hc[i]==0) /*=>*/ PORTA &= ~_BV(PA3); // pin 25
else /*=>*/ PORTA |= _BV(PA3);
PORTA |= _BV(PA7); // pin 29
}
PORTA |= _BV(PA4);
}
void setRegisterPins(byte cran) { //Place les pins du 74HC595 à l'état HAUT ou BAS
for(uint8_t engine(0) ; engine<numOfRegisterPins ; engine++) {
pin74hc[engine] = cran<PWM[engine];
}
writeRegisters();
}
ISR(TIMER2_OVF_vect) {
TCNT2 = tcnt ;
cran++;
setRegisterPins(cran);
if (cran==178) cran=53;
}
void loop() {
/* CODE PRINCIPAL ICI */
}
Le SPI dédié aux 74HC est maintenant sur les broches 26-29 du MEGA... parce que j'utilisais déjà les 50-52 pour le bus CAN et parce que je n'y ai vu aucune différence.
Mais voilà bien une zone d'ombre pour moi qui a résistée à mes questions à Google. Si quelqu'un peut m'indiquer le début de la piste, ça sera apprécié !
(Le Teensy à venir : un 3.5)
-
cadencer en pwm avec réglage de la période c'est tout aussi bon que le ctc, j'ai oublié de le mentionner
c'est pas mal, mais il faut faire le spi par le hardware ; ton arduino arrive à s'en sortir car il lui reste un peu de temps entre la fin de l'émission des trames spi et l'interruption, mais si tu charges encore la bête, tu vas te retrouver avec des "unexpected behaviors"
on peut faire le spi de 2 manières :
soit en soft, comme toi, en faisant bagoter manuellement les pins en digital HIGH ou LOW (tu l'a fais en écrivant direct sur les registres, ça va aussi (mais il y aurait aussi mieux comme méthode pour faire ça))
soit en utilisant le périphérique spi hardware de l'avr : une fois configuré, il n'y a plus qu'a écrire le byte à transmettre dans le périphérique, et celui-ci s'occupe tout seul de faire bagoter les pins MOSI et SCK, sans intervention de la cpu, qui reste disponible pour le reste du travail : c'est tout l'interrêt d'avoir des périphériques hardware, et en effet, souvent les programmateurs ignorent cela, je t'engage à te mettre au courant, c'est largement documenté et pas sorcier
pareil pour le latch (ou SS ou RCLK) : il vaut mieux configurer et utiliser une des 2 sorties pwm de ton timer2, plutôt que de l'écrire manuellement sur la pin 25
le spi hardware est sans doute déjà pris par le can sur l'avr, donc il faut débrancher le can si tu veux tester
le teensy a un can hardware, ce qui permet de libérer ses 3 spi hardwares pour piloter 3 branches de hc595 distinctes, et par là multiplier la fréquence du pwm par 3 ... tu vas pouvoir t'amuser !
je t'ai représenté le truc sur la pj
la 1ère ligne, c'est le signal pwm généré par l'arduino, et raccordé au(x) latch des hc595 ; la flèche vers le haut implique 2 choses :
1) le latch des hc595, qui prennent en compte, au front montant, les données qui viennent de leur être shiftés ; la durée de tes crans sera nickel
2) l'interruption provoquée par le timer du pwm
la 2ème ligne représente grossièrement les signaux MOSI (ou data ou SER) et SCK (ou SRCLK) envoyés par le spi hardware ; le déclenchement de cet envoi se fait dans la routine de l'interruption évoquée ci-dessus ; si tu fais ces signaux en soft, tu vois qu'il reste peu de temps à l'arduino pour faire autre chose ; si c'est automatique par le hardware, il aura tout son temps
les 3èmes et 4èmes lignes montrent les signaux obtenus (il n'y a que 6 crans dans l'exemple) sur 2 sections différentes
exemples : 1/6 3ème ligne : 3/6 4ème ligne
vbui fgazuityer ?
-
wouah cette fois j'ai compris... le principe !
D'un côté le CPU dont le boulot est d'exécuter le code
de l'autre le hard qui offre des services gratuits... très improductif en effet de s'embêter à les reproduire dans du code !
le timer qui se charge de faire "bagoter" (chez moi ça "commute"... pas la même promo on dirait) plutôt qu'une instruction ça c'est grandiose ! (pas encore mis en œuvre mais va falloir !)
Et pour me documenter sur le SPI "harware" ? pas besoin de Google... à priori tout est dans la datasheet.
Un grand merci pour cette explication, pour le temps que ça demande obligatoirement. Avec un schéma de plus ! (*)
Pour l'instant, en l'état, ça fonctionne déjà à merveille... au départ c'était "pour voir" mais l'élimination des PCA9685 semble en prime solutionner des problèmes de plantages du bus I2C, c'est bon à signaler au passage puisqu'il y a maintenant des milliers (presque) d'abonnés à cette chaîne !
Juste ça que je n'ai vraiment pas compris : la conclusion (... pas la même promo...)
(* une remarque sur le schéma : les deux sections sur lesquelles les pulses ne montent pas en même temps ne pourront pour le coup jamais être synchronisées ! Mais l'idée passe bien)
A nouveau : merci !
-
on peut fabriquer des signaux de toutes formes avec cette méthode
la 2ème ligne montre un décalage d'un cran avant l'application de la puissance : ce principe est utilisé dans des ic spécialisés pour répartir les appels de courant ; bien entendu, cette méthode ne nous convient pas, il faudra déterminer l'alim en conséquence
content de voir que tu suis 8)
-
j'ai réfléchi ... ! ... ?
il y a sans doute une solution beaucoup plus simple, tout dépend de la capacité de vos systèmes à la mettre en oeuvre, mais on est quand-même sur le forum locoduino, ça doit être possible !
l'idée, c'est de s'attaquer à la racine du problème, cad. à la transition entre deux pca9685, qui sont on l'a vu, forcément désynchronisés
on va prendre par exemple, pour fixer les idées, 31 sections, donc 2 pca :
- le 1er pca commande les sections 1 à 16, le 2ème pca commande les sections 16 à31
- donc la section 16 peut être, au choix, commandée par le 1er ou par le 2ème pca
- quand le train passe de la section 15 à la section 16, la section 16 est commandée par le 1er pca (pas par le 2ème) : la transition entre la section 15 et la section 16 se fait nickel
- quand le train passe de la section 16 à la section 17, la section 16 est commandée par le 2ème pca (plus par le 1er) : la transition entre la section 16 et la section 17 se fait chrome
- le choix duquel des 2 pca pour la section 16 se fait par un simple "ou câblé", avec 2 diodes et une résistance de pull down de 470R ; la sortie correspondante du pca qui ne commande pas la section 16 est simplement mise à 0%
que vous en pense-t-il ?
La voila ma solution !: commencer par alimenter une section par 1 PCA et finir de l'alimenter par un autre. Merci trimarco232.
Ca peut être fait logiciellement. Mais le montage avec 2 diodes ... m'intéresse et je n'ai pas bien compris. Peux tu me faire un petit schéma, merci.
-
voilà
dans l'exemple, je suis parti sur 40 sections, il faut 3 pca9685
il reste 6 sorties de libres
les 3 pca9685 sont spécialisés pour les signaux pwm ; tu peux choisir d'y mettre aussi les signaux dir1 et dir2, pour l'élégance du câblage : cela t'oblidera toutefois à disposer d'avantage d'ensembles diodes + résistance
-
Merci, je teste ce week-end (il faut que je réadresse les sections ....)
Je viens de tester une version plus simple à modifier, pour voir (je ne suis pas un pro en électronique) :
sortie16 L298 > diode > section 16
sortie17 L298 > diode > section 17
J'ai rajouté 2 diodes donc.
Cette fois au lieu d'un ralentissement, il y a une très légère accélération au changement de section, mais plus de broutement.
Au risque de faire hurler Simontpellier, j'alimente encore les L298 qu'avec 2 fils sur In1 et In2 !
En fait j'utilise des PCA pour tout, j'en ai déjà installé 6 et je vais en rajouter au moins 2 pour les feux sur lesquels je travaille actuellement!
- commande des moteurs d'aiguillage SG90
- alimentation des sections
- commande des feux de signalisation (ce qui permet de moduler l'éclairement)
ça marche nickel sauf lorsqu'il y a changement de PCA sur 2 sections contigües, mais ça progresse !!!
-
les 2 diodes ne suffisent pas, il faut aussi y ajouter la résistance et la mettre à la masse
il faut commander la vitesse par les entrées enableA et enableB (pwm) du L298 ; les entrées 1, 2 et 3, 4 du L298 ne servent qu'à déterminer le sens de marche, 2 doit être l'inverse de 1 (et réciproquement ; et pareil pour 3 et 4)
mon devoir d'information m'oblige à dire ceci :
on peut se passer des diodes et des résistances, en utilisant les pca9685 en mode open-drain
l'inconvénient, c'est que par défaut les entrées pwm des L298 seraient HIGH, ce qui entraine la puissance maximale, pendant l'initialisation des pca9685 ; c'est pourquoi je préconise les résistances de pull-down
tu peux toutefois faire ceci dans le cadre d'un test (tu ne mets pas ta trix à 700€ sur les rails) :
- configurer les pca9685 en open-drain (trouver sur la toile comment faire)
- relier ensemble, sans autre forme de procès : (sortie 16 du 1er pca) - (sortie 1 du 2ème pca) - (entrée enable (pwm) correspondante du L298 correspondant)
- pour les 2 sorties qui sont sur la même entrée, mettre le pwm à 100% pour celle qui n'opère pas, et mettre le pwm à la valeur de la vitesse voulue, pour celle qui opère
une config de test pourrait avoir l'allure suivante :
-
(...)
Mais auparavant : cette idée que tu as suggérée (puis retirée ??) de registres 74HC595 pilotés en SPI rapide.
(...)
Bonjour simontpellier,
je l'avais retiré car mon choix perso et désintéressé penchait pour la solution des pca9685 ...
mais bien entendu, on va continuer de parler de ton projet ici, je m'efforcerai à t'aider pour le mener à terme
il est même, je pense, très intéressant de développer parallèlement 2 approches d'une même problématique, ainsi, - car il y a toujours des amateurs pour l'analogique - ceux qui rechercheront une solution pourront opter pour celle qui leur plaît
-
Bonjour,
tu peux essayer ceci
c'est optimisé pour un avr ; il faut mettre le latch sur la pin 19
tu peux mesurer la fréquence en regardant le latch
#include <SPI.h>
/********** macros ***********/
// nombre de crans
#define crans 128
#define spi_latch_pin 19 // pin19 // PORTB permet l'instruction bitSet
/********** déclarations des variables ***********/
// octet à envoyer sur un 74hc595 // compteur de crans
uint8_t byte_to_spi, cran = 0;
// 40 PWM à simuler - pour chaque PWM, le tableau donne le cran entre 16 et 127
uint8_t PWM1[8] = { 54, 24, 105, 94, 109, 80, 123, 0 };
uint8_t PWM2[8] = { 54, 25, 106, 95, 110, 81, 124, 1 };
uint8_t PWM3[8] = { 54, 26, 107, 96, 111, 82, 125, 2 };
uint8_t PWM4[8] = { 54, 27, 108, 97, 112, 83, 126, 3 };
uint8_t PWM5[8] = { 54, 28, 109, 98, 113, 84, 127, 4 };
/********** setup ***********/
// le setup déroule 1 fois après le démarrage de l'arduino
void setup(void) {
// configure spi
SPI.beginTransaction(SPISettings(16000000, MSBFIRST, SPI_MODE0));
// initialise les broches qui doivent être en sortie
digitalWrite(spi_latch_pin, LOW); // latch est LOW
pinMode(spi_latch_pin, OUTPUT);
Serial.begin(115200);
}
/********** boucle principale ***********/
void loop(void) {
// transferts vers 74hc595
cran++; // la rampe qui monte les crans
bitClear(PORTB, 0); // pin19 // prépare le latch
byte_to_spi = 0; // met tout à LOW
for ( uint8_t bit0to7 = 0; bit0to7 < 8; bit0to7++ ) { // cherche chaque section
if (PWM5[bit0to7] >= cran) bitSet(byte_to_spi, bit0to7);
}
SPDR = byte_to_spi; // lance le transfert sans en attendre la fin
byte_to_spi = 0; // et au suivant ...
for ( uint8_t bit0to7 = 0; bit0to7 < 8; bit0to7++ ) {
if (PWM4[bit0to7] >= cran) bitSet(byte_to_spi, bit0to7); // si la valeur dépasse la rampe ...
}
SPDR = byte_to_spi;
byte_to_spi = 0;
for ( uint8_t bit0to7 = 0; bit0to7 < 8; bit0to7++ ) {
if (PWM3[bit0to7] >= cran) bitSet(byte_to_spi, bit0to7); // ... la sortie sera HIGH
}
SPDR = byte_to_spi;
byte_to_spi = 0;
for ( uint8_t bit0to7 = 0; bit0to7 < 8; bit0to7++ ) {
if (PWM2[bit0to7] >= cran) bitSet(byte_to_spi, bit0to7); // ... si non elle reste LOW
}
SPDR = byte_to_spi;
byte_to_spi = 0;
for ( uint8_t bit0to7 = 0; bit0to7 < 8; bit0to7++ ) {
if (PWM1[bit0to7] >= cran) bitSet(byte_to_spi, bit0to7);
}
SPDR = byte_to_spi;
bitSet(PORTB, 0); // pin19 // latch
if (cran == 127) cran = 0; // retour en début de période pwm, rampe à 0
// fin des transferts vers 74hc595
// what else ?
} // fin loop(void)
-
Ah oui ! l'essayer c'est l'adopter !
je viens de lancer, ça sort du 10kHz !
J'ai fait des essais de mon côté sur le SPI hardware et je suis très très loin de ça ! (Avec un code qui je dois dire ne ressemble en rien)
Évidemment je vais étudier ça de très près. A première vue, je suis juste surpris de voir un seul SPI.beginTransaction dans le setup (et jamais de endTransaction... qui laisserait la main pour autre chose ?)
Mais en tous cas le résultat brut est là, à moi de l'intégrer (dans tous les sens du terme).
________________ APRES PRISE EN MAIN _______________________
J'ai en effet bien besoin d'aide, merci pour la proposition et c'est fort agréable de savoir qu'il y a une hot-line dédiée!
Après étude de ton code et différents essais, voici ce que je comprends (mais peut-être pas) et ce que je ne comprends pas (et ça c'est certain) :
1 - comprends :
- le code en l'état ne fonctionne pas, c'est un bout de code qui pourrait aider
- sa structure permet de faire du daisy-chainning très simplement (si c'est bien ça, c'est très astucieux)
2 - comprends pas :
- SPI.beginTransaction dans le setup
- ligne 6 : #define spi_latch_pin 19 // pin19 // PORTB permet l'instruction bitSet
choisir une autre broche semble tout aussi possible
- ligne 32 : bitClear(PORTB, 0); // pin19 // prépare le latch
La broche 19 n'est pas sur le port B mais D et il faudrait écrire sur le bit 2 et non 0
- if (PWMx[bit0to7] >= cran) bitSet(byte_to_spi, bit0to7);
pas plutôt : if (PWMx[bit0to7] < cran) bitSet(byte_to_spi, bit0to7);
car si le cran dépasse la consigne PWM "bit0to7", ça doit provoquer le falling, non ? C'est en tous cas comme ça que ça fonctionne avec mon code.
(détail, à propos de "bit0to7" : il me semble que "byte0to7" serait plus exact et facile à comprendre. De plus, pour normaliser et comme en réalité ces datas représentent la PWM
à appliquer à une section donnée, ça pourrait donc encore plus clairement s'écrire : if (PWMx[section] < cran) bitSet(byte_to_spi, section);)
3 - comprends pas bien : le choix de bitSet pour construire la trame (voir mes essais)
Pour ma part, voici mes maigres avancées :
- le passage au SPI hardware a un effet très modeste, le gain n'est que d'une 20aine de %
- devant me plier au protocole SPI, j'ai des difficultés à construire la trame. Elle est limitée par le protocole à 32bits ce qui fait que je ne peux pas atteindre les 40PWM "imposées" sans devoir faire du daisy-chainning (ou définir deux esclaves). Mais donc ça se solutionne
Le plus ennuyeux est que la construction de la trame est semble-il ce qui ralentit le code à tel point que le bénéfice du SPI rapide disparaît presque complètement
Voici le nouveau code, avec une syntaxe quasiment normalisé pour que les échanges soient plus faciles.
Dans lequel j'ai essayé deux méthodes pour construire la trame : utiliser des bitWrite est TROIS FOIS moins rapide que l'autre, d'où mon interrogation, plus haut, sur bitSet (que j'ai donc eu l'idée d'essayer, mais il nécessite un "if" et le résultat est encore plus dégradé qu'avec bitWrite)
/* ARDUINO MEGA */
#include <SPI.h>
//#include "SPIDaisyChain.h"
#define crans 128
const int8_t howmany_74HC = 4;
boolean pin74HC[howmany_74HC*8] = { 0 }; // data-table, matching with the state of the 74HC595 ouputs
// 40 pseudos PWM à émuler - pour chaque PWM, la valeur donne le cran de consigne
uint8_t PWM[40] = { 54, 64, 105, 94, 109, 80, 130, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0 };
uint32_t count;
uint32_t chain;
void setup() {
Serial.begin(115200);
DDRF |= B00001010; // A1 & A3 = output
SPI.begin();
}
void writeSlave1() { // https://www.arduino.cc/en/Hacking/PinMapping2560
PORTF &= B11111101; // PIN A1 (latch) = LOW
SPI.beginTransaction(SPISettings(16000000, MSBFIRST, SPI_MODE0));
SPI.transfer(chain);
SPI.endTransaction();
PORTF |= B00000010; // => HIGH
}
void setRegistersSlave1() { // Place les pins des 74HC595 à l'état HAUT ou BAS
for (uint8_t cran(0) ; cran<crans ; cran++) {
chain = 0;
for(uint8_t section(0) ; section<howmany_74HC*8 ; section++) {
chain = chain<<1;
pin74HC[section]=cran<PWM[section];
// bitWrite(chain, section, pin74HC[section]);
chain = pin74HC[section] + chain;
}
writeSlave1();
}
}
void loop() {
setRegistersSlave1();
count++;
if (millis() > 3000) {
Serial.print(count/3);Serial.println("Hz");
Serial.end();
}
}
-
(...)________________ APRES PRISE EN MAIN _______________________
J'ai en effet bien besoin d'aide, merci pour la proposition et c'est fort agréable de savoir qu'il y a une hot-line dédiée!
Après étude de ton code et différents essais, voici ce que je comprends (mais peut-être pas) et ce que je ne comprends pas (et ça c'est certain) :
1 - comprends :
- le code en l'état ne fonctionne pas, c'est un bout de code qui pourrait aider
c'est sensé fonctionner (mais comme toujours après correction des erreurs, je n'ai pas testé)
- sa structure permet de faire du daisy-chainning très simplement (si c'est bien ça, c'est très astucieux)
c'est juste ce que j'ai trouvé de + facile ... mais en effet, ça permet de s'adapter facilement à d'autres configurations, à d'autres mcu ...
2 - comprends pas :
- SPI.beginTransaction dans le setup
c'est là qu'on initialise le hardware ; pas besoin de SPI.endTransaction(), c'est comme un ventilteur, ça s'arrête tout seul quand on coupe le courant à la fin ; par la suite les transfert sont lancés en écrivant directement dans le registre d'envoi, on ne reconfigure pas tout le barnum ; aussi, on n'attend pas la fin du transfert, on fait autre chose (calcul de la trame suivante) et pendant ce temps le transfert est fini
- ligne 6 : #define spi_latch_pin 19 // pin19 // PORTB permet l'instruction bitSet
choisir une autre broche semble tout aussi possible
oui, une autre broche convient, éviter les ports à partir de F, qui n'admettent pas bitSet en 1 cycle
- ligne 32 : bitClear(PORTB, 0); // pin19 // prépare le latch
La broche 19 n'est pas sur le port B mais D et il faudrait écrire sur le bit 2 et non 0
ok, confondu le numéro de la broche sur une mega, avec sa dénomination arduino :-[
- if (PWMx[bit0to7] >= cran) bitSet(byte_to_spi, bit0to7);
pas plutôt : if (PWMx[bit0to7] < cran) bitSet(byte_to_spi, bit0to7);
car si le cran dépasse la consigne PWM "bit0to7", ça doit provoquer le falling, non ? C'est en tous cas comme ça que ça fonctionne avec mon code. c'est exactement ce que j'ai fait : le bit est systématiquement initialisé à LOW et devient HIGH tant que la consigne dépasse la rampe
(détail, à propos de "bit0to7" : il me semble que "byte0to7" serait plus exact et facile à comprendre. De plus, pour normaliser et comme en réalité ces datas représentent la PWMje fais une évaluation depuis le bit0 jusqu'au bit7, il m'a semblé logique d'appeler le bit en cours bit0to7
à appliquer à une section donnée, ça pourrait donc encore plus clairement s'écrire : if (PWMx[section] < cran) bitSet(byte_to_spi, section);)
3 - comprends pas bien : le choix de bitSet pour construire la trame (voir mes essais)
c'est peut-être tout simplement 2 façons différentes de faire la même chose, chacun utilisant celle qu'il comprend
Pour ma part, voici mes maigres avancées :
- le passage au SPI hardware a un effet très modeste, le gain n'est que d'une 20aine de % c'est déjà ça, le but c'est de faire faire le + de travail possible au hardware, car le soft est déjà très pris par la confection des trames avant envoi
- devant me plier au protocole SPI, j'ai des difficultés à construire la trame. Elle est limitée par le protocole à 32bits ce qui fait que je ne peux pas atteindre les 40PWM "imposées" sans devoir faire du daisy-chainning (ou définir deux esclaves). Mais donc ça se solutionne
Le plus ennuyeux est que la construction de la trame est semble-il ce qui ralentit le code à tel point que le bénéfice du SPI rapide disparaît presque complètement
Voici le nouveau code, avec une syntaxe quasiment normalisé pour que les échanges soient plus faciles.
Dans lequel j'ai essayé deux méthodes pour construire la trame : utiliser des bitWrite est TROIS FOIS moins rapide que l'autre, d'où mon interrogation, plus haut, sur bitSet (que j'ai donc eu l'idée d'essayer, mais il nécessite un "if" et le résultat est encore plus dégradé qu'avec bitWrite) bitSet et bitClear prennent 1 cycle, on ne peut pas faire + vite
/* ARDUINO MEGA */
#include <SPI.h>
//#include "SPIDaisyChain.h"
#define crans 128
const int8_t howmany_74HC = 4;
boolean pin74HC[howmany_74HC*8] = { 0 }; // data-table, matching with the state of the 74HC595 ouputs
// 40 pseudos PWM à émuler - pour chaque PWM, la valeur donne le cran de consigne
uint8_t PWM[40] = { 54, 64, 105, 94, 109, 80, 130, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0 };
uint32_t count;
uint32_t chain;
void setup() {
Serial.begin(115200);
DDRF |= B00001010; // A1 & A3 = output
SPI.begin();
}
void writeSlave1() { // https://www.arduino.cc/en/Hacking/PinMapping2560
PORTF &= B11111101; // PIN A1 (latch) = LOW
SPI.beginTransaction(SPISettings(16000000, MSBFIRST, SPI_MODE0));
SPI.transfer(chain);
SPI.endTransaction();
PORTF |= B00000010; // => HIGH
}
void setRegistersSlave1() { // Place les pins des 74HC595 à l'état HAUT ou BAS
for (uint8_t cran(0) ; cran<crans ; cran++) {
chain = 0;
for(uint8_t section(0) ; section<howmany_74HC*8 ; section++) {
chain = chain<<1;
pin74HC[section]=cran<PWM[section];
// bitWrite(chain, section, pin74HC[section]);
chain = pin74HC[section] + chain;
}
writeSlave1();
}
}
void loop() {
setRegistersSlave1();
count++;
if (millis() > 3000) {
Serial.print(count/3);Serial.println("Hz");
Serial.end();
}
}
[/quote]
-
Bonjour,
moyennant beaucoup-beaucoup d'essais... ayé tout marche !
Je rapporte auparavant quelques grosses surprises notées en cours de route.
- le SPI logiciel... en réalité il est déjà bien rapide !
en effet, remplacer la boucle : for (uint8_t cran(0) ; cran<crans ; cran++)
par cran=0; //................// if (cran == 127) cran = 0;
multiplie la vitesse par 10 ! de 130 à 1200 Hz !
- mais bien loin c'est vrai du SPI Harware : 20kHz
avec la aussi une surprise (c'est confirmé) : chain = chain<<1; chain = (cran<PWM5[section]) + chain; tourne à 20Mhz
tandis que (PWMx[section] >= cran) bitSet(byte_to_spi, section); n'atteint pas 9Mz (mais un poil plus haut que bitWrite)
Voici le code, de plus en plus concis, avec ton code exemple à la base. Et avec comme dernière surprise qu'un code plus "Arduino-rustique" et qui utilise SPI.transfer fait légèrement mieux !
/* ARDUINO MEGA */
#include <SPI.h>
#define crans 128
#define SpiControl 0b01110000 // sur bits: SPIE SPE DORD MSTR CPOL CPHA SPR1 SPR0
#define bDa 2 // MOSI 51
#define bCk 1 // CLK pin 52
#define bLd 0 // SS pin 53
// pseudos PWM à émuler - pour chaque PWM, le tableau donne le cran entre de 0 à 127
uint8_t PWM1[] = { 0, 0, 0, 0, 0, 100, 0, 00 };
uint8_t PWM2[] = { 0, 0, 0, 0, 0, 0, 10, 0 };
uint8_t PWM3[] = { 54, 26, 107, 96, 111, 82, 125, 2 };
uint8_t PWM4[] = { 54, 27, 108, 97, 112, 83, 126, 3 };
uint8_t PWM5[] = { 54, 28, 109, 98, 113, 84, 127, 4 };
uint8_t cran = 0;
uint32_t count;
uint8_t chain;
void setup() {
Serial.begin(115200);
DDRB |= 1<<bLd | 1<<bCk | 1<<bDa ;
SPCR = SpiControl ;
}
void setSlaveRegisters() { //Place les pins des 74HC595 à l'état HAUT ou BAS
cran++;
bitClear (PORTB,bLd);
chain = 0 ;
for (int8_t section(0); section<8; section++) {
chain = chain<<1;
chain = (cran<PWM5[section]) + chain; /* pour mémoire : pin74HC[section]=cran<PWM[section]; */
}
SPDR = chain;
while (!(SPSR & 1<<SPIF)) {}
chain = 0 ;
for (int8_t section(0); section<8; section++) {
chain = chain<<1;
chain = (cran<PWM4[section]) + chain;
}
SPDR = chain;
while (!(SPSR & 1<<SPIF)) {}
(...)
chain = 0 ;
for (int8_t section(0); section<8; section++) {
chain = chain<<1;
chain = (cran<PWM1[section]) + chain;
}
SPDR = chain;
while (!(SPSR & 1<<SPIF)) {}
bitSet (PORTB,bLd);
if (cran == crans-1) cran = 0;
}
void loop() {
setSlaveRegisters();
}
20kHz... de quoi faire tourner même les moteurs qui aiment les hautes fréquences ! (avec mes 40Hz optimum constaté, je reste sur ma faim d'une explication!)
Beau travail non ? Un TRES GRAND MERCI.
Me reste juste à bagoter le latch avec un timer (je reviendrai) et j'aurai plus qu'à dessiner un réseau avec 40 sections !
-
bravo !
le problème à voir maintenant, c'est le temps qu'il reste au cpu de faire autre chose ...
dans ta maquette, tu as fait tourner en boucle le calcul des trames, il faut insérer du temps pour les autres opérations de l'arduino
au pif, je dirais qu'on peut limiter, par timer, la fréquence à 13kHz, ce qui laisse au cpu 1/3 de sa capacité de calcul
par ailleurs :
- générer le latch directement par le hardware du timer n'est peut-être pas une bonne idée, il faut peut-être pouvoir vérifier que les transferts sont terminés avant de latcher : à faire au début de l'interruption provoquée par le timer
- while (!(SPSR & 1<<SPIF)) {} : il faut enlever ça ! car quand le transfert hardware est lancé par SPDR = chain; , on peut directement passer au calcul de la trame du prochain transfert (pour 8 section), ce qui laisse très largement au spi hardware de terminer le job, donc : pas la peine de vérifier qu'il a fini, et surtout ne pas attendre qu'il ait fini avant d'enchaîner la suite des calculs
- on peut peut-être encore gagner un peu de temps en supprimant la boucle "for section<8", cad. réécrire 8 fois le calcul de chain ... (sauf si le compilo reconnaît la magouille et passe outre ... il faut voir si on a des options de compilation)
-
les "while" en effet mais le code ne tourne pas sans. On peut les enlever mais il faut alors ajouter un petit delay avant le latch, 10us au moins. En principe c'est pas très bon mais dans ce cas il y a un petit gain et le résultat égale quasiment des "SPI.transfer". Ce qui offre un choix
Là bien sûr c'est une performance brute avec une loop qui ne fait que ça (même pas vrai car j'ai testé l'ajout d'un second esclave, en prévision d'un "general purpose", rafraîchi toutes les 10ms, et c'est quasiment sans incidence).
Au final, le réglage de la fréquence PMW effective se fera par le timer2 et interruptions, ce qui a marché va resservir !
(Et comment on fait pour vérifier que les transferts sont effectués ?)
-
c'est ce qu'il y a derrière le while : tu mets if( à la place de while (!
-
...while/if... le problème ne s'est finalement pas posé. Je pense que ça s'explique par la gamme de (basse) fréquence qui m'intéresse.
Je reviens donc pour déposer le code final : ça va décidément très très vite : avec une fréquence bridée par interruptions à 60Hz vérifiés/oscillo et pour 40PWM, la loop tourne elle à ...160 kHz! (perso, avec un petit réseau école c'est vrai mais toutes les fonctions d'un grand, ma loop prend 6ms... 6 comparé à 160, y'a de la marge ! et je suis d'ailleurs de plus en plus étonné par ce qu'un Arduino Mega a dans le ventre).
D'autres paramètres (prescaler etc) permettraient une plage de fréquence bien plus haute sans étouffer le CPU ; je fais confiance à l'estimation l'analyseur logique à 10balles de Trimarco.
Le SPI étant largement susceptible d'avoir d'autres usages que de la PWM logicielle, pour l'exemple le code pilote en parallèle des registres indépendants de ceux de la PWM, par exemple pour les pins de polarisation des boosters, pour des signaux etc.
Juste dommage que tout ça ne puisse marcher qu'à condition de ne pas avoir besoin du (seul) SPI harware pour un bus CAN (et très dommage qu'il manque juste une broche au Mega pour pouvoir en créer un second). Mais un SPI logiciel, même moins véloce, pourra quand même abattre du boulot.
Le code en pièce jointe (encore merci à Trimarco)
Bien cordialement
-
...while/if... le problème ne s'est finalement pas posé. Je pense que ça s'explique par la gamme de (basse) fréquence qui m'intéresse.
Je reviens donc pour déposer le code final : ça va décidément très très vite : avec une fréquence bridée par interruptions à 60Hz vérifiés/oscillo
merci
et pour 40PWM, la loop tourne elle à ...160 kHz! (perso, avec un petit réseau école c'est vrai mais toutes les fonctions d'un grand, ma loop prend 6ms... 6 comparé à 160, y'a de la marge ! et je suis d'ailleurs de plus en plus étonné par ce qu'un Arduino Mega a dans le ventre).
D'autres paramètres (prescaler etc) permettraient une plage de fréquence bien plus haute sans étouffer le CPU ; je fais confiance à l'estimation de Trimarco.moi, je fais plutôt confiance à mon analyseur logique à 10 balles
Le SPI étant largement susceptible d'avoir d'autres usages que de la PWM logicielle, pour l'exemple le code pilote en parallèle des registres indépendants de ceux de la PWM, par exemple pour les pins de polarisation des boosters, pour des signaux etc.
oui, mais ça ralentirait tout inutilement ; il vaut mieux traiter les io lents avec un spi soft dédié
(pour les signaux tu peux utiliser un tlc5947)
Juste dommage que tout ça ne puisse marcher qu'à condition de ne pas avoir besoin du (seul) SPI harware pour un bus CAN (et très dommage qu'il manque juste une broche au Mega pour pouvoir en créer un second). Mais un SPI logiciel, même moins véloce, pourra quand même abattre du boulot.les méga comportent 3 usart prévus pour fonctionner en variante comme spi maitres (même mieux que le spi) mais les pinioufs de chez arduino n'ont pas jugé utile de sortir les broches clk sur la carte ; je pourrais le faire avec mon pro micro
mais de toutes manières, il est temps de "s'attaquer" à l'arm, non ?
Le code en pièce jointe (encore merci à Trimarco) service
Bien cordialement
-
quoique...
un certain "milwind" fait remarquer que la pin XCK qui est en 48 est tout près de la pin de la pin 50 qui, elle, sort sur une broche et qu'il suffit juste d'un petit pont de soudure. Faut oser ! Il a osé.
https://forum.arduino.cc/index.php?topic=257506.0
(Mais pourquoi une PWM de pourrait-elle pas plutôt être utilisée comme signal d'horloge ?)
(et OK j'ai corrigé : je fais confiance à l'analyseur logique à 10 balles de Trimarco)
-
bricolage infâme sur du pas de 0.4mm ... voir plutôt Mega2560 CORE chez aliex. par ex.
pwm : ça marche pas
-
@simontpellier :
on avait parlé parlé de la charge cpu que représente la préparation des trames 74hc595, avant de les envoyer via le spi (ou en manuel) : il ne restait pas beaucoup de ressources au mcu pour faire autre chose
il y a une possibilité de bien améliorer les choses, qui consiste à utiliser un nano ou un mini à base de LGT8F328P : il travaille à 32MHz à la place de 16MHz, il va donc (au moins) 2 fois + vite
j'ai parlé de ce module ici : https://forum.arduino.cc/index.php?topic=729831.0
-
@trimarco232 :
Bon plan merci ! (Pour pas trop cher!)
(le mega CORE était également une bonne suggestion, je ne connaissais pas non plus)
L'objectif en cours est néanmoins basé sur le Teensy 3.5 qui repousse très loin toutes les limites. Les librairies Arduino passent comme qui rigole, le code "shift-register-PWM" transféré sur Teensy tourne à une vitesse faramineuse... mais reste le problème du bus CAN. La librairie n'a rien en commun avec ACAN, les exemples sont peu nombreux, et abcons, et il y a 4 "variants" (tous anglais) de ladite librairie... j'ai eu beau labourer le web, pas moyen de se faire parler la teensy (via son CAN intégré) avec un Arduino, je suis au bord de l'appel au secours.
-
prends un esp32, il a 2 spi, et il me semble que le can a été testé ici
-
ACAN existe pour Teensy. C'est même sur cette cible qu'elle a été développée en premier. Elle est disponible dans le gestionnaire de bibliothèques.
En résumé les différentes incarnations :
ACAN, CAN Library for Teensy 3.1 / 3.2, 3.5, 3.6 : https://github.com/pierremolinaro/acan
ACAN2515, MCP2515 CAN Controller Library for Arduino : https://github.com/pierremolinaro/acan2515
ACAN2515Tiny, adaptation of ACAN2515 library in order to reduce the memory footprint : https://github.com/pierremolinaro/acan2515Tiny
ACAN2517, MCP2517FD CAN Controller Library for Arduino (in CAN 2.0B mode) : https://github.com/pierremolinaro/acan2517
ACAN2517FD, MCP2517FD and MCP2518FD CAN Controller Library for Arduino (in CAN FD mode) : https://github.com/pierremolinaro/acan2517FD
ACAN-T4, CAN Library for Teensy 4.0 : https://github.com/pierremolinaro/acan-t4
Une version pour le SJA1000 like intégré à l'ESP32 est en préparation.
-
Merci M Jean-Luc pour l'info ACAN pour Teensy. Je regrette d'avoir raté votre post mais pas grave puisque j'ai découvert cette librairie par ailleurs il y a ... deux heures !
Et je me suis permis de faire dans la foulée un mail à Pierre Molinaro (pour autant que l'adresse soit active) car je rencontre avec sa librairie exactement le même souci qu'avec "flexCAN", à savoir un Teensy qui lit sur le bus sans problème, et acquitte, mais ne sait pas écrite... j'ai mis tous mes moyens intellectuels sur le coup, ils n'y ont pas suffi et je n'ai plus de cartouche à tirer sauf d'acheter une autre carte "pour voir" !
Une petite question si je peux à propos de ACAN (celle des Arduino) ? J'y vais régulièrement voir sur site s'il y a des nouvelles de la note de renvoi 4: [4] Nous verrons les messages remote dans un prochain article aussi comme j'imagine que vous en serez l'auteur, eh bien je languis de cette publication à venir !
-
à savoir un Teensy qui lit sur le bus sans problème, et acquitte, mais ne sait pas écrite... j'ai mis tous mes moyens intellectuels sur le coup, ils n'y ont pas suffi et je n'ai plus de cartouche à tirer sauf d'acheter une autre carte "pour voir" !
Et par ailleurs la sortie TXCAN est-elle correcte pour le GPIO ? Serait-il possible qu'elle soit grillée ?
Le CAN est également disponible sur pins 32 et 25, voir page 8 et 9 de la doc de ACAN. Il s'agit des broches situées dessous.
Une petite question si je peux à propos de ACAN (celle des Arduino) ? J'y vais régulièrement voir sur site s'il y a des nouvelles de la note de renvoi 4: [4] Nous verrons les messages remote dans un prochain article aussi comme j'imagine que vous en serez l'auteur, eh bien je languis de cette publication à venir !
C'est dans les tuyaux mais il faut que je finisse d'abord les programmes :)
-
... ouf pas de sortie grillée ! (sur ma Teensy3.5 dont les pins RX/TX alternatifs sont brochés au recto, ce qui est heureux !)
j'avais ce matin déjà une réponse de Pierre Molinaro, dont cette version courte : Réponse courte : il faut que la patte STBY du MCP2562 soit à 0, sinon, par défaut, une résistance de tirage interne au MCP2562 la met au niveau haut, qui est le mode standby.
(La solution était toute bête, comme toujours ou presque, et ce qui est surtout bête de ma part c'est qu'elle était contenue dans un schéma récent de Dominique : https://forum.locoduino.org/index.php?topic=922.msg12443#msg12443 ) (réponse #418)
En cherchant les occurrences "teensy" sur le forum, je m'aperçois qu'elles sont très peu nombreuses et presque chaque fois très furtives, sans fil réellement dédié.
Je vais réfléchir s'il y a matière à en créer un, par exemple une fois que j'aurai bien en main la librairie CAN Teensy citée ici par Jean-Luc mais comme on est très loin du sujet originel c'est une info qui ne profitera pas comme elle pourrait. Façon de compléter par des aspects pratiques l'article du site sur ces cartes Teensy.
(et vivement l'opus 3 des articles ACAN !)
Merci pour ces interventions
cordialement
-
(La solution était toute bête, comme toujours ou presque, et ce qui est surtout bête de ma part c'est qu'elle était contenue dans un schéma récent de Dominique : https://forum.locoduino.org/index.php?topic=922.msg12443#msg12443 ) (réponse #418)
En cherchant les occurrences "teensy" sur le forum, je m'aperçois qu'elles sont très peu nombreuses et presque chaque fois très furtives, sans fil réellement dédié.
Je vais réfléchir s'il y a matière à en créer un, par exemple une fois que j'aurai bien en main la librairie CAN Teensy citée ici par Jean-Luc mais comme on est très loin du sujet originel c'est une info qui ne profitera pas comme elle pourrait. Façon de compléter par des aspects pratiques l'article du site sur ces cartes Teensy.
(et vivement l'opus 3 des articles ACAN !)
Merci pour ces interventions
cordialement
C'est vrai qu'on pourrait déplacer les parties de ce sujet consacrées au CAN et au Teensy dans la rubrique "Bus Can"
Si vous êtes d'accord, je le fais demain ou bientôt.
C'est d'autant plus interessant que j'ai prévu de passer du Due au Teensy pour le gestionnaire graphique de mon réseau car je dispose d'un bel écran 7 pouces et d'une carte splendide faite par Jean-Luc : Dès que j'aurai résolu mes derniers bugs dans la gestion des trains (suivi des trains, espacement, etc.. ) avec toute la rétrosignalisation en place via le bus Can, il sera temps alors de réécrire tout proprement ou autrement et le Teensy le mérite bien ;D
Car le gestionnaire reçoit tous les messages des capteurs de présence, les détections ponctuelles optiques et RFID et les changements de vitesse/direction de la traction DCC. Avec tous ces messages il faut garder en permanence la correspondance entre les zones et les trains qui sont dessus (pour les commander en DCC, il faut bien connaitre leur adresse) et agir sur les commandes DCC en conséquence. Il y a de la redondance et pas mal de vérifications et heureusement un recalage grâce aux capteurs RFID. Je me sers beaucoup du moniteur pour suivre les événements et les traitements.
-
Bonjour Dominique,
également, je pense qu'il serait bien de déplacer tous les posts concernant la synchro pwm par 74hc595 dans une rubrique ad hoc ; si tu veux bien, je te fais la liste des # des posts concernés
-
OK ce sera plus facile à retrouver dans une recherche.
Merci d'avance.
-
Bonsoir...
ça fait donc deux bonnes idées, il est vrai qu'un coup de tamis fera du bien. Désolé d'avoir floodé !
-
J’ai déjà copié les 2 contributions de Jean-Luc dans le sujet « ACAN et Teensy »
https://forum.locoduino.org/index.php?topic=1189 (https://forum.locoduino.org/index.php?topic=1189)
Il faudrait scinder le sujet en plusieurs parties et déplacer chaque partie, ce que je ne sais pas faire.
-
enfin, jai créé le sujet idoïne, et voici la liste des # à transférer
avec mille excuses pour le retard, et autant de mercis pour le travail à faire :
20
22
23
24
25
26
28
29
30
31
32
33
34
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54 (can)
55 (can)
56 (can)
57 (can)
58 (can)
59 etc - corbeille
-
A quoi correspondent ces nombres ?
-
c'est les # des posts qu'il faudrait retirer de ce sujet pour les transférer vers le nouveau sujet "pilotage des cantons en analogique : synchro des pwm par 74hc595"
c'est peut-être + facile de faire l'inverse