Fix SetLedRaw overflow bug

[beserge]

off = rawbrightness + on
on = startcycle = ledindex << 2. With lots of drivers ledindex can get quite large, so eventually off = (rawbrightness + on ) > 4095.

There's an if which sets the fullbrightness flag which I changed to rawbrightness + on > 4095 rather than rawbrightness > 4095

fixes #329

[github-actions[bot]]

Unit Test Results

    1 files  ±  0    16 suites  +3   0s :stopwatch: ±0s 145 tests +20  145 :heavy_check_mark: +20  0 :zzz: ±0  0 :x: ±0 

Results for commit effaff7d. ± Comparison against base commit 2333ad2d.

:recycle: This comment has been updated with latest results.

[beserge]

OK I've got the fix in as described earlier. For now I'm keeping track of updates on a per buffer basis rather than per led, which allows us to keep utilizing the DMA to its full extent.

There is a slightly noticeable blink when you push the led over the edge into the next frame, but I believe it's a function of the previously mentioned hardware aspect rather than the software.

[stephenhensley]

Nice! So this seems to fix that issue.

However, I am seeing something a bit funky, that is definitely more noticeable/distracting.

I'm using the Daisy Field - Keyboard Test example to verify this btw (in case that makes comparison easier).

So the new issue:

LEDs that are fully bright, flicker upon any changes being written to other LEDs. (e.g. using the field knobs to set LEDs 1,3,5 to fully bright, and then rotating any of the other knobs. You'll see only those three knobs flicker while rotating the knob).

---

Since it seems the issue is writing the full-on bit, mid-cycle causes the LED to temporarily not have the maximum brightness, A solution that could work, but seems like a bit more internal work than I'd like to imagine is necessary. Is to manage the full-bright LEDs separate from the LEDs that have <100% pulsewidth.

This would make the DMA message longer since we wouldn't be able to use auto-increment anymore, but we'd essentially build a list of address/values, only writing to the ones that had changed.

Alternatively, a much less technically correct, albeit simpler solution would be just limit the maximum brightness to 4095, and not use the 13th bit special 100% feature.

For LEDs this wouldn't really be an issue, but if/when this driver is used for servos, or other specific PWM use cases a true 0-100% may be required.