1) How do you determine the baud rate that you want for your application while considering the clock of the MCU?
Baud rate = number of bits / second. The most common baud rates used are:
- 9600 = up to 9600bps = 104uS per bit
2) So if I were to send out a data stream higher than 9600Hz, I would be better off using a baud rate higher than 9600 to avoid data corruption? I feel there's more to it than just that.
3) if we use USART with a clock, isn't data sampled at each clock pulse (rising/falling etc)? If you've got a 16MHz MCU clock, meaning you're putting out clock pulses every 62.5ns, and if you were to use a baud rate of 9600 for data, how do 104us and 62.5ns work out? Or as long as I'm using a faster clock than the TX data speed, I'm good cause MCU is capable of sending as fast as the clock?
4) What's the essence of oversampling (8,16) of the data on the RX side? if the baud rates are the same on both TX and RX, the data received is at the same speed as it's being sent. Or it has more to do with external noise that might corrupt the data? Even then, where does parity come into play then?
Follow up:
4.1) why are 3 middle out of the N samples are sampled and considered for noise detection, as shown in the image?
4.2) With oversampling, you're technically reducing the resultant baud rate since you're taking only three samples?
4.3) Does oversampling by 8 have more receiver tolerance to clock deviation cause it generates a higher speed than oversampling by 16 mechanism?
Best Answer
1) There's only two points, how much data you must send within some given time frame, and which baud rates your microcontroller is capable of with the master clock they have. Some have only simple baud rate generators that divide with an integer, some have more complex ones that have a fractional baud rate generator. For example, an AVR running at 4 MHz crystal can't go up to 38400 baud unless you switch the oversampling from 16x to 8x with U2X bit. Even then, the baud rate will be 0.16% off from 38400 baud, but the error is insignificant.
2) You can't send more bits per second than what your bits per second rate is! It defines the rate of bits you can send. If you need to send more, then increase baud rate.
3) Synchronous serial does use a bit clock for the data. But it does not mean that a 16 MHz CPU uses 16 MHz clock for everything. You can still use a divided down baud rate clock for example for 9600 baud rate, just as you would with only an internal clock except it stays within the chip and does not come out.
4) Baud rates have to match, but only to a certain degree that is within tolerance limits. By oversampling you have only one sixteenth of time difference between the sampled start bit edge and the real received edge, so you can start counting when to sample the middle of the data bits. So the clocks only need to be sufficiently close to each other during transmission of one byte, and depending on a lot of factors, it does not need to be more than 1% to 2% percent accurate. Which means devices with less precise clocks can be used and make them cheaper.
4.1) That is how it is in general done. Sample the middle, but to avoid a spike of noise just at the sampling moment, majority logic takes in 3 samples and gives out the result.
4.2) Of course you could change oversampling from 16 to only 8, but then you need tighter tolerance baud rate clocks, because you can be almost up to one eighth of a bit already wrong when detecting the start bit edge, instead of only one sixteenth. The sampling of three bits is for combating a noise spike at the sampling instance, if there would only be one sampling instance.