Any idea when System Threads will be available on the Photon?
There is a lot of activity on github right now:
4 Likes
System threads are available in the 0.4.6 release as a Beta feature (disabled by default.)
1 Like
@mdma - Huge favor to ask, since messages like this one make me realize many users are tackling this problem and coming up short: could you please provide some sample code for bootstrapping a cloud connection in MANUAL mode with threading enabled? As it is, I’m sure everyone is devising their own ugly if/else blocks going through the same sequence of steps to attaining cloud nirvana.
However, when one’s main reason to use this feature is simply to avoid being blocked by system code, the path to connectivity is the well-trodden one that SYSTEM_MODE(AUTOMATIC) takes, with maybe a convenient switch on whether to enter listening mode or not.
I realize there may be different approaches, like time delays between retries vs. waiting on ready/connected flags to get set, but at least one canonically robust example would be great.
1 Like
Sorry to chime in here too 
One big advantage of SYSTEM_THREAD(ENABLED) over the non-AUTOMATIC modes is that even the short blocking periods imposed on your own code by the actions required for WiFi.connect() and Particle.connect() are now hidden away and won’t be noticable.
You just call Particle.connect() and forget about it till Particle.connected() just goes true - no need to wait.
This might mean some change in code flow tho’ - but if the non-blocking aproach was already taken before multi-threading, this should already wrapped up correctly.
I mostly agree, except that WiFi.listen() apparently still blocks user code. For at least non-hobbyist users (like me) who need to control the minutiae of the user onboarding experience, MANUAL mode is required to have a very controlled bring-up of connectivity. Of course, ultimately everyone’s going to have their own decision tree of business logic (reconnect after disconnect? time out and give up? automatically enter listen? etc.) but at minimum, a snippet of code that shows the path to (re)connectivity within loop() would be great. This sounds elementary, but for instance I’m not even sure if it’s safe to call Particle.connect() in a tight loop, or WiFi.connect(), etc., so the example should allow for some application code to coexist within loop() without introducing any delays to manage connectivity.
3 Likes
True, but WiFi.listen() should not usually be considered part of the standard reconnection procedure of an already setup device.
It’d be done as a prerequisite to get things setup “once” (or rather infrequently) and since at least the Photon does exhibit fundamentally different behaviour (e.g. act as SoftAP) you could maybe liken this mode more to the BIOS setup mode of your desktop computer where no user applications will be serviced either.
You can instruct the OS to prepare to enter into BIOS/UEFI on next bootup, but once it will enter, the OS usually hasn’t got any say, till BIOS/UEFI hands control back.
Nevertheless your call for a exemplary connection procedure with comprehensive DOs and DONTs would definetly be desirable.
One specific use-case I had in mind is when a user first brings a new product into their home, the wifi will never have been set up. To ease the onboarding process, I figured the firmware could automatically enter listen mode for some amount of time when the device is powered on. Granted, this isn't necessarily the best example since perhaps opening up an unsecure AP in a user's home isn't the best thing to do.
Even if this is a reconnection and not a first-time connection, without being able to execute, the amount of feedback the firmware can give the user is limited without exposing them to details of the Photon - like what the blinky colors mean and what the buttons do. It's not just feedback, either. What if we want our own button to trigger listen mode, or say an entirely different kind of input method?
I'm mainly pushing this in order to improve the consumer-facing experience we (as firmware developers) can design given the limitations of the hardware, the environment the firmware is running in, and the softAP setup process. We want to hide the complexity of the whole setup process as much as we can so users don't have to feel like they are "entering the BIOS settings", which is not something anyone ever does to just set up or change wifi settings on a device.
This isn't so much a complaint as it is a request for guidelines and good practices for implementing our own connection management.
2 Likes
I agree. While we aim to provide an out-the-box experience that is suitable for many, it’s not possible to make one that suits all, and so flexibility is needed so that all the default options and behavior can be changed.
I don’t have any concrete guidelines around this but would welcome starting a new thread to discuss this.
2 Likes