Is a delay at beginning of sketch a bad idea?

My question is is it a bad idea to put a 10 or 15 second delay at the very beginning of a sketch? I’ll explain:

I have a bug in a sketch that hangs while using the http client. I am working on that bug. However, it seems to cause me to often not be able to OTA update firmware with a new one. If I hardboot the core and then send the sketch immediately I can get it in but if I let it run for more then a few seconds and hit my bug I can’t update it.

I think the core is rebooting after hitting this bug but I have not proven that yet. If it is rebooting and I put a delay at the beginning it might give me enough time to get the new sketch in.

Is this a terrible idea?

Here’s a different way of doing it–use an input pin to switch your loop() to just wait forever for a reflash. That way if things go really south, you can reset your with the pin tied high and it will stop at the beginning of loop() and wait for you to reflash it.

void loop() {
   int pin = digitalRead(D0);
    if (HIGH==pin) {
        Serial.print(" Waiting...");
        for(;;) {
        SPARK_WLAN_Loop();
        }
    }
// rest of loop here...

That’s a good idea and I will use it. Thank you.

However, I am often working on these remotely. Trying to come up with a way to update them when they get in this state and no one is there.

Maybe calling Spark.process() somewhere in your code might help with this.

Or using a Spark.function() to disable user code and o ly run and empty loop() by setting a flag might be useful :wink:

2 Likes

If the cores are remote, you can turn the idea around and put a while loop at the start of the loop() function that waits for a Spark.function() to be called which sets a boolean “go” variable in your sketch. That way the core waits to be re-flashed until you explicitly say go by calling the Spark function you have set up.

[Edit: @kennethlimcp beat me to it, I see! I need to type faster next time.]

2 Likes