Delay or not delay: that is the question

Firmware
1

Dear all,

I am pretty new to particle and I was looking at the code of AssetTrackerRK, in particular to this example:
https://github.com/rickkas7/AssetTrackerRK/blob/master/examples/3_WakeOnMove/3_WakeOnMove.ino

The whole thing is basically a FSM and some states are just there to loose time waiting for something to happen (e.g., a message is sent, device is fully booted, ...).

I am aware that sometimes is ok to use delay() while sometime is good to have a manually crafted "soft-delay" that allows you to do some other operations while you wait, see hereafter:

However I was wondering if in some cases the soft wait could be changed in favor of a delay() for example in the code of linked above of AssetTrackerRK.

For example the state BOOT_WAIT_STATE (line 147) where the code just waits for a while to make sure the electron is fully operative could be substituted with a delay(). Correct? Similarly with SLEEP_WAIT_STATE (line 141).

From this doubt an additional question comes into play. Assume for example I want to send a message with Particle.publish(...) and then go to sleep. After publishing I cannot immediately invoke Particle.sleep(...) because I need to let the device have the time to send the message (correct?).

Instead, can I use a delay() and immediately after go to sleep? In other words does the delay let the Particle code run or freezes everything? Does it freeze only my code and my libraries or every single line of code executed by the device?

Thank you for the clarification and sorry if the question is trivial (I am pretty new to the embedded world).

Best
G.

2

The reason it’s a finite state machine, aside from the that I prefer it that way, is this block of code at the top of loop:

while (Serial1.available() > 0) {
		if (gps.encode(Serial1.read())) {
			displayInfo();
		}
	}

Every time through loop it grabs data from the GPS and processes it. If you have a delay more than a few hundred milliseconds, you can start losing data from the GPS.

You could make a delay function that also pumps data from the GPS if you prefer to write your code linearly instead, however.

1 Like
3

Thank you @rickkas7 that explains your design (and thank you for your effort, this lib is extremely useful).

Still I am wondering if delay() freezes everything or I could use it while waiting for a message to be sent by the modem or for the boot to be completely finished…I guess I can make a little experiment to check…

Thx!
G.

4

delay() is implemented as a "tight" loop that keeps the flow trapped for x milliseconds performing a Particle.process() call (if required by system and threading mode) once every 1000ms accumulated delay time.

Additionally v0.7.0 will get rid of this "need" (for Electron devices this is already implemented that way in 0.6.2)

SYSTEM_THREAD(ENABLED) already changes some rules about delays.
Some cloud tasks will be performed on the "free running" system thread (e.g. servicing Particle.variable() requests) while others need to run on the application thread (e.g. Particle.function() callbacks or Particle.subscribe() handler calls) and hence require a call of Particle.process() (the quicker the more responsive the device will be).

If you want to do other jobs while waiting (but not only then), you definetly should adopt a completely non-blocking coding scheme - multi threading and interrupt driven approaches should "only" be employed when this does not suffice.

2 Likes