OTA flash doesn't work during Serial I/O

[kcbudd]

I have a sketch that is using TinyGPS to read from a NMEA GPS.  As is typical when you have a serial sensor spewing lots of data, my sketch checks for and parses serial data at every iteration it can. 

It seems that doing so prevents OTA updates from working.  I'm in SEMI_AUTOMATIC mode, and during startup I actually run a dedicated function for 14 seconds to check in with the cloud and look for OTA updates.

This snippet, called during the setup() stage, works fine.  It waits for 14 seconds before starting loop() during which an OTA flash will interrupt it and succeed:

Code: [Select]

void cloudCheck() {
    Particle.connect();
    for (uint8_t i=0; i<70; i++) {
      analogWrite(LED, 1023);
      delay(100);
      analogWrite(LED, 0);
      delay(100);
      if (Particle.connected() == false) Particle.connect();
    }
}

The below snippet merely adds serial buffer checking and GPS parsing with the TinyGPS library during the delay() function.  (I took serDelay() from the tinyGPS example, and also use it elsewhere in my sketch.)  However, in this version - OTA always fails.  The LED blinks at the same rate, and the device shows up in the Particle.io dashboard as connected, but it never accepts an OTA request.  It seems like the Serial I/O is blocking/interrupting the OTA ability.

Code: [Select]

void parseGPS() {
  while(Serial.available())
    gps.encode(Serial.read());
}

void serDelay(unsigned long ms) {
  unsigned long start = millis();
  do {
    parseGPS();
  } while (millis() - start < ms);
}

void cloudCheck() {
    Particle.connect();
    for (uint8_t i=0; i<70; i++) {
      analogWrite(LED, 1023);
      serDelay(100);
      analogWrite(LED, 0);
      serDelay(100);
      if (Particle.connected() == false) Particle.connect();
    }
}

It's not a big deal to me, I just reverted to the top version of the startup function.  (I abandon the cloud after setup() anyway, hence the initial delay to check for OTA.)   But I can see where someone who was doing primarily serial I/O in the main loop() body might get into trouble with this, if that is indeed what's happening.  Is this a known/documented limitation?