Run user setup() and loop() at boot-up even if Core is not connected to Cloud #172

Closed
satishgn opened this Issue Apr 10, 2014 · 23 comments

Comments

Projects
None yet
@satishgn
Contributor

satishgn commented Apr 10, 2014

@kennethlimcp

This comment has been minimized.

Show comment
Hide comment
@kennethlimcp

kennethlimcp Apr 10, 2014

Contributor

Another similar issue i would like to point out is also when there is 0 Wifi profile in the spark core.

The default now is to enter Listening Mode, perfect for a beginner! But what if i just want to build locally and run offline without a Wifi connection?

I must somehow use USB or Wifi to set at least one profile for now.

Debatable and hard to decide issue i think? But you guys at the Spark team have the call as always :D

Contributor

kennethlimcp commented Apr 10, 2014

Another similar issue i would like to point out is also when there is 0 Wifi profile in the spark core.

The default now is to enter Listening Mode, perfect for a beginner! But what if i just want to build locally and run offline without a Wifi connection?

I must somehow use USB or Wifi to set at least one profile for now.

Debatable and hard to decide issue i think? But you guys at the Spark team have the call as always :D

@towynlin

This comment has been minimized.

Show comment
Hide comment
@towynlin

towynlin Apr 10, 2014

Member

Great point @kennethlimcp, and we have a plan for this. Definitely there are many product cases where the user code should run before any Wi-Fi credentials are set. Since Smart Config blocks in the CC3000 host driver, we plan to add some "modes" that the user can set. The default will be the current beginner-friendly behavior, but other modes would allow more manual control.

Member

towynlin commented Apr 10, 2014

Great point @kennethlimcp, and we have a plan for this. Definitely there are many product cases where the user code should run before any Wi-Fi credentials are set. Since Smart Config blocks in the CC3000 host driver, we plan to add some "modes" that the user can set. The default will be the current beginner-friendly behavior, but other modes would allow more manual control.

@kennethlimcp

This comment has been minimized.

Show comment
Hide comment
@kennethlimcp

kennethlimcp Apr 10, 2014

Contributor

Sounds awesome! Thanks for listening to the feedback :)

Contributor

kennethlimcp commented Apr 10, 2014

Sounds awesome! Thanks for listening to the feedback :)

@kennethlimcp

This comment has been minimized.

Show comment
Hide comment
@kennethlimcp

kennethlimcp Apr 12, 2014

Contributor

@towynlin,

so this topic appeared in the community for like 2-3 times just this week alone and just wanted to send a pulse for this.

I guess you guys might want to see if this is worth the next sprint? :)

Contributor

kennethlimcp commented Apr 12, 2014

@towynlin,

so this topic appeared in the community for like 2-3 times just this week alone and just wanted to send a pulse for this.

I guess you guys might want to see if this is worth the next sprint? :)

@zingabuka

This comment has been minimized.

Show comment
Hide comment
@zingabuka

zingabuka Apr 13, 2014

+1 for this,
it would be best if the core can be run completely offline , so can be used in various scenario where there is no internet connection and spark-core can be used to communicate with other wifi devices over intranet.

If running core completely offline cant be doable then at least connecting core to internet at the first run only is doable. or even updating/uploading code from internet and running core without internet is feasible too.
my 2 cents.

+1 for this,
it would be best if the core can be run completely offline , so can be used in various scenario where there is no internet connection and spark-core can be used to communicate with other wifi devices over intranet.

If running core completely offline cant be doable then at least connecting core to internet at the first run only is doable. or even updating/uploading code from internet and running core without internet is feasible too.
my 2 cents.

@zsup

This comment has been minimized.

Show comment
Hide comment
@zsup

zsup Apr 13, 2014

Member

Hey guys, this is in the works! We'll be doing sprint planning on Monday and will definitely consider this as a much-requested feature.

Member

zsup commented Apr 13, 2014

Hey guys, this is in the works! We'll be doing sprint planning on Monday and will definitely consider this as a much-requested feature.

@nataliefreed

This comment has been minimized.

Show comment
Hide comment
@nataliefreed

nataliefreed Apr 22, 2014

+1! For making objects that travel from one network to another and don't stop working completely when they can't connect. Have been postponing taking apart a project to add a separate microcontroller in the hope that this feature will be added soon...so fingers crossed here, thanks for considering this.

+1! For making objects that travel from one network to another and don't stop working completely when they can't connect. Have been postponing taking apart a project to add a separate microcontroller in the hope that this feature will be added soon...so fingers crossed here, thanks for considering this.

@issackelly

This comment has been minimized.

Show comment
Hide comment
@issackelly

issackelly May 6, 2014

@zs- I assume that there was a whole sprint and sprint planning since the last comment.

I need to tackle this personally for two of my projects, that is unless it's happened/going to happen shortly.

Thanks!

@zs- I assume that there was a whole sprint and sprint planning since the last comment.

I need to tackle this personally for two of my projects, that is unless it's happened/going to happen shortly.

Thanks!

@nataliefreed

This comment has been minimized.

Show comment
Hide comment
@nataliefreed

nataliefreed May 6, 2014

An additional thought about why I think this is such a hugely important feature: without this, it's impossible to design fault-tolerant applications with the Spark Core alone. No matter how robust the Spark Core is, there's nothing it can do if the network is flaky (like most home networks in my experience!) When I design anything that needs to communicate with another system, I consider it critical engineering practice to anticipate a response to communication failure, and I can't seem to do that with the Spark Core's current behavior. The discussion in the other thread mentioned "increase in requirement of users wanting to run their code without internet/wifi" - but I want to add that it's not just about applications that don't require internet at certain times, it's also about being able to design an application that always responds reasonably when the network drops out. At a certain point that's the application designer's responsibility, not Spark Core's -- this feature is one of the tools that makes it possible for the application designer to take that responsibility on. (I truly hope I haven't misunderstood the issue, but wanted to try to explain what I can't find documented here yet).

An additional thought about why I think this is such a hugely important feature: without this, it's impossible to design fault-tolerant applications with the Spark Core alone. No matter how robust the Spark Core is, there's nothing it can do if the network is flaky (like most home networks in my experience!) When I design anything that needs to communicate with another system, I consider it critical engineering practice to anticipate a response to communication failure, and I can't seem to do that with the Spark Core's current behavior. The discussion in the other thread mentioned "increase in requirement of users wanting to run their code without internet/wifi" - but I want to add that it's not just about applications that don't require internet at certain times, it's also about being able to design an application that always responds reasonably when the network drops out. At a certain point that's the application designer's responsibility, not Spark Core's -- this feature is one of the tools that makes it possible for the application designer to take that responsibility on. (I truly hope I haven't misunderstood the issue, but wanted to try to explain what I can't find documented here yet).

@towynlin

This comment has been minimized.

Show comment
Hide comment
@towynlin

towynlin May 6, 2014

Member

Thanks @issackelly, @nataliefreed, and others. We hear you loud and clear. The sprint that just begun is primarily focused on community libraries and Maker Faire. After Maker Faire, you can count on this being top priority.

Member

towynlin commented May 6, 2014

Thanks @issackelly, @nataliefreed, and others. We hear you loud and clear. The sprint that just begun is primarily focused on community libraries and Maker Faire. After Maker Faire, you can count on this being top priority.

@ofZach

This comment has been minimized.

Show comment
Hide comment
@ofZach

ofZach May 10, 2014

sorry, don't mean to pile on here, but this is a hugely important issue for me as well -- I'm designing a project that will use a significant number of cores that I want to communicate with potentially spotty internet access (I am going to be communicating w/ them locally with them over the intranet) and I need to make sure they are robust. @nataliefreed's comment about fault tolerance is exactly spot-on.

ofZach commented May 10, 2014

sorry, don't mean to pile on here, but this is a hugely important issue for me as well -- I'm designing a project that will use a significant number of cores that I want to communicate with potentially spotty internet access (I am going to be communicating w/ them locally with them over the intranet) and I need to make sure they are robust. @nataliefreed's comment about fault tolerance is exactly spot-on.

@towynlin

This comment has been minimized.

Show comment
Hide comment
@towynlin

towynlin May 10, 2014

Member

No worries @ofZach, thanks for the feedback!

Member

towynlin commented May 10, 2014

No worries @ofZach, thanks for the feedback!

@teravolt93065

This comment has been minimized.

Show comment
Hide comment
@teravolt93065

teravolt93065 Jul 13, 2014

I've been counting on this being top priority... Any progress?

I saw the video of the internet connected dog feeder. Great idea, but does the dog starve when wifi is down?

I've been counting on this being top priority... Any progress?

I saw the video of the internet connected dog feeder. Great idea, but does the dog starve when wifi is down?

@zsup

This comment has been minimized.

Show comment
Hide comment
@zsup

zsup Jul 15, 2014

Member

Hi @teravolt93065 - it is in progress, @towynlin can provide a timeline for release of the improvements. It got pushed off a bit because we have been prioritizing the release and distribution of the CC3000 firmware update, which will happen next week.

Member

zsup commented Jul 15, 2014

Hi @teravolt93065 - it is in progress, @towynlin can provide a timeline for release of the improvements. It got pushed off a bit because we have been prioritizing the release and distribution of the CC3000 firmware update, which will happen next week.

@towynlin

This comment has been minimized.

Show comment
Hide comment
@towynlin

towynlin Jul 15, 2014

Member

After we release the CC3000 patch, a.k.a., deep update, early next week, then releasing a new firmware version will be on the short task list. The code is already written in pull request #229 for issue #216 and awaits my review and merging. It will definitely be included in the next firmware release. Anyone who is building locally can of course use (and test! and comment on test results!) that code now.

Using that "controlling the connection" code, in order to run setup() and loop() immediately upon boot, one simply needs to specify SYSTEM_MODE(SEMI_AUTOMATIC) or SYSTEM_MODE(MANUAL), rather than the default SYSTEM_MODE(AUTOMATIC). See the issue description for the intent of the modes.

We'll release a new firmware version during Sprint 16, currently scheduled for 7/24–8/6.

Member

towynlin commented Jul 15, 2014

After we release the CC3000 patch, a.k.a., deep update, early next week, then releasing a new firmware version will be on the short task list. The code is already written in pull request #229 for issue #216 and awaits my review and merging. It will definitely be included in the next firmware release. Anyone who is building locally can of course use (and test! and comment on test results!) that code now.

Using that "controlling the connection" code, in order to run setup() and loop() immediately upon boot, one simply needs to specify SYSTEM_MODE(SEMI_AUTOMATIC) or SYSTEM_MODE(MANUAL), rather than the default SYSTEM_MODE(AUTOMATIC). See the issue description for the intent of the modes.

We'll release a new firmware version during Sprint 16, currently scheduled for 7/24–8/6.

@dkowalewski

This comment has been minimized.

Show comment
Hide comment
@dkowalewski

dkowalewski Jul 22, 2014

Could You paste some code (application.cpp) using SYSTEM_MODE(MANUAL) ? I'm trying to change WiFi access point inside loop with no luck. Spark is seems to be listening for WiFi config and do not enter into loop function.

Could You paste some code (application.cpp) using SYSTEM_MODE(MANUAL) ? I'm trying to change WiFi access point inside loop with no luck. Spark is seems to be listening for WiFi config and do not enter into loop function.

@henriquesa

This comment has been minimized.

Show comment
Hide comment
@henriquesa

henriquesa Jul 23, 2014

Hey guys, just making sure, this isn't included on the deep update patch, right? It's yet to come?

Hey guys, just making sure, this isn't included on the deep update patch, right? It's yet to come?

@towynlin

This comment has been minimized.

Show comment
Hide comment
@towynlin

towynlin Jul 23, 2014

Member

Correct, this is not in deep update. As stated above, deep update was first priority, after which we'll include releasing new firmware with the system modes and connection control on the next sprint before August 6.

Member

towynlin commented Jul 23, 2014

Correct, this is not in deep update. As stated above, deep update was first priority, after which we'll include releasing new firmware with the system modes and connection control on the next sprint before August 6.

@wesner0019

This comment has been minimized.

Show comment
Hide comment
@wesner0019

wesner0019 Aug 7, 2014

Contributor

Just curious if this will be released this week?

Contributor

wesner0019 commented Aug 7, 2014

Just curious if this will be released this week?

@kennethlimcp

This comment has been minimized.

Show comment
Hide comment
@kennethlimcp

kennethlimcp Aug 7, 2014

Contributor

This has been implemented with 1684df5 but the documentation is not yet available.

Contributor

kennethlimcp commented Aug 7, 2014

This has been implemented with 1684df5 but the documentation is not yet available.

@wesner0019

This comment has been minimized.

Show comment
Hide comment
@wesner0019

wesner0019 Aug 9, 2014

Contributor

Thanks, is the newest stock firmware automatically uploaded when uploading from the website? Or does this need to be done manually through DFU?

Contributor

wesner0019 commented Aug 9, 2014

Thanks, is the newest stock firmware automatically uploaded when uploading from the website? Or does this need to be done manually through DFU?

@zsup

This comment has been minimized.

Show comment
Hide comment
@zsup

zsup Aug 9, 2014

Member

Automatically distributed through the Web IDE!
On Aug 9, 2014 8:26 AM, "wesner0019" notifications@github.com wrote:

Thanks, is the newest stock firmware automatically uploaded when uploading
from the website? Or does this need to be done manually through DFU?


Reply to this email directly or view it on GitHub
#172 (comment).

Member

zsup commented Aug 9, 2014

Automatically distributed through the Web IDE!
On Aug 9, 2014 8:26 AM, "wesner0019" notifications@github.com wrote:

Thanks, is the newest stock firmware automatically uploaded when uploading
from the website? Or does this need to be done manually through DFU?


Reply to this email directly or view it on GitHub
#172 (comment).

@m-mcgowan

This comment has been minimized.

Show comment
Hide comment
@m-mcgowan

m-mcgowan Sep 6, 2014

Contributor

SYSTEM_MODE(SEMI_AUTOMATIC) on a core with no wifi credentials. Successful test running user code without a wifi connection.

Contributor

m-mcgowan commented Sep 6, 2014

SYSTEM_MODE(SEMI_AUTOMATIC) on a core with no wifi credentials. Successful test running user code without a wifi connection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment