Skyduino:~#
Articles
arduino, C/C++, programmation, projet

[AVR] Matrices RGB et jolies couleurs

Bonjour tout le monde !

bug_signal_ctrl

Après avoir passé tout le week-end dernier à chercher un bug dans mon code pour les matrices de led, j’ai enfin fini par trouver l’origine du problème.

Pour les curieux le problème en question est visible dans la capture d’écran ci-dessus. Cherchez l’erreur ;)
Indice : regardez la largeur de chaque temps haut/bas sur la ligne « A », il y a comme un décalage vous trouvez pas ;)

Bref, après avoir corrigé ce bug gênant (et idiot …) j’ai pu terminer l’ajout des nuances de couleurs et même de la correction gamma pour la luminosité. Autant dire que le code actuel est désormais plutôt complet.
Il reste encore à ajouter le double buffering, mais ça ce sera pour une prochaine mise à jour.

Au final il est possible d’atteindre (au maximum) :
- 32768 nuances de couleurs avec une unique matrice,
– 4096 nuances de couleurs avec deux matrices,
– 512 nuances de couleurs avec trois matrices,
– 64 nuances de couleurs avec quatre matrices.

Edit : J’ai jamais été très fort en math :)
Voici les nouveaux chiffres revus et corrigés.

Avec un ATmega1284p à 16MHz :
– 28 matrices en mode 8 couleurs (limitation par manque de RAM)
– 14 matrices en mode 64 couleurs (pareil, limitation par manque de RAM)
– 9 matrices en mode 512 couleurs (toujours pareil, limitation par manque de RAM)
– 4 matrices en mode 4096 couleurs (limitation par manque de temps processeur cette fois)
– 1 matrice en mode 32768 couleurs (pareil, limitation par manque de temps processeur)

Avec un ATmega1284p à 20MHz (pas testé pour le moment) :
– 6 matrices en mode 4096 couleurs (limitation processeur)
– 2 matrices en mode 32768 couleurs (limitation processeur)

Le tout en gardant une fréquence de rafraîchissement stable à 60Hz.
Je trouve ces résultats tout à fait corrects pour un code basé sur un microcontrôleur 8 bits tournant à seulement 16MHz ;)

Pour être franc, j’ai essayé tous les niveaux de nuances possibles … 32K couleur ça ne sert franchement à rien.
C’est joli, c’est pour le challenge, mais 64 couleurs personnellement c’est largement suffisant pour ce que je veux faire.
Si le but avez été d’afficher des images en full-color j’aurai directement fait un montage à base de FPGA et d’ARM :)

Le nouveau code est disponible sur mon github comme d’habitude :
https://github.com/skywodd/RGB_Matrix_Arduino_AVR/tree/master/M1284_Software

Il ne vous reste plus qu’à changer les trois constantes : NB_HORIZONTAL_MATRIX (nombre de matrices horizontal), NB_VERTICAL_MATRIX (nombre de matrices vertical), NB_RESOLUTION_BITS (nombre de bits de résolution pour les composantes R,G et B) en fonction de votre configuration matérielle et d’ajouter votre code de dessin dans le corps de la boucle for(;;) {}.

J’espère voir de jolis projets pleins de couleurs dans les commentaires :)

Pour ceux qui serait intéressé j’ai aussi publié le code python pour générer les tables de correction gamma.
L’algorithme utilisé est le même que celui de la note d’application de Maxim. Je n’ai pas réinventé la roue.
Les tables prégénérées sont calculées pour une correction gamma de 2.5 et une entrée de données sur 8 bits (qu’importe le nombre de couleurs final au niveau des matrices, le code fait la conversion en interne).

Remarques

1) Le code en soit est compatible Arduino UNO, Mega2560 et ATMega1284p.
Mais si vous voulez avoir plus d’un bit de résolution (8 couleurs max) il faudra obligatoirement utiliser une carte à base d’ATmega1284p (pour ses 16Ko de RAM).

2) La fonction setPixelAt(x, y, r, g, b) prend en arguments des couleurs au format RGB888 (soit des couleurs sur 24 bits au total).
En interne après correction gamma les couleurs sont réajustées en fonction du nombre de couleurs possibles physiquement.
C’est le code qui fait son truc en interne, pour l’utilisateur c’est toujours du RGB888 quoiqu’il arrive.

Démonstration

Le code d’exemple fait défiler toutes les nuances de couleurs possibles.

Voilà ce que ça donne avec 4 matrices (64 couleurs) et 2 matrices (4096 couleurs) :

DSCF2785

DSCF2793

DSCF2794

Au passage j’en profite pour faire un peu de teasing concernant ma table basse interactive ;)

DSCF2799

Il manque encore pas mal de pièces en bois, mais ça avance.

Un double article devrait arriver d’ici peu pour expliquer l’optimisation du code dans un premier temps, puis l’ajout des nuances de couleurs dans un second temps.
Je vous préviens de suite ça va parler assembleur, timer 16 bits et mathématique (non ne partez pas !).

En attendant bon WE à toutes et à tous ;)

PS : Vous avez remarqué le QR-code sur la droite ? To the moon, à moi la richesse :)

About these ads

Discussion

9 réflexions sur “[AVR] Matrices RGB et jolies couleurs

  1. Tu as essayer d’utiliser la matrice avec l’Arduino Due ? Parce que à 84 Mhz ça doit être beaucoup plus fluide.

    Publié par yag48 | 30 mars 2014, 17 h 39 min
    • Porter du code avr-8 sur sam-3x, ça risque d’être long …
      Y’a énormément de trucs à changer vu que c’est du code assez bas niveau (les registres pour changer l’état des pins, c’est pas les même par exemple), et pis on passe de 8 à 32 bits.
      Sur le code assembleur ça fera encore plus de différence !

      Publié par Ogex | 30 mars 2014, 19 h 09 min
    • Non j’ai pas essayé parce que se serait contre productif.

      1) Porter du code AVR pour une architecture SAM3X c’est la merde (vraiment).
      2) Refaire toute la partie assembleur en ASM-ARM en suivant la syntaxe gcc … même pas la peine d’essayer.
      Autant tout reprendre en C pure et dure, en priant pour que le gain de puissance suffise à compenser le code en C.
      3) 84MHz ça fait « que » ~4x la puissance d’un ATmega à 20MHz, au mieux tu passerais à 6 bits par couleurs mais la fluidité ne changerait pas.

      Les MHz c’est une chose, mais (spoiler) pour la version ARM du contrôleur que je suis justement en train de prototyper (/spoiler) ce qui compte c’est que le hardware puisse directement faire le transfert mémoire -> GPIO.

      Il suffit par exemple d’une DMA à 20MHz pour avoir une amélioration de x10 par rapport à la version actuel.
      Le problème pour le moment c’est que je galère à trouver un ARM-CortexMx avec DMA et assez de RAM (sans tomber dans des extrêmes style STM32F4 en boiter 140 broches)

      Publié par skywodd | 30 mars 2014, 19 h 37 min
  2. Donc en faite c’est la rapidité de réponse du GPIO qui compte sur la carte ?

    Publié par yag48 | 31 mars 2014, 22 h 29 min
    • Oui, et c’est logique.
      Le CPU fait des calculs, ok, mais si pour chaque pixel il doit faire N calculs, avec une matrice ça fait 32N, avec deux matrices 64N, etc.

      Même avec 84MHz, au final, à la sortie les broches commutent pas aux 25MHz théoriques que peut supporter les matrices.
      Dans mon code actuel, en optimisant à mort, j’atteint péniblement les 1MHz, ce qui est déjà vraiment pas mal.

      Forcément, si le hardware peut faire le transfert lui même à 25MHz le gain de performance est de suite énorme. Après faut trouver un processeur avec une DMA qui va bien et ds GPIO qui commutent à >25MHz, et là c’est plus compliqué sans tomber dans des extrêmes style STM32F4.

      Publié par skywodd | 9 avril 2014, 12 h 37 min
  3. Salut,
    Lorsque je regarde ton chronogramme temporel, on pourrait peut être utiliser une pin du 1284P pour commander Clk, Lat et OE.
    Illusion ou réalité ?

    Publié par Icare Petibles | 1 avril 2014, 18 h 57 min
    • LAT = OE, en réalité ces deux broches pourraient être câblé sur une seule sortie mais par sécurité (et après pas mal de test foirés) j’ai préféré garder le contrôle des deux broches séparément.

      Publié par skywodd | 9 avril 2014, 12 h 38 min
  4. J’aime bien les phénomèmes aléatoires ou plutôt pseudo-aléatoires. J’ai modifié le programme pour afficher sur 2 matrices l’allumage des pixels de manière aléatoires avec des couleurs aléatoires.
    Mais j’ai toujours mon problème de prise de poto :(

    Publié par Icare Petibles | 1 avril 2014, 19 h 02 min

Rétroliens/Pings

  1. Pingback: [Erratum article précédent] 1 + 1 = 10 | Skyduino - Le DIY à la française - 12 avril 2014

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Archives

Wow. Dogecoin. Amaze.

Laissez un tip en Dogecoin

DMMNFk6WBVTpx2Wu1Z35GL61QXSd6r6WQx

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 771 autres abonnés