Power Management - PM in Nuttx

This note is to collect ideas on doing efficient Power Management in Nuttx.

My basis  is I am assuming there is a limited, but rechargeable store of coulombs -  (LiIon battery or Supercapacitor) and the supply of coulombs to the store is episodic. It may be a solar panel - which has a diurnal cycle interrupted by a weather system. It might be periodic replacement of a battery supply. I use coulombs as it is the essential method for calculating energy available on SuperCapcitors. Typically battery's are quoted in mAHrs which assumes a constant voltage and is slightly easier to understand. The constant voltage is a myth that that needs to be understood for the true battery capacity.

I've used the Nuttx PM system as a starting point. It is an API and has algorithm for entering  into the processors sleep/hibernation - which isn't very efficient from the point of view of minimizing coulomb consumption, and specifically doesn't address dynamic clock management. IMHO dynamic clocking is a crucial part of Arm's power management architecture. I've modified the  sleep/hibernation algorithm to be more efficient, however the dynamic clock management is a major rethinking.

Some discussions on nuttx list that have taken place, and I put the context for a specific view I'm developing
https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/15347

Greg has identified a "Random Walk" algorithm for what he would like to see in Nuttx (aspirational at the time of writing)
http://www.nuttx.org/doku.php?id=wiki:nxinternal:dynamic-clocking
https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/15345
Kudo's to Greg Nutt for being so dedicated to Nuttx and making it available as an open source repository.

The design I'm investigating uses a Kinetis processor, and there are NXP software tools for stetting up the clocks. In my experience the clock setup is fragile and much can go wrong with it. When something goes wrong in an Arm processor it often stops working, or generates a hard fault - both difficult to debug. Essential to have a working JTAG debugger to step through the code.

The implementation of reducing power useage is very dependent on hardware design and the processors options designed into silicon. So while its possible to define some abstractions to clocking modes, in the end the implementation is going to be in the processor domain, and going to need testing with that specific processor.

Using the RTC date/alarm in KinetisK/FRDM-K64

This is (a wip) tutorial on enabling the RTC Alarms on the KinetisK FRDM-K64.

There are a couple of gottchas to look out for when using time related functions
1) is the system clock internal nuttx maintaned counter or syncs with hardware RTC
2) does the internal format use Julian or epoch time.
3) is the RTC format Julian/yymmddss time, or epoch time
The KinetisK has an internal RTC that is 32bits
(The STM32F4 versions have an internal RTC with yyyymmdd mmss)

The internal clock running off the processor xtal, won't be as accurate as the RTC clock.
However I haven't figured out away for checking which is operational from Nuttx cmd line.
I let it run for 12+hrs and then check the accuracy - if its off by a discernible amount then the chances are its running on the internal clock.
The difference between the internal clock and the RTC could provide some strange RTC alarm failures.

To be able to configure the FRDM-K64 (assuming you have a nuttx build environment) set it as per this previous blog configuring-nuttx-to-use-kinetisk-frdm-k64f.

I've developed this already on a private Nuttx build, and I'm submitting it back into Nuttx, using the FRDM-K64 as the basis for the build.

The K64 has one 32bit register and it needs the following enabled for
make menuconfig
date command
 Application Configuration -> NSH Library -> Disable Individual commands
[ ] Disable date
NSH_DISABLE_DATE=N

RTC support
System Type--> Kinetis Peripheral Support  & [*] RTC
CONFIG_KINETIS_RTC

Device Drivers-> Timer Driver Support-> [*] RTC Driver Support
 --- RTC Driver Support
  │ │    [*]   Date/Time RTC Support
  │ │    [*]     Hi-Res RTC Support
  │ │    (1)       Hi-Res RTC frequency (NEW)
  │ │    [*]   RTC Alarm Support
  │ │    (1)     Number of alarms (NEW)
  │ │    [*]   RTC Driver Support
  │ │    [*]     RTC IOCTLs
  │ │    [ ]   External RTC Support (NEW)

CONFIG_RTC_DATETIME
CONFIG_RTC_HIRES=y
CONFIG_RTC_FREQUENCY=1
CONFIG_RTC_ALARM=y
CONFIG_RTC_NALARMS=1
CONFIG_RTC_DRIVER=y
CONFIG_RTC_IOCTL=y


To be able to test
Application -> Examples-> RTC alarm driver example
 [*] RTC alarm driver example
  │ │    (100) Alarm task priority
  │ │    (2048) Alarm stack size
  │ │    (/dev/rtc0) RTC device path
  │ │    (1)   Alarm signal


plug in the FRDM-K64 after updates (as described at mbed), on the USB SDA to a host
On the computer connect to the serial port that comes up.
Compile and then take the nuttx.bin and drop it on the USB port

Some background,  about the Kinetis K devices and family,
I've put up a number of memory maps
groups.yahoo.com/neo/groups/nuttx/files/KinetisComparision/
The Kinetis K has two generations of chips, and a number of families.
The familes K20, K40 K60, K64 are feature descritption
the generations sometimes have enhancements to the feature descriptions
The K60P 100MHz is a generation1 device with base line RTC features
The K60P 120MHz is a generation2 device with RTC enhanced features.
The K66 is only a generation2 device

Configuring Nuttx to use a KinetisK FRDM-K64 with SDA upload

This is a place holder to describe how to start using the FRDM-K64 package

Briefly I plug FRDM-K64 SDA uUSB is plugged into Windows10.
Then it mounts a disk say E "MBED (E:)" and a com port
I connect a TTY (Tera Term) to the com port at the speed specified in Nuttx serial port.

The Nuttx output is set to binary as follows
make menuconfig
Build Setup-> Binary Output Formats->
 [ ] rrload binary format
 [*] Intel HEX binary format
 [ ] Motorola S-Record binary format
 [*] Raw binary format
 [ ] U-Boot uImage  ----

and then make it.
On completion, pickup the
nuttx.bin
and drop it on the "MBED (E:)" which programs the FRDM-K64.
It still requires the FRDM-K64 reset button to be pressed, but then it responds on the TTY.