Does delay(ms) prevent Serial operations?

Hi - I have this bit of code that writes to the register on an external board requesting some data and then reads the response back. This code calls some utility code to write to the serial port and read from the serial port.

This mostly works ok with one external board attached but fails @ half the time when I have a 2nd board attached.

I tried putting in delays, etc. to give the external board time to respond but it didn’t help.

So my questions-

–does a delay called immediately after a serial operation affect that operation at all? (i.e. are Serial read/writes threaded)

–is there a limit to serial buffer size that I might be exceeding, and if so is there a way to increase buffer size.

(fwiw - this is with the Wiring board but I think it uses the same Serial lib.)



int  ReadReg(int boardID, int RegAdr, int RegLen) {
  // Reads a value from a Gamoto Register
  int Regvalue=0;
  long bytes_read;
  // Build the command
  wBuffer[0]= boardID;
  wBuffer[1]= gxWRITE;
  wBuffer[2]= RegAdr;
  wBuffer[3]= RegLen;
  wBuffer[4]= CheckSum(wBuffer,4);
  // Send the command


  // Get the response
  if (bytes_read>0){
    // We got a response - now parse the result
    for (int i=0;i<RegLen;i++) {
      Regvalue += rBuffer[i+1] * (1<<(8*i));
    // Handle negative case
    if (Regvalue >= (1<<(8*RegLen))/2)
      Regvalue -= 1<<(8*RegLen);
  return Regvalue;

Serial.print() is synchronous. That is, it is done and all the bits have left the board before the next statement after the call is executed. reads from a receiving buffer. Serial.available() checks if there are any entries in the buffer. Characters get into the buffer from an interrupt-service-routine, so if you lock out interrupts for too long, the characters can be lost. The buffer is of a limited size, so if you don't call to fetch them regularly, the buffer can fill up and characters can be lost. The default size of the board is 128 bytes, defined in hardware/cores/arduino/wiring_serial.c. That's fairly generous.

Thanks - that’s helpful.

One detail - so delay(ms) will lock out interrupts or am I misreading?

Similarly, would looping also lock out interrupts? Something like this:

while (Serial.available() != numOfBytesExpected){
//do nothing

The delay() function doesn’t “lock out” interrupts. However it does rapidly call millis() which does momentarily block interrupts (while checking the timer). So it’s technically possible to lose an interrupt. That being said, I’ve never seen it happen. I think in reality the hardware UART interrupt still happens but is momentarily delayed by the interrupt disabling in millis(). Other types of interrupts are probably more at risk.

Checking Serial.available() in a loop has no affect on interrupts.

So it's technically possible to lose an interrupt.

If an interrupt tries to happen when interrupts are blocked, the routine will be called immediately after interrupts are enabled again. Of course, by that time, a serial bit might not be available on the input anymore. This is pretty unlikely for most "normal" baud rates, which are fairly slow as far as processing speed goes.

If two interrupts of the same kind happen while interrupts are blocked, the routine will be called only once after interrupts are enabled again.