Sleep 2.0 duration var type?

Firmware
1

Hello!
I am trying out sleep 2.0, and I saw in the documentation that duration can now be defined as a chrono literal (neat!), but am just wondering 2 things.
1.) When NOT using chrono literal, does the duration still need to be a long type like it did with classic sleep, or can/should it be something else?
2.) Less importantly, how would one go about using chrono literals with a variable sleep duration? Could I pass it in like a string? For instance :

System.sleep(sleepMins + "min");

This doesn’t seem like it would work but I hope that conveys what I am asking.

2

Chrono literals are not strings as in your example but rather operators.
Have a look here

The expression immediately preceding the operator is taken as it’s parameter

When not using chrono literals the “anonymous” numeric parameter will be treated as milliseconds.
However, when you pass in a std:chrono type the conversion from its “granularity” to std:chrono:milliseconds will be performed implicitly.

https://docs.particle.io/reference/device-os/firmware/argon/#duration-systemsleepconfiguration-

3

As always, your help is greatly appreciated!
So for example:

void sleepForMins(String minsToSleep) {
  int sleepMinutes = minsToSleep.toInt();
  int sleepSeconds = sleepMinutes * 60;
  int sleepMilliseconds = sleepSeconds * 1000;
   config.mode(SystemSleepMode::ULTRA_LOW_POWER)
     .duration(longSleepMilliSeconds);
}

Would become:

void sleepForMins (String minsToSleep) {
  int sleepMinutes = minsToSleep.toInt();
   config.mode(SystemSleepMode::ULTRA_LOW_POWER)
     .duration(std::chrono::minutes(sleepMinutes));
}

Does that seem correct?

4

Seems reasonable (apart from the missing closing parenthesis).

But expecting one has read and understood the docs correctly is one thing, however I often find myself double checking anhow :wink:

Point being: You can always find out by conjuring up a test function that takes a std::chrono::milliseconds parameter and then pass in your std::chrono::minutes value and let it Serial.print() it.

That’s how I am learning new things - by trying it out.
Since I know, when I’m only getting it told or read it somewhere, I’ll definitely forget it rather sooner than later and have to look it up again. But once delving into the subject and messing around a bit (potentially with some errors on the way :see_no_evil: even the better so) it tends to stick better and a lot longer (hopefully :blush:).

There is an interesting (old) video about how to learn “better”

5

Thank you very much, and that was a great video!
I just gave it a test and it seems to work perfectly as shown above (just in case anyone comes across this wondering the same thing). Also just to loop back to the title question a bit, is there any reason that the duration should specifically be of type long and not int?
Just as some background, when I wrote this question I was thinking that a bug that came up over the weekend may have been related to something obscure where I had multiplied a long by 1000 before setting it as duration for sleep, however upon further investigation it appears that the backend system may have been accidentally sending negative sleep durations to device so I am not so sure it is a firmware issue (other than that it should be rejecting negative inputs to the function, haha!).

1 Like
6

Since the Particle devices are all based on 32 bit controllers int and long have both the same 32 bit numeric range.
To avoid that confusion many people have decided to use the more explicit data types uint32_t and int32_t which will be 32 bit no matter what platform you are using it on. Which is not true for int on 8bit controllers vs. 32bit controllers.

2 Likes
7

Thank you very much!
I have marked this as the solution since it is the most relevant to the question in the title!

8

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.