Low Power Managment Driver - LPMD Driver

[Tabulous]

Just wondering what peoples thoughts are on this around management of system drivers when using low power modes of MCU's

If the peripheral drivers registered with a power management driver, then when the power management mode is change via the LPMD driver, it could use callbacks to notify the drivers of a chnage. One could then implement power saving into the peripheral drivers.

I know this would mean changes to the peripheral drivers i.e.
Every driver would have to register with LPMD when the init is called.
Every driver would have to have a callback function if it needs to process the power change states.


Whats the thoughts on this ?

[Giovanni]

Hi,

I have been thinking about this, clocks management should go together with sleep/standby management.

Right now clock setup is static and done in the HAL driver, in my opinion there should be a dedicated clock driver, I have "finalized" the following ideas:

1) It needs to support multiple clock configurations, the one configured in mcuconf.h could be the "default" one. A "reset" configuration is always defined and reverts things to post-reset settings. Switching would be done using a clkSetConfig(config) function.
2) It needs to export a clkGetFrequency(point) API able to return the clock frequency in specific "clock points" (APB1, APB2, ADCCLK, SYSCLK for example).
3) Drivers must be reworked to get frequencies using clkGetFrequency() because the values are no more constants but calculated. A change in clock mode would require affected drivers to be stopped/restarted in order to calculate the new divider/baud/whatever settings.
4) Changes should generate events, perhaps a centralized "system events" module is required in HAL.
5) A function clkGoPowerDown(config) would be provided.

The idea revolves around the idea of clock configurations and power-down configurations, architecture-dependent of course.

Probably it will require a lot more, but should be part of the HAL6 cycle. Feel free to comment and add requirements.

Giovanni

[steved]

This sounds an excellent idea for low power applications, but I'm a bit concerned as to how much code it could add (since when I have only 32K of code space I seem to use all of it already). Ideally it would be possible to globally select between the existing fixed clock arrangement and the new fully controllable interface. I like the idea of being able to request the clock frequency at any point in the clock tree (although not sure how useful it would be outside debug).
One relatively simple use case I have which you might be able to bear in mind is the ability to defer parts of clock set up until later on - after all the chibi and hal-related initialisation and after some user code has run. In my case I have to program a peripheral to generate the crystal-controlled external clock, and then switch to it. To avoid having to think too much, I've made this external clock the same frequency as HSI, but it need not be. Obviously other clocks might be wrong until everything is set up, but that won't matter in some applications.