Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

xd60 backlight issues #3566

Closed
masterzen opened this issue Aug 4, 2018 · 4 comments
Closed

xd60 backlight issues #3566

masterzen opened this issue Aug 4, 2018 · 4 comments
Labels
question

Comments

@masterzen
Copy link
Contributor

Hi,

I'm new to QMK, but I was able to produce my own keymap and flash it to the keyboard.

Unfortunately, I have some backlight issues:

  • BL_TOGG doesn't work, but BL_STEP or BL_INC/DEC works correctly
  • when in lower backlight levels (like 1 to 4), when typing the backlight frequently flashes (going brighter), which is really annoying. It gets worst if more than one key is pressed at the same time (like pressing QWERTYU, really makes it flashing 100% of the time).

I double-checked all the soldering, and everything seems good.

Unfortunately I haven't used the original firmware (TKG based) to see if it exhibits the same thing.

While looking at the QMK code, I see that backlight uses B6 so hardware PWM.

It doesn't seem to be the case for the original firmware (see https://github.com/kairyu/tmk_keyboard_custom/blob/581da2a49c46739d0dfed636f7f201b7d60b77e1/keyboard/gh60/backlight.c) which for GH60_REV_ABC (the recommended vendor settings when flashing the original firmware) enables the software PWM.

Could that be the issue?
Any idea on how to fix the flickering?

Thanks for any help,
@masterzen
Copy link
Contributor Author

I just reflashed the original vendor provided firmware and there's no flickering of the backlight while typing. It has only 3 levels, though.

Note that I was wrong in my original post abose, QMK uses F5 and so from reading the code I think it uses a software PWM like tmk.

I'm going to read both PWM code to see if I can spot any differences among them.

@masterzen
Copy link
Contributor Author

I think the real difference comes from the fact that TMK uses a hardware timer interrupt, whereas QMK calls the backlight software PWM from the matrix scan. My understanding is that if the matrix scan is a bit delayed because it processes something (like pressing multiple keys), the next call of the backlight pwm will be slightly delayed and then the leds will be on for a longer time, hence the flickering.

@masterzen
Copy link
Contributor Author

Another difference is that QMK uses only the F5 port, whereas the original firmware uses F4, F5, F6, F7.

@masterzen
Copy link
Contributor Author

I ported the TKG softpwm code to QMK for the xd60, and I don't see any flickering when typing anymore.

I'm now trying to see how I could only make backlight_task called from a timer interrupt when NO_HARDWARE_PWM is set (xd60 case). I first need to understand fully QMK's PWM code...

@arpinfidel arpinfidel mentioned this issue Aug 9, 2018
Closed
@masterzen masterzen mentioned this issue Aug 10, 2018
Merged
masterzen pushed a commit to masterzen/qmk_firmware that referenced this issue Oct 27, 2018
Fix qmk#3566 use an hardware timer for software PWM stability
58aeeee 
With my XD60, I noticed that when typing the backlight was flickering.

The XD60 doesn't have the backlight wired to a hardware PWM pin.
I assumed it was a timing issue in the matrix scan that made the PWM
lit the LED a bit too longer. I verified it because the more keys that
were pressed, the more lighting I observed.

This patch makes the software PWM be called during CPU interruptions.
It works almost like the hardware PWM, except instead of using
the CPU waveform generation, the CPU will fire interruption
when the LEDs need be turned on or off.

Using the same timer system as for hardware PWM, when the counter
will reach OCRxx (the current backlight level), an Output Compare
match interrupt will be fired and we'll turn the LEDs off.
When the counter reaches its maximum value, an overflow interrupt
will be triggered in which we turn the LEDs on.
This way we replicate the hardware backlight PWM duty cycle.

This gives a better time stability of the PWM computation than pure
software PWM, leading to a flicker free backlight.

Since this is reusing the hardware PWM code, software PWM also supports
backlight breathing.

Note that if timer1 is used for audio, backlight will use timer3, and if
timer3 is used for audio backlight will use timer1.
If both timers are used for audio, then this feature is disabled and we
revert to the matrix scan based PWM computation.

Signed-off-by: Brice Figureau <[email protected]>
Shinichi-Ohki added a commit to Shinichi-Ohki/qmk_firmware that referenced this issue Apr 26, 2019
@Shinichi-Ohki
Merge branch 'master' of https://github.com/qmk/qmk_firmware
bc5db1c 
* 'master' of https://github.com/qmk/qmk_firmware: (99 commits)
  [Keyboard] Add a new keyboard ADKB96 (qmk#5685)
  test commit
  add RGBLIGHT_SPLIT_SET_CHANGE_MODEHSVS; to rgblight_update_dword()
  add RGBLIGHT_SPLIT_SET_CHANGE_MODEHSVS; to eeconfig_update_rgblight_default()
  Refactor cospad to current standards and enable support for backlight keycodes (qmk#5582)
  [Keymap] update (mouse emulation, rev 6 compatibility) (qmk#5696)
  [Keyboard] fix project zen rev1 bootloader declaration (qmk#5695)
  [FIX] Misspelled RGB_YELLOW (qmk#5692)
  [Keymap] Fix broken Shift-Insert binding (qmk#5689)
  [Keyboard] forgot to omit k05 from the electrical matrix in hhkb layout (qmk#5684)
  [Keyboard] Fix red an green leds location (qmk#5698)
  Translate docs into Chinese (qmk#5693)
  [Keymap] Fix my userspace RGB bug (qmk#5686)
  Boston meetup 2019 (qmk#5611)
  [Keymap] Update to Drashna Keymaps (qmk#5594)
  fix LIB_SRC and QUANTUM_LIB_SRC for ARM (qmk#5623)
  RGB Matrix Animations: Three/six new reactive effects (wide, cross, nexus) (qmk#5602)
  Fix qmk#3566 use an hardware timer for software PWM stability (qmk#3615)
  added info.json for ymd96 (qmk#4982)
  Define RGB colors (qmk#5300)
  ...
KauyonKais pushed a commit to KauyonKais/qmk_firmware that referenced this issue Apr 27, 2019
@KauyonKais
Fix qmk#3566 use an hardware timer for software PWM stability (qmk#3615)
876cfaa 
With my XD60, I noticed that when typing the backlight was flickering.

The XD60 doesn't have the backlight wired to a hardware PWM pin.
I assumed it was a timing issue in the matrix scan that made the PWM
lit the LED a bit too longer. I verified it because the more keys that
were pressed, the more lighting I observed.

This patch makes the software PWM be called during CPU interruptions.
It works almost like the hardware PWM, except instead of using
the CPU waveform generation, the CPU will fire interruption
when the LEDs need be turned on or off.

Using the same timer system as for hardware PWM, when the counter
will reach OCRxx (the current backlight level), an Output Compare
match interrupt will be fired and we'll turn the LEDs off.
When the counter reaches its maximum value, an overflow interrupt
will be triggered in which we turn the LEDs on.
This way we replicate the hardware backlight PWM duty cycle.

This gives a better time stability of the PWM computation than pure
software PWM, leading to a flicker free backlight.

Since this is reusing the hardware PWM code, software PWM also supports
backlight breathing.

Note that if timer1 is used for audio, backlight will use timer3, and if
timer3 is used for audio backlight will use timer1.
If both timers are used for audio, then this feature is disabled and we
revert to the matrix scan based PWM computation.

Signed-off-by: Brice Figureau <[email protected]>
foosinn pushed a commit to foosinn/qmk_firmware that referenced this issue May 6, 2019
@foosinn
Fix qmk#3566 use an hardware timer for software PWM stability (qmk#3615)
be7a5a1 
With my XD60, I noticed that when typing the backlight was flickering.

The XD60 doesn't have the backlight wired to a hardware PWM pin.
I assumed it was a timing issue in the matrix scan that made the PWM
lit the LED a bit too longer. I verified it because the more keys that
were pressed, the more lighting I observed.

This patch makes the software PWM be called during CPU interruptions.
It works almost like the hardware PWM, except instead of using
the CPU waveform generation, the CPU will fire interruption
when the LEDs need be turned on or off.

Using the same timer system as for hardware PWM, when the counter
will reach OCRxx (the current backlight level), an Output Compare
match interrupt will be fired and we'll turn the LEDs off.
When the counter reaches its maximum value, an overflow interrupt
will be triggered in which we turn the LEDs on.
This way we replicate the hardware backlight PWM duty cycle.

This gives a better time stability of the PWM computation than pure
software PWM, leading to a flicker free backlight.

Since this is reusing the hardware PWM code, software PWM also supports
backlight breathing.

Note that if timer1 is used for audio, backlight will use timer3, and if
timer3 is used for audio backlight will use timer1.
If both timers are used for audio, then this feature is disabled and we
revert to the matrix scan based PWM computation.

Signed-off-by: Brice Figureau <[email protected]>
Timbus pushed a commit to Timbus/qmk_firmware that referenced this issue Jun 23, 2019
@Timbus
Fix qmk#3566 use an hardware timer for software PWM stability (qmk#3615)
e116e27 
With my XD60, I noticed that when typing the backlight was flickering.

The XD60 doesn't have the backlight wired to a hardware PWM pin.
I assumed it was a timing issue in the matrix scan that made the PWM
lit the LED a bit too longer. I verified it because the more keys that
were pressed, the more lighting I observed.

This patch makes the software PWM be called during CPU interruptions.
It works almost like the hardware PWM, except instead of using
the CPU waveform generation, the CPU will fire interruption
when the LEDs need be turned on or off.

Using the same timer system as for hardware PWM, when the counter
will reach OCRxx (the current backlight level), an Output Compare
match interrupt will be fired and we'll turn the LEDs off.
When the counter reaches its maximum value, an overflow interrupt
will be triggered in which we turn the LEDs on.
This way we replicate the hardware backlight PWM duty cycle.

This gives a better time stability of the PWM computation than pure
software PWM, leading to a flicker free backlight.

Since this is reusing the hardware PWM code, software PWM also supports
backlight breathing.

Note that if timer1 is used for audio, backlight will use timer3, and if
timer3 is used for audio backlight will use timer1.
If both timers are used for audio, then this feature is disabled and we
revert to the matrix scan based PWM computation.

Signed-off-by: Brice Figureau <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@masterzen @drashna