Necessary loop intervals or delay timing for Spark API Housekeeping?

[chromegelato]

Continuing the discussion from LCD display getting corrupted:

@clyde

Hi *,

I do remember that I have the same problem with my i2c lcd display, but it´s been a while and I switched to a Digole OLED display right after writing the tutorial. I thought that I messed up things in my code and thus I getting these errors, so @BulldogLowell you proof me wrong, it´s seems that it is not my fault.

As far as I remember, with my 16x2, I have the problem after several hours, not after minutes. Can´t test it right now because my Core is in use and I´m waiting for my Photon

Continuing the discussion from Known issue: long delays or blocking code kills the connection to the Cloud:

@zach

That's true, our answers said the same thing, although they were worded differently. Basically:

1. It's ok to use long delay()s because in recent versions of the firmware, delay() calls a background task that services the Wi-Fi module's connection to the cloud
2. Passive delays by counting millis() is better practice
3. Code that blocks without calling Spark's background task (like while(1){}) will still kill the connection

Does that help clear things up?

I have a few questions on timing. While using a modified version of the I2C scanner code, I had some bad if logic that basically kept the core in a while loop. It was printing the same variable to serial, instead of incrementing and completing. Also I didn't have any delay statements (or minimal delay). I couldn't reflash or make an api/variable calls.
Is there guidelines on the amount of time necessary to let the spark core do internal cloud housekeeping aka connections? As in I should have x amount of millis or delay statements or finish the main loop every x seconds? I hope this make sense. I've also read that if you have too much delay, things can get "weird".Thanks!

[ScruffR]

You should allow for the cloud keeping at least once every 10sec - better more often.
If you want delay() to do that internally you’d need a delay > 1000ms (11x 900ms would never call SPARK_WLAN_Loop()).

[chromegelato]

Thanks!