I was reading about avr usart communications and how to implement it, when I found a formula which determines the baud rate:
BaudValue = ((F_CPU / (USART_BAUDRATE * 16)) - 1
F_CPU = main clock frequency
USART_BAUDRATE = desired baud rate
BaudValue = a value needs to be written to some registers which implement it into the usart subsystem
According to the table in http://www.wormfood.net/avrbaudcalc.php
none of the 16MHz entry is 100% error-free
So, how does arduino handle communication so good?
So, how does arduino handle communication so good?
Well the 16 Mhz is not exactly either
seriously, baudrates must be good enough to get a byte incl start & stopbits etc. lets say every byte needs 11 bits START BYTE SOP PARITY.
So after the edge of the startbit it waits halve a pulsewidth before sampling the bit (HIGH or LOW) and then it will jump a whole bit distance to sample the next bit.
Because the timings are not exact, the measurements of the bits will not be the middle of the bits but still be far enough of the bitborders, even after 11 bits read.
And the next byte starts with the startbit edge again. So it synchonizes more or less after every byte.
If you want a better understanding, make a drawing of the description above.
Well, I was actually working on a project with attiny2313 which will use usart communications!
So if I use a 16 Mhz Crystal or even 8Mhz it wont be much of a problem ? [will save me 40 km bus ride to the nearest electronic bazaar for those magic number crystals]
The project is a universal[term limited to my projects] remote control [wired, wireless, ir and whatever i could find], sort of like those super villains who control everything with a single remote.
Suppose we are using "conventional" UART protocol: One start bit, eight data bits, one stop bit. If the bit rate of the receiver is more than about 5% different from the bit rate of the transmitter, the receiver can not reliably receive continuous streams of bytes. (I am assuming no DSP autocorrelation or other fancy "optimal receiver" designs here.) The reason is that if the timing is off by more than a half of a bit time by the time we get to the middle of the stop bit, the beginning of the next start bit can't be reliably detected, and it's downhill from there. (Some UART designs don't "do it right," and their tolerance requirements may be even more strict than 5% error.)
Of course if the nominal CPU frequencies from which those charts were generated are not exact, the tolerances will be a little different.
With current 16 MHz Arduinos (Unos and Megas that use ceramic resonators rather than quartz crystals) people have reported frequency errors on the order of 0.12% or maybe a little more, so the actual bit rates may be off by that much (in addition to the values in the tables that you referenced.) Owners of these boards are apparently tooling along quite nicely at 115200 bits/second. On the other hand, if you look at the 8 MHz tables you can see why lilypad owners can't really expect anything worthwhile at 115200 bits/sec. (Well, they might expect something worthwhile, but...)
A couple of notes:
The roughly 5% tolerance is the total timing difference between transmitter and receiver. PC workstations and lots of embedded systems usually have "pretty good" values for bit rates up to 115200. If you are communicating Arduino-to-Arduino and both have the same nominal CPU frequencies, you may be able to venture farther into the orange zones (and even the red zones) of those tables.
Bottom line for me:
If I see bit rate errors on the order of 4% or greater in those tables, I wouldn't base my design on it. Otherwise, it's a go. (But still depends on the maximum error of the bit rate generator of the other end of the connection.)
On the other hand, if you look at the 8 MHz tables you can see why lilypad owners can't really expect anything worthwhile at 115200 bits/sec.
Bear in mind that those tables are for U2X turned off (the "show additional double speed mode information" does not appear to work). In addition, I think the UBRR values are truncated rather than rounded.
For a 328 processor running at 8 MHz (a Lilypad) the Arduino core has U2X enabled and uses a UBRR of 8 which gives an actual baud rate of 111111.1111; a 4% percent difference from 115200.
On the other hand, if you look at the 8 MHz tables you can see why lilypad owners can't really expect anything worthwhile at 115200 bits/sec.
Bear in mind...[/quote]
A really good point about the 2X mode if that's how it works. Maybe they do work at 115200; I have no way of knowing since I can't personally test them. I hope I didn't discourage anyone from trying. See Footnote.
Here's the thing...
Having read a few posts from the distant past (before I got involved with Arduino stuff a little less than a year ago) and recent past (after release of Uno and Mega2560 boards), I'm thinking the Arduino bootloaders and libraries haven't always chosen optimal values (maybe they truncated rather than rounded---I haven't tried to analyze the code). Also, I note references to band-aids apparently applied to try to make current Uno and Mega boards consistent with previous erroneous non-optimal values at nominal 57600 bit rates, but I haven't had occasion to test them.
Bottom line: I wouldn't bet the farm (a commercial product release) on anything that I haven't personally analyzed and tested. (Does anybody need a rate of 300 bits/second? Does it really work?) I would be comfortable starting a project where the nominal bit rate error is less than 4% according to the tables.
I have tested a couple of "authentic" Duemilanove and a single "authentic" Mega1280 at 115200, and I am very comfortable with this bit rate. The actual CPU frequencies were within two hundred or three hundred parts per million of 16 MHz (0.02% - 0.03%) and the actual bit rates were consistent with the value in the 16 MHz table.
The one Uno board to which I had access has a CPU frequency that is about 1200 ppm (0.12%) high, and the measured bit rate error (at nominal 115200) is consistent with the value from the table, so I'm thinking that 115200 is safe for the 16 MHz Arduinos.
Of course, all these measurements were at room temperature (20-22C or something like that).
I don't have any 8 MHz boards to test, so I can't speak to the possibility of errors in the Arduino Serial library, the bootloader software or the 8U2 software at any particular bit rate.
psyk3d:
Well, I was actually working on a project with attiny2313 which will use usart communications!
So if I use a 16 Mhz Crystal or even 8Mhz it wont be much of a problem ? [will save me 40 km bus ride to the nearest electronic bazaar for those magic number crystals]
You should take a look at the Atmel AppNote AVR053. It describes how you can adjust the internal clock and tune it by changing the OSCCAL register. If you want to run with the standard UART rates up to 115200, tune your OSCCAL value so that your clock runs at 7.3728 MHZ. You should be able to run without a crystal using any of the standard baud rates. The internal clock on most chips is adjustable from 7.3 - 8.1 MHZ.
Well, all the speeds that are "green" are calculated to have bit-rate errors that are too low to cause actual communications errors. The way that "asynchronous" communications is supposed to work is that the receiver re-synchronizes to the transmitter at the start of each byte, so as long as the bit edges don't drift past where they need to be within 10 or 11 bit times, everything should work just fine.
The other reason is that most of the arduino communications is between the arduino and the PC via that serial/usb chip on the board, so even if the bitrates are FAR off, you'll still get reliable communications as long as the serial/usb chip (on uno, ALSO an AVR running at 16MHz) both err in the same direction. (some of the problems that have occurred have been because the 8u2 and the 328 used DIFFERENT algorithms for picking the divisors, so that one ran +3% and the other ran -2.8%, which is not so good. (and while 115200bps is a common "fastest" speed for PCs, it's a particularly bad speed for a 16MHz AVR. Sigh.)
And that article about tuning the internal osc val was very helpful.
Keep in mind that you may be better off with a crystal oscillator that always produces a stable although slightly wrong baud rate as opposed to a non-stable RC oscillator that under optimum conditions may sometimes produce the correct baud rate.
