Questions regarding wakeup via interrupts


#1

Now that summer is over I am finally starting the conversion of a Particle Core project to Bluz. One thing I’m trying to plan for is the Bluz board constantly running loop(). I have two switches that would need to wake the Bluz up, but also call a function.

What is the expected behavior when a Bluz is woken up from an interrupt?

How can you differentiate between the normal Bluz loop() wakeup and an interrupt driven wakeup? Would an interrupt wakeup call the function that you specified in the interrupt?


#2

Are you trying to use deep sleep mode? If so, then when the interrupt wakes up bluz it will re-run the setup function as the system will basically start over like a reboot.

If you are just using interrupts, then there is no difference in how or when loop gets called. CPU sleep mode doesn’t actually force a reset of bluz, it just puts the CPU to sleep as much as possible while retaining all state info


#3

I was actually looking to use SLEEP_MODE_CPU. I was mainly concerned with how interrupts (and their associated functions) act when using this sleep mode in the loop. If I have a loop with SLEEP_MODE_CPU and an interrupt attached to a button, will the the associated function still be called when I push that button?

I was also looking at deep sleep mode, but wasn’t sure if it was implemented yet in the current firmware release. I also couldn’t really find documentation on it. I’d love to hear more about this also.


#4

Yes, it will. SLEEP_MODE_CPU just tries to turn off the CPU when possible, it doesn’t guarantee that it will be off since the BLE stack may turn it on. Also, there are system timers that trigger every 100mSec that will wake up the CPU, so your loop function always runs 10 times a second anyway.

Deep Sleep mode is implemented in v2.0. We just cut a pre-release of this and are currently testing it on Particle Staging. It required some new changes to how we build, so once that is all worked out, we will release a beta version, hopefully sometime this week. You can then use DEEP SLEEP, but only to wake up the device, but then you could immediately run your function on waking.


#5

What is the expected power consumption with nothing else drawing power, reading an input or two, setting a variable, and sleeping with SLEEP_MODE_CPU in the loop? Should it really be around 60uA? I’m going to be testing this tonight and looking at power consumption.

Also, how does DEEP SLEEP work with cloud functions (functions/variable reading/etc)?


#6

If BLE is off, you would see approximately 60uA of power consumption when in SLEEP_MODE_CPU most of the time. As I mentioned before, we have a software timer that wakes up the CPU every 100mSec to handle some house keeping tasks (like setting the RGB LED, seeing if any data was received from the cloud, etc.) that will briefly run and use more power. However, this should pass very quickly.

If BLE is on and you are connected, you will also see the radio wake up the CPU every connection interval (approximately 20mSec with a gateway). The radio will transmit/receive and you will see a much bigger spike. This power consumption can be mitigated in two ways:

  1. Increase the connection interval, thereby increasing the time between these events
  2. Decreasing the transmit power, thereby decreasing the power the radio uses when it transmits

Both 1 and 2 above require v2.0.50 of firmware, which should be released as a beta any day now.


Wake on interrupt