As far as I know, TX and RX pins operate independently. On the other hand, experimentally I get garbage reading if the baud rates of a lets say MCU and a PC are different.
Is there a way to explain this for a non-expert?
Asked
Active
Viewed 4,933 times
4 Answers
9
Synchronous communication will have a clock line and a data line. That makes it very easy:
- The TX sets the data on the data line and then strobes the clock line.
- The RX waits for the clock strobe and then reads the data.
It doesn't matter what the baud rate is and it could even vary during the transmission of a byte, for example.
In Asynchronous data transfer there is no clock. This presents a problem.
Let's say I am going to transmit messages to you using a flashlight.
- We agree that each message will be eight bits (one byte) and 'light' = '1' and 'dark' = 0.
- We decide that each byte transmitted will be preceded by a start bit = '1'. (Otherwise you wouldn't know when transmission had started for '00001010' for example.)
- We now need to agree the flash (baud) rate. We agree on 1 s per bit.
- You watch eagerly waiting for a start bit. When you see the first '1' you wait 1.5 s and then take a reading every 1 s after that.
.
Data bits S 0 0 1 0 1 1 1 1 Stop
___ ___ _______________
Data ______| |_______| |___| |___________
Read ` ^ ^ ^ ^ ^ ^ ^ ^
Figure 1. Timing diagram.
- The reason for the initial 1.5 s delay is because my clock and your clock are running independently and there could be timing errors. With you taking a reading in the middle of each bit period you can still get a good reading even if your clock is running a little faster or slower than mine. The timing error will accumulate and the last bit would be the worst but with crystal controlled TX and RX circuits even the last bit should be read accurately enough.
If you choose to read my flashes at a different rate than I'm transmitting then you will read garbage.
For transmission the data byte to be transmitted is loaded into the transmit register. On each clock transition the rightmost bit is transmitted and the byte is shifted right. This occurs eight times so that the whole byte is transmitted.
TX Buffer Serial out
TX buffer initial 0 0 0 0 0 0 0 0
TX data loaded 1 1 1 1 0 1 0 0
Send start bit 1
Send bit 0 . 1 1 1 1 0 1 0 --> 0
Send bit 1 . . 1 1 1 1 0 1 --> 0
Send bit 2 . . . 1 1 1 1 0 --> 1
Send bit 3 . . . . 1 1 1 1 --> 0
Send bit 4 . . . . . 1 1 1 --> 1
Send bit 5 . . . . . . 1 1 --> 1
Send bit 6 . . . . . . . 1 --> 1
Send bit 7 . . . . . . . . --> 1
Send stop bit . . . . . . . . 0
Figure 2. Parallel in. Serial out.
For the receiver, the clock starts after the start bit is received. At the middle of each bit the data is read and shifted into the data received latch. After eight cycles a signal is given to indicate that the byte of data is ready to be read.
Serial in RX Buffer
Receive start bit 1 start the receive timing clock
Receive bit 0 0 --> 0 . . . . . . .
Receive bit 1 0 --> 0 0 . . . . . .
Receive bit 2 1 --> 1 0 0 . . . . .
Receive bit 3 0 --> 0 1 0 0 . . . .
Receive bit 4 1 --> 1 0 1 0 0 . . .
Receive bit 5 1 --> 1 1 0 1 0 0 . .
Receive bit 6 1 --> 1 1 1 0 1 0 0 .
Receive bit 7 1 --> 1 1 1 1 0 1 0 0
Receive stop bit 0 can be ignored
Receive data 1 1 1 1 0 1 0 0
Figure 3. Serial in. Parallel out.
A. I. Breveleri
- 115
- 5
Transistor
- 175,532
- 13
- 190
- 404
-
But what hardware samples and stores the incoming RX data bits? How does it sample the data bits? Im wondering why different baudrate would cause garbage reading. But it is blur to me because I doint know how actually data bits are read and stored and at what sampling rate. – GNZ Feb 07 '20 at 11:58
-
You need to improve your question then. Can you not understand from my answer why different baudrate would cause garbage reading (even without understanding how the data is stored)? I've explained why the sampling rate is important. What part of that do you not understand. – Transistor Feb 07 '20 at 12:00
-
Yes but in hardware level how does it happen? Otherwise I dont really understand how it is happening. – GNZ Feb 07 '20 at 12:09
-
1With its own internal clock, the receiver counts clock ticks until it thinks it is in the middle of start bit, and keeps counting with the clock to sample rest of the data bits from the expected middle points of the bits. If they are transmitted slower or faster, the receiever will drift sampling earlier or later from the middle point and if baud rate difference is large enough it will sample the last bit before it is transmitted or after it is transmitted so it does not hit the correct window to sample the correct bit. – Justme Feb 07 '20 at 12:09
-
@Genzo: I've updated my answer although I note that you haven't updated the question as requested and you didn't answer my question, " Can you not understand from my answer why different baudrate would cause garbage reading?" – Transistor Feb 07 '20 at 14:23
-
Re, "Synchronous communication will have a clock line and a data line" Some synchronous protocols use self-clocking codes instead of dedicating a separate conductor to carry an explicit clock signal. – Solomon Slow Feb 07 '20 at 19:18
-
2@Solomon: I try to pitch answers within the grasp of the OP. If you think introducing self-clocking codes will help him/her then by all means write an answer ... – Transistor Feb 07 '20 at 19:45
-
I am new to electronics. so I have a newbi question. The reciever starts a clock only when it recieves the start bit? I just want to be sure this is how it works, or does it have a constant clock that it uses? – shodz Dec 22 '21 at 19:24
-
1@shodz, you need to ask your own question for that rather than start a discussion in the comments of an answer to someone else's question. Reference this answer if it's relevant. – Transistor Dec 23 '21 at 00:17
7
In a typical situation between two communicating systems A and B there are two signals:
- One from A's transmitting output to B's receiving input
- One from B's transmitting output to A's receiving input
Same speed in different directions?
Other than simplicity, there's no particular reason the signal should go at the same rate in the two directions. Many computers' hardware has only having one clock per UART, and many operating systems only allow one speed in the system call. Some hardware and operating systems will allow it,
Under some situations it makes sense for them to be different because the engineering will save money or increase overall delivered performance. Most notably current ADSL internet links are like this -- "A" stands for "asymmetric" after all -- and they might be 42 Mbit/sec "down" and 18 Mbit/sec "up". Historically, some systems were run 1200 bit down and 75 bit/sec up. (Eg Minitel and Viewdata.) Such systems require that the hardware is able to do this, and are designed for situations where the amount of information is very different in the two directions: ie asking for web pages needs much less data than receiving them.
Same speed at transmitter and receiver?
The following is describing just a single direction
In an asynchronous serial link, the transmitter sends a signal and then uses its own timing to send the bits after that. The receiver sees the start signal and uses its own timing to look at the bits after that. No two clocks are ever absolutely exactly the same, so the receiver's sampling will be at least a little bit different to the transmitter's sending. How much is allowed?
For non-electronic people: I'm going to send you eight yes/no answers by a special flag on a tower. First I'm going to raise the flag and you have to be ready for when I drop it. As soon as I drop it, start your clock: then you have an hour to get ready for my first answer. After 1 hour of get-ready and eight hours of answers you'll have my eight answers. Suppose for a moment my clock is extremely accurate and you have a candle-burning clock which actually takes longer than an hour. The real problem is that you can't see my flag unless you go to the top of your castle, and you're lazy so you only go look once per hour. Just to make sure you don't have to stay up in the rain for too long, you go up on the half-hour.
How does it go wrong?
Look at this example. If your clock's "candle hour" actually took 72 real minutes, then 8:30 "candle hours" actually took 10:12 of real time and I've finished sending. Here's an illustration of that and the error it produces. The sender is trying to send 01011000, but the receiver mistakenly receives 00110011.
How accurate does it have to be?
You can see that if 8.5 receiver time periods is as long as 9 sender clock periods, the receiver will be looking past the sender's message. In practice we like to have head room, and want only to be sampling in the middle 50% of the time period: so the limit is 8.5 receiver times = 8.75 sender times, which is an accuracy of about 3%. (But many times you design more accurately in case the sender is also wrong, in the other direction.)
You can see that you'll have the same kind of difficulty if the red clock is faster than the blue one.
Notes
In real RS-232 communication, the bits are sent least significant first. If it's alphabetic information being sent as ASCII, that means an 'A' is represented by 0x41, or b:01000001, which is sent "backwards" as XYYYYYXY, where X and Y are flags up or down poles, high and low voltages etc, with leftmost sent first. If you look at an oscilloscope trace of the voltages on a serial pin of a microcontroller, you will see a signal exactly like the "height on flagpole" graph in the example. If you look at an RS-232 signal it is mirrored vertically.
If you'd like to read more about how accurate things have to be, see
- https://www.allaboutcircuits.com/technical-articles/the-uart-baud-rate-clock-how-accurate-does-it-need-to-be/
- UART baud rate error tolerance
Signalling by dropping flags was real: how time synchronisation signals were sent from about 1833. The following picture shows the "time ball" at the Royal Greenwich Observatory.
Image from Wikimedia
jonathanjo
- 14,034
- 3
- 34
- 66
5
"Synchronous" means (in this context) that there's a separate line that just carries a clock strobe that tells you "when this signal goes high, measure the voltage on your RX line to get a value".
In asynchronous communications, there's no such signal. Instead, the receiver just watches the RX signal for a beginning-of-frame marker, and then simply measures in fixed intervals.
These intervals must be the same as the sender uses, or else the receiver measures the same bit twice, or measures while the signal changes and isn't yet stabilized.
The period between consecutive symbols is the inverse of the symbol rate, also called baud rate. Thus, both transmitter and receiver must work on the same baud rate, or else communication can't work.
Marcus Müller
- 94,373
- 5
- 139
- 252
-
It is still blur to me. Do you mean the clock freq. for the shift registers must be equal? – GNZ Feb 07 '20 at 10:58
-
No, not equal, just within certain tolerance, so that the receiver can still sample all bits of the transmitted symbol reliably. Which depends on a lot of factors, like UART oversampling rate, bits per symbol, skew from physical tranceivers, etc. More than 2% difference starts to be difficult, less than 1% will usually work. – Justme Feb 07 '20 at 11:21
0
The micro controllers in embedded systems share common clock baud rate generator clocked from the same cliyck source(TI, Microchip, ST, I have seen again). This won't allow the system to operate the same UART port with different baud rate.
To get around the problem:.
Use two UART ports, one for transmission and one for reception..both at different baud rates as needed (this ensures no frame loss).
Second option depends on the feasibility. You can transmit at Tx-Baud-rate and change the baud rate registers quickly to receive at the RX-Baud-rate, change it to needed Tx-Baud-rate just before reception. If this is not a Perfekt Handshake communication, there is risk of data loss(frame error indication).
Software serial option (bit bang) only for transmitter and normal UART for reception.
User323693
- 9,311
- 4
- 21
- 51
serial inof a shift register and the Tx output is theserial outof a shift register, a shift register is a chain of type D flip-flops connectedD-intoD-outand all sharing the sameclocksignal, and a flip flop can be constructed from a certain arrangement of logic gates. When you understand how all of those things work, then you will be ready to begin learning how a UART works. Google and Wikipedia are your friends... mostly. – Solomon Slow Feb 07 '20 at 20:30