@chap @bko We just deployed today the result of our spec’d github issue Controlling the Connection. Documentation forthcoming this week, probably tomorrow.
Wrote and then deleted a bunch of stuff because I misunderstood your issue…
Actually, mostly never mind there—I see you’re already using the workaround
spark_disable_cloud.h. You no longer need that as of today. Use
SYSTEM_MODE(SEMI_AUTOMATIC) instead. However, I see that’s not what you’re asking about.
OK, switching to more in-depth firmware explanation mode.
When you call
Spark.connect(), all you’re doing is setting a flag. That returns immediately.
loop finishes, we go handle all the background Cloud stuff in
If you need to connect to Wi-Fi, we do so here, which calls
WiFi.connect(). This is also really fast because it’s asynchronous, sending some messages to the CC3000 and returning. If the Wi-Fi module is not even on, then
wlan_start can take some milliseconds, but basically you won’t notice this.
Now your code goes back to running.
Later, when the CC3000 successfully gets an IP address from the router, we get an asynchronous event, which sets some flags and turns the LED green.
SPARK_CLOUD_CONNECT flag we set a while back? Now, after your loop runs and we go back to the background stuff, we now actually get past this return statement and because
WLAN_DHCP is set, we get to
Spark_Connect() defined here.
After some quick initial work to read the server address off the external flash chip, we actually open up the TCP socket to the Spark Cloud here, with the call to connect (TI doxygen). As you can see in the code surrounding the
connect call, we’ve implemented a watchdog that will kill the attempt to connect if it takes too long. Over in the
core-common-lib repo, you can see this is set to 8 seconds. If you’re building locally, adjust as you see fit.
Assuming the TCP socket got opened successfully (potentially 7.99 seconds later, but obviously usually much faster), then we attempt the secure handshake with the Cloud in
Spark_Handshake() defined here.
This is where we drop out to the
core-communication-lib here to do some encryption and send a handful of messages back and forth, all of which must complete before we head back to your
If you (and ten other capable people!) want to measure how long each of these steps takes, I’d be curious to hear your results. I suspect that the CC3000’s
connect varies a great deal and is usually the longest blocking call. I suspect that the communication library handshake, including the encryption, is much more consistent. It would vary a bit due to internet connection speed, but we’re only sending two messages each direction (plus TCP ACKs of course), for a total of 698 payload bytes + IP and ethernet frames.
And if you have ideas for improvements, we are, as always, all ears.
I hope this helps you understand all the states during which you could be receiving input, when your loop would be running, and when it will be blocked by other work. Cheers!