I'm looking to power a Duemilanove (FT2332R + ATmega328P) at 3.3V. The 328P spec says that the frequency limit for 3.3V is 12MHz.
Does the frequency defined in the boards.txt configuration file (atmega328.build.f_cpu=12000000L) correctly change the delay() function? I.e., will delay(1000) result in a 1 second delay? or will it become 1.33 seconds?
P.s. the flipside is to keep the board at 5V and boost the system with a20MHz crystal.
Almost. The core is designed to work correctly at 1, 2, 4, 8, or 16 MHz. At 12 MHz there is a small error (probably about 1%). The same is true for 20 MHz.
Thanks. I can live with a 1% error. 33% not so much!
bpospick:
I'm looking to power a Duemilanove (FT2332R + ATmega328P) at 3.3V. The 328P spec says that the frequency limit for 3.3V is 12MHz.Does the frequency defined in the boards.txt configuration file (atmega328.build.f_cpu=12000000L) correctly change the delay() function? I.e., will delay(1000) result in a 1 second delay? or will it become 1.33 seconds?
P.s. the flipside is to keep the board at 5V and boost the system with a20MHz crystal.
Keep in mind that many people and even a few commercial offerings (Seeeduino's 328p based board with switchable 5V or 3.3V operation comes to mind) operate their 328p chips at 16mhz at 3.3vdc and report no problems. While it is certainly outside the AVR recommended specs, you might find that it works fine for you. Not a personal recommendation, just an observation.
Lefty
I am running 328p 16MHz at 3V3. No issues so far (I do not use the bootloader).
You may set the fuse to "Ext. Full-swing Crystal..." in order to feel safe..
http://www.engbedded.com/fusecalc/
I've been looking at this lately as I'm running a home-made Arduino at 3.3v and find 8MHz is a bit too slow for my purposes.
At 12 MHz it appears that the millis() function will be out by 5.333 microseconds per millisecond. That is, the actual 'microseconds per timer0 overflow' appears to be 1365.333 but the millis() calculation is going to be based on 1360 microseconds per timer0 overflow. (Based on my understanding of the maths involved.)
That seems to be off by only about 0.4% - but in my application I'm relying on the time to be accurate, for a software RTC. It updates several times per day via GPS but in between updates it's relying on millis() for the timekeeping.
So I'm wondering, what sort of problem could happen if the microprocessor is run 'too fast'? Would that shorten the lifespan of the chip? Or does runing it out of spec lead to logic errors or something like that?
Essentially, what is the risk of running the arduino too fast?
Thanks!
So I'm wondering, what sort of problem could happen if the microprocessor is run 'too fast'? Would that shorten the lifespan of the chip? Or does runing it out of spec lead to logic errors or something like that?
Essentially, what is the risk of running the arduino too fast?
Many individual and a few commercial offering run their board at 3.3vdc at 16Mhz and report no problems. The risk of running outside the AVR datasheet recommendations is random logic errors, not any shortening of device life. So It's not something that AVR recommends, but again many report no problems with 'overclocking' the device, so you pays your dime and you take your chances. I wouldn't recommend doing it if the board is controlling a nuclear reactor or a cat-scanner, but if your just blinking leds, or making sound effects no problem.
Speaking of cat-scans, did you hear this one?
A man is concerned about his dog so he takes it in to the vet for a check. He places the dog on the examination table and the vet looks the dog over. After a few mins the vet tells the man "I think your dog is dead". "Dead!" says the man, "are you sure, I would really like a second opinion". Ok says the vet and he goes to a door and opens it and in walks a cat. The cat jumps up on the table, takes a few sniffs at the dog and then jumps down and leaves. Yep, your dog is dead, that will be $580 please. "$580! for just this little time?" asks the man. "Well I only charge $80" says the vet, "but the cat-scan runs you $500".
Lefty
Thanks for the info Lefty!
I'll have to try both, 12MHz and 16MHz and see how it goes. I should be able to code around the millis() problem at 12MHz but 16MHz would be much nicer... on the other hand, debugging can be hard enough as it is, without having to worry about random logic errors from running the uC out of spec.
I'm not using it for anything health & safety related - no nuclear cats or reactive scanners. It's basically just running an array of sensors. But I like things to work correctly, even if they're not mission-critical.
Cheers!
All of my boards are 3.3V and run at 12MHz. When I make the bootloader
I change F_CPU in the bootloader makefile. The delay function
works fine.
However, you could run into problems with some libraries. One customer
reported issues with NewSoftSerial. The issue was a timing
table that looks at F_CPU. There were constants for 8MHz and 16MHz
but none for 12MHz. I wrote a Perl script that added the constants
for 12MHz and the library works. The details are at --
http://wiblocks.luciani.org/docs/app-notes/software-serial.html
There could be other libraries with similar issues. These are usually easy
to fix.
(* jcl *)