Test out different LED update timings

[gedankenexperimenter]

The problem

It takes a long time (~825µs) to update a single bank of LEDs. Anytime we update all of them, we get a delay of ~6.6ms before keyswitch data is read again. If an LED mode is sending updates every cycle, that's a pretty big delay (~4-6 times as long as without LED updates).

Possible solution

To minimize that delay, I've got a few ideas.

First, we could spread out the updates, by only updating one bank on each side every time an update is called for. This would add a delay of ~1.6ms each cycle.

Second, instead of a boolean flag to record that an update is needed, store it as a bitfield, so we only update banks that need it, and don't waste time with the others.

Third, don't update LEDs every cycle; 30fps is probably sufficient (this needs testing, though), which means that we can use a timer to determine if it's time to do any updates at all. Probably a boolean and a timer, in fact – when the timer runs out, set the boolean (or the next_led_bank value to 0), and update one bank (each side) per cycle until they're all done, then start checking the timer again.

[gedankenexperimenter]

Alternatively, we could just do an update of a single LED bank (not one on each side) every cycle. If keyswitch handling takes .5ms and LED updating takes .8ms, and every bank always needs an update, that takes ~10.5ms for a full update, which is close to 100fps.

[gedankenexperimenter]

One more thing – I've experimentally determined that it's necessary to either do a i2c read or write in order for the LEDs to update reliably. This shouldn't be a problem when things are running normally, but I don't want to forget.

[gedankenexperimenter]

TODO: measure average cycle times for the "breathe" led mode.

[gedankenexperimenter]

I've got a pretty good idea of how big an interval is okay now. To my eyes, a refresh every 64 ms is just barely noticeable with a slowly-changing effect. I think 32 ms is acceptable, and 16 is definitely small enough.