EB500 to BS2 loosing chars with hardware flow control.
tea333
Posts: 10
When using the code·pasted at the bottom of this email, I·send the following string over bluetooth to the BS2 (to the code·far·below):
"[url=mailto:abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$%^&*()_+-={}[]\|:";'<>?,./]abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$%^&*()_+-={}[noparse]/noparse\|:";'<>?,./[/url]"
I did two identical tests sending the above string. I show the DEBUG output for both attempts (see pasted below).
The "abcde" is always received in both cases. But subsequent characters are mostly lost. (Once again, see DEBUG output below.)
I'd expect CTS high would stop 'f' until the next read. Is that not happening due to latency between SERIN getting 'e' and raising CTS? Is it the way Bluecore2 sends data to the UART? 9600 seems slow enough but I've not worked with this PIC enough to know certainly 9600 is fast enough to beat the processor to raising CTS. (?)
Here is the BS2 DEBUG output of both attempts (different chars are lost on different attempts):
Attempt #1:
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt abcde
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt 23456
Attempt #2:
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt abcde
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt Z1234
BS2 Code snippet:
TryRead:
· GOSUB ClearPkt
· ' Read bufferred character, clearing UART_CTS (inactive high) when done
· SERIN 0\2,84,BadData,wTimeOut,NoData,[noparse][[/noparse]STR Buf\5]
· bGotPkt = 1
· nBufLen = 5
· Buf(nBufLen) = 0
· RETURN
BadData:
· DEBUG "PE", CR
· RETURN
NoData:
· RETURN
ClearPkt:
· Buf(0) = 0
· nBufLen = 0
· bGotPkt = 0
· RETURN
"[url=mailto:abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$%^&*()_+-={}[]\|:";'<>?,./]abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$%^&*()_+-={}[noparse]/noparse\|:";'<>?,./[/url]"
I did two identical tests sending the above string. I show the DEBUG output for both attempts (see pasted below).
The "abcde" is always received in both cases. But subsequent characters are mostly lost. (Once again, see DEBUG output below.)
I'd expect CTS high would stop 'f' until the next read. Is that not happening due to latency between SERIN getting 'e' and raising CTS? Is it the way Bluecore2 sends data to the UART? 9600 seems slow enough but I've not worked with this PIC enough to know certainly 9600 is fast enough to beat the processor to raising CTS. (?)
Here is the BS2 DEBUG output of both attempts (different chars are lost on different attempts):
Attempt #1:
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt abcde
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt 23456
Attempt #2:
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt abcde
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt Z1234
BS2 Code snippet:
TryRead:
· GOSUB ClearPkt
· ' Read bufferred character, clearing UART_CTS (inactive high) when done
· SERIN 0\2,84,BadData,wTimeOut,NoData,[noparse][[/noparse]STR Buf\5]
· bGotPkt = 1
· nBufLen = 5
· Buf(nBufLen) = 0
· RETURN
BadData:
· DEBUG "PE", CR
· RETURN
NoData:
· RETURN
ClearPkt:
· Buf(0) = 0
· nBufLen = 0
· bGotPkt = 0
· RETURN
Comments
PC--->RS-232 (pretend EB500)--->BS2--->same program that reads from EB500--->RS-232 (normal BS2 RS-232)--->Same PC
It looks like it handles the flow control well. If I pound it during a pause with this string:
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$%^&*()_+-={}[noparse]/noparse\|:";'<>?,./"
it reads abcde, pauses again, fghij, pauses, etc. (As pasted below.)
Looks like the EB500 isn't holding off on UART_CTS high as well as with normal RS-232. My guess is that either the Bluecore2 requires all held data to be read on next UART_CTS low (iow, flow control only holds new data during CTS high, and expects all waiting to be taken), or there is some other issue where the EB500 (Bluecore2) should behave differently. This is all a guess.
TryRead
Got pkt 12345
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt 67890
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt abcde
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt fghij
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt klmno
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt pqrst
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt uvwxy
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt zABCD
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt EFGHI
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt JKLMN
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt OPQRS
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt TUVWX
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt YZ123
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt 45678
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt 90!@#
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt $%^&*
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt ()_+-
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt ={}[noparse]/noparse
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt \|:";
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Got pkt '<>?,
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
TryRead
Pausing before AGAIN. Send chars via bluetooth to see if bufferred
Also, if I send the following to a single character SERIN read loop:
lmnopqrstuv
wxyzABCDEFG
etc
I get this:
Buf=ab
Buf=abc
Buf=abcd
Buf=abcde
Buf=abcdef
Buf=abcdefg
Buf=abcdefgh
Buf=abcdefghi
Buf=abcdefghij
Buf=abcdefghijk
Got pkt abcdefghijk
No lost characters.
Once again, looks like the EB500 isn't holding off on UART_CTS high either because the Bluecore2 requires all held data to be read on next UART_CTS low, or there is some other issue where the EB500 should behave differently.
·· I have contacted the designer of the EB500 and asked for some input on this.· Hopefully we can get some input on this soon.· Sorry for any delays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
The short answer is that the eb500-SER (revA and revB) is slow in generating and responding to the flow control signals. This can cause data loss if the device it is connected to does not have a FIFO (like the BS2). For more details take a look at this thread in the EmbeddedBlue discussion forum.
http://groups.msn.com/EmbeddedBlue/general.msnw?action=get_message&mview=0&ID_Message=799&LastModified=4675583543988158066
This problem will be fixed·with rev C·of the eb500-SER with version 2.1 firmware.
Bryan Hall
A7 Engineering
Is the firmware of exsisting modules upgradeable?
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info - Home of the Hydrogen Fuel Cell Robot