16
Débuter / Re : PCA9685
« le: février 11, 2022, 09:40:57 pm »
hihihi... +1 ! 
(on a tous débuté !)
(on a tous débuté !)
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
17
Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls
« le: février 11, 2022, 09:35:54 pm »
... comparer les valeurs des interruptions n-1 et n ?
Oui je vois l'idée mais... non... ça donnerait juste une tendance ; il la faut pour les asservissements les plus performants, sinon c'est sans intérêt. C'est la comparaison instant "t" entre mesure et demande ("consigne") qui indiquera le sens de la correction à effectuer. Charge à l'asservissement de calculer son intensité et à partir de là, palier de vitesse, accélération, ralentissement, pas de différence, c'est toujours le delta mesure_consigne qui sera la base de calcul de la juste PWM à appliquer.
Quant-à la problématique "capteur de présence"... bonne et déterminante question ! Sauf qu'elle est tellement vaste, je n'oserai qu'une qu'une réponse sommaire...
Déjà on peut éliminer les réseaux digitaux car sauf possible cas particulier je ne vois pas la place que pourrait y avoir un L298N... mais je ne connais rien au digital.
Côté analogique... ? Je n'ai jamais vu de post sur un réseau qui utiliserait le Vsensor des L298... je pense que ça s'explique comme cela :
- si on utilise des L298N en nombre égal à celui des trains possiblement en circulation - dans ce cas, la PWM(+polarisation) d'un train donné doit être adressée à la section électrique qu'il occupe au moyen d'une batterie de relais. Il n'y a donc plus de lien entre la mesure Vsensor et l'occupation ou non d'une section précise. (quid de la FCEM ? ça marche si c'est une motrice... pas si c'est un wagon, donc c'est mort)
- si c'est en nombre égal à celui des sections électriques : là c'est le code qui à mesure de l'avancement du train adresse chaque PWM/train "perso" au(x) pont(s) affecté(s) à la (aux) section(s) occupées. Et donc dans ce cas, si telle ou telle section est occupée, le code le sait déjà !
Le problème primordial de la détection demeure donc ! Et c'est choisir la technologie, puis les capteurs, mais aussi la façon dont seront utilisées les informations le but étant que le code puisse toujours se faire une représentation exacte du réseau.
Disons juste qu'il y a deux grands principes, qu'on peut d'ailleurs combiner :
- une détection par capteurs de consommation de courant. Mais problème avec les wagons... il faut graphiter les essieux (et prier) sinon le détecteur ne voit que les motrices ! Pour avoir une vision temps réel du réseau ces capteurs impliquent aussi je crois de les interroger en continue ;
- une détection par détecteurs de passage. Dans ce cas motrice ou wagon peu importe. On peut dire que le détecteur prend une photo => à partir de ces clichés, charge au code de tenir à jour un tableau des sections occupées, ça n'est pas sorcier. Mais la détection doit être infaillible sinon la catastrophe guette (la aussi).
Ni le Vensor ni la FCEM n'ont donc d'intérêt en tant que détection.
Mais...
il n'a été jusque là question que de l'occupation des sections. Outre réguler la vitesse, ce que la FCEM peut faire en prime c'est indiquer la POSITION d'un convoi dans une section donnée ! En effet, la FCEM renseignant en continue sur la vitesse, il suffit d'introduire la variable temps pour obtenir une distance parcourue (à partir par exemple du dernier détecteur de passage).
De quoi cogiter !
Oui je vois l'idée mais... non... ça donnerait juste une tendance ; il la faut pour les asservissements les plus performants, sinon c'est sans intérêt. C'est la comparaison instant "t" entre mesure et demande ("consigne") qui indiquera le sens de la correction à effectuer. Charge à l'asservissement de calculer son intensité et à partir de là, palier de vitesse, accélération, ralentissement, pas de différence, c'est toujours le delta mesure_consigne qui sera la base de calcul de la juste PWM à appliquer.
Quant-à la problématique "capteur de présence"... bonne et déterminante question ! Sauf qu'elle est tellement vaste, je n'oserai qu'une qu'une réponse sommaire...
Déjà on peut éliminer les réseaux digitaux car sauf possible cas particulier je ne vois pas la place que pourrait y avoir un L298N... mais je ne connais rien au digital.
Côté analogique... ? Je n'ai jamais vu de post sur un réseau qui utiliserait le Vsensor des L298... je pense que ça s'explique comme cela :
- si on utilise des L298N en nombre égal à celui des trains possiblement en circulation - dans ce cas, la PWM(+polarisation) d'un train donné doit être adressée à la section électrique qu'il occupe au moyen d'une batterie de relais. Il n'y a donc plus de lien entre la mesure Vsensor et l'occupation ou non d'une section précise. (quid de la FCEM ? ça marche si c'est une motrice... pas si c'est un wagon, donc c'est mort)
- si c'est en nombre égal à celui des sections électriques : là c'est le code qui à mesure de l'avancement du train adresse chaque PWM/train "perso" au(x) pont(s) affecté(s) à la (aux) section(s) occupées. Et donc dans ce cas, si telle ou telle section est occupée, le code le sait déjà !
Le problème primordial de la détection demeure donc ! Et c'est choisir la technologie, puis les capteurs, mais aussi la façon dont seront utilisées les informations le but étant que le code puisse toujours se faire une représentation exacte du réseau.
Disons juste qu'il y a deux grands principes, qu'on peut d'ailleurs combiner :
- une détection par capteurs de consommation de courant. Mais problème avec les wagons... il faut graphiter les essieux (et prier) sinon le détecteur ne voit que les motrices ! Pour avoir une vision temps réel du réseau ces capteurs impliquent aussi je crois de les interroger en continue ;
- une détection par détecteurs de passage. Dans ce cas motrice ou wagon peu importe. On peut dire que le détecteur prend une photo => à partir de ces clichés, charge au code de tenir à jour un tableau des sections occupées, ça n'est pas sorcier. Mais la détection doit être infaillible sinon la catastrophe guette (la aussi).
Ni le Vensor ni la FCEM n'ont donc d'intérêt en tant que détection.
Mais...
il n'a été jusque là question que de l'occupation des sections. Outre réguler la vitesse, ce que la FCEM peut faire en prime c'est indiquer la POSITION d'un convoi dans une section donnée ! En effet, la FCEM renseignant en continue sur la vitesse, il suffit d'introduire la variable temps pour obtenir une distance parcourue (à partir par exemple du dernier détecteur de passage).
De quoi cogiter !
18
Débuter / Re : PCA9685
« le: février 10, 2022, 10:19:52 pm »
normalement cette seule instruction "pwm.setPWM(...)" devrait en effet fonctionner... à condition toutefois de ne pas avoir oublié (?) deux lignes dans le setup :
pwm.begin();
pwm.setPWMFreq(x);
Côté "hard", il est bon effectivement de se référer à l'article indiqué par msport pour que le pont soit correctement câblé, borne "enable" sur la sortie pwm "0" (dans ce cas du moins) du PCA et les deux pins de polarisation en boolean inverses, l'une à "1" et l'autre à zéro. (Et interconnecter tous les GND !)
pwm.begin();
pwm.setPWMFreq(x);
Côté "hard", il est bon effectivement de se référer à l'article indiqué par msport pour que le pont soit correctement câblé, borne "enable" sur la sortie pwm "0" (dans ce cas du moins) du PCA et les deux pins de polarisation en boolean inverses, l'une à "1" et l'autre à zéro. (Et interconnecter tous les GND !)
19
Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls
« le: février 10, 2022, 09:56:00 pm »
Bonsoir,
msport a donné la version courte ;
une précision si besoin en est : le Vsensor renseigne sur la force électromotrice fournie au moteur (qui n'est pas précisément corrélée à son régime tr/mn)
Alors que ce que l'on cherche est la force CONTRE électromotrice, réinjectée par le moteur, en mode génératrice du fait de son inertie, lorsque le pont L298 ne l'alimente (brièvement) PAS. Or là, la tension recueillie représente parfaitement son régime.
msport a donné la version courte ;
une précision si besoin en est : le Vsensor renseigne sur la force électromotrice fournie au moteur (qui n'est pas précisément corrélée à son régime tr/mn)
Alors que ce que l'on cherche est la force CONTRE électromotrice, réinjectée par le moteur, en mode génératrice du fait de son inertie, lorsque le pont L298 ne l'alimente (brièvement) PAS. Or là, la tension recueillie représente parfaitement son régime.
20
Vos projets / Re : L298 et relais
« le: janvier 23, 2022, 12:00:06 pm »Citer
merci de citer vos sources lorsque vous affirmez quelque chose
40 kHz c'est exact et je suis confus : l'information était corrompue, comme ma mémoire qui n'avait retenu que le fait qu'il était conseillé de ne pas utiliser les L298N au dessus de 25kHz.
La source était là : https://passionelectronique.fr/tutoriel-l298n/
Asservissement versus compensation de charge ?
Disons que dans votre auto, si vous mettez en route le régulateur de vitesse (supposons), c'est un asservissement - le système à partir d'une seule information initiale, la consigne vitesse, agit pour la maintenir constante en toute circonstances (dans certaines limites bien sûr)
Maintenant imaginons un système plus limité : 1) vous restez maître de la vitesse à tout moment 2) le "système" traduit cette consigne temps réel (enfoncement de l'accélérateur) en vitesse cible et "appuie" en renfort lorsque la vitesse constatée est insuffisante. C'est donc une compensation, qui intervient notamment lorsque la charge moteur augmente.
21
Vos projets / Re : L298 et relais
« le: janvier 22, 2022, 05:51:18 pm »
? Que désignent PWM1 et PWM2 ? La PWM étant de la "Modulation de la Largeur de l'Impulsion", le principe ("hachage") reste, quelque soit la fréquence adoptée
(une note à l'intention de babskwal qui utilise des L298 : ceux-ci ne pouvant pas commuter plus vite que 25 kHz, il faut oublier le 32Kz). EDIT : faux !! voir posts suivants
Je crois qu'il me manque de comprendre ceci : "je synchronise mes cantons sur le secteur redressé double alternance, soit 100Hz" ; s'agit-il de ce que cet article de l'AFMN appelle "alimentation à découpage à partir de l'alternatif" (voir lien plus bas) ? Dans ce cas ça n'est pas de la PWM mais ça doit ne pas faire de différence (?) pour ce qui de mesurer une FCEM.
Sur le sujet "asservissement", le fil de référence ici est celui-ci : http://forum.locoduino.org/index.php?topic=36.0
Ayant pour ma part échoué à le mettre en pratique, j'ai bifurqué vers de la compensation de charge ; une aventure développée ici : https://forum.locoduino.org/index.php?topic=1217.0
(La compensation de charge est d'ailleurs ce que sait faire couramment le décodeur d'une motrice digitale en mesurant "in situ"sa propre FCEM)
Hors Locoduino, L'AFMN traite également de l'asservissement de vitesse : http://amfn.nice.free.fr/alim.htm
(une note à l'intention de babskwal qui utilise des L298 : ceux-ci ne pouvant pas commuter plus vite que 25 kHz, il faut oublier le 32Kz). EDIT : faux !! voir posts suivants
Je crois qu'il me manque de comprendre ceci : "je synchronise mes cantons sur le secteur redressé double alternance, soit 100Hz" ; s'agit-il de ce que cet article de l'AFMN appelle "alimentation à découpage à partir de l'alternatif" (voir lien plus bas) ? Dans ce cas ça n'est pas de la PWM mais ça doit ne pas faire de différence (?) pour ce qui de mesurer une FCEM.
Sur le sujet "asservissement", le fil de référence ici est celui-ci : http://forum.locoduino.org/index.php?topic=36.0
Ayant pour ma part échoué à le mettre en pratique, j'ai bifurqué vers de la compensation de charge ; une aventure développée ici : https://forum.locoduino.org/index.php?topic=1217.0
(La compensation de charge est d'ailleurs ce que sait faire couramment le décodeur d'une motrice digitale en mesurant "in situ"sa propre FCEM)
Hors Locoduino, L'AFMN traite également de l'asservissement de vitesse : http://amfn.nice.free.fr/alim.htm
22
Vos projets / Re : L298 et relais
« le: janvier 21, 2022, 04:02:09 pm »Citer
Où est l'erreur ?
... c'est une question !
Malheureusement je ne suis pas qualifié, il faudrait qu'un expert passe par là !
Je remarque seulement que 2millisecondes, c'est énorme, à se demander si le ralentissement permet, ensuite, une mesure représentative ?
Et qu'en appliquant le même calcul à la fréquence de 40Hz que j'utilise, c'est 25ms qu'il faudrait attendre ! Alors que la pratique habituelle est de respecter un délai de 300 à 400 microsecondes (soit une coupure de l'ordre de 600us mesures comprises).
L'échelle (N / HO) aurait-elle une influence ? Je ne vois pas de raison...
Enfin, pourquoi une telle proportionnalité entre fréquence avant coupure et délai d'extinction du flux ? Est-ce empirique ou imposé par l’électromagnétisme ? Dans le second cas, j'aurais tout à revoir... je me joins donc à la question : Où est l'erreur ?
(en demandant à babskwal de pardonner ce détournement du sujet d'origine ! On se rattrapera !)
23
Vos projets / Re : L298 et relais
« le: janvier 20, 2022, 11:38:13 pm »
Les pins et les timers sont différents mais c'est rigoureusement le même principe.
Tout est là : https://arduinoinfo.mywikis.net/wiki/Arduino-PWM-Frequency
Concernant cette remarque de JPM06 :
Tout est là : https://arduinoinfo.mywikis.net/wiki/Arduino-PWM-Frequency
Concernant cette remarque de JPM06 :
Citer
Je suis étonné qu'on puisse utiliser des fréquences élevées comme 32kHz, parce que ça ne doit pas être facile de mesurer la FCEM.La fréquence de PWM est à priori sans la moindre incidence puisque la FCEM ne peut pas se mesurer autrement que courant traction coupé.
24
Composants / Re : Benchmark MCU
« le: janvier 20, 2022, 04:13:51 pm »
Ça me paraît en effet très complexe au point que le processus de choix l'est tout autant ; c'est ce que je découvre avec surprise à mesure que j'entre dans cet univers.
Car je ne connais pas de tableau comparatif, c'est bien là la question.
Sauf si l'on parle de comparer les besoins en entrées/sorties avec les pinouts des cartes du marché. Mais pour ce qui est des performances... j'ai plusieurs fois constaté que les benchmark bâtons ne correspondaient pas à mes observations. Ils sont d'ailleurs tellement globaux qu'on ne sait plus ce qu'ils mesurent (ni comment !).
C'est sur ce point que je m'interrogeais et sur l'existence de sources fiables sur le sujet.
Pour ce qui est de mon cas perso, Jean-Luc à bien relevé que le goulot d'étrangement est (ou sera un jour) l'I2C. Car I2C mis à part, la question de la puissance brute ne se pose pas. Que j'exploite aujourd'hui +/- 10% de la capacité d'un Teensy3.5 ou +/-15% d'un ESP32, ça ne fait aucune différence. Mais c'est effectivement toujours l'I2C le traînard (avec lib SSD1306AsciiWire.h).
( Peut-être mon programme fait-il en effet de l'attente active ? J'avoue ne pas savoir ce que c'est mais je soupçonnais quelque chose de ce genre.
Avec deux parades en tête : remplacer les écrans I2C par leur équivalent SPI / ou envoyer les trames par CAN à une carte supplémentaire, dédiée aux écrans)
Ce qui reste un souci très secondaire comparé à la question... carrément existentielle ! (bof) de savoir choisir une carte. Qui devient d'ailleurs chaque jour un peu plus aiguë ! Je viens (seulement) de découvrir la nouvelle "portée" d' Arduino NANO, les officielles. Avec déjà des variantes à ne plus compter en Chine, la championne du bâtardage !
Car je ne connais pas de tableau comparatif, c'est bien là la question.
Sauf si l'on parle de comparer les besoins en entrées/sorties avec les pinouts des cartes du marché. Mais pour ce qui est des performances... j'ai plusieurs fois constaté que les benchmark bâtons ne correspondaient pas à mes observations. Ils sont d'ailleurs tellement globaux qu'on ne sait plus ce qu'ils mesurent (ni comment !).
C'est sur ce point que je m'interrogeais et sur l'existence de sources fiables sur le sujet.
Pour ce qui est de mon cas perso, Jean-Luc à bien relevé que le goulot d'étrangement est (ou sera un jour) l'I2C. Car I2C mis à part, la question de la puissance brute ne se pose pas. Que j'exploite aujourd'hui +/- 10% de la capacité d'un Teensy3.5 ou +/-15% d'un ESP32, ça ne fait aucune différence. Mais c'est effectivement toujours l'I2C le traînard (avec lib SSD1306AsciiWire.h).
( Peut-être mon programme fait-il en effet de l'attente active ? J'avoue ne pas savoir ce que c'est mais je soupçonnais quelque chose de ce genre.
Avec deux parades en tête : remplacer les écrans I2C par leur équivalent SPI / ou envoyer les trames par CAN à une carte supplémentaire, dédiée aux écrans)
Ce qui reste un souci très secondaire comparé à la question... carrément existentielle ! (bof) de savoir choisir une carte. Qui devient d'ailleurs chaque jour un peu plus aiguë ! Je viens (seulement) de découvrir la nouvelle "portée" d' Arduino NANO, les officielles. Avec déjà des variantes à ne plus compter en Chine, la championne du bâtardage !
25
Vos projets / Re : L298 et relais
« le: janvier 17, 2022, 10:09:33 pm »
bonsoir,
il y a un fil qui traitait des PCA9685 et du problème de leur synchronisation (sans solution de mémoire, mais il y a sûrement d'autres idées à piocher) :
http://forum.locoduino.org/index.php?topic=1097.0
Attention en effet aux longueurs de fils mais surtout entre l'Arduino et le module car la communication se fait en I2C, sensible au parasitage (bien que des solutions existent). Mais pas de contrainte il me semble entre les sorties PVM du module et les ponts H.
Attention également au fait que les PCA9685 vont fournir une PWM à 60Hz... alors que pour la santé des moteurs vous tomberez sur des recommandations de plusieurs dizaines de kilo-Herz !! Ceci-dit, ayant expérimenté les 9685 je n'ai jamais subi de conséquences... pour moi ça fonctionnait même beaucoup mieux au point que j'ai aujourd'hui des PWM réglées à 40Hz.
En ce qui concerne les 74HC595 : ils fournissent bien des sorties digitales, uniquement. Même si un MEGA en propose un bon nombre... en fait on finit par en manquer et l'autre intérêt, peut-être le principal, des registres 74HC595, est de transmettre les ordres non en parallèle mais en série : => uniquement 4 fils pour à l'arrivée un nombre illimité de pins ( en théorie, car la limite vient du temps de mise à jour des registres)
il y a un fil qui traitait des PCA9685 et du problème de leur synchronisation (sans solution de mémoire, mais il y a sûrement d'autres idées à piocher) :
http://forum.locoduino.org/index.php?topic=1097.0
Attention en effet aux longueurs de fils mais surtout entre l'Arduino et le module car la communication se fait en I2C, sensible au parasitage (bien que des solutions existent). Mais pas de contrainte il me semble entre les sorties PVM du module et les ponts H.
Attention également au fait que les PCA9685 vont fournir une PWM à 60Hz... alors que pour la santé des moteurs vous tomberez sur des recommandations de plusieurs dizaines de kilo-Herz !! Ceci-dit, ayant expérimenté les 9685 je n'ai jamais subi de conséquences... pour moi ça fonctionnait même beaucoup mieux au point que j'ai aujourd'hui des PWM réglées à 40Hz.
En ce qui concerne les 74HC595 : ils fournissent bien des sorties digitales, uniquement. Même si un MEGA en propose un bon nombre... en fait on finit par en manquer et l'autre intérêt, peut-être le principal, des registres 74HC595, est de transmettre les ordres non en parallèle mais en série : => uniquement 4 fils pour à l'arrivée un nombre illimité de pins ( en théorie, car la limite vient du temps de mise à jour des registres)
26
Composants / Re : Benchmark MCU
« le: janvier 17, 2022, 09:42:21 pm »
wouff ! c'est d'un clarté telle que je crois bien avoir tout compris.
le compilateur : plus de souci.
Mais le "SOC" (notion intégrée je crois)... ça soulève quelques questions car dans ces conditions, comment connaître A PRIORI les prédispositions de tel ou tel... même le datasheet (1000 pages parfois!) restera nébuleux, sauf certainement pour un expert.
Expérience perso : l'ESP32, alléchant et approvisionné pour voir, qui se révèle 2x plus lent qu'un Nano en lecture analogique. L'adaptation du code d'un matériel à l'autre ne se faisant pas d'un clic, pouvoir choisir sur papier ça serait quand même pas mal !
Il faudrait une sorte d' "auto-journal" des SOC... ça existe ?
le compilateur : plus de souci.
Mais le "SOC" (notion intégrée je crois)... ça soulève quelques questions car dans ces conditions, comment connaître A PRIORI les prédispositions de tel ou tel... même le datasheet (1000 pages parfois!) restera nébuleux, sauf certainement pour un expert.
Expérience perso : l'ESP32, alléchant et approvisionné pour voir, qui se révèle 2x plus lent qu'un Nano en lecture analogique. L'adaptation du code d'un matériel à l'autre ne se faisant pas d'un clic, pouvoir choisir sur papier ça serait quand même pas mal !
Il faudrait une sorte d' "auto-journal" des SOC... ça existe ?
27
Composants / Re : Benchmark MCU
« le: janvier 16, 2022, 06:10:13 pm »
Bonsoir Msport,
et merci... bien que ça sonne hélas comme une réponse valable je m'en rends compte.
Maintenant le compilateur à considérer "en plus" !! Bon bon, mais oui au fait !
Mais là il doit bien y avoir un compilateur plus performant dans l'absolu (sensiblement ?) que les autres !? ( Ou disons... l'un plus que l'autre, mon choix se limitant à Arduino / PIO )
et merci... bien que ça sonne hélas comme une réponse valable je m'en rends compte.
Maintenant le compilateur à considérer "en plus" !! Bon bon, mais oui au fait !
Mais là il doit bien y avoir un compilateur plus performant dans l'absolu (sensiblement ?) que les autres !? ( Ou disons... l'un plus que l'autre, mon choix se limitant à Arduino / PIO )
28
Composants / Benchmark MCU
« le: janvier 16, 2022, 03:03:51 pm »
Bonjour,
Je serais heureux de recevoir de l'aide pour devenir capable de bien choisir une carte, selon ses caractéristiques ET mes besoins propres ... aujourd'hui c'est au petit bonheur la chance !
Pour concrétiser rapidement ce qui a amené ce besoin : après être passé par différents matériels et configurations, mon MCU principal, gestionnaire, est aujourd'hui un Tennsy 3.5. Il est sollicité par beaucoup de tâches et s'en sort fort bien mais prend juste beaucoup de temps pour les communications I2C, au point qu'il serait vite coincé sur un réseau de bonne taille, d'où mon souci et ma question.
Sur le site PJRC, on trouve ce tableau de benchmark :
Je suis malheureusement incapable d'en tirer un enseignement... on y voit cependant qu'un ESP32 surclasse le Tennsy 3.5 (pour 10 fois moins cher !!)
Ayant des ESP32, j'ai donc tenté de retrouver dans des tests simplistes cette supériorité potentielle mais ça n'est pas sauf exception ce qui en ressort. (CPU speed sur : Teensy 120 / ESP 80)
Faudrait-il encore que ces tests aient un minimum de validité... un benchmark rigoureux est probablement une discipline, un art, à part entière...
Il doit néanmoins exister des critères élémentaires pour dégrossir la question ?
Donc grand merci par avance pour toute réponse.
Voici le code des tests perso avec les résultats :
cordialement
Je serais heureux de recevoir de l'aide pour devenir capable de bien choisir une carte, selon ses caractéristiques ET mes besoins propres ... aujourd'hui c'est au petit bonheur la chance !
Pour concrétiser rapidement ce qui a amené ce besoin : après être passé par différents matériels et configurations, mon MCU principal, gestionnaire, est aujourd'hui un Tennsy 3.5. Il est sollicité par beaucoup de tâches et s'en sort fort bien mais prend juste beaucoup de temps pour les communications I2C, au point qu'il serait vite coincé sur un réseau de bonne taille, d'où mon souci et ma question.
Sur le site PJRC, on trouve ce tableau de benchmark :
Je suis malheureusement incapable d'en tirer un enseignement... on y voit cependant qu'un ESP32 surclasse le Tennsy 3.5 (pour 10 fois moins cher !!)
Ayant des ESP32, j'ai donc tenté de retrouver dans des tests simplistes cette supériorité potentielle mais ça n'est pas sauf exception ce qui en ressort. (CPU speed sur : Teensy 120 / ESP 80)
Faudrait-il encore que ces tests aient un minimum de validité... un benchmark rigoureux est probablement une discipline, un art, à part entière...
Il doit néanmoins exister des critères élémentaires pour dégrossir la question ?
Donc grand merci par avance pour toute réponse.
Voici le code des tests perso avec les résultats :
Code: [Sélectionner]
/* POUR TESTS DE PERF */
uint16_t count = 0;
uint32_t timerTests = 0;
void setup() {
Serial.begin(115200);
delay(100);
}
void loop() {
for (int f=0; f<1000; f++) {
/* test calculs*/
float sqr = sqrt(f); /* resultat TEENSY : 773 Hz / resultat ESP32 : 244 Hz */
/* test IO */
// digitalWrite(4, HIGH); /* resultat TEENSY : 1390 Hz / resultat ESP32 : 4074 Hz */
// digitalWrite(4, LOW);
/* IO rapide - TENNSY 3.5 */ /*resultat TEENSY : 19633 Hz */
// digitalWriteFast(4, HIGH);
// digitalWriteFast(4, LOW);
/* IO rapide - ESP32 */ /* resultat ESP32: 9384 Hz */
// GPIO.out_w1ts = ((uint32_t)1 << 4); // HIGH
// GPIO.out_w1tc = ((uint32_t)1 << 4); // LOW
}
count++;
if (millis()-timerTests >= 3000) {
Serial.printf("%u Hz \n", count/((millis()-timerTests)/1000));
timerTests = millis();
count = 0;
}
}
cordialement
29
Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls
« le: janvier 08, 2022, 07:22:00 pm »
Bonsoir,
Je me permets de réveiller ce fil pour y mentionner la découverte de deux possibilités... à priori "unexpected" offertes par la mesure de la FCEM sur un réseau analogique.
Il y a juste un pré-requis : que le réseau soit organisé en sections, équipées d'une détection de passage (et/ou présence). Mais c'est certainement toujours le cas ?
Outre la compensation de charge, on peut alors bénéficier de deux fonctions bien intéressantes :
- très simple, la détection du sens de marche, non pas bien-sûr le sens de rotation mais la marche TRACTION/REFOULEMENT
* premier cas : une section détecte un train et concomitamment une FCEM => c'est une motrice (sauf cas ennuyeux mais très-très rare d'un matériel avec un seul bogie moteur) ;
* second cas : un train est détecté mais la FCEM reste nulle, ou insignifiante => c'est un CONVOI en refoulement.
Une donnée qui peut être utilisée pour éviter une marche à grande vitesse en refoulement, possiblement périlleuse (et peu réaliste ?)
- plus "sioux", que je n'ai pas implantée mais les tests sont positifs :
une FCEM étant le reflet du nombre de tours moteurs, il suffit d'une variable, par motrice, donnant sa démultiplication pour que les mesures de FCEM, intégrées sur un temps donné, indiquent une distance parcourue ;
* un top détection puis un top fin-de-détection SUR UNE SECTION : la différence des deux temps donnera la longueur du convoi (comptage des wagons, triage) ;
* un top détection puis l'atteinte PAR LE TRAIN d'une FCEM intégrée prédéterminée => le convoi a atteint un point précis (dépendant c'est vrai de mesures elles-mêmes précises, donc de la qualité du contact rails/roues)
et ceci quelque soit le sens de marche, traction/refoulement et sa vitesse !
de quoi disposer à volonté de détecteurs de position virtuels pour ralentissements, arrêts etc
et de quoi s'amuser non ?
Je me permets de réveiller ce fil pour y mentionner la découverte de deux possibilités... à priori "unexpected" offertes par la mesure de la FCEM sur un réseau analogique.
Il y a juste un pré-requis : que le réseau soit organisé en sections, équipées d'une détection de passage (et/ou présence). Mais c'est certainement toujours le cas ?
Outre la compensation de charge, on peut alors bénéficier de deux fonctions bien intéressantes :
- très simple, la détection du sens de marche, non pas bien-sûr le sens de rotation mais la marche TRACTION/REFOULEMENT
* premier cas : une section détecte un train et concomitamment une FCEM => c'est une motrice (sauf cas ennuyeux mais très-très rare d'un matériel avec un seul bogie moteur) ;
* second cas : un train est détecté mais la FCEM reste nulle, ou insignifiante => c'est un CONVOI en refoulement.
Une donnée qui peut être utilisée pour éviter une marche à grande vitesse en refoulement, possiblement périlleuse (et peu réaliste ?)
- plus "sioux", que je n'ai pas implantée mais les tests sont positifs :
une FCEM étant le reflet du nombre de tours moteurs, il suffit d'une variable, par motrice, donnant sa démultiplication pour que les mesures de FCEM, intégrées sur un temps donné, indiquent une distance parcourue ;
* un top détection puis un top fin-de-détection SUR UNE SECTION : la différence des deux temps donnera la longueur du convoi (comptage des wagons, triage) ;
* un top détection puis l'atteinte PAR LE TRAIN d'une FCEM intégrée prédéterminée => le convoi a atteint un point précis (dépendant c'est vrai de mesures elles-mêmes précises, donc de la qualité du contact rails/roues)
et ceci quelque soit le sens de marche, traction/refoulement et sa vitesse !
de quoi disposer à volonté de détecteurs de position virtuels pour ralentissements, arrêts etc
et de quoi s'amuser non ?
30
Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls
« le: juillet 30, 2021, 09:16:02 pm »
Bonsoir Dominique,
Merci pour cette attention !
Et note bien que quand tu te lanceras, ça sera un grand plaisir pour moi si tu veux qu'on échange (d'autant que j'en tirerai profit, j'en suis certain !).
Amicalement
Philippe
NB : Ça sera également un vrai plaisir de répondre sur ce sujet à quiconque le souhaiterait. Je joins d'ailleurs à titre documentaire et pour démystifier le bout de code, commenté, qui permet d'obtenir, pour chaque train, un signal FCEM exploitable par un gestionnaire (dans une logique à 1 satellite pour 4 sections (au plus), communiquant avec un gestionnaire central)
Merci pour cette attention !
Et note bien que quand tu te lanceras, ça sera un grand plaisir pour moi si tu veux qu'on échange (d'autant que j'en tirerai profit, j'en suis certain !).
Amicalement
Philippe
NB : Ça sera également un vrai plaisir de répondre sur ce sujet à quiconque le souhaiterait. Je joins d'ailleurs à titre documentaire et pour démystifier le bout de code, commenté, qui permet d'obtenir, pour chaque train, un signal FCEM exploitable par un gestionnaire (dans une logique à 1 satellite pour 4 sections (au plus), communiquant avec un gestionnaire central)
Code: [Sélectionner]
const uint16_t PWM_OFF = 300; // 300 microSeconds - temps de coupure du courant traction
const uint16_t PWM_ON = 10000; // ~10 milliSeconds - période "ON", moteur alimenté
uint32_t time_ON;
bool timeToEmitFCEM;
const uint8_t NB_SECTIONS = 4; // ex : 4 sur ce satellite
const uint8_t SECTION_PINOUT[NB_SECTIONS][5] = {.......};
// pour chaque section :
// - numéro de la section (sur le réseau)
// - num de la pin(satellite) de polarisation 1 du pont H qui alimente la section
// - pin de polarisation 2
// - pin analogique de lecture FCEM de la section en polarisation 1
// - pin analogique de lecture FCEM en polarisation 2
uint8_t trainOnSection[NB_SECTIONS] = { 0, 0, 0, 0 }; // contiendra 0 pour libre ou num de train+1 (fourni par ailleurs par le master) si occupée
bool polarization[NB_SECTIONS] = { 0, 0, 0, 0 }; // data fournie par le master en complément du numéro de train
uint8_t trainNum[NB_SECTIONS] = { 0, 0, 0, 0 }; // numéros des trains présents sur les sections du satellite (numérotation "vraie")
uint8_t trains; // nombre de trains différents recensés à l'instant "t"
uint16_t sumFCEM[NB_SECTIONS];
uint16_t count[NB_SECTIONS];
int16_t reading[NB_SECTIONS][6]; // 6 mesures pour chaque section (si occupée)
void mesureFCEM() {
if (timeToEmitFCEM) /*=>*/ sendFCEM(); // LES sats ont reçu (par ailleurs) un message du MASTER enjoignant à transmettre les relevés
if (micros() - time_ON < PWM_ON) /*=>*/ return;
if (trains) {
for (uint8_t i=0; i<NB_SECTIONS; i++) { // au moins un train détecté => tous pins de polarization LOW (=> coupure du courant traction)
digitalWriteFast(SECTION_PINOUT[i][1], LOW);
digitalWriteFast(SECTION_PINOUT[i][2], LOW);
}
delayMicroseconds(PWM_OFF); // attente avant mesures
for (uint8_t i=0; i<NB_SECTIONS; i++) {
if (trainOnSection[i]>0) { // TOUT OU PARTIE du train numéro "trainOnSection[i] occupe la section i
for (uint8_t j=0; j<6; j++) { // 6 mesures
reading[i][j] = analogRead(SECTION_PINOUT[i][3+polarization[i]]);
}
}
}
/* TRAITEMENT DES DONNEES */
int16_t read[NB_SECTIONS] = {0, 0, 0, 0}, maxRead[NB_SECTIONS] = {0, 0, 0, 0}, minRead[NB_SECTIONS] = {0, 0, 0, 0};
for (uint8_t i=0; i<NB_SECTIONS; i++) {
if (trainOnSection[i]) { // il y a un train dans la section i => au moins une section est occupée
if (polarization[i]) /*=>*/ digitalWriteFast(SECTION_PINOUT[i][1], HIGH);
else /*=>*/ digitalWriteFast(SECTION_PINOUT[i][2], HIGH); // rétablissement de la polarization initiale
maxRead[i] = reading[i][0]; // première mesure
minRead[i] = reading[i][0];
read[i] = reading[i][0];
for (uint8_t j=1; j<6; j++) { // on lit les 5 autres mesures et on repère les deux extrêmes
maxRead[i] = max(reading[i][j], maxRead[i]);
minRead[i] = min(reading[i][j], minRead[i]);
read[i] = (read[i] + reading[i][j]); // sommation des SIX lectures
}
read[i] = (read[i] - maxRead[i] - minRead[i])/4; // moyenne des 4 valeurs retenues après élimination des extrêmes
maxRead[i] = 0;
}
}
// si train sur 2 sections (ou plus), on filtre les résultats "fake" (wagons) en comparant les mesures de ce train
for (uint8_t j=0; j<trains; j++) { // à ce stade, "trains" est forcément au moins égal à 1, le numéro du premier train nomenclaturé étant inscrit dans trainNum[0]
for (uint8_t i=0; i<NB_SECTIONS; i++) { // on recherche ce train sur toutes les sections et on repère son read max
if (trainOnSection[i] == trainNum[j]) { // un train a été nomenclaturé à l'indice j (toujours vrai une fois au moins)
maxRead[j] = max(read[i], maxRead[j]); // max-des-max pour le train j de numéro trainNum[j]
}
}
for (uint8_t i=0; i<NB_SECTIONS; i++) { // on compare les résultats section par section, on garde ou non
if (trainOnSection[i]==trainNum[j] && read[i]> maxRead[j]/2) { // écart "normal" => on prend en compte la mesure (maxRead répond à la condition)
sumFCEM[j] = sumFCEM[j] + read[i];
count[j]++; // sumFCEM == première ou nouvelle sommation pour ce train, puis comptage des sommations
}
}
}
}
time_ON = micros();
}
void sendFCEM() {
timeToEmitFCEM=false;
for (uint8_t j=0; j<trains; j++) {
if (count[j]) {
const uint16_t TRAIN = trainNum[j]-1;
messageCAN_FCEM.id = 72 + TRAIN; // EXEMPLE : (64 pour satellite"0", 72 pour sat"1" etc) + n° du train converti en valeur "code"
// /!\ une loco en chevauchement sur 2 sections gérées par 2 sats # pourrait générer 2 messages identiques et simultanés, provoquant
// UN PLANTAGE DU BUS. L'ajout du n° de sat dans l'ID permet,de discriminer les messages (+ autres usages) */
uint16_t fcem = sumFCEM[j]/count[j];
if (fcem < FCEMtrain[TRAIN]/2) /*=>*/ fcem = FCEMtrain[TRAIN]/2; // "passe-bas", bride les points aberrants
messageCAN_FCEM.data16[0] = fcem; // on ne transmet pas la section, c'est une donnée connue du master
const bool OK = ACAN::can0.tryToSend(messageCAN_FCEM);
FCEMtrain[TRAIN] = fcem;
}
sumFCEM[j] = 0; count[j] = 0; trainNum[j] = 0;
}
scanSections(); // AVANT LES PROCHAINES MESURES, ON REFAIT LA NOMENCLATURE DES TRAINS
}
void scanSections() { // inventaire et classement dans trainNum[] des trains présents sur les sections traitées par le sat
bool flag = 1;
trains = 0;
for (uint8_t i=0; i<NB_SECTIONS; i++) {
trainNum[i] = 0;
if (trainOnSection[i]) {
for (uint8_t j=0; j<=trains; j++) {
if (trainOnSection[i] == trainNum[j]) {
flag = 0;
break;
}
}
if (flag) {
trainNum[trains] = trainOnSection[i];
trains++;
}
flag = 1;
}
}
}