UART Receiver Receivers are more difficult to design than transmitters.

The main reason for this has to do with the clock. A prime example of this is the UART. The data sent by a UART transmitter is sent bitserially and no clock signal is sent with the data. (Some systems have a separate line that carries the clock, or some other way to give the receiver the clock that was used to send the data). That means that the receiver has to figure out where the clock the transmitter used, is. Where its edges are, and, in other transmitting methods (not UART), how fast the clock is To say this another way, the thing that makes receivers hard to build is that the sender and the receiver are running on separate, unsynchronized clocks. In our case, we have a 16MHz clock. The transmitter may also have a 16MHz clock. But we are never guaranteed that both of those clocks are running at EXACTLY 16MHz. They usually will be some small percentage off. Also, if we receive data from the transmitter we built last week, the data will be coming at 31.25KHz. Thats 512 ticks of a 16MHz clock. But, as you might have already guessed, determining where the 31.25KHz data edges are is also a challenge. So lets look at some of these problems: 1. 16MHz clock not exactly the same (Not needed for the homework). If clock cycle of the transmitter and receiver is different, then, when you make a 31.25KHz t clock, or make a high signal every 512 16MHz clock ticks, the edge will be off by 512*t seconds. By the end of 10 bits, youll be off by 512*t*10. How do you solve this? You need to look at the Tolerance of the receiver. If the receiver can handle a 15% error per 10 bits of data, then you need to do the math. Is 512*t*10 smaller than 15% off from the receiver clock? Or is The difference between the clocks at the end of data transmission Total time of receiver for data transmission

= (512*t*10) / (512*10) = t So, if the difference (t) is less than 15%, this system will work. For the homework, well assume that the receiver 16MHz clock and the transmitter 16MHz clock are close enough, that counting from the START bit (to be explained below), will be within this error rate. 2. Determining the 31.25KHz clock edge from data (Important for homework) This is the main part of this homework. Your receiver will receive a bitstream at 31.25KHz. Your job is to use your 16MHz clock and somehow grab the 8-bits (10-bits will come, but only 8 of them are data). How do you do this? Start Bit Bit Bit Bit Bit Bit Bit Bit Stop Bit 0 1 2 3 4 5 6 7 Bit Well, first of all, you need to find the start of the data. Lets remember what will be coming to us. (See diagram on next page). First well see a start bit. Then the 0th bit, then the 1st bit, 2nd, 3rd. So the first thing we should look for is the Start bit. The UART protocol guarantees that the Start bit will be visible. When there is no data on the line, UART requires that the line is held high. So, if the line has been idle, and then a Start bit comes, youll see a zero-to-one transition on the line. A falling edge. In homework 3, you built a rising-edge detector so designing a falling edge detector to find the Start bit

should be straight forward for you. The other possible signal combination you might see is two pieces of data directly following each other. In other words, you may see two pieces of data following each other with no idle time between (lets call the two pieces of data D1 and D2). Then, the value before the Start bit of D2 will be the Stop bit of D1. The Stop bit is always 1, so, once again, youll see a falling edge for D2s Start bit. You may ask: How do you know that the Start bit is a new piece of data, and not a continuation of the previous data?. Your STD will know. If your STD is keeping track of which bit youve received, then youll know if youve received 9-bits and youre on the Stop bit or not. Now that youve found the beginning of the Start bit, you know where your data starts. And you know that from there, the data should come at a data rate of 31.25KHz. Theres one last thing you need to be careful of. The signals that you receive will be coming across a cable, or maybe air. Sending signals over almost anything make the signals worse than when they started. You may get something like the results above. You send a nice signal, but the received signal is degraded. In most cases, the biggest degradation occurs at the edges of the signal. So a square signal may be rounded and lose its edges. But, as in the picture below, though the edges are quite different from the original signal, the center of the signal is pretty close to the original value. When you receive a signal, you want to grab a

Sent data

Received data

value from the best part of the signal. Here thats the center. So when you receive a signal, you dont want to sample or grab a value from the edges, you want to grab the value from the middle:

Start Bit Bit 0

Bit Bit Bit 1 2 3

Bit Bit Bit 4 5 6

Bit Stop 7 Bit

Now you should know how to find the clock from the data, and where to grab the data. Now youre ready to design a receiver. Remember to start by drawing boxes and determining the big picture. Then break it down into smaller problems until you have a set of problems that you can solve. For those of you that need a better description of how the receiver will work, heres some pseudocode: Now lets build the STD for the receiver. Heres some pseudo-code for our STD: 1. 2. 3. Wait for falling edge (the start bit) Wait for middle of first data bit (Youll need a timer state here) For 9 bits: a. Sample bit b. Done 9 bits? If so, goto 4. c. Wait until middle of next bit d. Go to a. Wait for middle of stop bit Go to 1.

4. 5.