Forgive me if this is an odd question, but I've done extensive reading on the AVR and am still a bit confused on this point. Can someone explain why nearly all implemented ATTiny/ATMega designs are clocked at 8 or 16 Mhz rather than a higher clock rate? The '328P is a 20MHz part, after all.
The question is academic. If I were to build a design that needed better throughput I would probably select a more appropriate MCU or just go FPGA. Has anyone come across a 20MHz Arduino clone? What are the design concessions which have to be made in this case? What kind of compatibility issues arise at a faster clock rate? Does a 20% increase in clock rate equate to a 20% increase in power consumption or is the relationship less linear?
It's a good question, not sure how things got that way, but it certainly is prudent to be conservative and not run right at the specification limit. And yes, generally the faster the clock rate, the higher the power consumption. Running a part capable of 20MHz at 16MHz is actually quite a modest concession. If you're out of gas at 16MHz, a 20% improvement will often not do the job either, a 100% increase may be more appropriate. The spec limit at 2.7V is 10MHz, so that goes along with a 3.3V supply, where 20MHz requires 4.5V.
People have modded their arduinos to run at 20mhz. Takes a modified bootloader (hard coded baudrate in there) and some tweeking of the arduino core boards.txt file, but not too hard in theory.
There may be some older 3rd party library code that don't properly utlilize the now avalible F_CPU variable to make time calculations, but all the arduion core stuff should work fine.
A little googling resulted in the answer. The ATMega8 the original Arduino was based off of was a 16MHz max part. The frequency a legacy relic (not that it is inappropriate).
The original Arduino was built using an ATmega8 processor chip, which had a maximum clock speed of 16MHz. All subsequent Arduinos have continued to used 16MHz for the sake of backward compatibility.
16 is a power of two, and so if you do some maths when using timers and prescalers, powers of two divide evenly because the prescalers are also only available in powers of two.
(and in fact the "timer tick" of the Arduino happens every 1024 milliseconds (976.56 Hz), which is what you get when you divide the 16MHz clock by 16384. The timer interrupt and/or millis() function go to some effort to adjust this to the nearest millisecond.)
So we should really by using 16,777,216 Hz crystals/oscillators to make life easier on the software?
I believe that would make the code simpler but it would also require rewriting and retesting.
In my opinion, that's moving in the wrong direction. The code needs to be made slightly more complicated so it's capable of supporting arbitrary clock frequencies. At a minimum, the core really needs to support 20 MHz, 7372800 Hz, and 14745600 Hz. Unfortunately, the day-job has me buried or I'd take a run at it. Maybe in October (jury duty :0).
So we should really by using 16,777,216 Hz crystals/oscillators to make life easier on the software?
Only if you think that having an exact 1ms clock tick is particularly important. I'd rather go 18.432MHz and have all the common serial bitrates come out exact.
But all in all, I don't really see any compelling reasons to do either one. 16MHz is fine...
(of course, if they had gone from 16MHz to "something else" when the mega8 went away, all the bugs having to do with different clock rates, and all the design issues for dealing with CPUs having different speeds, would probably have been worked out by now.)
I suppose Forum browsing makes for a nice mental break during the day.
Designing gives me something to do at night while waiting for parts.
Will dig out my 128/x64 graphics display soon and start playing with that again.
Wow, lots of activity on this thread today. Good info, thanks all!
Ultimately I'm wanting to drive a bunch of ATTiny85s at 20MHz for an insane little side project (tiny SMP FTW!) Utterly impractical, but an interesting diversion. Boot loader? Pfft. Who needs it.
CrossRoads:
Will dig out my 128/x64 graphics display soon and start playing with that again.
Ooh, which display? I've amassed quite a collection of these recently. The new Sharp Memory LCDs are really cool... BTW, Crossroads, Any interest in becoming a guinea pig for my generic display library? I need an initial victim^H^H^H^H^H^Htester to supply some brutally honest feedback...