Bonjour à tous,
Afin de piloter une bande de LEDs WS2812B avec un Arduino Nano, j'initialise une bande de LEDs RGB avec un tableau de couleurs.
Sachant que mon mètre de LEDs comporte 144 leds, j'arrive à saturer la mémoire du Nano très rapidement, avec 7/8 tableaux pré-initialisés.. car limité à 32k
Mon idée étant d'extraire X colonnes de couleurs provenant d'une image de 144 pixels de haut, et là la gestion de la mémoire sera primordial car je veux pouvoir afficher minimum 150 colonnes à 600 maximum à la suite.
Faut-il stocker ces valeurs en dur via PROGMEM ? stocker l'image sur une SDcard et la lire à la volée?
Mes initialisations sont actuellement telles que ci-dessous
FastLED.clear();
leds[0]=CRGB(0,0,0);
leds[1]=CRGB(0,2,0);
leds[2]=CRGB(0,4,0);
...
Une contrainte : l'affichage doit être relativement rapide!
Merci pour vos retours/conseils et votre aide car il y a surement d'autres techniques ou améliorations à apporter.
Tu veux mettre 600 colonnes de 144 LEDs ? à 60mA par LED, il te faudra une centrale nucléaire pour alimenter tout ça : 5184 A !!! à 5V ça fait 26kW...
lesept:
Tu veux mettre 600 colonnes de 144 LEDs ? à 60mA par LED, il te faudra une centrale nucléaire pour alimenter tout ça : 5184 A !!! à 5V ça fait 26kW...
Non, 1 unique bande LED mais 600 allumages séquentiels différents.
Tu veux profiter de la persistance rétinienne et déplacer la bande rapidement pour créer l'image ? De ce genre là :
Je pense que tu aurais intérêt à lire chaque ligne depuis une carte SD, car 600 * 144 bytes = 86 ko, ça
risque de saturer. Ou alors il te faudra un ESP8266 qui dispose de 96 ko de data RAM.
@lesept : c'est exactement ça, photographie en pause longue d'une bande de LEDs en mouvement
Par compte l'ESP8266 nécessite alors un server pour la fourniture des données (téléphone portable?)
@pepe : la compression, éventuellement mais je ne sais pas comment le faire actuellement. L'affichage devant être rapide 10-20ms entre chaque réaffichage de la nouvelle rangée.
Non, l'ESP8266 a la capacité de se connecter en Wifi, mais tu peux l'utiliser comme un Arduino normal. Il a juste plus de mémoire.
pepe:
Tout d'abord, si l'image peut être compressée de façon simple (répétitions, nombre de couleurs réduit), alors il serait peut-être possible de réduire la quantité de mémoire nécessaire.
Je pense que pepe fait allusion à la compression de type Run-length encoding (wikipedia) :
Le système s'applique essentiellement à des documents scannés en noir et blanc :
au lieu de coder un bit par point, on dispose d'un compteur — en général sur un octet —
indiquant combien de points blancs ou noirs se suivent. Comme il est fréquent d'avoir au
moins 8 pixels noirs ou 8 pixels blancs de suite, et que 256 ne sont pas rares sur les endroits
vierges ou les à-plats noirs, le système a bien pour effet une compression. S'il y a plus de 256
bits de la même couleur, on peut placer ensuite un octet spécifiant 0 bit de la couleur opposée,
puis coder le nombre de bits qui restent.
Par exemple, considérons un écran de texte noir sur fond blanc. Il sera constitué de longues séquences
de pixels blancs pour le fond, et de courtes séquences de pixels noirs pour le texte. Représentons une
ligne d'un tel écran, avec B (comme black) pour les pixels noirs et W (comme white) pour les pixels
blancs :
WWWWWWWWWWWWBWWWWWWWWWWWWWWBBBWWWWWWWWWWWWWWWWWWWWWWWBWWWWWWWWWWW
Un encodage Run Length Encoding consiste à indiquer pour chaque suite de pixels d'une même couleur
le nombre de pixels de cette séquence. Le résultat comporte en général moins de caractères, bien que
ça ne soit pas une obligation. On obtient, par exemple, pour la ligne précédente :
12W1B14W3B23W1B11W
