RGB LED матрица 64x32

Пришла китайская RGB-матрица

Неплохо, дошла за 15 дней с момента заказа.

Буду вешать в коридоре для всякой инфо при выходе из дома. Погода, напоминалки, предупреждения, что газ не погашен и т.п. Сейчас прицепил для теста через Arduino Mega. На Uno не хватает памяти, на ESP8266 — выводов (нужно 13).

В реальной работе, наверное, подключу к STM32 и буду связь держать через ESP8266.

Коротко впечатления по матрице.

Запитывал от внешнего лабораторного БП. Жрёт в режиме ожидания (все светодиоды чёрные) 70мА. При работе с простым текстом, в среднем, порядка 600мА. Если засвечивать все светодиоды, то потребляет до ~1.7А и перестаёт. Этого тока не хватает и вместо полной яркой белой заливки получается полутонная жёлтая Заявлена пиковая потребность 5В 4А, у меня БП выдаёт 5А при напряжении до 32В, но тут всё почему-то утыкается на ~1.7А. Может, провода питания?

Но при отсутствии полной заливки, с обычным текстом, как писал, ток редко превышает 600мА и почти никогда — 1.2А. Т.е. старого телефонного БП 5В 2А должно хватить.

Очень помогает при начальной то, что матрица принимает почти любые значения, Т.е. не нужна целостность по данным. Не проверял, но полагаю, если на её входы начать гнать белый шум, матрица начнёт им заполняться. Так что то, что она в принципе работает, понял почти сразу

Вот нормально заставить её работать с Arduino Uno так и не смог. Примеры для мелких матриц, типа 32x16 работают, но изображение расползается. 64x32 ни в одном тесте не завелось. Только потом уже прочёл (а сам не догадался, отвык уже от особенностей такой мелочи) 64*32*3 = 6144 байт, так что полноценный RGB-буфер по байту на канал в Arduino Uno с его 2кБ не запихнуть. В то время, как 32*16*3 = 1536 байт, что уже влезает. А без буферизации примеры не заработали. Может, там в самой библиотеке без буфера никак? Не разбирался. Поэтому, как и писал в топикстарте, для теста перешёл на Arduino Mega. Там завелось почти сразу.

Теперь буду пытаться подключить к STM32 Скорее всего, придётся ставить преобразователи уровней. Матрица может не завестись на 3.3В сигналах. Но буду ещё экспериментировать.

Для переписывания Arduino-библиотеки под сабж на STM32 разбираюсь с ней. Открыл совершенно новую для себя вещь

Матрица не имеет встроенного управления яркостью. Фактически она получает в несколько проходов битовые массивы вкл/выкл для каждого светодиода. 2048 светодиодов в 16 блоков, по 128 значений в каждом. Как передаётся конкретное значение — пока не разбирался. Интересное не в этом

Регулировка яркости осуществляется через PWM (ШИМ). Но 2048 светодиодов рулить через ШИМ/PWM — это ж сколько ресурсов нужно!

Так вот, в библиотеке матрицы используют некую модификацию PWM — Binary Code Modulation:

На пальцах всё понятно. Вместо того, чтобы, как в PWM выставлять 1, ждать период скважинности, выставлять 0 и ждать полный период мину период скважинности, мы выставляем значение бинарного бита с выводимого уровня и ждём время, пропорциональное значению этого бита:

Для 4-х битного числа 0b1101 = 0xD = 13 (и, соответственно, скважинность 13/15):

При высокой частоте повторения это ничем для глаза не отличается от PWN с линейной скважинностью, но заявляется, что так нагрузка на процессор не зависит от числа каналов.

То есть, у PWM нагрузка на процессор:

- Не зависит от разрешения
- Зависит от числа каналов

У BCM:

- Не зависит от числа каналов
- Зависит от разрешения

Практика показывает, что Arduino отлично справляется. У матрицы 64x32 и 2048 светодиодов максимальная частота обновления где-то на уровне 100Гц.

Но почему получается независимость от числа каналов я пока не понимаю В моём представлении всё равно задержка на каждый канал же должна рассчитываться индивидуально. Что-то я недопонимаю...

Ещё ссылки по этому методу (на русском — нет)

Разбираюсь с низкоуровневым программированием матрицы. Это жесть!

Логика работы такая.

Матрица фактически разделена на два блока, верхние 16 строк и нижние 16 строк. В первые пишут через R1, G1 и B1, во вторые, соответственно, через R2, G2 и B2.

Одновременно светится только одна строка. Для полноценного свечения нужно просто организовывать развёртку. Фактически памяти там в каждой половине экрана — один сдвиговый регистр + выбор адреса, куда ему светить.

Сигналом LAT (пиком высокого уровня) сигнализируем, чтобы сдвиговый регистр принял строку данных. Дальше в цикле 64 раза выставляем данные (R1,G1,B1,R2,G2,B2) и запихиваем их низким импульсом CLK. Сразу в оба сдвиговых регистра.

Входами A, B, C, D выбираем строку, в которой светится этот сдвиговый регистр. Точнее, будут светиться две строки, в первой и второй половинах.

Для того, чтобы избегать мерцания и призраков, высоким уровнем OE на время манипуляций можно гасить отображение.

Т.е. полный цикл выглядит примерно так:

1.  
2. // Цикл по строкам в каждой половине экрана
3. for(int row=0; row<16; row++)
4. {
5.     // Вырубаем отображение
6.     digitalWrite(OE, HIGH);
7.  
8.     // Указываем принять данные
9.     digitalWrite(LAT, HIGH);
10.     digitalWrite(LAT, LOW);
11.  
12.     // Цикл вывода светодиодов в строке
13.     for(int i=0; i<64; i++)
14.     {
15.         // Выставляем биты включения светодиодов
16.         digitalWrite(R1, r1);
17.         digitalWrite(G1, g1);
18.         digitalWrite(B1, b1);
19.         digitalWrite(R2, r2);
20.         digitalWrite(G2, g2);
21.         digitalWrite(B2, b2);
22.  
23.         // Отправляем выставленное значение
24.         digitalWrite(CLK, LOW);
25.         digitalWrite(CLK, HIGH);
26.     }
27.  
28.     // К этому месту строка светодиодов загружена
29.  
30.     // Выставляем адрес для отображения
31.  
32.     digitalWrite(A, row & B00000001);
33.     digitalWrite(B, row & B00000010);
34.     digitalWrite(C, row & B00000100);
35.     digitalWrite(D, row & B00001000);
36.  
37.     digitalWrite(OE, LOW);
38. }

Правда, в таком виде цикл вывода будет работать ОЧЕНЬ медленно (digitalWrite работает медленно!), экран будет очень тёмный и будет мерцать, т.к. заполнение матрицы будет происходить бОльшую часть времени.

Для ускорения работы нужно делать запись сразу всего блока цветов одной записью в регистр. Например, в случае MEGA вешаем R1,G1,B1,R2,G2,B2 на, соответственно, 24,25,26,27,28 и 29 пин. И тогда это будут биты со 2 по 7 регистра PORTA. А CLK пусть висит на 11 порту, это 5 бит PORTB. Внутренний цикл станет примерно таким:

1.     // Цикл вывода светодиодов в строке
2.     for(int i=0; i<64; i++)
3.     {
4.         // Выставляем биты включения светодиодов (младшие два бита обнуляются)
5.         PORTA = (r1<<2) | (g1 << 3) | (b1 << 4) | (r2 << 5) | (g2 << 6) | (b2 << 7);
6.  
7.         // Отправляем выставленное значение
8.         PORTB &= ~0x20; // pin 11, bit 5
9.         PORTB |= 0x20; // pin 11, bit 5
10.     }

Вот в таком виде оно будет выводиться очень быстро! Хотя яркость будет не максимальной, так как заметную часть времени экран будет погашен через OE. Можно после включения OE добавлять небольшую паузу, тогда мерцания будет чуть больше, но и яркость станет выше. Тут надо будет ещё поэкспериментировать

Например, если потребна максимальная яркость, можно вообще не использовать гашение по OE.

...

Конечно, всё это уже реализовано в готовой библиотеке, но под STM32 её надо радикально переписывать Так что пришлось разобраться, как оно работает.

Возиться с STM32 так руки и не доходят. В результате сегодня плюнул, и спаял шилд к Arduino Mega. В смысле, готовое решение «воткнул и включай». Лучше пока данные на Мегу буду скармливать по NRF24L01 или даже через ESP8266 А потом когда-нибудь, может, и на STM32 сделаю.