You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For clarification, this is about the LEDs under the keycaps, not underglow.
At least when breathing to max intensity, the intensity steps of the LEDs become visible, resulting in a not-so-smooth breathing effect.
As I understand, this is related to the breathing_table in quantum.c and possibly(?) to the timer interrupt, which I think would need finer resolution. The code looks pretty complex, which is why I wanted to create this issue before trying anything myself. Maybe @jackhumbert, who seems to be who originally wrote the code, can tell me if there's something more fundamental that would prevent smoother stepping.
Oh and if the code gets looked at anyway, we might want to think about allowing a finer speed setting as well. Right now, +1 in speed results in half the speed. -1 in double the speed.
The text was updated successfully, but these errors were encountered:
Couldn't help but look around before a reply anyway. I may have found an error. In the ATmega32u4 data sheet, section 14.5, last paragraph it says:
The ICRn Register can only be written when using a Waveform Generation mode that utilizes the ICRn Register for defining the counter’s TOP value. In these cases the Waveform Generation mode (WGMn3:0) bits must be set before the TOP value can be written to the ICRn Register.
It looks like this is done in the wrong order in quantum.c.
For clarification, this is about the LEDs under the keycaps, not underglow.
At least when breathing to max intensity, the intensity steps of the LEDs become visible, resulting in a not-so-smooth breathing effect.
As I understand, this is related to the
breathing_table
in quantum.c and possibly(?) to the timer interrupt, which I think would need finer resolution. The code looks pretty complex, which is why I wanted to create this issue before trying anything myself. Maybe @jackhumbert, who seems to be who originally wrote the code, can tell me if there's something more fundamental that would prevent smoother stepping.Oh and if the code gets looked at anyway, we might want to think about allowing a finer speed setting as well. Right now, +1 in speed results in half the speed. -1 in double the speed.
The text was updated successfully, but these errors were encountered: