NeoPixel-UserGuide-Programmation-Avancée

Question - Réponse

Mo 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? Why do I see two different names mentioned?

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.

Writing Your Own Library

The 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.

There’s a math goof in the datasheet’s timing values. Use these figures instead:

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.

There are three bytes of data for each pixel. These should be issued in green, red, blue order, with the most-significant bit first.

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!

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.”

You may want to dig through our Arduino library for insights. The timing-critial parts are written in AVR assembly language, but it’s extensively commented with C-like pseudocode.

My Microcontroller Isn’t Fast Enough to Do That

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 WS2811 datasheet:

---

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.