next topic »

[on:]

Hello,
   I'm using the Arduino UNO so the clock speed is set by the on-board crystal (16 MHz), but my electronics professor friend, who does a lot of MCU projects, recommends that in systems with a stand alone MCU (ie. not using the Arduino boards) the clock should be run at about half the recommended speed because he says the system will operate more reliably that way.  For example, he'll run an ATMega16 or 32 system at 8 MHz even though the chips are rated at 16 MHz.  Since most projects involve interaction with people via switches, LEDs, etc. the reduced speed doesn't matter.  But if I use an Arduino at 16Mhz to prototype a project and develop the code, I'm under the impression that I can't simply use the identical code if I make a system running at half that clock speed - especially if there is anything involving clocks (which I have in my project) or other timing related functions.

So I have two questions:
1) is it true a system will run more reliably at a reduced clock speed?
2) can I use the very same code developed for a system with a 16MHz clock on a system with an 8MHz clock?

- Doug Rogers, Nha Trang, Vietnam

[Reply #1 on:]

Hello,

1) is it true a system will run more reliably at a reduced clock speed?

Only in the case where a mistake was made in the system design.

2) can I use the very same code developed for a system with a 16MHz clock on a system with an 8MHz clock?

Yes.  So long as the processor is running fast enough to do all the work you need it to do within the time you need the work to be done.

[Reply #2 on:]

2) can I use the very same code developed for a system with a 16MHz clock on a system with an 8MHz clock?

Functions like millis() and micros(), which deal with elapsed time, should work at 8 MHz because they use different constants (you would need to recompile, not just use the exact identical hex code). Ditto for things like serial communications.

If you directly set up things like timers, where you calculate the timer rate based on a 16 MHz clock, the code would need to be adjusted to allow for the slower clock.

[Reply #3 on:]

1) No.
2) Yes. You will see things taking twice as long, serial baud rates being half what you expected, etc.

Reduced speed does matter because the system won't seem as responsive, perhaps leading to extra button pushes, delayed output on LCD screens, etc.

Operation is guaranteed at 20 MHz, so at 16 its already running at a derated speed. Further derating does not gain anything.

I've had 14 Promini's & standalone equivalents running at 16 MHz at my fencing club since Dec 2010, 3-4 classes a week for hours at a time. We go in, turn on a power strip, and 3-5 hours later turn off the strip & go home. They've worked great.
Pic's here:
Main score/time box with 2 16 MHz Promini's

Remote control for main  box, 3.3V/8MHZ Promini running in 1000mAH LiPo

Smaller boxes that only show touches being scored, some have Promini's, some are built-up equivalents

All are wirewrapped.
I realize that's only anecdotal. Does he have anything to offer for comparison?

At the same time, this Sony Vaio I am typing on gets used for more hours at a time at an waaaay higher clock speed (2200 MHz) on a daily basis, and it seems pretty reliable too, 3+ years old and runs much warmer than any arduino.

[Reply #4 on:]

I have a few Unos here running 24/7 doing assorted things (like a security system). They only time they get rebooted is when the power fails. I never, ever, have any trouble with them.

I suggest that if things "seem unreliable" at 16 MHz you should investigate why. Eg. noise on data lines, noise on the power, not enough decoupling capacitors.

[Reply #5 on:]

On topic 1) and Mr. "Coding Badly"'s response "Only in the case where a mistake was made in the system design."  There are many levels of "mistakes" and I probably make some of them all the time, such as neglecting a filter capacitor on the VCC of a chip, or using the wrong value; having a slightly noisy power supply; perhaps drawing a little too much current from an output pin by driving an LED directly; not having the best ground plane on a home made PC board; having noisy relays or solenoids in the circuit; etc.  For those common kinds of minor "sloppy" mistakes does a reduced clock speed make the system more forgiving, or does the clock speed not affect things like that?

On topic 2) thanks to Nick Gammon, since he answered the more accurate question I should have asked: "do I need to recompile the code for different clock frequencies?" It sounds like I do, so that I cannot run the identical hex code on the Arduino (@ 16 MHz) and the stand alone ATMega328 if I run it at 8 MHz. 

[Reply #6 on:]

"perhaps drawing a little too much current from an output pin by driving an LED directly;"
That will kill a chip for sure, no matter the clock speed.

"I cannot run the identical hex code on the Arduino (@ 16 MHz) and the stand alone ATMega328 if I run it at 8 MHz.  "
Sure you can  - things will just run at 1/2 speed.
If you look at the list of boards, you will only see 1 board type that runs  at 8 MHz, so  you may have to do some other fooling around to recompile for an 8 MHz crystal.

[Reply #7 on:]

For those common kinds of minor "sloppy" mistakes does a reduced clock speed make the system more forgiving, or does the clock speed not affect things like that?

What does it matter?  You are far better off working on ways to prevent those mistakes.  A suggestion that pops into mind is a checklist of potential mistakes (your post is an excellent starting point).

Having said that, like Nick Gammon and CrossRoads I have never had a problem that could be attributed to clock speed.

[Reply #8 on:]

For example, he'll run an ATMega16 or 32 system at 8 MHz even though the chips are rated at 16 MHz. 

The ATmega328 is rated for 20MHz at 5.0V.

[Reply #9 on:]

Good point. If you are running off a 3V battery, then a slower speed is certainly called for.