Power consumption

[lactide]

This decreases the power consumption when the pok3r is running by ~10mA.

Moreover the Deep-Sleep1 power saving mode is used when the host suspends it. It uses the EXTI Wakeup Interrupt to wake up when the user presses a key. The pok3r consumes less then 1mA during Deep Sleep, which can be tested e.g. by using powertop on Linux to toggle the Tunable "Autosuspend for USB device POK3R"

Before accepting this pull request, the submodule lib/chibios-contrib should be updated after accepting the outstanding Pull Request for ChibiOS-Contrib.

[ChaoticEnigma]

Nice work. Interesting that lowering the clock speed decreases power that much. I will have to setup a more precise way to measure the current.
I'll try testing the suspend functionality. Mainly, I need to make sure that interrupt messages from the host wake the keyboard up, so the raw hid api still works.

[ChaoticEnigma]

Okay, here's what I've seen so far. With the current version of the firmware, without leds, the keyboard draws 39.0 mA. With the clock change, without leds, it draws 25.8 mA. That's a tidy improvement.
I'm surprised that lowering the AHB clock makes that big a difference. I suspect it's not the CPU making most of that difference, since the CPU spends almost all it's time on a WFI, and the CPU clock should be stopped here. Unfortunately, the CPU doesn't have a separate prescaler, so it's hard to say.
The only effect of lowering the AHB clock I've seen is that it also lowers the SPI clock. So this triples the time it takes to read/write from the external SPI flash.

Now, in Deep-Sleep1, the the keyboard draws 1.3 mA. It seems to behave correctly when suspending, but occasionally it seems to hard fault when waking. So at the moment, this is no-go.
Also interestingly, when a raw hid command is sent while the keyboard is suspended (e.g. pok3rtool list), it looks like it fails to read the report descriptor, and the host then disconnects the device. If you press a key on the keyboard, and watch the power draw, it looks like it tries to wake (the CPU starts and the interrupt goes off), then it immediately goes back to sleep, probably because usbWakeupHost fails, and the USB driver state is still suspended.

[lactide]

I agree with not merging it yet. The current wakeup code doesn't work when the host wants the keyboard to resume. Additionally we'll loose keypresses when you're a typing fast during the resume.

I didn't see a hardfault when the code tries to wakeup with the EXTI interrupt, but that was probably just luck.

[lactide]

Just some update on this pull request: I'm using it with a ChibiOS-Contrib tree where PR pok3r-custom/ChibiOS-Contrib#3 is applied. I've modified and force pushed one of the earlier commits that changed the AHB frequency. On my main development machine i could go down to 6MHz and didn't see any errors, while the keyboard only consumed 17mA. But unfortunately this didn't worked well together with the BIOS of a T480, where i got some USB state machine assertions. The first frequency that also worked on the T480 reliably was 48MHz, which brings us now to a power consumption of ~30mA without any LEDs on.

Another change that i have stashed is a second condition "USB_DRIVER.state == USB_SUSPENDED" at

qmk_pok3r/tmk_core/protocol/chibios/main.c

Line 137 in f24fb6e

if(USB_DRIVER.state == USB_ACTIVE) {

to leave the while loop. Without that change your OS could suspend the keyboard before the keyboard_task was run. It'll hang in that loop until the host resumes it (e.g. by pressing capslock on another keyboard).
I won't commit that change, because a similar commit was included in the qmk master tree qmk@73a3399 which could be applied by rebasing.

Another issue which can't be fixed since pok3r reuses keymap rows/colums for the dip switches: There will be no visible power consumption change if one of the dip switches is enabled.