@mohit I tested this firmware branch a bit ago with some of my problematic user test code.
That code is for a SainSmart TFT LCD display and has many long delays to give me time to view the results on the display. The LCD communication is via SPI. The code also includes Serial1 output for debugging. Unfortunately, with all the 2-4 second delays in the user code, the Spark Core quickly drops off wireless such that the test code cannot be updated via the web IDE.
This build fixes those issues.
The Spark Core stays online such that I can continue to tweak the code in the web UI and push those changes over wireless.
Regarding the concerns raised above…
To at least partially address some of the concerns above, is it possible to only do the WiFi loop if the user code is already executing a
delay call? In other words, if the user code isn’t doing anything but waiting for the next 100ms or longer, then allow the system code to do a WiFi loop. I think this should be the default behavior.
If someone needs a “hard delay” that is more accurate and doesn’t yield, then they can call a new function, say,
wait that works like
delay did prior to this change.
BTW, you may also want to add a
yield function that explicitly allows the WiFi loop to run during long user code sequences.
Bottom line: If I specify a 2000ms delay in my test code, I don’t care if that delay really takes 2050ms. However, I do care that I can’t update my user code because the Spark Core drops off of WiFi permanently. I like this decoupling feature but I think the user code should be able to control whether it’s enabled (the default) or not.