32mHz ARDUINO PROJECTS.. ATMega328P etc...

I have been using 32mHz crystal oscillators on my projects for some time now without any crashes or ANY noticable heat from the processor.

Instead of the 16mhz crystal the parts I use are like these
http://www.ebay.co.uk/itm/201074903412

You cant just use a 32mHz CRYSTAL because the micro isnt able to drive it properly, so therefore it must be a TTL CRYSTAL OSCILLATOR (as above)

I created a new entry in boards.txt to cover the new chip frequency (for example)

uno32.name=Arduino Uno 32mhz
uno32.upload.protocol=arduino
uno32.upload.maximum_size=32256
uno32.upload.speed=115200
uno32.bootloader.low_fuses=0xff
uno32.bootloader.high_fuses=0xde
uno32.bootloader.extended_fuses=0x05
uno32.bootloader.path=optiboot
uno32.bootloader.file=optiboot_atmega328.hex
uno32.bootloader.unlock_bits=0x3F
uno32.bootloader.lock_bits=0x0F
uno32.build.mcu=atmega328p
uno32.build.f_cpu=32000000L
uno32.build.core=arduino
uno.build.variant=standard

This WILL affect your BOOTLOADER as it will be running a 2x speed, you can solve this problem by one of two ways:
(1) Dont use the bootloader, only upload via USBISP etc etc
(2) Put some clever switch to switch between 16mhz (serial upload) and 32mhz (operational) clocks

There could be a few issues regarding your peripheral devices, for example using LCDs, perhaps SPI problems, and obviously serial is cracking away twice as fast so your debugging speed will need adjustment.

LIBRARIES:

so far, in the LiquidCrystal library, I found that the following mod fixed writing problems

void LiquidCrystal::pulseEnable(void) {
  digitalWrite(_enable_pin, LOW);
  delayMicroseconds(1);    
  digitalWrite(_enable_pin, HIGH);
  delayMicroseconds(1);    // enable pulse must be >450ns
  digitalWrite(_enable_pin, LOW);
  [b]delayMicroseconds(200);[/b]   // commands need 200us if using 32mHz xtal (was 100us)
}

As yet I havent found any issues when using internal EEPROM and the EEPROM library

I have been using 32mHz on ATMega328P_PU (DIL) and ATMega328P_AU (QFP32) chips so far without problems, and I shall be trying many more as I get them

This may be well outside the 20mhz specification of the atmel device, but sometimes its worth a little extra nitro to squeeze a bit more out, just for fun.

NOTE: Please do this at your own risk, even though I havent had a problem there is no guarantee that your device wont kick the bucket, blow up in your face, or set off world war III !

Regards Bob

Well done. If I want to over clock I now know how....

Am I missing something?

I would think that if you set uno32.build.f_cpu=32000000L, delay should work correctly, without having to change delay lengths...

DrAzzy:
Am I missing something?

I would think that if you set uno32.build.f_cpu=32000000L, delay should work correctly, without having to change delay lengths...

Well I think you are correct, but if you are talking about the amendment in liquidCrystal.cpp then its because the HD44780 chip needs >37us to set the command, I tried it at the 100us delay and the display was crashing, adjusted to 150us still the same, 200us worked fine.

It may be worth checking each timing-based function you may use. When I use a 32mHz clock, I just go through everything and work out what MAY be affected, perhaps even do a few solo tests in a clean sketch etc

Regards

In Arduino.h I found this...

#define clockCyclesPerMicrosecond() ( F_CPU / 1000000L )

so with that, millis() and micros() should work as intended, unless micros() is timer interrupt triggered based on a number rather than a function.. I shall look into this

I am surprised that more people aren't interested in testing 32mHz... at least just for fun. Would you be able to share how you wired the crystal and what "extra" parts you use to make it work?

Thanks for posting!
Mark

as mentioned a crystal cannot be used at that frequency, only an external oscillator. this is confirmed by my own tests. the fastest i was able to get with a crystal was 22mhz-24mhz depending on the cut and caps.

this is great for fun but be aware there is potential for damage. not from heat like overclocking a pc cpu as many think but damage to the flash structures. atmel makes it clear flash and eeprom cell programming is not recommended over 10% of nominal clock speed. i verified that spm at highest limit does indeed result in failure. constant erase cycles caused measurable retention time deficit in minutes or hours overclocked while same routines within spec went for weeks. few tens of thousands vs at least couple million.

moral of the story: if you overclock dont write to flash.

I don't know if you can program them to have a default frequency, but using an AD9850 function (square wave) generator module for the clock would be interesting.

i.e you could dynamically increase the frequency using the device its self

not sure about initial boot though from cold / no power

You can lower the clock core frequency before flash/EEPROM critical write functions.
From change-the-frequency-of-my-atmega

Apart from that default loaded value you can change the clock prescale at will during runtime, all you need is to include the following header

#include <avr/power.h>
and call the following function with the appropriate value you want to use

   clock_prescale_set(clock_div_1),    // divide by 1, for example with 20MHz clock result      20MHz
   clock_prescale_set(clock_div_2),    // divide by 2, for example with 20MHz clock result      10MHz
   clock_prescale_set(clock_div_4),    // divide by 4, for example with 20MHz clock result       5MHz
   clock_prescale_set(clock_div_8),    // divide by 8, for example with 20MHz clock result     2.5MHz
   clock_prescale_set(clock_div_16),   // divide by 16, for example with 20MHz clock result   1.25MHz
   clock_prescale_set(clock_div_32),   // divide by 32, for example with 20MHz clock result  0.625MHz
   clock_prescale_set(clock_div_64),   // divide by 64, for example with 20MHz clock result  0.312MHz
   clock_prescale_set(lock_div_128),   // divide by 128 for example with 20MHz clock result  0.156MHz
   clock_prescale_set(clock_div_256),  // divide by 256, for example with 20MHz clock result 0.078MHz
power.h manual

Interesting views - as I said I havent had any problems YET

Ray, thats an interesting concept for the frquency drop before eeprom write, I do use eeprom within the app, but I am guessing it doesnt matter much about the frequency when programming via USBASP ??

I also tried using standard xtals, I bought a range to try, I could only get to 24mHz before it became hit and miss...

I have dozens of 20/24/25/32 mHz crystals if anyone wants them !!

I have dozens of 20/24/25/32 mHz crystals

I very much doubt that

mcnobby:
Interesting views - as I said I havent had any problems YET

probably wouldnt ever because not many people reprogram tens of thousands of times. typically a few dozen or hundred. and you might not notice that the 10-20 yr retention spec was compromised.

eeprom tolerates about an order of magnitude more cycles so unless writing constantly wouldnt notice there either. rare applications that reprogram flash a lot and need long data storage might have a problem though.

also worth noting that the programming timer is not influenced by clk prescale so while slowing the cpu helps with power consumption, it does not fix the flash retention problem.

mcnobby:
I also tried using standard xtals, I bought a range to try, I could only get to 24mHz before it became hit and miss...

glad to see you were able to duplicate my own crystal experiments.

they are so cheap i also have dozens of different crystals, even hundreds for common values like 16mhz. not that unbelievable.

even hundreds for common values like 16mhz. not that unbelievable.

Yes, it really, really is.
In thirty odd years in the electronics industry, I have never, ever seen a single "20/24/25/32 mHz" crystal.

AWOL:
Yes, it really, really is.
In thirty odd years in the electronics industry, I have never, ever seen a single "20/24/25/32 mHz" crystal.

Ah, I get it now... 20/24/25/32 mhz = 1041 hz

or perhaps you meant I spelled Mega Hertz with a small M, so its milli Hertz !!

That really HURTZ !! ha ha

UPDATE : I have tried & tested 32MHz crystal oscillators on many ATMega328, ATTiny85, and ATTiny13A (all 20MHz variants) I have decided to push things to the limit...

I have ordered one 40mhz oscillator for testing.. these things run at a juicy 40ma plus more current drawn from the microprocessor because of the extra speed.

I shall revisit with my results soon

Do you feel the need for speed?

ChilliTronix:
Do you feel the need for speed?

IMO..

Not just speed, but the thrill of the chase.

Ray

For a while, I was thinking that one of the new XMega chips running at 32MHz would be a useful addition to the Arduino line. Now, I just think that anyone who needs the speed should jump to one of the ARM boards.

Yes, make those LEDs blink really fast ... even faster delay() for button pushes ...