When the system thread is enabled, application execution changes compared to non-threaded execution:
setup()is executed immediately regardless of the system mode, which means setup typically executes before the Network or Cloud is connected.
Particle.subscribe()will function as intended whether the cloud is connected or not.
You should avoid calling
Particle.publish()before being cloud connected as it may block. This is important if you are switching to threaded mode and previously published an event from setup.
Other network functions such as
TCPClient) should wait until the network is connected before use.
loop()is called repeatedly, independent from the current state of the network or cloud connection. The system does not block
loop()waiting for the network or cloud to be available, nor while connecting to Wi-Fi.
MANUALdo not not start the network or cloud connection automatically, while
AUTOMATICmode connects to the cloud as soon as possible. Neither has an effect on when the application
setup()function is run - it is run as soon as possible, independently from the system network activities, as described above.
delay()are not needed to keep the background tasks active - they run independently. These functions have a new role in keeping the application events serviced. Application events are:
- cloud function calls
- cloud events
- system events
- serial events
Cloud functions registered with
Particle.function()and event handlers registered with
Particle.subscribe()continue to execute on the application thread in between calls to
loop(), or when
delay()is called. A long running cloud function will block the application loop (since it is application code) but not the system code, so cloud connectivity is maintained.
- the application continues to execute during listening mode
- the application continues to execute during OTA updates