Jump to content
43oh

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


Recommended Posts

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.

Link to post
Share on other sites

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?

Link to post
Share on other sites

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;
  }
}

Link to post
Share on other sites

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?

Link to post
Share on other sites

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!

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...