Différences entre versions de « NeoPixel-UserGuide-Programmation-Avancée »

De MCHobby - Wiki
Sauter à la navigation Sauter à la recherche
 
(17 versions intermédiaires par le même utilisateur non affichées)
Ligne 2 : Ligne 2 :
  
 
== Question - Réponse ==
 
== Question - Réponse ==
===  Mo code servo sur Arduino arrête de fonctionner lorsqu'il est combiné avec NeoPixels! ===
+
=== Combien de pixels sur un Arduino Uno ===
 +
{{bloc-etroit|text=La façon de gérer les pixels nécessite l'usage d'une mémoire tampon (buffer) pour mémoriser tous les éléments du ruban/strip. Souvent, sur Arduino UNO il ne reste que 500 octets/bytes libre une fois tous les extras ajouter au projet.
 +
 
 +
500 bytes, c'est assez pour contrôler 150 pixels. Si vous désirez piloter un strip/ruban complet en utilisant des librairies complémentaires, vous pourriez avoir besoin d'un Mega (voir ce tuto sur la comparaison de la mémoire SRAM).}}
 +
 
 +
===  Mon code servo sur Arduino arrête de fonctionner lorsqu'il est combiné avec NeoPixels! ===
 
{{bloc-etroit|text=Malheureusement, les bibliothèques NéoPixel et servo ne fonctionne pas très bien ensemble; La première ayant besoin de désactiver les interruptions de façon périodique et la deuxième en a absolument besoin pour fonctionner. Vous avez néanmoins quelques alternative:
 
{{bloc-etroit|text=Malheureusement, les bibliothèques NéoPixel et servo ne fonctionne pas très bien ensemble; La première ayant besoin de désactiver les interruptions de façon périodique et la deuxième en a absolument besoin pour fonctionner. Vous avez néanmoins quelques alternative:
  
Ligne 9 : Ligne 14 :
  
 
=== A quelle vitesse puis-je rafraichir une chaine de (N) pixels? ===
 
=== A quelle vitesse puis-je rafraichir une chaine de (N) pixels? ===
{{bloc-etroit|text=Les NéoPixels reçoivent le flux de donnée à la fréquence fixée de 800 KHz (excepté pour les pixels Flora “V1” qui utilisait un fréquence de 400 KHz). One bit therefore requires 1/800,000 sec — 1.25 microseconds. One pixel requires 24 bits (8 bits each for red, green blue) — 30 microseconds. After the last pixel’s worth of data is issued, the stream must stop for at least 50 microseconds for the new colors to “latch.”
+
{{bloc-etroit|text=Les NéoPixels reçoivent le flux de donnée à la fréquence fixée de 800 KHz (excepté pour les pixels Flora “V1” qui utilisait un fréquence de 400 KHz). Un bit à donc besoin de de 1/800.000 de sec — soit 1.25 microsecondes pour être transmit. Un pixel à besoin de 24 bits pour fixer sa couleur (8 bits pour chaque couleur de base rouge, vert, bleu) — soit 30 microsecondes. Après l'envoi des données du dernier pixels, le flux de donnée doit être arrêté pendant au mois 50 microsecondes avant de relancer un nouveau flux de donnée (et recommencer le cycle d'initialisation des couleurs du premier au dernier pixel)
  
For a strip of 100 pixels, that’s (100 * 30) + 50, or 3,050 microseconds. 1,000,000 / 3,050 = 328 updates per second, approximately.}}
+
Pour un ruban de 100 pixels, cela représente (100 * 30) + 50, soit 3.050 microsecondes par cycle. Comme il y a 1.000.000 micro-secondes dans une seconde, cela donne 1.000.000 / 3.050 = approximativement 328 mise-à-jour par seconde.}}
  
'''However'''
+
'''Cependant'''
  
That’s only the time needed to push the bits down the wire. The actual refresh rate will be something less than this, and can’t be estimated as a single number for all cases. It takes time to process each “frame” of animation. How much time depends on the complexity of the math and the efficiency of the code (for example, floating-point calculations can be relatively slow). The technique above gives a maximum ''theoretical'' rate, but that’s just a starting point. Reality in some cases could fall an order of magnitude (or more) below this.
+
C'est seulement le temps nécessaire pour l'envoi des données sur le fil. Le taux de rafraichissement réel sera quand même inférieur et ne peux pas être facilement évaluer en un valeur finie couvrant tous les cas. Le traitement de chaque image d'une animation prends du temps. Le temps nécessaire dépends de la complexité, des opérations mathématiques et de l'efficacité du code (par exemple, les opérations en virgule flottante sont relativement lente). La technique ci dessus donne un taux '''maximum théorique''' mais c'est juste un point de départ.
  
For exploratory benchmarking, you can always write code as if a large number of pixels were present, and time the result. The extra output bits will simply be ignored by the strip (or you can even test with no NeoPixels connected at all).
+
Si vous désirez faire des explorations et des relevés (du ''benchmarking''), vous pouvez toujours écrire du code pour un plus grand nombre de pixels même s'il ne sont pas présent. Cela permet de relever le temps de traitement. Les bits de données en extra (pour les pixels non présents) sont simplement ignorés par le ruban/chaine (ou vous pouvez même tester sans aucun NéoPixel connectés).
  
=== That won’t do. Now what? ===
+
=== Ca ne va pas. Que faire? ===
Because NeoPixels use a fixed-frequency clock, options are limited. You can’t switch out for a faster microcontroller and expect substantially different results.
+
Etant donné que les NéoPixels utilisent une fréquence d'horloge fixe, les options sont limitées. Vous pouvez opter pour un microcontrôleur plus rapide dont vous pouvez attendre une différence substantielle.
  
One option is to use a different LED type, such as our LPD8806 strips or WS2801 pixels. These can be driven at higher data rates, though they do have some other tradeoffs with respect to NeoPixels (cost, color resolution and/or pixel density).
+
Une autre option est d'utiliser un type de LED différent, tel que des rubans LPD8806 ou pixels WS2801. Ils peuvent être pilotés avec un débit de données plus élevé mais présente néanmoins quelques inconvénients par rapport aux NéoPixels (coût, résolution des couleurs et/ou la densité des pixel).
  
Another is to develop your own code for a more capable microcontroller or an FPGA that drives multiple NeoPixel strips in parallel. One such project — OctoWS2811 for the Teensy 3.0 microcontroller — is shown later. This sort of thing is a complex undertaking and not recommended for beginners. And even among more experienced programmers, there’s often an unreasonable over-emphasis on data rates when the real bottlenecks lie elsewhere…don’t dwell on this too much unless you can confirm it’s a problem.
+
Une dernière option est de développer votre propre code sur un microcontrôleur performant ou un FPGA qui pilote plusieurs ruban NéoPixel en parallèle. De tels options sont abordés plus tard comme OctoWS2811 pour le microcontrôleur Teensy 3.0. Cette option nécessite la compréhension de choses complexes et n'est pas recommandé aux débutants. Et même pour les développeurs expérimentés, il arrive de mettre l'accent de façon déraisonnable sur le débit de donnée alors que le goulot d'étranglement se cache ailleurs... ne vous attardez donc pas trop sur le remplacement du microcontrôleur à moins que vous ne sachiez confirmer que le débit est le problème.
  
=== Can I control NeoPixels using (Board X)? ===
+
=== Puis-je contrôler les NéoPixels en utilisant la carte X? ===
We currently only offer an Arduino library. See the links later for other devices. For anything beyond this, if considering writing your own library, understand that some devices are better suited to the task than others. Read through the timing requirements shown below and determine if the processor or device in question can synthesize a signal meeting those specifications. An 8 MHz AVR can just barely keep up…anything slower may have trouble, though some hardware-specific hacks (like clever use of SPI) might make it possible. In many cases, assembly language is required.
+
AdaFruit offre uniquement une bibliothèque Arduino. Voyez les liens (plus loin) pour d'autres périphériques. Pour toutes les autres plateformes, et si vous considérez l'option d'écrire votre propre bibliothèque, vous devez comprendre qu'il y a des périphériques plus aptes que d'autres à cette tâche. Lisez le point concernant les exigences de gestion du temps (ci-dessous) pour savoir si le processeur ou le périphérique en question, est capable de générer le signal en concordance avec les spécifications. Un AVR à 8 MHz peut à  peine suivre... tout ce qui sera plus lent sera source de problèmes, bien que quelques ''hackings hardware spécifiques'' (comme une utilisation intelligente du SPI) pourrait rendre cela possible. Dans de nombreux cas, l'utilisation de l'assembleur sera nécessaire.
  
=== Why not Raspberry Pi? ===
+
=== Pourquoi pas un Raspberry Pi? ===
The Raspberry Pi running Linux is a multitasking system, and control may switch among multiple running programs at any time. As such, it’s impossible to guarantee the strict 800 KHz signal required by NeoPixels. You may be able to fudge it for short intervals, but it’s not something that can be counted upon. This is why we use LPD8806 pixels for the [http://learn.adafruit.com/light-painting-with-raspberry-pi Raspberry Pi light painting] demonstration.
+
Un Raspberry Pi exécute un système d'exploitation multi-tâche, et le contrôle peut passer d'un programme à l'autre à n'importe quel moment. Par conséquent, il est impossible de garantir strictement le signal à 800 KHz requis par NéoPixels. Vous devriez être capable de produire un tel signal pendant un court interval, mais ce n'est pas quelque-chose qui peut être tenu en compte. C'est c'est raison pour laquelle Adafruit utilise des pixels LPD8806 [http://learn.adafruit.com/light-painting-with-raspberry-pi pour son projet de light painting avec Raspberry Pi].
  
=== Third-Party Libraries ===
+
=== Bibliothèques tierces ===
NeoPixel-compatible libraries have been developed for devices beyond Arduino. Please keep in mind that Adafruit did not develop any of this code, does not know it inside and out, and can’t fix bugs or offer technical help. This is Wild West stuff.
+
Des bibliothèques compatible NéoPixel ont été développé pour d'autres périphériques qu'Arduino. Ces librairies n'ont pas été développées par Adafruit, seul les auteurs respectifs savent comment fonctionne leur code et seront les seul à pouvoir offrir aide, support technique et correction de bug.
  
* [http://www.pjrc.com/teensy/td_libs_OctoWS2811.html OctoWS2811]: specifically for the PJRC Teensy 3.0 microcontroller board. Uses DMA to drive up to 8 NeoPixel strips concurrently with minimal processor load. Multiple boards can be cascaded for still larger displays.
+
* [http://www.pjrc.com/teensy/td_libs_OctoWS2811.html OctoWS2811]: conçu spécialement pour les cartes microcontrôleurs PJRC Teensy 3.0. Utilise DMA pour piloter jusqu'à 8 rubans NéoPixels concurrent avec une charge processeur minimale. De multiples cartes peuvent être assemblée en cascade pour réaliser de grands afficheurs.
* [https://github.com/scanlime/fadecandy FadeCandy]: also for Teensy 3.0. Doesn’t support as many pixels as OctoWS2811, but adds smooth interpolation and other features for the color-persnickety.
+
* [https://github.com/scanlime/fadecandy FadeCandy]: aussi pour Teensy 3.0. Mais ne supporte pas autant de pixels que OctoWS2811, mais ajoute de chouette interpolation et autres caractéristiques autour des couleurs.
* [http://www.nycresistor.com/2013/07/27/ledscape/ LEDscape]: specifically for BeagleBone Black. Although the BeagleBone is a multitasking Linux system like the not-NeoPixel-compatible Raspberry Pi, this code exploits hardware features specific to the BeagleBone Black to drive hundreds of meters of NeoPixel strip with virtually no processor load.
+
* [http://www.nycresistor.com/2013/07/27/ledscape/ LEDscape]: spécialement pour BeagleBone Black. Même si BeagleBone est un système Linux multitâche tel que Raspberry Pi (donc non compatible avec NéoPixel), ce code exploite des caractéristiques matérielles spécifiques du BeagleBone Black pour piloter des centaines de mètres de ruban NeoPixel sans aucune charge processeur (ou presque).
* [http://obex.parallax.com/object/703 WS2812 LED Driver] for Parallax Propeller.
+
* [http://obex.parallax.com/object/703 Pilote pour LED WS2812] pour la plateforme Parallax Propeller.
* [https://github.com/teachop/xcore_neopixel_leds xCORE NeoPixel test code] for the XMOS xCORE startKIT.
+
* [https://github.com/teachop/xcore_neopixel_leds xCORE NeoPixel test code] pour le startKIT XMOS xCORE.
  
{{ambox-stop|text=Some of these are 3.3V devices. See the “Powering NeoPixel” page for notes on controlling 5V NeoPixels from 3.3V microcontrollers.}}
+
{{ambox-stop|text=Certaines de ces plateformes fonctionne sous 3.3V. Voyez la page "[[NeoPixel-UserGuide-Alimenter|Alimenter des NéoPixel]]" qui contient des notes pour contrôler des NéoPixels 5V depuis un microcontrôleur 3.3V.}}
  
=== WS2811? WS2812? Why do I see two different names mentioned? ===
+
=== WS2811? WS2812? Pourquoi y a t'il différents nom?!?! ===
The WS2811 is an earlier driver chip separate from the RGB LED. The data signal is similar, but runs at half the speed. By the time the WS2812 (with integrated LED) was released, a lot of code and projects had already built up around the WS2811 name. Sometimes code “for the WS2811” might actually be for the newer chip, or for either type. The Adafruit_NeoPixel library supports both.
+
Le WS2811 est une puce de pilotage séparé de la LED RGB. Le signal de donnée est similaire mais fonctionne à la moitié de la vitesse. Entre temps, le WS2812 (avec LED RGB intégrée) a été mis en vente, il n'empêche qu'il existe beaucoup de code et de projet autour du nom WS2811. C'est parfois "pour le WS2811" mais qui est en fait destiné au contrôleur plus récent, ou pour les deux types. La bibliothèque Adafruit_NeoPixel supporte les deux modèles.
  
== Writing Your Own Library ==
+
== Ecrire votre propre bibliothèque ==
  
The [http://www.adafruit.com/datasheets/WS2812.pdf WS2812 datasheet] explains the data transmission protocol. This is a self-clocking signal — there’s only one wire, not separate data and clock lines. “1” and “0” bits are indicated by varying the duty cycle of a fixed-frequency square wave.
+
La [http://www.adafruit.com/datasheets/WS2812.pdf fiche technique du WS2812] explique le protocole de transmission des données. C'est un signal portant aussi le signal d'horloge il n'y a qu'un seul fil, par de fils séparés pour le signal d'horloge et transport de données. Les bits "1" et "0" sont mentionnés en faisant varier le cycle utile d'une onde carrée à fréquence fixe.
  
[[Fichier:NeoPixel-UserGuide-YourLib-01.jpg]]
+
[[Fichier:NeoPixel-UserGuide-YourLib-01.png]]
  
There’s a math goof in the datasheet’s timing values. Use these figures instead:  
+
Il y a une gaffe mathématique dans les valeurs temporelles de la fiche technique. Il faut utiliser le graphique suivant à la place:  
  
[[Fichier:NeoPixel-UserGuide-YourLib-02.jpg]]
+
[[Fichier:NeoPixel-UserGuide-YourLib-02.png]]
  
Note that there’s nearly 25% “wiggle room” in the timing. So if your code can’t match the recommended times exactly, it’s usually okay.
+
Notez qu'il y a "une marge de manoeuvre" de presque 25% dans la gestion du temps. Cela reste généralement correct si vous ne pouvez pas strictement respecter la base de temps.
  
There are three bytes of data for each pixel. These should be issued in green, red, blue order, with the most-significant bit first.
+
Il y a 3 octets/bytes de données pour chaque pixel. Qui doivent être envoyés dans l'ordre vert, rouge, bleu (''green, red, blue'') avec le bit le plus significatif en premier.
  
[[Fichier:NeoPixel-UserGuide-YourLib-03.jpg]]
+
[[Fichier:NeoPixel-UserGuide-YourLib-03.png]]
  
The data for pixel #0 (nearest the microcontroller) is issued first, then pixel #1, and so forth to the furthest pixel. This does not operate like a traditional shift register!
+
Les données pour le pixel #0 (proche du microcontroleur) sont émises en premier, ensuite le pixel #1 et ainsi de suite pour les pixels suivants. Cela ne fonctionne pas comme un registre à décalage traditionnel!
  
After all the color data is sent, the data line must be held low for a minimum of 50 microseconds for the new colors to “latch.
+
Après l'envoi de toutes les données de couleur, la ligne de donnée doit être maintenue au niveau bas (''low'') pendant un minimum de 50 microsecondes pour indiqué l'envoi d'un nouveau flux de donnée (à partir du pixel #0).
  
You may want to dig through our [https://github.com/adafruit/Adafruit_NeoPixel Arduino library] for insights. The timing-critial parts are written in AVR assembly language, but it’s extensively commented with C-like pseudocode.  
+
Vous pourriez avoir besoin de consulter les sources de la [https://github.com/adafruit/Adafruit_NeoPixel bibliothèque Arduino] pour vous faire une idée. Les parties critiques (celles où la gestion du temps est critique) sont écrit en langage d'assemblage AVR mais très largement documentté en pseudo-code C.  
  
=== My Microcontroller Isn’t Fast Enough to Do That ===
+
=== Mon microcontroleur n'est pas assez rapide pour cela ===
The WS2812 appears to be backwardly-compatible with the 400 KHz WS2811 signal. If you can precisely match the latter chip’s timing, either type will respond. '''The WS2811 protocol is not simply a half-speed WS2812'''. The duty cycle for the “0” and “1” bits is slightly different. From the [http://www.adafruit.com/datasheets/WS2811.pdf WS2811 datasheet]:
+
Apparemment, le WS2812 est rétro-compatble avec le signal 400 KHz du WS2811. Si vous pouvez atteindre le signal 400 Khz avec précision, les deux types devraient répondre. '''Le protocole WS2811 n'est pas simplement la moitié de la vitesse du WS2812'''. Le cycle utile des bits "0" et "1" diffèrent aussi légèrement. Voyez ce graphique extrait [http://www.adafruit.com/datasheets/WS2811.pdf de la fiche technique du WS2811]:
  
[[Fichier:NeoPixel-UserGuide-YourLib-10.jpg]]
+
[[Fichier:NeoPixel-UserGuide-YourLib-10.png]]
  
 
{{NeoPixel-UserGuide-TRAILER}}
 
{{NeoPixel-UserGuide-TRAILER}}

Version actuelle datée du 22 janvier 2015 à 21:28


MCHobby investit du temps et de l'argent dans la réalisation de traduction et/ou documentation. C'est un travail long et fastidieux réalisé dans l'esprit Open-Source... donc gratuit et librement accessible.
SI vous aimez nos traductions et documentations ALORS aidez nous à en produire plus en achetant vos produits chez MCHobby.

Question - Réponse

Combien de pixels sur un Arduino Uno

La façon de gérer les pixels nécessite l'usage d'une mémoire tampon (buffer) pour mémoriser tous les éléments du ruban/strip. Souvent, sur Arduino UNO il ne reste que 500 octets/bytes libre une fois tous les extras ajouter au projet.

500 bytes, c'est assez pour contrôler 150 pixels. Si vous désirez piloter un strip/ruban complet en utilisant des librairies complémentaires, vous pourriez avoir besoin d'un Mega (voir ce tuto sur la comparaison de la mémoire SRAM).

Mon code servo sur Arduino arrête de fonctionner lorsqu'il est combiné avec NeoPixels!

Malheureusement, les bibliothèques NéoPixel et servo ne fonctionne pas très bien ensemble; La première ayant besoin de désactiver les interruptions de façon périodique et la deuxième en a absolument besoin pour fonctionner. Vous avez néanmoins quelques alternative:

  • Utiliser un shield controleur servo ou un breakout controleur PWM/Servo, déchargeant le processeur de la tâche et libérant ainsi les interruptions.
  • Utiliser une bibliothèque servo hardware-PWM-based (signal PWM contrôlé matériellement) plutôt que la librairie Servo Arduino (d'origine). Cela peut offrir un contrôle du temps vraiment très stable sans utiliser d'interruption, mais peut seulement contrôler but un nombre très limité de servo (2-3) et uniquement sur des broches très spécifiques. PWMServo semble pouvoir gérer cela... téléchargez la "bibliothèque de Paul (v2)” depuis cette page.

A quelle vitesse puis-je rafraichir une chaine de (N) pixels?

Les NéoPixels reçoivent le flux de donnée à la fréquence fixée de 800 KHz (excepté pour les pixels Flora “V1” qui utilisait un fréquence de 400 KHz). Un bit à donc besoin de de 1/800.000 de sec — soit 1.25 microsecondes pour être transmit. Un pixel à besoin de 24 bits pour fixer sa couleur (8 bits pour chaque couleur de base rouge, vert, bleu) — soit 30 microsecondes. Après l'envoi des données du dernier pixels, le flux de donnée doit être arrêté pendant au mois 50 microsecondes avant de relancer un nouveau flux de donnée (et recommencer le cycle d'initialisation des couleurs du premier au dernier pixel)

Pour un ruban de 100 pixels, cela représente (100 * 30) + 50, soit 3.050 microsecondes par cycle. Comme il y a 1.000.000 micro-secondes dans une seconde, cela donne 1.000.000 / 3.050 = approximativement 328 mise-à-jour par seconde.

Cependant

C'est seulement le temps nécessaire pour l'envoi des données sur le fil. Le taux de rafraichissement réel sera quand même inférieur et ne peux pas être facilement évaluer en un valeur finie couvrant tous les cas. Le traitement de chaque image d'une animation prends du temps. Le temps nécessaire dépends de la complexité, des opérations mathématiques et de l'efficacité du code (par exemple, les opérations en virgule flottante sont relativement lente). La technique ci dessus donne un taux maximum théorique mais c'est juste un point de départ.

Si vous désirez faire des explorations et des relevés (du benchmarking), vous pouvez toujours écrire du code pour un plus grand nombre de pixels même s'il ne sont pas présent. Cela permet de relever le temps de traitement. Les bits de données en extra (pour les pixels non présents) sont simplement ignorés par le ruban/chaine (ou vous pouvez même tester sans aucun NéoPixel connectés).

Ca ne va pas. Que faire?

Etant donné que les NéoPixels utilisent une fréquence d'horloge fixe, les options sont limitées. Vous pouvez opter pour un microcontrôleur plus rapide dont vous pouvez attendre une différence substantielle.

Une autre option est d'utiliser un type de LED différent, tel que des rubans LPD8806 ou pixels WS2801. Ils peuvent être pilotés avec un débit de données plus élevé mais présente néanmoins quelques inconvénients par rapport aux NéoPixels (coût, résolution des couleurs et/ou la densité des pixel).

Une dernière option est de développer votre propre code sur un microcontrôleur performant ou un FPGA qui pilote plusieurs ruban NéoPixel en parallèle. De tels options sont abordés plus tard — comme OctoWS2811 pour le microcontrôleur Teensy 3.0. Cette option nécessite la compréhension de choses complexes et n'est pas recommandé aux débutants. Et même pour les développeurs expérimentés, il arrive de mettre l'accent de façon déraisonnable sur le débit de donnée alors que le goulot d'étranglement se cache ailleurs... ne vous attardez donc pas trop sur le remplacement du microcontrôleur à moins que vous ne sachiez confirmer que le débit est le problème.

Puis-je contrôler les NéoPixels en utilisant la carte X?

AdaFruit offre uniquement une bibliothèque Arduino. Voyez les liens (plus loin) pour d'autres périphériques. Pour toutes les autres plateformes, et si vous considérez l'option d'écrire votre propre bibliothèque, vous devez comprendre qu'il y a des périphériques plus aptes que d'autres à cette tâche. Lisez le point concernant les exigences de gestion du temps (ci-dessous) pour savoir si le processeur ou le périphérique en question, est capable de générer le signal en concordance avec les spécifications. Un AVR à 8 MHz peut à peine suivre... tout ce qui sera plus lent sera source de problèmes, bien que quelques hackings hardware spécifiques (comme une utilisation intelligente du SPI) pourrait rendre cela possible. Dans de nombreux cas, l'utilisation de l'assembleur sera nécessaire.

Pourquoi pas un Raspberry Pi?

Un Raspberry Pi exécute un système d'exploitation multi-tâche, et le contrôle peut passer d'un programme à l'autre à n'importe quel moment. Par conséquent, il est impossible de garantir strictement le signal à 800 KHz requis par NéoPixels. Vous devriez être capable de produire un tel signal pendant un court interval, mais ce n'est pas quelque-chose qui peut être tenu en compte. C'est c'est raison pour laquelle Adafruit utilise des pixels LPD8806 pour son projet de light painting avec Raspberry Pi.

Bibliothèques tierces

Des bibliothèques compatible NéoPixel ont été développé pour d'autres périphériques qu'Arduino. Ces librairies n'ont pas été développées par Adafruit, seul les auteurs respectifs savent comment fonctionne leur code et seront les seul à pouvoir offrir aide, support technique et correction de bug.

  • OctoWS2811: conçu spécialement pour les cartes microcontrôleurs PJRC Teensy 3.0. Utilise DMA pour piloter jusqu'à 8 rubans NéoPixels concurrent avec une charge processeur minimale. De multiples cartes peuvent être assemblée en cascade pour réaliser de grands afficheurs.
  • FadeCandy: aussi pour Teensy 3.0. Mais ne supporte pas autant de pixels que OctoWS2811, mais ajoute de chouette interpolation et autres caractéristiques autour des couleurs.
  • LEDscape: spécialement pour BeagleBone Black. Même si BeagleBone est un système Linux multitâche tel que Raspberry Pi (donc non compatible avec NéoPixel), ce code exploite des caractéristiques matérielles spécifiques du BeagleBone Black pour piloter des centaines de mètres de ruban NeoPixel sans aucune charge processeur (ou presque).
  • Pilote pour LED WS2812 pour la plateforme Parallax Propeller.
  • xCORE NeoPixel test code pour le startKIT XMOS xCORE.

WS2811? WS2812? Pourquoi y a t'il différents nom?!?!

Le WS2811 est une puce de pilotage séparé de la LED RGB. Le signal de donnée est similaire mais fonctionne à la moitié de la vitesse. Entre temps, le WS2812 (avec LED RGB intégrée) a été mis en vente, il n'empêche qu'il existe beaucoup de code et de projet autour du nom WS2811. C'est parfois "pour le WS2811" mais qui est en fait destiné au contrôleur plus récent, ou pour les deux types. La bibliothèque Adafruit_NeoPixel supporte les deux modèles.

Ecrire votre propre bibliothèque

La fiche technique du WS2812 explique le protocole de transmission des données. C'est un signal portant aussi le signal d'horloge — il n'y a qu'un seul fil, par de fils séparés pour le signal d'horloge et transport de données. Les bits "1" et "0" sont mentionnés en faisant varier le cycle utile d'une onde carrée à fréquence fixe.

NeoPixel-UserGuide-YourLib-01.png

Il y a une gaffe mathématique dans les valeurs temporelles de la fiche technique. Il faut utiliser le graphique suivant à la place:

NeoPixel-UserGuide-YourLib-02.png

Notez qu'il y a "une marge de manoeuvre" de presque 25% dans la gestion du temps. Cela reste généralement correct si vous ne pouvez pas strictement respecter la base de temps.

Il y a 3 octets/bytes de données pour chaque pixel. Qui doivent être envoyés dans l'ordre vert, rouge, bleu (green, red, blue) avec le bit le plus significatif en premier.

NeoPixel-UserGuide-YourLib-03.png

Les données pour le pixel #0 (proche du microcontroleur) sont émises en premier, ensuite le pixel #1 et ainsi de suite pour les pixels suivants. Cela ne fonctionne pas comme un registre à décalage traditionnel!

Après l'envoi de toutes les données de couleur, la ligne de donnée doit être maintenue au niveau bas (low) pendant un minimum de 50 microsecondes pour indiqué l'envoi d'un nouveau flux de donnée (à partir du pixel #0).

Vous pourriez avoir besoin de consulter les sources de la bibliothèque Arduino pour vous faire une idée. Les parties critiques (celles où la gestion du temps est critique) sont écrit en langage d'assemblage AVR mais très largement documentté en pseudo-code C.

Mon microcontroleur n'est pas assez rapide pour cela

Apparemment, le WS2812 est rétro-compatble avec le signal 400 KHz du WS2811. Si vous pouvez atteindre le signal 400 Khz avec précision, les deux types devraient répondre. Le protocole WS2811 n'est pas simplement la moitié de la vitesse du WS2812. Le cycle utile des bits "0" et "1" diffèrent aussi légèrement. Voyez ce graphique extrait de la fiche technique du WS2811:

NeoPixel-UserGuide-YourLib-10.png


Source: NeoPixel UserGuide créé par Phillip Burgess pour AdaFruit Industries. Crédit AdaFruit Industries

Traduit par Meurisse D. pour MCHobby.be

Traduit avec l'autorisation d'AdaFruit Industries - Translated with the permission from Adafruit Industries - www.adafruit.com

Toute référence, mention ou extrait de cette traduction doit être explicitement accompagné du texte suivant : «  Traduction par MCHobby (www.MCHobby.be) - Vente de kit et composants » avec un lien vers la source (donc cette page) et ce quelque soit le média utilisé.

L'utilisation commercial de la traduction (texte) et/ou réalisation, même partielle, pourrait être soumis à redevance. Dans tous les cas de figures, vous devez également obtenir l'accord du(des) détenteur initial des droits. Celui de MC Hobby s'arrêtant au travail de traduction proprement dit.