According to this:http://www.wormfood.net/avrbaudcalc.php the 8MHz 16MHz clock frequencies that are standard to use with Arduino aren't that good for communicating at standard baudrates like 57600 and 115200. (the only baudrates where they are perfect is actually the standard MIDI one at 31250)
It seems that 18.432 and 7.3728 MHz would be the best choices.
How would you go about doing this in a standard Arduino environment?
Do I need to make any changes to the bootloader or is the boards.txt enough?
How do I make sure that millis() and other time related functions (also libraries) work?
Is it worth it? Would I need to do the same thing to the 8U2 to get any real benefits?
(I most often use the internal clock at 8 MHz or use an external 16MHz crystal together some 8U2 board)
No.
As long as the baud rate is within 2% it will communicate fine. There is no point in having it spot on.
You don't gain anything.
But it's not within 2%... 57600 at 16MHz is pretty close though with 2.1%, but for 115200 at 16 and 57600 at 8MHz its 3.7% off and 115200 at 8MHz is 7.8 % off. Also taken into account the internal oscillator is not super accurate, could it not be an actual improvement to clock that at 7.3728 MHz when doing 115200 serial communication?
I have too, but lately I have has some problems establishing a connection with some internal 8MHz clocked Arduinos. It works most of the time and It's probably caused by some bug in a PureData object called [comport]. But I did a little research into other possible causes and found the AVR Baud Rate Calculator.
[quote author=Jack Christensen link=topic=98331.msg737604#msg737604 date=1332691308]
I use 57600 and 115200 all the time without issues.
I have too, but lately I have has some problems establishing a connection with some internal 8MHz clocked Arduinos. It works most of the time and It's probably caused by some bug in a PureData object called [comport]. But I did a little research into other possible causes and found the AVR Baud Rate Calculator.
[/quote]
The internal RC oscillator is not considered accurate enough for serial communications. Although I have tried it too, and it works surprisingly well, it's not one of things that can be complained about when it doesn't work!
I should have said, the internal RC oscillator's factory calibration of ±10% is not considered good enough for serial communications. However, the datasheet says that it can be calibrated within ±1% (with some work on your part). Its frequency is dependent on both supply voltage and temperature, but assuming both are reasonably constant, perhaps it would be accurate enough.
Yes, and that's not surprising since the it's 7.8% off... hence my question about 7.3728 MHz that is 0% off.
99% of the time it works great with 57600 on a 8MHz internal clock, but since I'm building my own boards, I though that if I could choose to clock it at a speed more suited for serial com, the risk of getting a chip that don't work could decrease.
It's not for a specific project. I do a lot of different things myself and I also teach in art school and make cheap solutions that the students can use in installations and such. In some cases it's not practical to use a non standard baudrate. It would not hurt to have a 328 with the internal clock that could run 115200.
According to this:WormFood's AVR Baud Rate Calculator Ver. 2.1.1 the 8MHz 16MHz clock frequencies that are standard to use with Arduino aren't that good for communicating at standard baudrates like 57600 and 115200.
Don't forget that Arduino uses the doublespeed BRG option (u2x); IIRC, that pushes the actual rates closer to the desired rates... (for instance, 115200 @ 8MHz is "only" 3.55% off (alas, in the opposite direction of the 16MHz USB/Serial 8u, which is bad.)
The actual "requirement" is that the "center" (sample time) of a bit not drift into some other bit's timeslice. For a 10bit character that would be about 5% total error (0.5bit/10bits) (It's actually a bit better than that, because the stop bit probably doesn't count.) This is normally allocated to 2.5% max error on each side of the communication, but if the other side is known to be better than that, the arduino can be worse.
In any case, it should be a "digital" thing. Either it works or it doesn't work. If it works, then being closer to the true bitrate won't give you any additional advantages...
If you did want to switch to a different crystal, then:
change bootloader.
check millis() (some of the calculations are automatic based on F_CPU, but they're not "certain."
expect that any number of third-party libraries may need adjustment.
The 8U2 has limitations (I think) on clock rate due to the need to support USB. The FTDI chips derive their clock from the (supposedly rather accurate) USB port. I think you should assume that those aren't easily changeable.