ARDUINO Цветомузыка на MSGEQ7 и на фильтрах

ЦМУ на MSGEQ7. Также сюда добавляю второй проект ЦМУ на фильтрах.
ссылка на плату и схему https://oshwlab.com/technotrasher/colormusic
За год была проведена большая работа.
Итак ЦМУ на MSGEQ7.
1. Двухканальная схема. стерео.
2. Ручная регулировка шумов. предустановки шумов.
3. 7 режимов цму. в которых есть под-режимы.
4. 10 вариантов световых эффектов.
5. регулировки эффектов и режимов.
6. за "спектр" отвечают микросхемы MSGEQ7. достать рабочие сложно. (Купить более менее рабочие MSGEQ7 - по поиску на алиэкспресс "Модуль анализатора звука Aispark")
7. Аудио компрессор и система контроля клипинга взята тут - kompressor_SSM2167. прочтите обязательно, кто будет собирать.
8. описание режимов в начале скетча.
9. работа возможна с 300 светодиодами!
10. регулировка параметров с пульта и возможность сброса настроек "когда, что то нажал и все поломалось"
11. режим тишины с подсветкой (можно отключить), время срабатывания так же выставляется в скетче.
12 . Использованы статьи. тут для понимания работы MSGEQ7.
13. работа от микрофона. включается с пульта! на плате есть возможность отрегулировать чувствительность и время срабатывания микрофона.
14. режимы работы отображаются светодиодами на плате. на плате возможно механическое отсоединение сигнала с микрофона либо "байпас"
компрессора.
15. регулировка уровня входного сигнала линейным стерео потенциометром.
17. кнопки с платы убраны все, кроме переключения из ждущего режима. нужно для аварийного режима. если перестал работать пульт, а нужно включить хоть что то.
никаких энкодеров и т.д. скетч в первую очередь адаптировался под большую ленту. была битва за каждый байт и даже бит. и дорабатываться будет дальше.
18. Параметры сохраняются в память при отключении ЦМУ. в том числе режимы, шумы, настройки для режимов.
19. питание ленты обособлено от питания ардуино. вы не "сожжете" ардуино, забыв подключить внешний БП и программируя её через USB.
20.

Если вы нашли ошибку или знаете, как что то доработать - напишите об этом.

Особая благодарность Евгению (Slenk) - он находил на меня пару минут на ответ и подсказку. я же подглядывал в его скетч и брал самое лучшее.
так же благодарность - Sergo_ST без его подсказок и терпеливых ответов на мои глупые вопросы скетч был бы намного "толще и тупее". и не факт, что работал бы.


Этап второй ЦМУ на фильтрах. проект делается совместно с poty
проект сложен для сборки.
что сделано - плата. бетта версия. постоянно вносятся изменения. часть отлажена и уже работает.
модуль сбора данных. частично отлажен. работа продолжается.
ЦМУ на фильтрах можно повторять. работает! плату можно заказывать. недавно были изменены некоторые номиналы конденсаторов в фильтрах.
плата доступна тут .
скетч colorMusic_v8_filter.rar
эффектов очень много. все описано вначале скетча. могу сказать, что есть эффекты от Лумазоид ЦМУ.

 

[bort707]

там есть строчка FastLED.setBrightness(50);
если убрать эту строчку то - тоже только красный и зеленый!!!! по всей ленте. если поставить больше 50-60 то тоже только красный и зеленый!!!!!!!
но ведь - CHSV((rainbow_steps + i) * RAINBOW_PERIOD, 255, 255) - тут же переопределяется!!!!

@technotrasher, исходники Фастлед свободно лежат на гитхабе, текст не засекречен, что мешает посмотреть, как работает эта функция? Чтото мне помнится, что как раз настройки отдельных пикселей яркость не переопределяют. Но могу и ошибаться.

Не работайте с библиотекой как с черным ящиком. Привыкайте смотреть в код, это лучше любой документации

 

[poty]

@technotrasher, давно разбирался, возможно ошибаюсь, но в FastLED имеется несколько уровней контроля цвета, в частности, brightness, color correction и ограничение тока - это глобальные параметры экземпляра класса, то есть, если в CRGB хранится некоторое значение цвета, то выводится это будет после применения суммарного коэффициента, рассчитанного из некоторых общих для всех ячеек параметров.
@VictorArx, не очень понимаю о каких двух каналах идёт речь?

 

[kostyamat]

@technotrasher для начала работы с FastLED наверное стоит полистать вот эти примеры https://github.com/marmilicious/FastLED_examples
Почитать ВиКи https://github.com/FastLED/FastLED/wiki/Controlling-leds#wiki-pages-box
FastLED нахрапом не возьмёшь, это не просто библиотека, а целая экосистема. Там не только вывод на ленту, а и таймеры, и математические функции, и много всего другого.

Хотел было писать развернутый ответ по радуге, но нашел отличное объяснение (извинити за английский) https://forum.makerforums.info/t/fi...-parameter-of-the-fill-rainbow-function/63840
Имхо, там очень доходчиво.

 

[kDn]

@technotrasher,
Что касается fastled, то ее основал вполне разбирающийся человек, но он умер и сейчас проект тоже в виде зомби существует, на поддержке других контрибьюторов. Следовательно вам нужно принять некоторые меры чтобы код не работал странно.
1. Яркость не должна дергаться постоянно, т.е. FastLED.setBrightness(50); выставляется однократно, дальше не трогайте
2. Метод show() не должен дергаться постоянно, в идеале его вызывать по таймеру, в главном цикле, т.е. допустим каждые 1/50 секунды, получив при этом 50 кадров в секунду. Вызов должен быть один, т.е. единая точка отображения кадра. Если этого не сделать, то могут быть либо мерцания, либо другие загадочные эффекты с яркостью.
3. Следует учитывать, что и выставление яркости и ограничение по току работают совместно. Ограничение по току не позволит поднять яркость выше какого-то лимита, к примеру, если вы выставите 1А ограничение по току, то яркость можно будет менять в пределах от 0...90 (верхнее значение с потолка, для понимания идеи), а дальше от 90+ до 255 она уже не будет меняться, а будет зафиксирована ограничением тока. Также следует учитывать, что коррекция гаммы влияет на то, как отображаются цвета на минимальной глобальной яркости (0...10), либо когда составляющая V в CHSV низкая при высокой глобальной, либо когда составляющие CRGB малых значений по всем цветовым каналам... Суть влияния - неравномерность зажигания отдельных каналов цвета, если выбрана неверная коррекция. Объясение: допустим красный будет загораться начиная с 1, синий начиная с 10, а зеленый начиная с 3, тогда выставив белый (все каналы включены) но на 1 глобальной яркости вы увидите лишь красный, остальных цветов просто не будет, начиная с 3 у вас уже бдет подмешан зеленый к красному, но красный будет на уровне 3, а зеленый на минимальном уровне, и лишь начиная с 10 у вас уже будет все 3 составляющие, но синий на минимальном уровне - итоговый цвет будет отдаленно напоминать белый, скорее оранжевый, даже ближе к красному. Ну и только на относительно больших яркостях эти расхождения нивелируются и где-то на 50 яркости вы увидите относительно белый цвет, хотя в реальности это будет 50, 47, 40 по каналам.

* К примерам в вики и документации по фастлед нужно относиться критически, т.к. их писали не те же люди, которые создавали библиотеку))). По крайней мере недавний пример с бегущей точкой явно написан рукожопами (лень искать тему) и так делать не нужно.

Исходя из того, что я написал выше, ваш код можно изменить так:

#define NUM_LEDS 180
#include "FastLED.h"
#define LED_PIN 12
CRGB leds[NUM_LEDS];
byte rainbow_steps;
byte RAINBOW_PERIOD = 4;
void setup() {
  FastLED.addLeds<WS2812B, LED_PIN, GRB>(leds, NUM_LEDS); //.setCorrection(0xFFB0D0); // она вам нужна???
  FastLED.setBrightness(50); // ок, ограничили глобальную яркость в 50
}
void loop() {
  EVERY_N_MILLIS(30){
    rainbow_steps -= 1;        // counter меняется от 0 до 255 (тип данных byte)
  }
  for (int i = 0; i < NUM_LEDS; i++ ) {         // от 0 до первой трети
    leds[i] = CHSV((rainbow_steps + i) * RAINBOW_PERIOD, 255, 255);  // HSV. Увеличивать HUE (цвет)// умножение i уменьшает шаг радуги
  }
EVERY_N_MILLIS(20){
  FastLED.show();
}
}

* Писал с головы, без проверки, могут быть мелкие неточности.

 

[kostyamat]

2. Метод show() не должен дергаться постоянно, в идеале его вызывать по таймеру, в главном цикле, т.е. допустим каждые 1/50 секунды, получив при этом 50 кадров в секунду. Вызов должен быть один, т.е. единая точка отображения кадра. Если этого не сделать, то могут быть либо мерцания, либо другие загадочные эффекты с яркостью.

Не совсем так. Каждый луп дергать show() чревато тем что вы описали, это гарантировано, тут полностью согласен. Но и фикс.частота вывода тоже не панацея, и тоже будет создавать артефакти, теряя вывод промежуточных кадров, которые были обсчитаны, но не выведены из за того, что еще не выстрелил таймер для show().
На много правильнее когда каждый эффект выделен в отдельную процедуру, каждая из которых возвращает bool. True - если производился обсчет кадра и производилась запись новых даннных в массив leds, и false - если нет. В таком случае и дергать ленту и контроллер лишним выводом не будем, и кадры терять.

Как пример (из примера выше, поэтому тоже могут быть неточности, воспринимайте как псевдокод):

#define NUM_LEDS 180
#include "FastLED.h"
#define LED_PIN 12
CRGB leds[NUM_LEDS];
byte rainbow_steps;
byte RAINBOW_PERIOD = 4;
void setup() {
  FastLED.addLeds<WS2812B, LED_PIN, GRB>(leds, NUM_LEDS); //.setCorrection(0xFFB0D0); // она вам нужна???
  FastLED.setBrightness(50); // ок, ограничили глобальную яркость в 50
}

bool rainbow(){
    EVERY_N_MILLIS(30){
        rainbow_steps -= 1;        // counter меняется от 0 до 255 (тип данных byte)
   
        // блок ниже тоже лучше перенести сюда, в EVERY_N...,
        // если rainbow_steps не менялся, нет смысла перенабивать массив leds
        for (int i = 0; i < NUM_LEDS; i++ ) {         // от 0 до первой трети
            leds[i] = CHSV((rainbow_steps + i) * RAINBOW_PERIOD, 255, 255);  // HSV. Увеличивать HUE (цвет)// умножение i уменьшает шаг радуги
        }
        return true;
    }
    return false;
}


void loop() {
    bool toShow = false;
    switch (eff) { // тут переключаем эффекты
        case ...
        //....
        case 3:
            toShow = rainbow(); // отрабатывает функция расчета эффекта
            break;
        case...
    }

    if (toShow) {         // выводим на ленту только если функция эффекта действительно что-то обновила в массиве leds.
// FastLED.setBrightness(newBri); // тут же можна и яркость новую установить, она будет применена к буферу перед выводом на ленту
        FastLED.show();
    }
}

 

[kDn]

Но и фикс.частота вывода тоже не панацея, и тоже будет создавать артефакти, теряя вывод промежуточных кадров, которые были обсчитаны, но не выведены из за того, что еще не выстрелил таймер для show().

1. Для кода выше цвет будет смещаться каждые 30мс, а вывод кадра каждые 20мс. Объясните условия при которых будет потеря кадра.
2. Даже если допустить, что появилось желание снизить частоту вывода кадров до 25к/с, и то, что в этом случае уже будет 30мс на 40мс, и в 25% случаев будет выпадание кадра, то в случае радуги и смещения цвета на 1 единицу, вы способны будете на глаз без приборов найти эту разницу? Т.е. разницу между HUE = 100 и HUE = 101 или HUE = 102 к примеру? ))) Или вы будете записывать видео и на скорости .25 от номинальной пытаться это вычислить, как в случаях снежинок))).
3. Ну и то что вы описываете элементы механизма работы эффект-процессора в прошивке лампы это замечательно, но на самом деле там все несколько сложнее сделано, т.к. есть еще статический и динамические буферы, их синхронизация, слои вывода и управление самим эффект процессором, с учетом фейдеров. Я не вижу смысла расписывать весь механизм обсчета, вывода поскольку для данной задачи это во-первых избыточно, во-вторых не особо относится к делу и является оверкиллом для задачи. Так-то код открыт и желающие могут поглядеть в нашей прошивке как все организовано, только я сомневаюсь, что такие герои найдутся.

Мое мнение пока что прежнее - причина странного поведения - это коррекция гаммы + какой-то баг задания яркости + слишком частое дергание show(), его однозначно нельзя дергать чаще 1мс, но в идеале ставить 16-20мс.

 

[bort707]

ребята, вы оба правы, метод show должен дергаться по факту обновления картинки (@kostyamat), но не чаще чем раз в nn мс (@kDn)

 

[kostyamat]

@kDn,
1-2) вы описали частный случай, в котором выпадений кадров видимо не будет, или будут малозаметны. Тут не спорю совершенно.
Я же описываю общий концепт, который гарантирует корректный вывод всех кадров при любых условиях, с любым периодом таймера эффекта, без надмерного дергания show(), и сопутствующих этому рисков.

3) Я не описываю механизм эффект-процессора в прошивке нашел лампы. Предложенный мной механизм применяется во множестве проектов, и хорошо себя зарекомендовал, очень задолго до того, как родилась лампа. Да и в лампе этот механизм несколько другой, и по факту сейчас применяется в паре-тройке эффектов, после перехода на реалтайм и субпиксель. В риалтайме функция эффекта всегда что-то считает и меняет буфер. Поэтому show() отрабатывает после каждой итерации, и выпадений кадров не происходит.
*** По ходу это я не вас все пишу, вы это лучше всех сами знаете. Я для людей читающих все это.

 

[kDn]

Я же описываю общий концепт, который гарантирует корректный вывод всех кадров при любых условиях, с любым периодом таймера эффекта, без надмерного дергания show(), и сопутствующих этому рисков.

Вы описываете неправильный концепт. Вывод кадров фиксируется, если вы не фиксируете вывод кадров, то попросту не сможете синхронизировать множество параллельных процессов и будет нечто а-ля реализация Гуннер-подобных методов, где все работает через жопу. Попробуйте понять, что у вас кадр может обсчитываться 100 раз в секунду, 50 раз в секунду, 20 раз в секунду, что параллельно на других слоях могут работать фейдеры, вывод текста (а у него своя задержка на отрисовку и смещения), да и вообще потенциально идеалогически возможен параллельный вывод нескольких эффектов на разных слоях - каждый со своим кол-вом кадров.

*** По ходу это я не вас все пишу, вы это лучше всех сами знаете. Я для людей читающих все это.

Конечно не для меня, но вот вам бы следовало самому разобраться как все работает и почему я с самого начала фиксировал вывод кадра и почему призывал и призываю всех делать именно таким образом. Да, т.к. речь сейчас идет о микроконтроллерах и в случае эффектов с кучей тригонометрии получить ожидаемый ФПС в 50к/с не всегда удается, т.к. расчет кадра не прерывается и эффект-процессору приходится ждать, но в то же время для быстрых эффектов нет никакого смысла выводить кадр 100 раз в секунду, даже если подобный расчёт сделан, у вас глаз не способен различить информацию с такой частотой, а вот избыточно нагружать контроллер выводом, особенно если нет DMA - явно не стоит. Более того - подобная концепция применяется повсеместно, у вас нет мониторов с плавающей частотой вывода, у вас есть фиксированные частоты передачи интерфейсов, у вас везде тактирование с заданными интервалами... Это не потому, что невозможно сделать "плавающие" тайминги, а потому что делая их - стреляем себе в ногу. Впрочем это уже объяснялось, в том числе и вам. Если по прошествии кучи времени вы так этого и не поняли - ну пичалька, чо... бывает.

Да и в лампе этот механизм несколько другой, и по факту сейчас применяется в паре-тройке эффектов, после перехода на реалтайм и субпиксель.

Вот и разберитесь какой механизм и как работает. Давно пора.

 

[kostyamat]

@kDn, какое отношение все это, описанное вами в первом блоке после цитирования, относится к данному проекту? Не нада проэцировать один проект на другой. Вот совершенно не надо. Тут концепта, придуманного давно умными людьми, и предложенного мной - с головой, и гарантией.

По второму блоку - я то разобрался как лампа вывод делает, и не надо чушь нести. Если бы не разобрался, то не смог бы эффекты под нее писать/переносить/переписывать на субпиксель и реалтайм.

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

 

[kDn]

@kostyamat, вы даёте вредные и плохие советы, почему вредные и плохие я объяснил, также указал на ошибочные утверждения о выпадении кадров, описал случаи даже если его добиться в рамках данной радуги и на что это скажется. Если мои объяснения все ещё не понятны - ваши проблемы, будете все также вставлять костылики с разного рода задержками, как это делали уже неоднократно. Вам я больше ничего объяснять не собираюсь, можете успокоиться, бессмысленность этого уже осознал давно.

Кратко - отсутствие фиксации макс. ФПС плохо и неоправданно практически никогда. Следствие -

if (toShow) { // выводим на ленту только если функция эффекта действительно что-то обновила в массиве leds. // FastLED.setBrightness(newBri); // тут же можна и яркость новую установить, она будет применена к буферу перед выводом на ленту FastLED.show(); }

Код плох, комментарий в коде плох и глуп. На этом все.

 

[kostyamat]

Код плох, комментарий в коде плох и глуп. На этом все.

Ага...

void loop() {
  EVERY_N_MILLIS(30){
    rainbow_steps -= 1;        // counter меняется от 0 до 255 (тип данных byte)
  }
  for (int i = 0; i < NUM_LEDS; i++ ) {         // от 0 до первой трети
    leds[i] = CHSV((rainbow_steps + i) * RAINBOW_PERIOD, 255, 255);  // HSV. Увеличивать HUE (цвет)// умножение i уменьшает шаг радуги
  }

вот пример плохого кода, - переменная меняется по таймеру, но буфер перенабиваем каждый луп, совершенно бессмысленно. (Ваше)
А если изменить таймер к примеру на 35, или другое произвольное значение, то начнем весело терять кадры, на фиксорованой вами частоте show(). Это да это "гениальное" решение конечно.

 

[technotrasher]

с фастлед не уйти. пробовали уже. поэтому в нем разбираться. да. это целая экосистема. очень мало примеров с пояснениями. на форуме по нему иногда бывают очень хорошие пояснения. не я один страдаю. да. в с++ я еще только полгода разбираюсь...

 

[bort707]

с фастлед не уйти. пробовали уже. поэтому в нем разбираться. да. это целая экосистема. очень мало примеров с пояснениями.

Не переживайте, на уровне обычного зажигания пикселей в фастледе никакая "экосистема" не требуется и он не сложнее неопикселя. Многие функции работают и даже называются так же. Библиотека довольно логично построена и понятна без документации.

"Экосистема" там появляется совсем на ином уровне. Если вы вдруг захотите добавить в либу новый тип диодов или другой микроконтроллер - то чтобы сделать это логически правильно, не нарушив структуру библиотеки - вот тут эту всю "экосистему" придется изучить по полной программе. Но это требуется. наверно. не более чем одному проценту пользователей.

 

[technotrasher]

Хотел было писать развернутый ответ по радуге, но нашел отличное объяснение (извинити за английский) https://forum.makerforums.info/t/fi...-parameter-of-the-fill-rainbow-function/63840
Имхо, там очень доходчиво.

я это именно и читал!!!!!

Не переживайте, на уровне обычного зажигания пикселей в фастледе никакая "экосистема" не требуется и он не сложнее неопикселя. Многие функции работают и даже называются так же. Библиотека довольно логично построена и понятна без документации.

"Экосистема" там появляется совсем на ином уровне. Если вы вдруг захотите добавить в либу новый тип диодов или другой микроконтроллер - то чтобы сделать это логически правильно, не нарушив структуру библиотеки - вот тут эту всю "экосистему" придется изучить по полной программе. Но это требуется. наверно. не более чем одному проценту пользователей.

в неопиксель не удалось перенести работу с палитрами. в фастлед она проще организованна.

 

[kostyamat]

@technotrasher, ну так какие у вас тогда сложности?

    case 6: {
        switch (light_mode) {
          case 0: one_color_all(LIGHT_COLOR, LIGHT_SAT, 255); break;
          case 1:
            if (timer_func(RUNNING_SPEED)) {
              this_color -= 1;
              //rainbow_steps -= 1; // rainbow_steps++ counter меняется от 0 до 255 (тип данных byte)
            }
            fill_rainbow( leds, 50, this_color, RAINBOW_STEP );   // RAINBOW_STEP 1 - 30

            //for (int i = 0; i < NUM_LEDS; i++ ) {         // от 0 до первой трети
            //leds[i] = CHSV(rainbow_steps + i * RAINBOW_STEP, thissat, 255);  // HSV. Увеличивать HUE (цвет)// умножение i уменьшает шаг радуги
            //}
            break;
        }
      }
      break;

Определите вашу ошибку, на основе той статьи.

Ответ тут https://editor.soulmatelights.com/gallery/1398-test (укажите размер 1хСколько_там)

 

[technotrasher]

эксперимент показал - параметр FastLED.setMaxPowerInVoltsAndMilliamps никак не влияет ни на что. ставил и 1000 и с шагом 1000 до 5000.
например FastLED.setBrightness(100); и FastLED.setMaxPowerInVoltsAndMilliamps(5, 5000) выдает все ту же проблему. БП - 3А. правильный. как для камер видеонаблюдения ставят. в дырчатом таком корпусе. тестирован под нагрузкой. 180 светодиов для него - ничто.
теперь изучаю вариант с частым дерганьем show().

 

[kDn]

FastLED.setMaxPowerInVoltsAndMilliamps никак не влияет ни на что

Вообще-то влияет на максимальную яркость, как я писал выше. До определенного уровня - эффекта на увидите. Ну и смотреть желательно с амперметром на белом цвете. Правда фастлед местами э... несколько глючный и установка лимита тока или яркости могут при определенных обстоятельствах чуток неправильно отрабатывать. Все я уже не вспомню, но в коде лампы есть комментарии вида:

  setcurLimit(curlimit);

  //FastLED.addLeds<WS2812B, LAMP_PIN, COLOR_ORDER>(leds, NUM_LEDS).setCorrection(TypicalLEDStrip);
  //FastLED.addLeds<WS2812B, LAMP_PIN, COLOR_ORDER>(leds, NUM_LEDS).setCorrection(TypicalPixelString);
  FastLED.addLeds<WS2812B, LAMP_PIN, COLOR_ORDER>(getUnsafeLedsArray(), NUM_LEDS);

  brightness(0, false);                          // начинаем с полностью потушеной матрицы 1-й яркости
  if (curlimit > 0){
    FastLED.setMaxPowerInVoltsAndMilliamps(5, curlimit); // установка максимального тока БП
  }
  FastLED.clearData();
  //FastLED.clear();                                            // очистка матрицы
  //FastLED.show(); // для ESP32 вызывает перезагрузку циклическую!!! Убираю, т.к. при 160Мгц вызывает бросок тока и яркости!!! Не включать и оставить как напоминание!

* Хотя не исключаю, что под AVR свое поведение, отличное от ESP, надо будет собраться поцепить кусок ленты и поглядеть.

 

[technotrasher]

вы бы для начала своим видением поделились, а то может эти лажи только в вашем воображении

несколько раз повторялось FastLED.setBrightness. убрал. сделал глобально. установил 60. все заработало. на яркость никак не влияет????? что 60 что 255!!! почему так... или это моё восприятие. могу взять лайт метр...

 

[VictorArx]

Доброе утро всем! Прошу прощения, что вмешиваюсь в ваши умные изречения( С++ только три месяца изучаю, ох сложное это дело). Загружаю ваши коды радуги, компиляция проходит, но в середине проскакивают красные строчки. Это ошибки в написании кода?
PC. Вот вы полуночники, а днём дрыхните.

 

[technotrasher]

Доброе утро всем! Прошу прощения, что вмешиваюсь в ваши умные изречения( С++ только три месяца изучаю, ох сложное это дело). Загружаю ваши коды радуги, компиляция проходит, но в середине проскакивают красные строчки. Это ошибки в написании кода?
PC. Вот вы полуночники, а днём дрыхните.

спать некогда. . не ошибки. предупреждения. с ошибками вообще не пройдет компиляция. у ядра, например Алекса там есть ещё и забавные сообщения при компиляции.

 

[technotrasher]

а откуда такое - EVERY_N_MILLISECONDS, в какой библиотеке?
можно ли его использовать вместо громоздкого if (millis() ......

 

[kostyamat]

@technotrasher, в FastLED, конечно. Там не только таймеры есть.

 

[kDn]

а откуда такое - EVERY_N_MILLISECONDS, в какой библиотеке?
можно ли его использовать вместо громоздкого if (millis() ......

Если используете FastLED то и можно, и нужно. По сути это классы-обертки, их несколько штук с похожими названиями, к примеру EVERY_N_SECONDS еще есть

 

[bort707]

а откуда такое - EVERY_N_MILLISECONDS?
можно ли его использовать вместо громоздкого if (millis() ......

я предпочитаю всегда использовать "громоздкое" if millis().
Да, набирать больше, зато я уверен, что оно сработает так, как я написал.
А вот как будет работать цикл по EVERY_N_MILLISECONDS, если их поместить несколько в одном блоке или вложить один в другой - очень зависит от грамотности автора этой "удобной" конструкции. А в ней, в грамотности, часто есть большие сомнения