Re: Uart baud rate matching

On a card that I am designing at the moment, the microcontroller will have a

>uart that will not be able to match standard baud rates exactly (because of >the clock speed it is running at). At 115200 baud, it will be 1.36% out. >As far as I understand it, this is not going to be a problem - there is only >a problem if the receiver and transmitter differ by 5% or more. The line >here is likely to be pretty stable (no noise or slow edges to reduce the >margins), and the other end of the communication is a PC, where the baud >rates are pretty much dead-on. Does anyone have experiance to suggest that >this might be a problem?

A 1.36% error combined with a nominal 0% error from the other end should present you with few problems.

If the other end was potentially 1.36% off in the opposite direction, You're looking at a combined potential error > 2%, which would make me nervous.

A 5% error would almost guarantee problems. Consider that about 10 bits are sent to transmit a single byte. Even though everything is re-synched at the beginning of each byte, the error within a byte accumulates so that the error at the end of the byte might be 50% or more of a bit width. Depending how the UART does its bit sampling, you could end up with an erroneous value for the last bit as much as

50% of the time.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen
Loading thread data ...

Typical RS-232 asynchronous serial communications require that each side's clock is accurate to within 2% of the nominal data rate. The receiver syncs up his clock at the leading edge of the start bit, but never resyncs during the frame. The receiver then tries to sample the remainder of the frame in the center of each bit. Assuming the sender and receiver are both off 2%, but in different directions, the receiver would be about 42% of a bit width off center by the time he got to the first stop bit on an 8-bit+parity "frame." IOW, just about ready to fall off the bit entirely.

Reply to
Robert Wessel

with

safe

That's pretty much what I thought, and what I have seen in practice. Thanks to all posters for confirming it.

David

Reply to
David Brown

All of the replies so far have ignored the slew rate limiting in the line drivers. The effect of these at 115200 bps is that an appreciable amount of each bit time will be consumed by a possible change of state, mark -> space or space -> mark. If the final bit time is off by 42%, there is a very high probability that it will sample during a change of state. Behavior of the line driver is probably undefined during this time period, and is likely to produce erratic behavior.

To see what I'm talking about, hook a scope to the Tx line of a serial port transmitting at 115200 bps. Send a continuous stream of 'u's, which have a transition between each pair of bits. The tops and bottoms of the bits almost don't flatten out before the end of the bit time. Compare that to the same data transmitted at a much lower data rate. Peaks are comparitively flatter.

Just one of those darn real-world analog phenomena. --- rod.

Reply to
Rod B. Nussbaumer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.