Timing of the calls to loop()

Firmware
1

Hi All,

For my own purposes, I wanted to know what the timing was like between the time you exit the loop() function, and when it is re-entered. I know the firmware is doing work during that time maintaining the WiFi and Cloud functionality. I have a project in mind where deterministic times around the loop() will be critical. So, I did a series of software experiments, and here are the results. I hope this information is useful to the community.

Tested: Photon
Firmware Version: 0.4.3
Unless otherwise stated, all times are from loop() exit until it is re-entered.

Automatic Mode
Typical: 998 µS
Maximum: 14,383 µS
Note: I tried creating cloud variables and calling cloud functions. None of that significantly increased these numbers

Semi Auto Mode
No WiFi or Spark Connection
Typical: 3 µS or 8 µS
Maximum: 45 µS

WiFi Connected but not Spark
Typical: 3 µS or 8 µS
Maximum: 270 µS

Spark Connected
Typical: 997 µS
Maximum: 13,698 µS

Manual Mode
No WiFi or Spark Connection
Typical: 3 µS or 8 µS
Worst Case: 45 µS

WiFi Connected but not Spark
Typical: 3 µS or 8 µS
Maximum: 267 µS

Spark Connected
Typical: 5 µS
Maximum: 129 µS

In Manual mode calling Spark.process() manually takes …
Typical: 992 µS
Maximum: I didn’t test this, but I bet it is like 13,000 or 14,000 like in automatic mode

Finally, I wrote a tight while(1){} and never exit the loop() function
No WiFi or Spark Connection
Typical: 0.1 µS
Maximum: 0.1 µS

WiFi Connected but not Spark
Note: Not sure if I can actually operate on WiFi (Didn’t try, I should probably test this.)
Typical: 0.1 µS
Maximum:0.1 µS

Spark Connected: HANGS Apparently you need to exit the loop() function for Spark.connect() to work

Note: This mode makes the Photon useless as a could device, and I suspect WiFi won’t work either.

Conclusion:
The worst case I saw was the return to loop taking 14,383 µS. This is 0.014 seconds. This occurred rarely, and the typical loop() time was around 1,000 µS (or 0.001 seconds). It seems to me that for the vast majority of purposes this would be sufficient responsiveness of the loop() cycle. If for some reason you need loop to run faster or more predictably, then the manual modes would probably be for you and you could turn off Spark cloud functions until you need them.

5 Likes
2

Nice tests! Thanks! I was wondering about this the other day and @peekay123 helped me with some tests. :smile:

I hope this gets better with threading feature in future where the system thread (wifi, rgb led etc) are separately managed :smile:

3

I’ve run a similar but (less sophisticated test- didn’t check different System modes - on a Photon (running 0.6.3), and got a cycle time of exactly 1ms (± .00002).
Presumably calls to loop are scheduled using a hardware timer? Or is this an artefact of how millis() works?

4

When running FreeRTOS multithreaing the threads get 1ms time slices, but since there are other things serviced between iteration of loop() the timing may depend more on the work load needed between these iterations.
So if you happen to have Particle.function() requests of Particle.subscribe() callbacks to service or a serialEvent() to deal with I’d guess your timing will vary (typically slow down).
Also if you are running disconnected (e.g. WiFi.off()) you will see much faster iterations.