FlProg

Тест-версия 9.7.1.



Работа с адресными светодиодами WS2812.
Можно работать с тысячами СВД, включая и выключая нужные, не нагружая код особо.
Позволяет вывести СВД на лицевую панель по трём проводам. К примеру, есть у вас в работе 20 клапанов, и по старинке на каждом ключе висит СВД, показывающий состояние нагрузки. Чтобы их вынести, понадобится только 20 проводов на управление, а если они ещё RGB, то 60 проводов + минус, а также столько же резисторов. Плюс тут это конкретное состояние ключа, у адресника — виртуальное. Кому что, в общем.

Используется один пин RX.
Код не нагружается особо, работа на аппаратном модуле.

Библиотека с нуля собрана:
+двойной буфер
+3 режима работы
+количество свд до 3000 шт
+яркость всей цепочки
+выбор типа порядка цветов

Двойной буфер — для быстроменяющихся цветов, потребляет в два раза больше памяти, а значит, максимальное количество СВД почти в два раза меньше чем указано ниже.

Режим обновления по таймеру — для любого количества СВД. (до 3000шт свд)
Режим по изменению — тут от загруженности кода. (до 2500шт свд)
Режим по обновлению и по изменению — тут от загруженности кода. (до 2500шт свд)

С вай фай количество берите меньше что бы памяти хватило и вайфаю.

Если только изменение, то состояние выставится, и если питание пропадёт и появится на СВД, то состояние у них будет сброшено, ибо у СВД своя память; то же самое и со статическим блоком.
Режимы с обновлением решают эту проблему.

Работает всё просто: перевёл на массивы, как у своих блоков-расширителей, но для этого пришлось отказаться от привычных RGB-настроек, а использовать конвертер на 24 бита. Для этого создал веб-страницу по работе с цветом. viewtopic.php?f=126&t=9706

Результаты сравнения:
Блоков не нашёл по работе отдельно с SVD.
Взял с гитхаба FastLED и сделал из него аналог моего режима.
Сначала может показаться, что разницы по сути нету, но тут нужно понимать, что FastLED — это программник, а мой профильник — аппаратный.
И в начале, да, разница не особо, потому что я трачу время на запись DMA, а FastLED тратит время протактировать себя.
С виду вроде и 1000 тянет FastLED, но он рвёт луп: на 1000 СВД уходит 35 мс, то есть вай-фай у вас уже сдох на этом этапе, ибо луп ставится на паузу во время тактирования.
Профильник же на это тратит около 2 мс, а сама транзакция не мешает лупу работать. Ну и на 3000 он и вовсе сдох, а профильник потратил лишь 7,3 мс, чтобы заправить DMA.
И т. к. скорость продвижения по ленте не очень высокая, то транзакция длится при 3000 СВД 86,4 мс, не мешая лупу.
Притом у Fast LED это будет длиннее — 95,1 мс, ибо он делает паузы ещё между пачками СВД.
У меня же транзакция пакетирования непрерывная.
И стоит добавить, что это всего лишь обновление каждые 100 мс, а если сделать 50 мс или ниже, то FastLED загнётся ещё намного раньше.
И стоит так же добавить, что это чистовые тесты: только блок и ничего более.
И чем тяжелее код, фастлед так же поплывёт вниз ещё в разы быстрее.
По мне так, под него нужен отдельный МК для больших количеств СВД и только для них ничего туда более не пихать.
Аппаратнику же пофиг на это всё.

Работать с ним легко, как и с прошлыми моими расширителями.
Нажимаем «Создать массив».
Индексы его количество — это количество ваших СВД на линии.
Нажмите «Заполнить», чтобы он инициализировался; можно уже цветами заполнить либо оставить всё нулями (если для статики, то нужно заполнять цветами, ибо это только для сетапа у него). А в динамике уже вытаскиваете блочки массивов и настраиваете.
Там же можно создать новые массивы, там же есть в разделе копирования массивов.
Главное, чтобы памяти хватило.
И вставлять цвета нужно, используя мою интерактивную страницу, ту, что указал выше, — это если нужен градиент, либо ограничиться стандартными цветами: 255 — синий, 65280 — зелёный, 16711680 — красный (теперь они так именуются).

Какой же молодец и умница. Так держать !!!

Для понимания, сколько выделять светодиодов: так как мы кодируем его в 24 бита, но храним в 32 битах, у нас уходит на один светодиод четыре байта. Это только статика. Далее, через динамику, мы его кодируем для нашей периферии — на один светодиод уходит ещё 12 байт. Итого 16 байт на один светодиод, то есть чтобы взять 1000 светодиодов, нужно примерно свободной памяти 16 КБ. Если же сюда добавить двойной буфер, где, пока идёт отправка транзакции кадра, процессор готовит во второй буфер следующий кадр, то это ещё динамической памяти 12 байт на светодиод. Итого 4 байта статики плюс 24 байта динамики, то есть один светодиод уже обойдётся в 28 байт, или же на 1000 светодиодов — примерно 28 КБ. Это только если идёт обновление по времени. Если же включить режим по изменению, то добавится ещё один статический буфер, который равен по количеству основному массиву. То есть получается 8 КБ памяти статики на 1000 светодиодов плюс динамика, если это двойной буфер, то 24 КБ. Итого 32 КБ на 1000 светодиодов при режиме изменения с двойным буфером. Но режим изменения сильно просаживает код, очень сильно, на большом количестве светодиодов, потому что ему нужно в каждом цикле прогнать полностью массив на поиск изменения хотя бы одного светодиода. Поэтому, если очень много светодиодов, то лучше использовать режим обновления по таймеру, если мало светодиодов — там вообще без разницы, по сути. Если контроллер использовать без вай-фая, то там примерно 50 КБ свободной памяти на чистовой код, отсюда следует уже понимание, на что можно будет рассчитывать. Можно, конечно, использовать функцию чтения свободной памяти через UART, но автор сделал маленько неправильный UART. Ну, либо сделал его так, как ему удобнее. Даже если я переназначаю пины под свою периферию, то при активном UARTе автор переназначает пины под себя, и так как мы используем RX, а чтобы прочитать данные через UART, то он там совершенно не нужен, то он все равно болтается в воздухе, и получается, наша транзакция идёт, но она не связана физически уже с пином RX. Если же в не флпрог подключать Serial Port, то данные без проблем выводятся, потому что там нужен только TX. Ну и, как уже говорил ранее, сама концепция протокола адресного светодиода довольно-таки медленная, и, как уже упоминалось, что при трёх тысячах светодиодов транзакция будет идти примерно 90 мс, то, как уже поняли, FPS там будет очень маленький для быстрой анимации. Поэтому толку никакого нету на анимашку городить огромное количество светодиодов, там уже нужно подбирать под 30 FPS либо под 60 FPS для плавности зрения, что уже ограничивает количество светодиодов значительно относительно FPS. Либо использовать медленные анимации.

Также нужно учитывать, что если лента питается 5 В, а уровень сигнала нужен ей для единицы примерно 0,7 x напряжение питания (это где-то около 3.5 В, от разброса характеристик светодиода ещё), то лента, скорее всего, не будет работать, как в моём случае. Тут нужен либо конвертер уровней с ESP на ленту, либо поставить просто диод в питание ленты светодиодной — обычный диод, не Шоттки. 5в всё равно не нужны, она стабится при максимальной яркости, если понижать яркость, то сама себя диммирует.