Discussion :

[Guesset]

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

[f-leb]

Hop,

si la recherche incrémentale fonctionne bien, une recherche dichotomique sera sensiblement plus rapide.

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 (n², n=nbr de leds). Avec 1000 leds, on est à une quinzaine de secondes et ça vaut le coup de passer à une méthode dichotomique.

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.

Le comptage direct des 24 fronts montants... ? 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.

[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 D_out.

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

[Jay M]

Bonjour,

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.

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ère

[Guesset]

Bonjour Jay M,

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ère

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.

Salut

[Jay M]

Oui - OK sur ESP32 avec le module RMT c’est possible effectivement

[cobra38]

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

[f-leb]

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 ?

[Guesset]

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 n_min = (dT entre dernier envoi et rétablissement des interruptions) / 300 ns ).

Salutations

[cobra38]

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 ?

Salut 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

[cobra38]

Bonjour,

Une couleur prend 30 us (24*1.25us) donc pour 150 il faudra 4550 us entre deux actualisations (150*3 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 n_min = (dT entre dernier envoi et rétablissement des interruptions) / 300 ns ).

Salutations

Merci Guesset pour ces précisions

[f-leb]

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.

[Guesset]

Bonjour f-leb,

...Soit une durée maxi théorique : (1+2+3+...+151) x 30 us ...

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.

Un dessin sera peut être plus explicite :

Verticalement, on passe d'une LED à l'autre (boules oranges). Horizontalement figurent les chronogrammes de chaque D_in et le D_out 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

[cobra38]

Bonjour à tous

Donc si on met

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

delay (100) ;

après le calcul, on comble largement le retard et on favorise bien le comptage exact du nombre total de leds raccordées

c'est çà ?

[Guesset]

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