Skip to content
This repository has been archived by the owner on Sep 20, 2022. It is now read-only.

bench_pm: Helper application for testing pm behavior #55

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

jnohlgard
Copy link
Member

@jnohlgard jnohlgard commented Nov 13, 2018

The application assists in measuring wake up delays and for measuring power consumption of different low power modes. A logic analyzer or oscilloscope is required for taking any measurements.

This application was used to test the GPIO interrupt optimizations in RIOT-OS/RIOT#8558

Works out of the box on any board which defines BTN0_PIN which is used as a wake up trigger.

A special "coma mode" is used when building with CFLAGS=-DCOMA_MODE, this will make the application skip initialization of wake up sources and go to the lowest power mode without waking up. This mode is specifically designed to measure the baseline power consumption, to use as a reference when comparing different hardware settings and software changes.

@jnohlgard jnohlgard added the new app This contributes a new application label Nov 13, 2018
The application assists in measuring wake up delays and for measuring
power consumption of different low power modes.
Copy link
Member

@smlng smlng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments, look good to me - untested ACK

bench_pm/Makefile Outdated Show resolved Hide resolved
bench_pm/main.c Outdated Show resolved Hide resolved
@jnohlgard
Copy link
Member Author

addressed comments

@jnohlgard
Copy link
Member Author

Updated:

  • Cleaned up defines for pins, better general platform support.
  • Added "coma mode" which runs pm_set(0) in a tight loop without any additional wake up sources, to get a good reference for the minimum achievable power consumption.

#endif

#if COMA_MODE
puts("Coma mode, going to pm_set(0), not coming back");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've had some boards that made it really difficult to re-attach a debugger when going to deep sleep too fast.
Could we maybe guard this, either by a second delay or using something like while (gpio_read(BUTTON1)) {}?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some boards that made it really difficult to re-attach a debugger

Like, the only way was to do "while true; do make -C examples/hello-world flash; done" and hammering the reset button, hoping to hop into the short time from reset to CPU stop...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And reset_config connect_assert_srst and a recent openocd did not help?
(including the important improvement bb976e3c387bc82e20ab7304f0cfac3e5eede3a1 in https://repo.or.cz/openocd.git/commit/bb976e3c387bc82e20ab7304f0cfac3e5eede3a1 if you are using a CMSIS-DAP debugger)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
new app This contributes a new application
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants