RobertWoodruff 7 Posted May 17, 2016 Share Posted May 17, 2016 Without this delay call the Serial device/UART only seems to receive Quote Link to post Share on other sites
abecedarian 330 Posted May 18, 2016 Share Posted May 18, 2016 If you change Serial.write("AT\r\n"); to Serial.println("AT\r\n"); do you still need the delay? Quote Link to post Share on other sites
chicken 630 Posted May 18, 2016 Share Posted May 18, 2016 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. energia and tripwire 2 Quote Link to post Share on other sites
RobertWoodruff 7 Posted May 18, 2016 Author Share Posted May 18, 2016 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? Quote Link to post Share on other sites
chicken 630 Posted May 18, 2016 Share Posted May 18, 2016 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 1 Quote Link to post Share on other sites
energia 485 Posted May 18, 2016 Share Posted May 18, 2016 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; } } tripwire and dubnet 2 Quote Link to post Share on other sites
RobertWoodruff 7 Posted May 18, 2016 Author Share Posted May 18, 2016 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? Quote Link to post Share on other sites
RobertWoodruff 7 Posted May 18, 2016 Author Share Posted May 18, 2016 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! tripwire 1 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.