Светодиодные матрицы для "чайников" (часть 2)
Ну что, дружище, надеюсь ты освоил первую часть моего лонгрида и уже запилил свою лампу Гайвера с блэкджеком и всем остальным? Тогда вперед, через тернии к звездам, гексагонам, кругам, гирляндам.
Во многих подобных конструкциях раскладка светодиодов не имеет строк и столбцов, а порой она и вовсе хаотичная. Да и и соединены диоды не рядами, а как было удобно для разводки платы.
Возьмем, к примеру, мою новогоднюю звезду . Диоды там уложены концентрическими звездами, да еще и змейкой.
Но отчаиваться не будем, попробуем мыслить логически. У каждого диода на звезде есть реальные координаты центра в миллиметрах, или координаты на картинке в пикселях.
Мы можем создать таблицу соответствия порядкового номера диода и его координат. Изменим наш цикл обхода диодов по координатам на обход по номерам.Перепишем функцию мэппинга так, чтобы она искала координаты по индексу диода в таблице и дело в шляпе.
uint16_t mapTable[][2] = {
{ 206, 340 },
{ 181, 354 },
{ 156, 369 },
{ 132, 383 },
{ 107, 398 },
{ 89, 404 },
{ 89, 385 },
{ 95, 357 },
{ 101, 329 },
{ 107, 301 },
{ 114, 273 },
... // и так далее, для всех 180 диодов
};
struct ledCoords {
uint16_t x;
uint16_t y;
};
ledCoords mapIdxToXY( byte index ) {
return { mapTable[index][0], mapTable[index][1] };
}
void loop() {
for ( byte i = 0; i < NUM_LEDS; i++ ) {
ledCoords lc = mapIdxToXY(i);
leds[i] = effectColorByCoords(lc.x, lc.y);
}
FastLED.show();
}
На практике это оказывается не очень удачным решением. Координаты - штука относительная. У кого-то линейка в дюймах, а у кого-то 4К картинка с четырехзначными координатами. Замучаешься подгонять масштаб анимации под каждое устройство. Чтобы избежать этого выполняют нормализацию координат.
Звучит страшно, но на практике это просто пересчет в некую фиксированную систему координат. Например, давай примем за правило, что минимальная координата по X среди всех диодов это 0 в нашей "нормализованной" системе, а максимальная - 1. И все остальные координаты пересчитаем пропорционально Xn = ( x - Xmin )/(Xmax - Xmin). Аналогично поступим с координатами Y.
Теперь у нас все координаты на любом устройстве лежат в пространстве 0..1
Такой подход используется в программируемых контроллерах Pixelblaze.
Казалось бы, можно закончить занудствовать на этом, но позволь еще немного помучать тебя.
Во-первых все эти дробные координаты для контроллера являются числами с плавающей точкой (float) и он тебе не скажет спасибо за их использование. В отместку контроллер будет тратить кучу времени на расчеты даже простой арифметики, не говоря уж о корнях, степенях и тригонометрии.
Во-вторых, некоторые алгоритмы эффектов требуют расчета по всей площади, а не только в точках расположения диодов. Например операция размытия (blur) требует значения цветов всех соседних точек в пределах радиуса размытия.
Ну и в-третьих, тут уж мое личное мнение, куча дробных чисел в формулах снижает читабельность кода, а отладка такого кода вызывает у меня тихий ужас.
И тут ты подкидываешь наивную идею: "А можно как-то так чтобы координаты остались целыми, но не такими большими и более-менее схожей размерности на разных устройствах?"
Можно!
Потребуется всего лишь привести реальные координаты диодов к прямоугольной матрице низкого разрешения. Представь, что мы взяли листок бумаги в клеточку и положили поверх нашей звезды и пометили клетки в которые попали центры диодов.
Теперь у каждого диода есть простые координаты в координатной системе листочка в клеточку. И эти координаты гораздо более удобоваримые чем реальные. И если мы захотим посчитать наш эффект для каждой клеточки на этом листочке, то даже наш не супер-мощный контроллер это осилит. Попробуем записать результат в таблицу мэппинга.
byte mapTable[][2] = {
{ 12, 18 },
{ 11, 19 },
{ 9, 20 },
{ 7, 21 },
{ 6, 22 },
{ 5, 22 },
{ 5, 21 },
{ 5, 19 },
{ 6, 18 },
{ 6, 16 },
{ 6, 15 },
... // и так далее, для всех 180 диодов
}
Вроде неплохо получается.
А чтобы все алгоритмы были похожи на работу с обычной прямоугольной матрицей,можно развернуть мэппинг. Будем хранить в таблице не координаты, а индексы диодов для каждой ячейки нашей матрицы 27x23
Только как же быть с пустыми клеточками, ведь их нужно как-то пропустить при обработке? Да запиши в них просто какое-то значение индекса которое ты отловишь в цикле и пропустишь обработку. Например любое число большее общего количества диодов. И таблица примет такой вид:
byte mapTableIndex[23][27] = {
{ 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 27,
255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 },
{ 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 26, 255,
28, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 },
{ 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 25, 77,
29, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 },
{ 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 78, 255,
76, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 },
{ 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 24, 255, 255,
255, 30, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 },
{ 255, 255, 255, 255, 255, 255, 255, 255, 255, 23, 255, 79, 117,
75, 255, 31, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 },
... // и еще 17 строк
}
Тогда функция мэппинга и рабочий цикл будут выглядеть как-то так:
byte mapXYtoIdx( byte x, byte y ) {
return mapTableIndex[y][x];
}
void loop() {
for ( byte y = 0; y < 23; y++ ) {
for ( byte x = 0; x < 27; x++ ) {
byte ledIndex = mapXYToIdx(x,y);
if ( ledIndex == 255 ) continue;
leds[ledIndex] = effectColorByCoords(x, y);
}
}
FastLED.show();
}
Конечно, хранить такие большие массивы с таблицами мэппинга в оперативной памяти не стоит, обычно их загоняют во flash используя PROGMEM.
Собираем все полученные знания в кучу и зажигаем)
(Продолжение следует, stay tuned)
