* protect pixel buffer changes with critical section
* protect segment list modification with critical section
* make _isServicing and _triggered atomic (move out of packed bitarray)
* allow custom timeout for waitUntilIdle - DDP needs a longer timeout
* protect strip.show() and effect drawing functions with mutex, to prevent crashes
Seems like a 10 microsecond delay on boards like the ESP32-P4 may not be enough, causing some issues with UDP audio sync being delayed or appearing "buffered". Oddly 10 microseconds was fine with the ESP32 and ESP32-S3, so it may also be an underlying IDF v5.3 change.
Practically, 10 microseconds or 100 microseconds isn't a real difference when we're dealing in frames per second.
This disables bus caching (and related speedups) while receiving realtime UDP pixels.
Its still totally unclear to me what happens, and why disabling the cache solves problems.
I've found a code spellchecker, so this is what can be corrected easily. Changes are only affecting comments, readme and a few user-visible strings. So no functional impact expected.
* it seems that `WiFiUDP.flsuh()` does something completely different from 8266, and its actually causing WLED to stall on UI calls. So not usable on 8266.
* fixing a few compiler warnings about "comparing signed and unsigned"
NB: its a hotfix, we have to check if there are other problems on 8266. Also its definitely ugly, but it helps as a band aid.
* getpixelcolor: attribute pure - it reads memory, but does not write
* some optimizations for SEGMENT.blur() and SEGMENT.fadeToBlackBy()
* FX.c:pp remove double calls to blur() and fade_out()
* FX.cpp: SEGMENT.setUpLeds() added to effects, to enable LED buffering (safe some time because getPixelColor does not need to access NeopixelBus)
* a few other optimizations to safe time and avoid "expensive" operations
* set I2C bus speed to 400kHz (default is 100Khz)
* a few other small optimizations and tweaks
* pio: esp32 V4 builds use "patch5" toolchain version, which contains a few bugfixes especially for memory management.
art-net transmit was not sending out LEDs, but only transmitted headers repeatedly (thanks @troyhacks for noticing).
Actually such problems can be found by newer compilers, so i've added the warning option to [esp32_idf_V4].
wled00/udp.cpp: In function 'uint8_t realtimeBroadcast(uint8_t, IPAddress, uint16_t, uint8_t*, uint8_t, bool)':
wled00/udp.cpp:824:40: warning: declaration of 'byte buffer [12]' shadows a parameter [-Wshadow=compatible-local]
byte buffer[ART_NET_HEADER_SIZE];
^
wled00/udp.cpp:720:85: note: shadowed declaration is here
uint8_t realtimeBroadcast(uint8_t type, IPAddress client, uint16_t length, uint8_t *buffer, uint8_t bri, bool isRGBW) {
Like DDP, this allows WLED to address network systems using the Art-Net protocol.
Universe starts at zero, because that's the first universe in Art-Net.
Works with RGB. It's coded to also work with RGBW, but I couldn't find a great place to enable it without mucking with things I don't understand.
Some additions:
pio.ini: add debug entries
cfg.cpp, set.cpp, xml/cpp: keep storing basic 2D setup
index.js: use ledmapFileNames
settings_2D.htm: keep using basic and advanced
FX_2Dfcn.cpp: use gaptable and also MM ledmaps
FX_fcn.cpp: extend enumerateledmaps with AC ledmapNames (but not used in UI)
* Release of WLED v0.13.3
* Fixed a type in the file name (#2781)
* Fixed the dependency (#2782)
* Usermod Wordclock update to use an alternatve wiring pattern (#2757)
* Update
* update readme file
* readme update
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update platformio.ini
* Add number of UDP retries
Add a configurable number of retries to the UDP WLED sync function.
* Add migration from old eeprom settings
* Revert some accidental carry overs
* Correct issues found in pull request
Change default number of retries
Fix migration from old settings
* Make the minimum number of retries 0
* Import notify twice setting
Co-authored-by: cschwinne <dev.aircoookie@gmail.com>
Co-authored-by: Soren Singh Dary <67230851+sorensd@users.noreply.github.com>
Co-authored-by: Patrick <40436536+paeppi88@users.noreply.github.com>
