Removing the bool saves on code size and makes the function a tiny bit faster. Also this is a cleaner solution IMHO.
-updated blend function to optimized 8bit calculation
- efficient color blend calculation in fews operations possible
- omitting min / max checks makes it faster on average
- using 8bit for "blend" variable does not significantly influence the resulting color, just transition points are slightly shifted but yield very good results (and better than the original 16bit version using the old fastled math with improper rounding)
- updated drawCircle and drawLine to use 8bit directly instead of 16bit with a shift
progress() is called in setPixelColor(), calculating the transition progress for each pixel. Replaced that call with an inline function to get the new segment variable.
The progress is updated in service() when handleTransition() is called.
The new variable is in a spot where padding is added, so this should not use more RAM.
Result: over 10% increase in FPS on 16x16 matrix
* removed IRAM_ATTR: `updateTransitionProgress()` is called only once per frame, no need to put it in RAM.
* changed transitionprogress to static, private variable, this is now more aligned with other variables using the same logic
* added inline: the function is only used in one place
Processing of received button command is no longer processed in the callback, instead the value is saved to a variable and processed in the main loop.
The actual fix is to not access the file system while data is being sent out: even just trying to open a non-existing file causes glitches on the C3. Waiting for the bus to finish fixes this BUT it causes a frame-delay which is the lesser evil than random color flashes.
- previous fix worked but there was still an overflow after some time passed. there were still missing roll-overs apparently: reverting these two variables back to 16bit/8bit should fix it for good.
When adding a new bus, the numeric current limit field was not being
initialized; this was causing it to save 0 when saved instead of the
default 55mA value.
- sin/cos calls with incrementing numbers can lead to bad outcomes, the functions (_approx or original sinf/cosf) return bad values for very large float inputs
- code is a bit cleaner and faster as well
- chaning array access to pointer access in bus_manager makes it a few instructions faster
- changed getNumberOfPins and getNumberOfChannels to return 32bit values, saving the unnecessary 8bit conversion
