Go Down

Topic: 32mHz ARDUINO PROJECTS.. ATMega328P etc... (Read 16346 times) previous topic - next topic

mcnobby

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)

Code: [Select]

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

Code: [Select]
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
http://www.youtube.com/user/Recovered
http://www.smartshow.lighting

ChilliTronix

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

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...
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

mcnobby

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
http://www.youtube.com/user/Recovered
http://www.smartshow.lighting

mcnobby

In Arduino.h I found this...

Code: [Select]

#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
http://www.youtube.com/user/Recovered
http://www.smartshow.lighting

cyclegadget


 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
Good links: Eagle tutorial= http://www.youtube.com/playlist?list=PLDE1858BD83D19C70
General Arduion tutorials = http://tronixstuff.wordpress.com
http://www.gammon.com.au/forum/bbshowpost.php?bbtopic_id=123

john1993

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.

rogerClark

#7
Nov 22, 2014, 01:38 am Last Edit: Nov 22, 2014, 01:39 am by rogerClark
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
Freelance developer and IT consultant
www.rogerclark.net

mrburnette

#8
Nov 22, 2014, 03:43 am Last Edit: Nov 22, 2014, 05:16 pm by mrburnette
You can lower the clock core frequency before flash/EEPROM critical write functions.
From change-the-frequency-of-my-atmega

Code: [Select]
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


mcnobby

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 !! :)
http://www.youtube.com/user/Recovered
http://www.smartshow.lighting

AWOL

Quote
I have dozens of 20/24/25/32 mHz crystals
I very much doubt that ;)

john1993

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.

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.

AWOL

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

mcnobby

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 :)
http://www.youtube.com/user/Recovered
http://www.smartshow.lighting

mcnobby

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

That really HURTZ !! ha ha
http://www.youtube.com/user/Recovered
http://www.smartshow.lighting

Go Up