* new setting in UI page: "Don't use effect palette and segment parameters" - only meaningful when "Use effect default parameters" is enabled, too.
--> effect slider defaults will still be applied, however palette, 1D2D mapping mode and other segment settings will not change.
There were three problems here:
- AsyncWebServer is going to copy to a heap buffer anyways, so we might
as well just pass it one it can use
- The buffer size estimate was wrong -- we need 9 bytes per pixel
("RRGGBB",), so the buffer could overflow, and it was not
considering the extra 2D requirements
- On ESP8266, the stack allocation was overflowing the stack, causing
corruption and crashes.
The NeoPixelBus RMT driver seems to get stalled when ESP.get.... functions are called (big kernel lock?). Also its glitching during flash file access.
This change tries to avoid some conflicts by first checking that the driver is not sending.
Release the json buffer lock as soon as we've finished serializing.
This should slightly reduce the number of lock collisions as the
response class isn't destructed until after the last packet is ack'd.
fix for #90
In principle its dangerous to write pixels from the webserver callback, but in this case we should be save - `suspendStripService=true` ensures that strip.service() is not active in the main loopTask.
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.
Segments are created/deleted on-the-fly; it seems that "local leds" buffers did not follow properly.
* revise segment copy/move constructors
* de-optimize use of local leds (as they need to be re-allocated when segment size changes)
* minor stability improvements
* handling of stop = 0 when calculating sizes (avoid unsigned underflow)
* make sure groupLength() is never zero (to avoid div/0)
* gapmaps: check for "(gapSize > 0)" added.
not sure if all the checks are 100% needed, but they will improve robustness in corner cases.
This disables parts of the new feature that might lead to delays, so basicially there is some detection, but no protection any more.
further development needed --> audio_fastpath branch
compile with -D WLEDMM_PROTECT_SERVICE to enable full protection.
*This patch allows to compile with BOARD_HAS_PSRAM, but not set WLED_USE_PSRAM - reserved pins will be protected, and PSRAM usage will be shown in info.
* if you add `-D WLED_USE_PSRAM_JSON` then PSRAM will be used for some JSON buffers, but not for LEDs and Segments.
the root cause of the crash is not really clear, as the problem seems to occur randomly, mosr frequent with fresh installations.
This workaround prevents the array bounds violation, by re-using the last valid gGradientPalettes entry.
