Puzzled by USART behavior

[andyturk]

Posted on August 14, 2012 at 21:32

I'm porting over some code that I previously ran on Stellaris hardware to an F4Discovery board. I hooked a logic analyzer up to take a peek at what my USART code (with hardware flow control) was doing and found something I hadn't seen before.

RTS is going high at the end of each byte received by the MCU. I'm pretty sure that didn't happen with the Stellaris setup (I'd check it, but re-wiring the logic analyzer to another board is a pain).

I'll admit that the whole RTS/CTS thing drives me into dyslexic confusion, but it seems odd that either end of the connection would be signalling RTS at the *end* of a transmitted byte. Isn't flow control more useful before the data is sent?

Here's a screenshot from the logic analyzer:

http://turkish.smugmug.com/Electronics/Panasonic-13XX/24660876_PQSq5Z#!i=2025474323&k=pn5dqwm

The code is using USART3 with TX/RX on PD8/PD9 and RTS/CTS on PB14/PB13.

PS. Is there any way to include an image directly in a forum post? I tried the help link, but it brings up some generic MS help system.

[Tesla DeLorean]

Posted on August 14, 2012 at 22:06

Mountain/Sun Icon

+ Upload

Select (100KB file limit, JPG works better than PNG/GIF)

Upload

Insert

[andyturk]

Posted on August 15, 2012 at 01:07

Maybe less puzzled...

The datasheet says: ''

nRTS:

Request to send indicates that the USART is ready to receive a data (whenlow).''

So based on the logic trace, the MCU is ready to receive data most of the time, but at the end of each byte it says ''whoa!''. Perhaps that's because the byte hasn't been read out of the receive register by the interrupt routine?

The Stellaris part I was using before had a hardware receive FIFO. Maybe it never got to the point of raising RTS because the interrupt routine always cleaned out the FIFO before it filled up.

[Tesla DeLorean]

Posted on August 15, 2012 at 04:41

Yes, there is only one holding register, if you delay servicing RXNE you'll probably expand the RTS time.

[andyturk]

Posted on August 15, 2012 at 06:03

Interesting. This code is running under the hardware abstraction layer inside Chibios, but one would assume the interrupt is serviced promptly. The RTS pulse is actually 9.25 usecs in duration, which seems like an eternity for a 168MHz cpu. Maybe it's related to the bit timing for 115200 baud?

It'll be interesting to see what happens when the baud rate gets cranked up to 3M. My guess is that this is just the way a non ''buffered'' uart has to work. As long as there's a stop bit anyway (e.g., 8-N-1) it doesn't actually cost any time.