Particle.process() quirks

[sampath1]

Hi -

I’m developing some Particle firmware for the Argon in the Manual mode and compiling using OS 1.5.2.

The documentation on the particle website specifies that a particle.process() function needs to be included in the main loop for the cloud connection to not be lost.

The initial prototype did not include this line, but the code works just fine. Obviously I have no confidence that this code will perform well long term or in a production setting, so I’m trying to understand what the particle.connect() function does and why the code works well despite not adding it.

This is how the main loop looks currently - Sensors update data at 1Hz frequency, so the particle publish pushes that data to the cloud at that frequency…

void loop() {
  if(!WiFi.ready()){
    connectToWifi(mySSIDs, myPasswords);
  }  
    Message msg;
    if(get__data(&msg)) {
               //business logic
               publishData();
        }
    }
  delay(1000);
}

[robc]

@sampath1

delay(1000);

this statement you have in your code just so happens to invoke Particle.process() when delay() statements accumulate to 1000 ms. So, your loop is, at some point, calling Particle.process() in background.

Particle.process() is a blocking call, and blocks for a few milliseconds. Particle.process() is called automatically after every loop() and during delays. Typically you will not need to call Particle.process() unless you block in some other way and need to maintain the connection to the Cloud, or you change the system mode. If the user puts the device into MANUAL mode, the user is responsible for calling Particle.process() .

Perhaps, a better ending for the loop() would be:

delay(X);
Particle.process();
}

or, just

Particle.process();
}

[sampath1]

So is particle.process() being called during delays even in manual mode (which I am in)…

Thanks for your explanation that it is the case when we’re in automatic mode, but the manual mode is bit more unclear to me…

Thanks @robc

[robc]

@sampath1

So is particle.process() being called during delays even in manual mode (which I am in)…

Yes. While in manual mode, you are responsible for placing Particle.process() in your code. So far, you have had no trouble with your code. A one second blocking delay is not affecting your connection, yet.
The delay(1000) statement happens to call Particle.process() for you but, as you add new routines, may not call it often enough. A connection could break if not attended by Particle.process() often enough.

I had read about this a long time ago. Hope the following helps. Here is what I found today in the forum:

@ScruffR

While the suggestion to write non-blocking code is good practice in any case, I’d say this delay() should not cause the disconnect, since in default “single” threaded mode delay() calls Particle.process() every 1000ms of accumulated waiting time.

Known issue: long delays or blocking code kills the connection to the Cloud

@b3ko, if you post your actual code it would help. If you want to delay without killing the cloud connection, you need to implement a non-blocking delay, something like this: unsigned long myDelay = millis() + (60*5*1000); while (millis() < myDelay) { Particle.process(); delay(10); } This will appear like a blocking delay (where other code is not running and loop() is not looping). However, it will be calling Particle.process() which will keep the cloud connection active.

[friedl_1977]

Hi @sampath1 -

Welcome to the forum. I have not worked with Manual mode much, I tend to stick to Semi-Automatic mode. That said, maybe this explanation by @ScruffR can shed some light on the particle.process(); command. Made me learn something new today

Particle.process() on Electron

Nope. It only makes sure that any change between device and cloud will be dealt with. If your code doesn’t cause any change that needs to be synced to the cloud and the cloud has no change for your device to announce Particle.process() in itself won’t cause any traffic. If you loop() is regularly falling through Particle.process() isn’t needed since it’s implicitly called between iterations of loop() anyway.

Best of luck!

Regards, Friedl.

[sampath1]

Thanks! @friedl_1977 and @robc, going through @ScruffR’s and @peekay123’s post were really good in helping clarify things to me… .