I’m trying to get a better understanding of how multi-threading works, especially while connecting to the cloud.
It’s my understanding that ISRs would still be serviced while connecting to WiFi or the cloud… What about software timers?
I, like a few others I’ve read posts from have a product that must remain responsive, even if a users internet goes out. At the moment my whole program hangs for about 8 seconds+ while connecting to WiFi and then the cloud. Not so much of a problem if it only happens at startup but if a user has an inconsistent connection, then regular cloud connection attempts can really make the program unusable.
I’m aware there are a few different system modes, I’m currently experimenting with SEMI_AUTOMATIC, although I don’t see how this will help me that much, as ‘connecting’ to WiFi or the cloud still appears to be completely blocking.
I’m running 0.4.9 and my understanding was that connecting to WiFi and the cloud was not a blocking call. Any ideas?
Thanks for your reply @Moors7 I did have SYSTEM_THREAD(ENABLED) in there. Just realised it was not in fact my software timers that were blocking but calls to Particle.publish within the software timer callbacks.
I’ve put a Particle.connected() conditional around these now and we’re good to go. Noob mistake sorry!
I think you should be treating those timer callbacks like ISR, that is, keep them as light as possible. Don’t try to do fancy cloud stuff in them, but rather set a flag for the main loop to check on. That should prevent any timer issues that might come to existence when calling things like that on ‘dedicated stuff’. (Does that make sense?)
That way you only have to call one function every so often and it takes care of calling the tasks on their schdule, its not multithreaded, but takes the boiler plate code away from having to maintain a number of variables with millis() etc.
If you use system_threading and then call that lib from the loop function, maybe you get acceptable performance during wifi connecting.
