V-USB suspend refactor

[fauxpark]

Description

V-USB boards currently do not switch off RGB and backlight on suspend. Fixing this was complicated by the fact that the ATmega32A does not have a watchdog timeout interrupt, which is defined in suspend.c to nudge the global timer while the chip is in sleep mode. Instead we just ignore that whole part of the process while still turning off RGB and backlight by pulling them up into suspend_power_down(), leaving only the watchdog and sleep code in power_down().

Since this touches the general AVR suspend code it would be good to check it still works on USB AVRs (eg. 32U4). The change in mcu_selection.mk can also probably apply to the 328P, but I only have a Plaid-Pad which has neither RGB nor backlight.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[spidey3]

Hmm... To my mind, NO_SUSPEND_POWER_DOWN is a feature of the MCU (from mcu_selection.mk) telling us that is cannot be put into sleep mode. That doesn't mean that we cannot shut off all of the leds and audio (as permitted, e.g., by RGBLIGHT_SLEEP, etc.).

Perhaps rather than checking for the existence of WDT_vect, can just check NO_SUSPEND_POWER_DOWN?

[fauxpark]

You can add NO_SUSPEND_POWER_DOWN = yes to your rules.mk to prevent the RGB and underglow turning off on suspend; there are a few boards that do this (most of Wilba's for example). So I think at the very least that would be a breaking change, if it even makes sense to do.

[spidey3]

Yeah, true. I don't feel terribly strongly about this right now.
One note - you might get a merge conflict vs. #11820 #11553, which also touches suspend.c.

[fauxpark]

I don't see it in the file list...

[spidey3]

I don't see it in the file list...

Correction: #11553

[fauxpark]

Okay, not too bad.

[fauxpark]

Just checked this PR with a neopixel stick on a pro micro, doesn't seem to have broken anything.

[spidey3]

I tested the latest update on atmega32u4 and it doesn't seem to have broken anything.