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.

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

Hardware PWM on PD0 #5953

Open
al3ph opened this issue May 22, 2019 · 10 comments
Open

Hardware PWM on PD0 #5953

al3ph opened this issue May 22, 2019 · 10 comments

Comments

@al3ph
Copy link

@al3ph al3ph commented May 22, 2019

Hi, I've flashed my keyboard (XD87) with the latest firmware, but I get random flashing of the backlight (even on full brightness), I assume that some USB processing is interrupting the soft PWM.

But confusingly the keyboard uses PD0 for the backlight on an atmega32u4, which as far as I can tell supports hardware PWM, is there away of QMK actually using this instead of falling back to soft PWM, which is a bit flaky ?

cheers!

@al3ph al3ph changed the title XD87 backlight flicker Hardware PWM on PD0 May 22, 2019
@fauxpark

This comment has been minimized.

Copy link
Member

@fauxpark fauxpark commented May 22, 2019

The ATmega32U4 datasheet says of PD0:

This pin can be used to generate a PWM signal from the Timer 0 module.

However, I'm pretty sure Timer0 is used internally by QMK.

Soft PWM still uses a hardware timer as of recently - you should be seeing a message like this when compiling:

#pragma message "Using hardware timer 1 with software PWM"
@al3ph

This comment has been minimized.

Copy link
Author

@al3ph al3ph commented May 22, 2019

Ah I see.
Yep I got that message, but somethings still glitching it.
I guess that that mode is still not perfect.

@Wraul

This comment has been minimized.

Copy link
Contributor

@Wraul Wraul commented May 26, 2019

Have you tried using another USB cable?

I have experienced similar problems with the hardware PWM when using a thick cable with an aviator connector.

My theory is that something about the cable causes the VCC to drop lower than the controller can handle, and that the PWM feature is more sensitive to this.

@fauxpark fauxpark mentioned this issue May 26, 2019
5 of 13 tasks complete
@al3ph

This comment has been minimized.

Copy link
Author

@al3ph al3ph commented May 28, 2019

I doubt it, as it was stable on the native firmware

@drashna

This comment has been minimized.

Copy link
Member

@drashna drashna commented Jun 17, 2019

@al3ph have you had a chance to test the PR referenced? With the suggested settings by fauxpark?

@LouWii

This comment has been minimized.

Copy link
Contributor

@LouWii LouWii commented Aug 29, 2019

I'm confirming this issue. I'm also seeing the backlight blinking.

I compiled XD87 with the changes from #5983 (I looked in quantum.c and found the fix).

#ifdef BACKLIGHT_BREATHING
  if(is_breathing()) {
    breathing_task();
  }
#endif

I'm seeing the pragma message Using hardware time 1 with software PWM when compiling.

I'm coming from the TMK firmware which didn't have that problem (didn't change anything beside the firmware).

My knowledge won't get me far in debugging this though, at least without any help.

(also, related but unrelated, is the RGB underglow supposed to work? Doesn't look like it is on my end. I'm using RGB_TOG, RGB_VAI, RGB_MOD but nothing happens)

@fauxpark

This comment has been minimized.

Copy link
Member

@fauxpark fauxpark commented Aug 29, 2019

@LouWii could you try adding #define BACKLIGHT_ON_STATE 1 to your config.h? The default is 0, which is assuming a P-channel MOSFET where the LEDs are turned on by a low signal from the PWM pin (most backlight circuits use N-channel).

As for the RGB - resetting the EEPROM should work, otherwise perhaps it hasn't been set up - it's not enabled in rules.mk by default, and the config.h settings are commented out.

@LouWii

This comment has been minimized.

Copy link
Contributor

@LouWii LouWii commented Aug 29, 2019

@fauxpark With #define BACKLIGHT_ON_STATE 1, the LEDs aren't blinking anymore at max brightness. However, the commands are reversed (bright+ decreases the brightness, and vice versa). Minimum brightness has the LEDs just a tiny bit lit up (not fully off) and they flash at almost full brightness randomly. When between max and min brightness, they flash like they do without #define BACKLIGHT_ON_STATE 1.

I'm going to look at the RGB config. EEPROM reset didn't work, but that's not surprising if RGB is not configured at all.

@al3ph

This comment has been minimized.

Copy link
Author

@al3ph al3ph commented Aug 29, 2019

Those are exactly the same symptoms I got.

@LouWii

This comment has been minimized.

Copy link
Contributor

@LouWii LouWii commented Aug 30, 2019

I've setup the RGB configuration for underglow and everything works fine. Submitted a PR for it: #6635

Still not sure what to do about the backlight though. Would the TMK firmware version help? I found it there: kairyu/tmk_keyboard_custom@bfcda56

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.