Why is the delay needed for reading from response from HC-05 over UART on a Launchpad 1.5?

[RobertWoodruff 7]

Without this delay call the Serial device/UART only seems to receive

[abecedarian 330]

If you change

 

Serial.write("AT\r\n");

 

to

 

Serial.println("AT\r\n");

 

do you still need the delay?

[chicken 630]

delay(500); // *** WHY IS THIS NEEDED ? ****

With the delay, all the characters of the response were received by the MCU and waiting in a buffer before you read it.

 

Serial communication is not instantaneous. At 9600 baud, the 4 characters will take about 4ms to be transmitted. Add to that the time it takes to actually send the command and the time for the Bluetooth module to process your command and you quickly get to a few 100ms.

 

You should check for the end of line to ensure you received the complete response.

[RobertWoodruff 7]

Hi Chicken,

 

Yes I understand that response from the Serial communications is not instantaneous.. My thinking is that with the traffic on the UART RX being processed by an ISR (interrupt service routine) that the incoming characters would be delivered to  serialEvent(), eventually (at least that is how it looks to me in the Energia source code). And that the response characters might not all come in at once but be delivered to serialEvent(), in dribs and drabs, in the future. Eventually, when the program detects the /r/n pattern it would know the response was complete.  

 

It is like the ISR has somehow been disabled and is not able to pick up all the traffic on the UART RX channel. Maybe I am misunderstanding how the Energia ISR's work and deliver the UART's RX traffic to serialEvent() ?

 

What do you think?

[chicken 630]

Hard to tell without seeing all the code code, the one above is missing where you read the buffer.

 

A few potential issues:

- the buffer offset variable should be declared as volatile if you use it inside and outside of the ISR.

- Serial.available() will return false for a while between characters.

[energia 485]

Note that serialEvent() is not executed in ISR context. What happens is that main() calls a function serialEventRun(). This function then calls Serial.available() to check if any characters are available. If they are it will call your serialEvent(). 

 

A quick "dirty" work-around to demonstrate that all char are recieved would to check if cmdBufferOffset == 4. If it is then you got the entire string you where expecting. As @@chicken mentioned, it is better to check for "\r\n" to make sure you got the response.

char cmdBuffer[128];
int cmdBufferOffset;
int AT_PIN = P1_3;


void setup()
{
  cmdBufferOffset = 0;

  /*
            * Init the BT device
   */
  Serial.begin(9600);
  pinMode(AT_PIN, OUTPUT);
  digitalWrite(AT_PIN, HIGH);

  delay(500); // Time to reach AT mode
  Serial.write("AT\r\n");
  //            delay(500); // *** WHY IS THIS NEEDED ? ****
}

void loop()
{
  if(cmdBufferOffset == 4) {
    Serial.print(cmdBuffer);
    cmdBufferOffset = 0;
  }
}

/*
* From BT device on UART
 */
void serialEvent(void) {
  while(Serial.available()) {
    int cInt = Serial.read();
    cmdBuffer[cmdBufferOffset++] = (char)cInt;
  }
}

[RobertWoodruff 7]

Hi Chicken,

 

That is all the code I wrote. The remainder is in the Energia libraries for TI (for the MSP430G2 LaunchPad). I get the bytes from the UART with the statement

 

int cInt = Serial.read();

 

Somehow, without the delay call, not all the bytes are delivered back to serialEvent(void). I can see this by watching the calls to serialEvent(void) via the Code Composer Studio debugger.

 

Wonder why the call to delay() lets all the info return to the UART, but without the delay() only some of the response gets back? It is like the ISR was/is disabled or something and the return traffic falls into bit bucket. Or maybe the CSS debugger is interfering?

 

Your thoughts?

[RobertWoodruff 7]

Believe I have this figured out.

 

It is the CSS debugger that interferes with the ISR routines. When the debugger is sitting at a breakpoint it keeps the ISRs from firing as expected which has the effect of causing input to the UART RX channel to appear to fall in the bit bucket. Not unexpected really by virtue of the way the debugger works.

 

The delay() call gave the IRS routines time to absorb all the responses before the debugger break point was reached. That is good news really, Because now we know that UART input continues to be accepted even when a delay() call is active.

 

So be careful when attempting to use debugger break points about the time the UART ISR routines might be firing. They will be disabled and input will get lost.

 

Otherwise the input from the HC-05 is coming in as expected on the UART RX channel.

 

Very cool!