NeoPixel-UserGuide-Programmation-Avancée

Question - Réponse

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.

Writing Your Own Library

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.

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

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.

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:

---

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.