Version imprimable
Bonjour,
Absent quelques jours, je vois que le problème n'a pas résisté longtemps. Une seule remarque, si la recherche incrémentale fonctionne bien, une recherche dichotomique sera sensiblement plus rapide.
En revanche, je ne pense pas que le comptage direct des 24 fronts montants par couleur excédentaire (encore plus rapide) soit compatible avec le pilotage des Leds sur un Arduino même si l'interruption de comptage ne perturberait que les couleurs inutilisées.
Salutations
Hop,
Avec un ruban de 200-300 leds, on est dans la seconde et c'est peut-être encore raisonnable. Après, le coût est quadratique (n2, n=nbr de leds). Avec 1000 leds, on est à une quinzaine de secondes et ça vaut le coup de passer à une méthode dichotomique.Citation:
Envoyé par Guesset
Le comptage direct des 24 fronts montants... ?:koi: Je ne comprends pas... Il n'y aura qu'un seul front montant détecté, dès le 1er bit envoyé juste après avoir allumé la dernière led du ruban.Citation:
Envoyé par Guesset
Bonjour,
La dernière led laisse passer toutes les couleurs qui n'ont pas trouvé preneur. Par exemple, s'il y a 3 couleurs de plus que le nombre de LEDs, il y aura 3*24 fronts montants supplémentaires sortant de Dout.
Illustration de l'envoi de 3 couleurs (l'ordre RGB peut changer selon les bandes) sur une bande de 4 LEDs.
Si au lieu de basculer un flag ,on incrémente un compteur c, le nombre de leds effectif est le nombre de couleurs envoyées diminué de c/24. Le problème est que ce comptage sur interruption (1 toutes les 1.25 us) peut perturber l'émission du train de couleurs (contrainte de ressources Arduino). Cette perturbation peut aller jusqu'à altérer suffisamment le flux pour que la transmission devienne erratique et le comptage non fiable.
Une machine sensiblement plus rapide que les 16 MHz voire multicœur n'aurait pas ce risque.
Salutations
Les 2 bibliothèques (adafruit et fastled) courantes bloquent les interruptions durant l’appel à l’affichage donc la majorité des interruptions se perdrait et on n’aurait que la dernièreCitation:
Envoyé par Guesset
Bonjour Jay M,
Sur un Arduino, c'est ce que j'exprimais, mais sur une machine double cœur et rapide (genre ESP32 et Pico, ce dernier pouvant émettre les flux sans bloquer les interruptions) il est possible de capter les flux Dout sur une entrée en interruption ou scrutation rapide. D'un autre coté, c'est une initialisation et le gain en vitesse sur des MPU rapides ne sera pas forcément perçu.Citation:
Envoyé par Jay M
Salut
Oui - OK sur ESP32 avec le module RMT c’est possible effectivement
Bonjour à tous
Heureux de constater que ma question reste ouverte ,
pour ma part, je continue plus sur la mise en œuvre des "rails" que sur la programme car je pensais naïvement que le problème semblait résolu
pourriez-vous développer svp le problème car pour ma part , l'utilisation d'un nano (certes en simulation ) fonctionnait
( je n'ai pas encore testé en réel avec une bande de 150 Leds )
mais suivant les propos précédents, on peut craindre une dérive dans le calcul du nombre de Leds raccordées lié à la lenteur de l'µC
est-cela ?
pascal
Salut,
Le problème est qu'à chaque fois que tu allumes une nouvelle led, il faut envoyer les signaux aussi pour allumer les leds qui précèdent dans le ruban.
Mais pour discuter concrètement des performances, il faut nous dire combien de leds tu dois allumer ? Combien de "rails" au maximum ? Combien de leds par "rail" ?
De quelle durée tu peux disposer pour faire l'apprentissage du nombre de leds ? C'est grave si cela prend une seconde ou deux ? Ou c'est critique, il faut faire cela en 1/10è ou 1/100è de seconde ?
Bonjour,
Une couleur prend 30 us (24*1.25us) donc pour 150 il faudra 4550 us entre deux actualisations (150*30 us + 50 us).
Par ailleurs, les changements ne sont pas instantanés. Selon les rubans, il faut environ 300 ns de transfert par led. Cela signifie que la 150e est en retard de 149*(30 us +0.3 us) soit 4514.7us par rapport à la première.
Ces retards, notamment les 300 ns, expliquent pourquoi, malgré d'éventuels blocages des interruptions, les dépassements sont quand même détectés. Les interruptions sont rétablies à la fin de la transmission mais, pour n leds, le dernier Do a lieu n x 300 ns, soit après le rétablissement des interruptions s'il y a un minimum de leds (le nombre exact dépend de la programmation nmin = (dT entre dernier envoi et rétablissement des interruptions) / 300 ns ).
Salutations
Salut f-lebCitation:
Envoyé par f-leb
combien de leds tu dois allumer ?
Au maximum , je vais en raccorder 150 leds , normalement je dis "raccorder" car il s'agit d'un "genre de circuit 24", on allume donc les leds suivant la progression dasn le jeu ( 1 couleur par concurrent ) et non pas comme pour un éclairage normal
Combien de "rails" au maximum ?
Je ne peux pas répondre à cette question puisque les rails sont de dimension différente tantôt de 10 , 20 ou 30 cm et pour une courbe il s'agit d'un rail à angle de 90°
Combien de leds par "rail" ?
au départ, j'avais imaginé de faire tous les rails de même longueur pour supporter le même nombre de Leds mais avec le recul , c'est impossible en effet pour une courbe ( qui sera ici certainement un simple angle à 90° ) il y aura 2 leds
pour une droite de 10 cm , c'est 3 leds etc ....
De quelle durée tu peux disposer pour faire l'apprentissage du nombre de leds ? C'est grave si cela prend une seconde ou deux ? Ou c'est critique, il faut faire cela en 1/10è ou 1/100è de seconde ?
Le temps d'Init si je l'appelle comme çà peut-être de 5 ou 10 secondes , çà n'a pas de grande importance , mais si j'ai bien compris, il devra être logé dans le setup c'est çà ?
l'essentiel étant de compter le chiffre exact du nombre de Leds raccorées soit un chiffre <= 150
pascal
Merci Guesset pour ces précisionsCitation:
Envoyé par Guesset
30us par led
Si tu fais une progression led par led avec le code comme dans le wokwi.
La première led : 1x30us
La deuxième led : 2x30us
La troisième led : 3x30us
...
La 150è led : 150x30us
La 151è led fictive avec sa détection sur l'entrée Arduino : 151x30us
Soit une durée maxi théorique : (1+2+3+...+151) x 30 us = 344280us, soit 0,34s.
Quelques tempos techniques à chaque nouvelle led allumée, mais tu rentres dans la seconde.
Le coût est en nbre de leds au carré. Si tu as deux fois plus de leds (env. 300), cela prendra quatre fois plus de temps, soit 4x0,34=1,36s.
Bonjour f-leb,
Ce n'est pas quadratique. Quand la dernière LED s'allume soit 150 x 30 µs + 149 * 0.3 µs soit n*30.3µs - 0.3µs, toutes les autres se sont déjà allumées. Le temps nécessaire est donc de 4544.7 µs soit 4,5 ms environ.Citation:
Envoyé par f-leb
Un dessin sera peut être plus explicite :
Verticalement, on passe d'une LED à l'autre (boules oranges). Horizontalement figurent les chronogrammes de chaque Din et le Dout de rebouclage.
La verticale jaune d'or pointillée représente le temps pour allumer les quatre LEDs présentes.
La verticale orange montre comment le rétablissement des interruptions (SEI) permet de capturer quand même les dépassements.
Salut
Bonjour à tous
Donc si on met
après le calcul, on comble largement le retard et on favorise bien le comptage exact du nombre total de leds raccordéesCode:delay (100) ;
c'est çà ?
Bonjour,
Il est inutile d'ajouter du temps pour la détection qui ne dépend que de la différence de propagation des couleurs vs leur émission.
S'il y a trop peu de LEDs (moins de 5 par exemple) le retard de propagation pourrait être inférieur au temps que met la librairie utilisée pour réactiver les interruptions, auquel cas les impulsions des couleurs excédentaires se présenteraient devant une entrée d'interruption du MPU avant que les interruptions soient réactivées.
Dans les autres cas, pas de problème.
Salutations
