Piloter des dizaines de LED avec une seule PIN du satellite

[Tanguy]

Bonjour à tous,

J'ai été très enthousiasmé par les projets de "satellite" présentés tant sur le site éditorial que sur le forum.
Dans mon mes réflexions sur son utilisation sur mon prototype de réseau, j'ai voulu optimiser l'utilisation des entrées/sorties de la carte satellite surtout pour la gestion des signaux lumineux, lesquels consomment beaucoup de sorties.

Je partage aujourd'hui les résultats de mes premiers tests.

La solution testée
La solution consiste à utiliser la puce WS2811 que l'on trouve habituellement dans les guirlandes NEOPIXELS pour gérer, à partir d'une seule sortie de l'arduino, une chaine de LEDS RGB connectées en série. L'arduino envoie sur l'unique sortie une suite d'octets pour "commander" en couleur et intensité chacune des LEDS RGB.

Dans mes expériences, la puce WS2811 n'est pas utilisée pour piloter des LED RGB mais les trois led mono-couleur d'un signal lumineux. En chaînant quelques WS2811 on pilote facilement plusieurs signaux de 3 LEDS ou plus. La puce W2811 permet de commander chaque LED en PWM pour plus de réalisme.

Le matériel utilisé
J'ai commandé des circuits imprimés vendus par lot de 50 unités sur ebay pour un peu moins de 8 euros (https://ebay.us/BwxQcH)
Je les ai ensuite connectés en série à un arduino nano et quelques signaux pour les programmer enfin avec la bibliothèque light_ws2812 (https://github.com/cpldcpu/light_ws2812/tree/master/light_ws2812_Arduino)



Les résultats
Piloter la chaîne de LED est simple avec la bibliothèque citée plus haut.
Mes problèmes ont commencés quand j'ai testé l'utilisation conjointe de ces LED avec des servos.
En effet, la bibliothèque LIGHT_WS2812, comme toutes les autres similaires que j'ai testées, désactivent les interruptions le temps d'envoyer à l'ensemble des LED la série d'octets (un octet par LED). La bibliothèque servo utilise des interruptions pour gérer la durée des impulsions envoyées aux servomoteurs => potentielle collision !



En poussant mes tests avec 8 servos et 18 LEDS (6 puces) j'ai constaté les effets néfastes de cette désactivation temporaire des interruptions : les servomoteurs ont des petits tremblements de temps en temps.

J'ai finalement trouvé une parade en vérifiant, avant de lancer le rafraichissement des LED, qu'il restait suffisamment de temps avant la prochaine interruption générée par la bibliothèque servo :

Code: [Sélectionner]

  if (OCR1A - TCNT1 > LEDS_SYNC_DURATION)) {
      // on verfie que le temps restant avant la prochaine interruption (OCR1A - TCNT1)
      // est suffisant pour rafraichir toutes les LED
     [...]
      leds.sync();
  }
Mes questions à ce stade

• L'implémentation usuelle du bus CAN sur locoduino utilise des interruptions. Est-ce que je peux espérer avec la nouvelle puce MCP2517FD et son énorme mémoire que l'on puisse se passer des interruptions pour éviter de nouvelles collisions entre les bibliothèques ?
• Est-ce que quelqu'un a déjà testé ce type de LED (neopixel) dans un environnement ferroviaire ? sont-elles sensibles aux perturbations électromagnétiques  sur courtes distances (30 cm) ?

[Jean-Luc]

Bonjour Tanguy

C’est une très bonne idée d’utiliser ces circuits qui de plus sont très bon marché

Pour répondre à tes questions :

1) on peut laisser l’interruption CAN. Elle sera juste prise charge en différé. On peut configurer une fifo de réception de 64 messages sans problème dans le MCP2517FD. Avec un bus à 1Mb/s ça permet de bloquer les interruptions pendant 41 x 64 = 2,6 ms. A 400khz ça permet de charger une chaîne d’un millier de LED.

2) autant j’ai testé avec un ruban de « LED » WS2812, autant je ne saurais te répondre ici. Sur un ruban c’est très différent car les LED sont proches et le signal est régénéré par chaque LED. Ici tu aurais des fils d’une longueur égale à la distance entre deux signaux. Je pense qu’il y aura des problèmes de réflexion du signal et des erreurs de transmission mais je n’ai pas testé.

Par ailleurs les WS2811 sont autonomes mais seulement pour un allumage fixe. Si tu veux avoir le clignotement avec allumage et extinction progressifs d’une seule des LED de la chaîne, il faut la rafraîchir disons 32 fois en 250ms et avec une période suffisamment stable pour que la variation de luminosité se fasse à vitesse constante. Ça complique vis à vis de la bibliothèque Servo.

Donc pourquoi ne pas utiliser ces circuits pour faire une carte fille qui en regroupe 6 (18 leds) plus un ATtiny85 (la bibliothèque Adafruit Neopixel supporte les ATtiny avec l’horloge interne à 8Mhz) qui est chargé de les rafraîchir et qui reçoit les états via le SPI ? De cette manière plus d’ennuis avec les servomoteurs, plus de fréquence de rafraîchissement importante sur le nano, et pas de problème de communication puisque les fils sont courts entre les WS2811.

[Jean-Luc]

Question subsidiaire:

Le WS2811 a des sorties à courant constant. Que se passe-t-il si une sortie est laissée en l’air ? Les autres fonctionnent bien ?

[Tanguy]

Bonjour Jean-Luc,

je reprends ce fil après quelques semaines sans arduino. Merci de ta réponse détaillée; j'ai vu que tu avais déjà dessiné une carte fille pour associer les WS2811 au satellite ..., je suis beaucoup plus lent :

J'ai testé le WS2811 avec une sortie en l'air (pendant près d'une heure) : les 2 autres LED fonctionnent correctement.
J'ai aussi testé une chaîne de WS2811 avec un mètre de fils entre l'arduino et le premier circuit, les 3 fils courants le long de mon réseau de test. Je n'ai noté aucun dysfonctionnement sur les LED malgré la proximité du signal DCC et du moteur de locomotive.

Concernant ta proposition (carte fille avec ATtiny + liaison SPI) : je ne vois pas comment cela résout plus efficacement le problème. La bibliothèque Neopixel (comme les autres) désactive les interruptions le temps de rafraîchir les LED. Pendant ce rafraîchissement, l'ATtiny à toutes les chances de perdre des données transmises par l'arduino maître.

[Jean-Luc]

Bonjour Tanguy

Concernant ta proposition (carte fille avec ATtiny + liaison SPI) : je ne vois pas comment cela résout plus efficacement le problème. La bibliothèque Neopixel (comme les autres) désactive les interruptions le temps de rafraîchir les LED. Pendant ce rafraîchissement, l'ATtiny à toutes les chances de perdre des données transmises par l'arduino maître.

Non c'est très différent.

Entre le pilotage d'un ou plusieurs servo et l'envoi de données aux LED, tu as deux processus qui ne tolèrent aucune gigue. Entre une communication SPI qui peut être redondée et pour laquelle il n'y aura pas d'interruption, et l'actualisation des LED, il n'y a pas de soucis. Le rafraîchissement de 18 LED demande 24 x 18 x 1/400000 = 1,1ms. Il suffit que l'envoi des données par SPI se fasse avec une période plus grande que 1,1ms, 5ms par exemple, voir plus vu le type de système, pour qu'il n'y ai aucune perte de données.