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

Interrupt cloud connection when entering listening mode or powering off the device via setup button #1260

Merged
merged 1 commit into from May 4, 2017

Conversation

@sergeuz
Copy link
Member

commented Feb 26, 2017

This PR implements #1067 by introducing a flag that can be set from an ISR and cause read/write operations on the cloud socket to fail with a generic error, effectively breaking any busy loop within the comms library.


Doneness:

  • Contributor has signed CLA
  • Problem and Solution clearly stated
  • Code peer reviewed
  • API tests compiled
  • Run unit/integration/application tests on device
  • Add documentation (N/A)
  • Add to CHANGELOG.md after merging (add links to docs and issues)

Enhancement

@sergeuz sergeuz added this to the 0.7.0 milestone Feb 26, 2017

@m-mcgowan

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2017

This is a good step towards interrupting the cloud connection. I wonder about some of the edge cases though...such was when the wifi network disappears or a socket doesn't timeout. Can we push the "pull the plug" functionality down into the networking layers too to the socket connect/read/write implementation in our various HALs? I know this is a big ask - async interruption of I/O is tricky - just would like to discuss and see what possibilities there might be. (For example, I believe the Electron HAL supports interruptible socket operations. )

@sergeuz

This comment has been minimized.

Copy link
Member Author

commented Feb 26, 2017

@technobly will correct me, but uBlox manual says that socket AT commands cannot be aborted, so if we want to interrupt a blocking socket call on Electron and keep the modem and the parser in a consistent state the only option is probably to reset the modem. As for the Photon, any blocking socket calls are normally aborted as part of the LwIP shutdown process which in turn is performed during WICED's WLAN uninitialization, so shutting down WLAN connectivity is the only option we have on the Photon, unless we add necessary calls to the WICED API to invalidate sockets selectively.

@technobly technobly added the bug label Apr 4, 2017

@m-mcgowan m-mcgowan self-requested a review Apr 18, 2017

@technobly technobly requested review from technobly and removed request for m-mcgowan May 4, 2017

@technobly technobly merged commit 2303f9e into develop May 4, 2017

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@technobly technobly deleted the fix/cancel_comms branch May 4, 2017

@technobly technobly added enhancement and removed bug labels Jun 14, 2017

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