AVR Essentials Question: Why 16MHz?

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?

Whew. Thanks in advance for your answers!

-- Steve

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.

Just my $0.02.

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.

Lefty

...except millis and micros. They're a bit off if the clock is not a power of 2.

They're a bit off if the clock is not a power of 2.

But perhaps just a "Tiny" amount? :wink:

...except 16000000 is not a power of 2 either.

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.

16 is a power of two

But, as has already been pointed out 16x106 is not.

(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.)

...except millis and micros. They're a bit off if the clock is not a power of 2.
...except 16000000 is not a power of 2 either.

millis and micros are not accurate when the processor clock, measured in megahertz, is not a power of 2.

So we should really by using 16,777,216 Hz crystals/oscillators to make life easier on the software?

power =2^power
1 2
2 4
3 8
4 16
5 32
6 64
7 128
8 256
9 512
10 1,024
11 2,048
12 4,096
13 8,192
14 16,384
15 32,768
16 65,536
17 131,072
18 262,144
19 524,288
20 1,048,576
21 2,097,152
22 4,194,304
23 8,388,608
24 16,777,216

Available from Digikey with 2 week lead time

Digi-Key Part Number FXO-HC730-16.777216-ND
Manufacturer FOX ELECTRONICS
Description OSC 16.777216 MHZ 3.3V HCMOS SMD

'course, they cost more than an Uno - $29.58!

Or go a little less accurate for $3.99 (100 lot minimum)

Digi-Key Part Number FN1660005-ND
Manufacturer PERICOM
Description IC OSC 16.600MHZ 3.3V CMOS SMD

4 week lead time.

Makes $0.31 look pretty good, and the software can work a little more:
http://www.dipmicro.com/store/XC7-16000

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).

Why these two? They don't fit the power of 2 idea. Do they work better for Serial rates?

7,372,800 Hz, and 14,745,600

Think I should have looked up crystals instead of oscillators - they are priced much more reasonably.
16.8MHz, $2.40 at Digikey for singles.

CrossRoads:
Why these two? They don't fit the power of 2 idea. Do they work better for Serial rates?

Yup. Zero error for most standard baud rates. Those two clock frequencies are occasionally mentioned on the forum.

Think I should have looked up crystals instead of oscillators - they are priced much more reasonably.

You seem to be a bit distracted lately. Too much day-job / not enough recreation?

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.)

"Too much day-job / not enough recreation?"

I suppose :slight_smile: 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. :smiley:

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...