What is USART CTS latency?

[paulrbryson]

I am starting a product design tentatively using the STM32F072RBT6.

I want to determine how soon the CTS input must go low to prevent the USART from transmitting the next byte.
Even informed opinion would be appreciated; but a reference to documentation or direct experience would be  preferable.

One note in the reference manual says, 

"For correct behavior, CTS must be de-asserted at least 3 USART clock source periods
before the end of the current character."  page 740, Reference Manual PDF 

[What about the first character?]  I assume that what they mean is "before the beginning of the next character"? 

Which clock is "USART clock source"?
In this diagram from the reference manual the ultimate source clock seems to be Fck,  but the diagram seems to show that only the slower "Transmitter clock" is used for "Transmit control".
Note that this diagram shows obvious incorrect or at least misleading info for the receiver clock. [So, can this diagram really be trusted?]

 

[Uwe Bonnes]

Probably the 8x/16x Uart Bit sampling clock is meant. Probably "end of current character" means the stop bit. So probaly when CTS is deasserted in the first half of the stop bit, you are on the save side. Some confirmation from ST would be fine.

Or better the CTS controlling side should deassert when there is still one word space in the .fifo to be on the safe side.

 

[paulrbryson]

Thanks for your help.
What about the case where there is a gap between the characters or the first character in a message.  That is why I think they really mean "before start of next character".  Also CTS has no effect on the current character - only on the start of the next. Btw, that is the case I am interested in - not continuous transmission.

[paulrbryson]

So, I ordered an eval board and measured the CLS latency.

Yellow Trace = USART TX data (run thru a high pass filter; data byte = 0x00; The low going pulses are the beginning of a TX.)

Blue Trace = CLS

Baud Rate = 4800
fck = 48MHz (21nS period)

After running for more than an hour, I was only able to capture a single transfer which started after the de-assertion of CLS.  And this one transfer started within 100ns of the CLS de-assertion.  From this I conclude that the clock referenced by, "at least 3 USART clock source periods" is fck.