Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entering listening mode does not block the system thread #788

Closed
m-mcgowan opened this issue Dec 26, 2015 · 7 comments

Comments

@m-mcgowan
Copy link
Contributor

commented Dec 26, 2015

Currently, when the device enters listening mode, the thread running system code enters a tight loop servicing the listening mode implementation:

  • on entry to listening mode, setup the radio hardware for listening (Core: enter smart setup mode, Photon: start soft AP.)
  • blinking the LED blue at 250ms intervals
  • detecting when the WiFI profiles should be deleted and deleting them (flashing the LED quickly in the process)
  • on exit from listening mode, the radio os reset to the normal state. (Core: exit smart config mode, Photon: tear down SoftAP and reinstate STA mode.)

Some consequences of this implementation:

  • the cloud is not serviced during listening mode, nor are any of the other background thread processes.
  • application code does not execute during listening mode in single threaded mode. In multithreaded mode, application code is intended to be executed (but may fail presently due to issues with the system thread being blocked.)
  • Serial is used to receive commands during listening mode - this is interleaved with whatever the application was presently doing with Serial.

On the Photon, entering listening mode specifically tears down all sockets and the current wifi connection. This is to mirror the behavior on the Core. In future, we can run listening mode in parallel with regular STA WiFi without having to tear down the existing wifi connection. To this end, we have plans to allow the SoftAP mode to be used by application code, where the photon supports 2 network interfaces at the same time.

The solution will need to consider how Serial is handled in the case when the application loop continues to run, since Serial will be used by both the listening mode loop and application code. One possible approach is to allow the application to specify if listening mode should activate the Serial interface or not. The setting also takes affect when the end user manually enters listening mode by pressing Setup for 3 seconds.

@m-mcgowan m-mcgowan changed the title Entering listening mode does not block the background loop Entering listening mode does not block the system thread Dec 26, 2015

@m-mcgowan m-mcgowan added this to the 0.4.9 milestone Jan 11, 2016

@karlhenricksen

This comment has been minimized.

Copy link

commented Jan 14, 2016

@m-mcgowan - I see slow blinking blue LED when calling Wifi.hasCredentials() in listening mode and the user app is blocked due to that. Is this behavior the same issue?
https://www.youtube.com/watch?v=SNmeHpOhAB0

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Jan 14, 2016

Yes. If you are building locally, you can try the latest develop state which allows the application to run while in listening mode.

@karlhenricksen

This comment has been minimized.

Copy link

commented Jan 15, 2016

@m-mcgowan I tried the latest dev version, and I no longer see the slow blinking blue, but still see that if we call Wifi.hasCredentials() while we're not connected to wifi but we DO have credentials, our user app is still blocked. We've been able to reproduce this easily by calling Wifi.hasCredentials() right after entering listening mode with credentials (this is done within a wifi reset function in our case). User pgm is blocked after a quick blue flash, and Photon's LED stays at a solid cyan:
https://www.youtube.com/watch?v=Nck-RoLtJBI

Not sure if this is still the same issue or you would prefer I open a separate issue describing that behavior.

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Jan 15, 2016

Thanks for testing! DId you flash the system modules to the device? (You can verify by connecting to serial in listening mode, pressing v should print version 0.4.8-rc.6)

I tried this app on a photon that has WiFI credentials configured:

#include "application.h"

SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(MANUAL);

void setup()
{
    WiFi.listen();

}

void loop()
{
    WiFi.hasCredentials();
    delay(500);
    Serial.println(millis());
}

I'm seeing loop freely execute and the Serial output produced. I hope you can verify this. Thanks!

@karlhenricksen

This comment has been minimized.

Copy link

commented Jan 15, 2016

Yes, we did check on the system file and verified it was correct. But we did a little more digging into how this is occurring and it looks like a 2s delay following the wifi reset within listening mode (which we were using to debug #804) was causing the user/system crash upon entering listening mode.

We won't do this in the final product, but seems worth noting and being aware of if that delay is in fact an issue. Should I open a separate issue for this?

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Jan 15, 2016

Yes, please, and if you could post a minimal app that produces the problem that would be very much appreciated.

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Jan 19, 2016

This has been resolved in PR #793 and verified with automated tests.

@m-mcgowan m-mcgowan closed this Jan 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.