show HUB75 and DMX pins in usermods pin dropdown, and fix a bug related to busses without pins.
Previously the pins allocated to HUB75 and DMX were wrongly listed as available 🟢.
* use native 32bit types (similar to upstream)
* avoids gaps on left/right side of strip, by using higher accuracy for zoneLength
* prevent overflow on "s"
* fix wrongly named slider in "spots fade"
The function uses a UDP buffer of ~1200 bytes on stack, which is only needed when actually sending out notifications.
-> separate activation checks and actual sending into two functions, to reduce stack pressure.
* reduce JSON buffer from 1024 to 640
* ESP32: define buffer globally (reduces likelyhood of crashes due to low stack)
* added some sanity checks after string ops
* delete hueClient object after closing the connection
* make functions static if not used outside of hue.cpp, re-shuffle order where needed
* rename JSON buffer object: root -> jsonHUEroot
hotfix for DMX-serial output (prevents random crashes caused by array bounds violations)
* Align ESPDMX and SparkFunDMX with upstream code
* Prevent driver compilation when WLED_ENABLE_DMX is not set (saves ~1KB RAM)
* Protect against writing outside of array bounds
* Align start byte handling between ESPDMX and SparkFunDMX driver.
If Channel is less than 0, it's clamped to 0 on line 134. Then on line 138, dmxData[0] is written with the value, overwriting the start byte that was just set on line 137. DMX Channel numbers should be 1-based (1-512). The bounds check should clamp Channel to a minimum of 1, not 0, to prevent corrupting the start byte
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* added bitwise operation based sqrt16
- replacement for fastled, it is about 10% slower for numbers smaller 128 but faster for larger numbers. speed difference is irrelevant to WLED but it saves some flash.
* updated to 32bit, improved for typical WLED use
- making it 32bits allows for larger numbers
- added another initial condition check for medium sized numbers
- increased the "small number" optimization to larger numbers: the function is currently only used to calculate sqrt(x^2+y^2) which even for small segments is larger than the initially used 64, so optimizing for 1024 makes more sense, although the value is arbitrarily chosen
