Hi all, I'm a third year EE student at Cal Poly San Luis Obispo, and I've owned an Arduino Uno for a few months now, and I've got a suggestion for the next revision, with some evidence to support it.
I would like to suggest that the 16MHz ceramic resonator used to clock the ATmega328P be removed, and replaced with a cuttable solder jumper to the ATmega8U's CLK0 (Clock Output) pin.
For precise timing, such as running real time clocks and waveform generation applications, it is desirable to use a clock reference with the highest available accuracy. Typically crystal oscillators are selected for a good balance between accuracy and cost.
Here is a comparison between the 16MHz resonator and 16MHz crystal on the Arduino Uno:
As you can see, the resonator has a stable frequency of 15.9331MHz, a -0.42% difference, as well as a jitter of about 7ns over a 30s period, 1ms from the trigger. The crystal oscillator has a stable frequency of 16.0000MHz (as well as my Rigol scope's frequency counter can tell) and a jitter of about 4ns for the same conditions.
Assuming a +/-30ppm frequency tolerance for the crystal, a clock based on such a crystal would be accurate to within about 1 minute and 19 seconds per month. For the resonator, however, such a clock would be off by 3 hours and 3 minutes by the end of the month.
Thankfully, the fix (to my knowledge) seems fairly simple. The ATmega8U (as well as most AVR microcontrollers) have a clock output fuse which can output a buffered version of the input clock on one of the pins, in this case, PC7.
(p.77 in the ATmega8U datasheet)
(p.35 in the ATmega8U datasheet)
So all that is needed is to set the corresponding fuses on both devices, and route a trace from the ATmega8U to the ATmega328P. The end-user would still have the option of cutting the trace and installing a different frequency crystal or resonator to their liking, but this change saves on the part count and provides a much more accurate default clock source for the microcontroller.
(p.35 in the ATmega328P datasheet)
Granted, this is all through the eyes of a hardware engineer, so there may be specific software considerations that are preventing this from being possible, but to me, this seems the obvious solution.
Finally, I have attached the modified board (I tried to make as little changes as possible to the rest of the board, although I had to shift around a few traces, it still passes the DRC file I commonly use).
arduino_Uno_extclk.zip (201 KB)