[Tuto/Info] Matrice de leds RGB – partie 1

Bonjour tout le monde !

Oui je sais je suis encore en retard dans mes articles – comme d’habitude quoi 🙂
Pour faire vite : l’article « surprise » du 1er janvier devrait être finalement OK pour ce WE (du coup c’est moyen pour la surprise je vous l’accorde).
Concernant mon projet « top secret » pour l’article n°256, c’est en cours, j’en parlerai dans un autre article.
Voilà pour les news.

—

Elles sont enfin là !

Si vous avez participé à la précommande des matrices de leds d’il y a un petit peu plus de deux mois maintenant, vous devriez avoir reçu un gros colis 😉
Et oui on les attendait nos matrices et bien les voilà !

On n’oubliera pas de remercier toute l’équipe de belectronique.fr pour le travail et l’arrachage de cheveux en terme de logistique 😉
Ils ont bossé sacrément dur pour que tout se passe bien et ont même fait les emballages de tous les petits sachets de câbles à la main.

Bon.
Maintenant que les matrices sont arrivées, c’est l’heure de passer aux choses sérieuses 😉

Dans cet article je vais juste poser les bases pour la suite, on va commencer petit pour pouvoir finir grand.
Note : Les moins téméraires d’entre vous devraient normalement être en mesure de contrôler une matrice seule à la fin de cet article.

NB: cet article vise en particulier les matrices de la précommande citées ci-dessus. Vous pouvez trouver le même genre de matrice sur ebay avec les mots clefs adéquats, mais je ne peux pas garantir que mon article fonctionnera avec d’autres matrices que celles de la précommande.

—

Les matrices – introduction

Avant de partir dans les trucs techniques voici un petit tour d’horizon du contenu du kit :

Chaque matrice est fournie avec :
– un câble de données (une nappe 2×8 points),
– un câble d’alimentation (qui permet l’alimentation de deux matrices),
– 6 pieds à visser et 6 aimants.

Personnellement je n’ai pas eu de câbles d’alimentations, en réalité j’ai donné les miens à un autre participant de la précommande.
Dans ses calculs notre vendeur chinois avait oublié 3 câbles d’alimentation, du coup il a bien fallu que quelqu’un se sacrifie 😉

En réalité les câbles d’alimentations d’origines ne me font ni chaud ni froid.
Dès le début j’avais prévu de faire des câbles « à ma sauce », sous-entendu de la taille qui me convient.

Si comme moi vous voulez vous faire des câbles d’alimentations de longueurs quelconques, il vous suffit de prendre :
– du fil pouvant résister à 2A minimum (du AWG-18 c’est pas mal),
– des cosses à sertir,
– des connecteurs JST 4-points au pas 3.96mm (référence « VHR-4N »).

Une fois assemblait on obtient un joli câble comme celui-ci :

Note : J’ai ajouté des embouts pour éviter que les fils partent en morceaux. Ça fait plus « pro » 🙂

—

Remarque concernant les pieds à visser et les aimants

On m’a demandé à plusieurs reprises à quoi servait c’est choses. C’est ULTRA simple :
Vous glissez les aimants dans la base des pieds à visser, et … voilà, vous avez des pieds magnétiques à visser.
C’est tout.

L’idée derrière ces pieds magnétiques est de pouvoir fixer les matrices sur des rails en métal (c’est comme ça qu’elles sont fixées normalement).
Avec des vis classiques, il est impossible d’aligner deux (ou plus) matrices ensemble, alors qu’avec des pieds magnétiques c’est trivial.

A l’origine ces matrices sont conçues pour faire des murs vidéo pour de la publicité, des plateaux de TV, et divers autres affichages basse définition (comme des fonds de scène de concert par exemple).
Imaginez le pauvre mec avec sa visseuse devant aligner plusieurs centaines de matrices. Sans ces pieds magnétiques, je ne voudrai pas être à sa place.

—

Les matrices – hardware

Les matrices de leds dans la vraie vie c’est des carrés de 16cm de côté avec plein de leds, en l’occurrence 1024 leds pour ces matrices de 32×32 pixels.

Niveau documentation de base c’est pas la joie.
J’ai bien réussi à trouver un datasheet en chinois, mais bon le chinois … c’est du chinois pour moi 🙂

Voici les points importants que j’ai pu traduire avec l’aide de l’ami google :

• Résolution : 32 x 32 pixels, 3 couleurs par pixel (rouge, vert, bleu)
• Distance entre deux pixels : 5mm (« PH5 » en terme technique)
• Gestion des leds par driver à courant constant (SM16126ES, impossible de trouver un datasheet potable)
• Circuit de remise en forme de signal intégré, théoriquement le nombre de matrices en cascade est donc illimité
• Led de type RGB en boitier CMS 5050
• Longueur d’onde :
• Rouge : 625±5nm
• Vert : 520±5nm
• Bleu : 470±5nm
• Tension d’alimentation : 5v DC (régulé)
• Consommation max : 2A // prévoir une alimentation qui puisse tenir le coup !
• Taille extérieure : 160 x 160mm
• Pas de bordure = pas de bande noire visible entre deux matrices
• Techniques de multiplexage : scanline 1 / 16 (adressage ligne par ligne sur 16 lignes)
• Fréquence de rafraîchissement à respecter : >= 400Hz (idéal selon mes tests : 960Hz)

IMPORTANT : l’alimentation pour les matrices doit sortir du 5V RÉGULÉ (pas 24v, pas 12v, 5 volts) et doit pouvoir résister au minimum à 2A.
Quand toutes les leds sont à pleines puissances et sur la couleur blanche je mesure pas loin de 1.97A avec mes matrices donc 2A c’est vraiment le minimum.

Si vous voulez une alimentation qui ne prend pas de place et qui ne coute pas trop cher (20€) cherchez « 5V 10A LED Power Supply » sur ebay.
J’ai acheté 3 alimentations de ce genre chez un vendeur allemand nommé « Assus » et elles sont vraiment bien pour tout ce qui contient des leds (matrices, rubans, …).
Elles sortent du 5.5v à vide et environ 4.67v à pleine charge (à 8A, je n’ai pas pu tester à 10A), en plus elles sont aux normes CE et FCC.

—

Les matrices – hardware (connectiques)

En matière de connecteurs, on ne peut pas faire plus simple.
Il y a trois connecteurs :
– une entrée de données,
– une sortie de données (pour chainer plusieurs matrices à la suite),
– et une alimentation.

Pour l’alimentation tant que vous utilisez un câble avec détrompeur ça devrait aller.
Sinon pour les bidouilleurs, il y a clairement marqué de quel côté se situe VCC et GND sur la carte mère.
Évitez d’inverser VCC et GND car il n’y a pas de diode de protection ou autre, à moins de vouloir un gros presse-papier c’est direction la poubelle en cas d’erreur.

Pour le câble de données, c’est plus compliqué dans le sens où l’entrée et la sortie ne sont pas clairement indiquées.
L’entrée de données est au niveau du connecteur avec les annotations des différents signaux, juste au-dessus du gros texte marqué « HUB75 ».
La sortie de données est au niveau de l’autre connecteur sans aucune annotation.

—

Procédure de branchement et de débranchement

Contrôler 1024 leds en même temps c’est techniquement très compliqué.
Pour contourner ce problème les matrices sont conçues de manière à se qu’une seule ligne ne soit affichée à tout instant t.
Pour avoir une image « fixe » il faut donc rafraichir les lignes plus vite que l’œil humain ne peut les voir.

Le truc – et ça on ne peut pas le deviner sans lire la doc constructeur – c’est que si le processus de rafraichissement reste figé sur une même ligne toutes les leds de la ligne en question se retrouvent à devoir supporter l’intégralité du courant fourni par l’alimentation. Pas la peine de vous dire que les leds n’aiment pas trop ça.
Il faut donc éviter à tout prix de laisser une ligne allumée trop longtemps de manière fixe.
(c’est un peu comme sur les oscilloscopes cathodique où il ne faut pas laisser le spot figé au même endroit)

Pas la peine de commencer à paniquer en vous disant que vous avez déjà branché les matrices, ya des sécurités de prévues 😉
Les matrices sont conçues de telle façon que par défaut, sans câble de données branché, les leds soient toutes éteintes.
En gros avec juste l’alimentation sans rien d’autre les matrices ne risquent absolument rien.

Du coup pour éviter les « oups » il suffit de faire les choses dans l’ordre :
1) Programmer l’arduino (ou le microcontrôleur quel qu’il soit) qui va transmettre les signaux de données.
2) Brancher le câble d’alimentation.
3) Brancher le câble de données.
4) Admirer les jolies lumières (c’est une étape très importante).
5) Débrancher le câble de données
6) Débrancher l’alimentation.
7) Se retrouver dans le noir (attention aux orteils, les coins de bureau ça fait très mal).

Le point 1) est important, on ne programme pas un microcontrôleur avec une charge de 2A au bout du fil qui ne demande qu’as se figer sur une ligne et cramer.
Autre point important : les timmings généraient par le programme dans le microcontrôleur DOIVENT être testé AVANT de brancher le câble de données. Ce n’est pas une fois le code planté sur une ligne qu’il faudra se dire « mince ya un bug ».
Le code d’exemple que je montrerai plus tard dans l’article a été testé, retesté et re-retesté avec un analyseur logique et un oscilloscope. Il fonctionne sans aucun problème avec les matrices ci-dessus.
Si vous faite votre code testez au moins UNE chose : que les lignes A, B, C et D (je les présente un peu plus tard dans l’article) changent régulièrement de valeur à une fréquence >400Hz pour qu’une ligne ne reste jamais figé qu’importe si tout le reste bug.

Remarque concernant les matrices de la précommande :
On y regardant de plus prés on remarque que les matrices de la précommande intègrent un driver de leds à courant constant.
En théorie donc, de par la présence de ce driver à courant constant, même si le rafraîchissement reste bloqué sur une même ligne ça ne devrait pas endommager les leds.
Sauf que …

Je n’ai trouvé aucune « vraie » documentation sur le driver en question (SM16126ES) et d’après mes tests il se comporte exactement comme un registre à décalage 74HCT595.
Par sécurité je vais faire comme si c’était un registre à décalage sans sortie à courant constant. A 35€ la matrice, vous comprendrez que je ne veux pas essayer de voir si ça crame ou pas 😉

—

Les matrices – fonctionnement (théorie)

Le premier point à comprendre avec ces matrices c’est le principe de « scanline ».
On ne peut pas commander toutes les leds de toutes les lignes en même temps. C’est un fait.
Pour contourner ce problème, on contrôle donc une unique ligne à chaque fois, en changeant de ligne régulièrement pour tromper la persistance rétienne de l’œil humain.
Ce principe c’est le « scanning », en gros c’est le principe des bons vieux écrans cathodiques.
Et la « scanline » c’est tout simplement le nombre de lignes que l’on rafraichit régulièrement pour créer une image.

Mais du coup combien de ligne contrôle-t-on à tout instant t ? 1 ligne, 2 lignes, 4 lignes ?
J’ai dit qu’on contrôlé une unique ligne à tout instant t, mais en fait ce n’est pas le cas.

Avec une matrice de 32 lignes il faudrait une « scanline 1/32 » pour réellement contrôler 1 ligne à tout instant t.
Ici les matrices de la précommande sont des « scanline 1/16 », il faut donc contrôler 2 lignes à tout instant t.
C’est assez bête en réalité, quand on contrôle la ligne N on contrôle aussi la ligne N + 16.

Pourquoi s’embêter à devoir gérer deux lignes en même temps ?
Tout simplement parce que gérer une scanline 1/32 demande une fréquence deux fois plus élevée qu’avec une scanline 1/16.
C’est logique, pour avoir la même fréquence de rafraîchissement il faut transmettre les données deux fois plus vite, car on a deux fois plus d’informations.
Avec seulement 8 couleurs, ça ne fait pas de différence, mais quand on commence à monter dans des puissances de deux ça commence à coincer sérieusement.
Car plus on veut de couleurs plus il faut rafraîchir rapidement l’affichage (les matrices ne font pas de modulation PWM d’elles même, il faut simuler une modulation PWM à la main). Et arrive finalement un moment où le processeur ne peut plus suivre.

Dans ce cas pourquoi ne pas prendre une matrice avec une scanline 1/8 ?
Tout simplement parce que gérer 4 lignes en même temps demande beaucoup trop de lignes de données (4×3 lignes) et dès lors cela devient une vraie galère.

La scanline 1/16 est le juste milieu en puissance nécessaire et facilité de câblage.
C’est pour cela que lors de la précommande j’ai fait le choix de prendre des matrices avec scanline 1/16 😉

L’autre point important à comprendre c’est les registres à décalage.
Imaginez un circuit dans lequel vous faite entrer des données séries (DATA), synchronisées par une horloge (CLOCK).
Un registre à décalage c’est tout bête : en sortie (DATA out) vous retrouvez les données en entrées, mais décalées de 8 tics d’horloge.
Ce n’est vraiment pas compliqué, d’un côté ça rentre, de l’autre ça sort, mais décalé.

Le truc c’est qu’un registre à décalage qui ne ferait que décaler ça ne servirait pas à grand-chose, sauf cas particulier.
Le but d’un registre à décalage c’est quand même de pouvoir transférer le contenu des registres « de travail » (ceux qui décales) à un instant t vers une autre série de registres « fixes ».
Ces registres « fixes » eux sont directement connectés à des broches de sorties (avec juste une broche OE pour mettre toutes les sorties en haute impédance si besoin). Ainsi on peut envoyer un flux série d’un côté, figer les valeurs à un instant t, et avoir ces valeurs sur des sorties parallèles.

C’est le principe fondamental des registres à décalage : transformer des données séries en données parallèles.
Et pour cela on utilise la broche « LATCH », une impulsion sur cette broche transfert aussitôt les valeurs séries des registres de travail vers les registres fixes et leurs sorties parallèles.

Maintenant que je vous ai bien assommé avec mes registres à décalages qu’est ce que ça vient faire avec nos matrices ?
Et bien si on prend 4 registres, qu’on les met en cascade, qu’on envoi un signal série d’un côté et qu’on a 32 leds de l’autre on obtient … une ligne de leds d’une même couleur.

Multipliez ce montage par 3 pour avoir les trois couleurs de base : Rouge, Vert, Bleu. Puis multipliez-le encore par 2 puisque l’on travaille en scanline 1/16 et bingo vous avez le montage interne des matrices de leds RGB !
Ce n’est pas compliqué, c’est juste plein de registres en cascade.

Mais du coup vous l’aurez surement remarqué : on se retrouve avec 3 broches communes : CLOCK, LATCH et OE.
Et avec 6 broches de données : R1, R2, G1, G2, B1, B2.
On est donc très loin du bon vieux port SPI avec sa ligne CLOCK et sa ligne de données (MISO). Il va falloir refaire en logiciel l’équivalent d’un shiftOut() en Arduino, mais avec non pas une mais 6 lignes de données. Ce sera justement le sujet de mon prochain article.

Et pour les colonnes ? Ben oui on a parlé des lignes, mais pas des colonnes …
Pour les colonnes c’est ultra basique (oui tout est facile sur le papier :)).

Tout d’abord sur l’entrée de données il y a un premier étage de remise en forme pour pouvoir chainer plusieurs matrices sans perte de signal.

Ensuite il y a tout simplement un décodeur binaire / décimal sur 4 bits.
Chaque sortie du décodeur (de 0 à 15) est reliée à un mosfet qui permet d’alimenter ou non une ligne de leds.
Il suffit d’envoyer un nombre en binaire dans A, B, C, D pour sélectionner la ligne N (et N + 16) voulue.

La table de vérité pour les curieux (en scanline 1/16):

D (MSB)	C	B	A (LSB)	Ligne
0	0	0	0	0 et 16
0	0	0	1	1 et 17
0	0	1	0	2 et 18
0	0	1	1	3 et 19
0	1	0	0	4 et 20
0	1	0	1	5 et 21
0	1	1	0	6 et 22
0	1	1	1	7 et 23
1	0	0	0	8 et 24
1	0	0	1	9 et 25
1	0	1	0	10 et 26
1	0	1	1	11 et 27
1	1	0	0	12 et 28
1	1	0	1	13 et 29
1	1	1	0	14 et 30
1	1	1	1	15 et 31

—

Les matrices – fonctionnement (pratique)

Comme on a pu le voir juste au-dessus les matrices se contrôlent au moyen de 6 lignes de données, 4 lignes d’adresses, et 3 signaux de contrôles.
Rn, Gn, Bn (avec n = 1 ou 2) sont les lignes de données.
A, B, C, D sont les lignes d’adresses.
CLK, OE, LAT sont les lignes de contrôles (horloge, sorties actives, latch).

Il y a une logique dans le design du connecteur 😉
Si vous faites des « Z » vous remarquerez que les lignes de données sont dans l’ordre R1, G1, B1, GND et R2, G2, B2, GND.
Pareil pour les lignes d’adresse A, B, C, D et les lignes de contrôles CLK, LAT, OE, GND.

Personnellement pour faciliter le câblage j’ai fabriqué un petit adaptateur pour breadboard.
C’est juste un morceau de « plaque à trous » avec deux connecteurs DIL de chaque côté.
D’un côté je branche la matrice, de l’autre j’enfiche dans une breadboard ou dans des fils.

Pour faire marcher tout ça il va falloir deux bibliothèques logicielles :
https://github.com/adafruit/RGB-matrix-Panel
et :
https://github.com/adafruit/Adafruit-GFX-Library

La première sert à contrôler une matrice (mais pas plusieurs, juste une seule matrice), la seconde sert à faire des dessins (cercles, carrés, etc). Les deux sont obligatoires sinon l’exemple « colorwheel_32x32 » fourni avec la bibliothèque ne compilera pas.

Concernant le câblage il s’agit de celui fourni ici :
http://learn.adafruit.com/32×16-32×32-rgb-led-matrix/

Comme il n’est pas très simple à comprendre, voilà une version plus lisible:
Matrice -> Arduino UNO
R1 -> 2
G1 -> 3
B1 -> 4
R2 -> 5
G2 -> 6
B2 -> 7

A -> A0
B -> A1
C -> A2
D -> A3

CLK -> 8
OE -> 9
LAT -> 10

Si vous utilisez une carte Mega2560 il faudra faire une petite modification dans le code de l’exemple :

#define CLK 50
#define OE 51

Et bien sûr câbler les deux broches en question sur 50 et 51 au lieu de 8 et 9 😉

Une fois le code d’exemple compilé & uploadé et les matrices branchées voila le résultat :

Dans mon prochain article, je vous donnerai un code ultra basique (8 couleurs possibles) pour comprendre le principe de fonctionnement des matrices. Ce sera aussi une bonne base pour vos projets si vous n’avez pas besoin de couleur en nombre démesurée, ou que vous voulez avoir plusieurs matrices en cascades.

Le code final que je présenterai dans un troisième article devrait pouvoir gérer un bon paquet de couleurs (256 au moins) et aux maximum 4 matrices en cascades (cf photo ci-dessus).
Mais avant cela je vais avoir besoin d’une table en bois, d’une plaque de plexiglas et de 4 manettes de NES. Je vous laisse méditer là-dessus 😉

Bon WE à toutes et à tous !