* separate mutexes for improved performance:
- busses.show and effect drawing
- critical changes to segment vector
- block out critical segment changes while strip.service() loops over segments
* UDP realtime acquires mutex before drawing
- prevents corrupted outputs, caused by parallel tasks updating pixels while busses.show() runs
* 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)
