next topic »

[on:]

Hi there,

Been doing some research on running a atmega328p at 3.3v - seems easy enough to do at 8mhz but I've read that some were able to do it at 16mhz. Further research showed that this was not stable, but 12mhz should be. Therefore I got to work trying to create a entry in the boards.txt for a 12mhz atmega328 based on the uno entry and the entry found here http://wiblocks.luciani.org/docs/app-notes/boards-txt.html but so far I have not been able to upload a sketch to the chip once it's burned. If I burn the standard uno bootloader and put in a 16mhz crystal then it works fine, so I am not suspecting my connections to be faulty. Does anybody have any ideas of this is even feasible and what I might be doing wrong?

This is my current progress:

Code:

##############################################################

wiblocks_328.name=Custom 328 at 12MHz shit
wiblocks_328.upload.protocol=stk500
wiblocks_328.upload.maximum_size=32256
wiblocks_328.upload.speed=19200
wiblocks_328.bootloader.low_fuses=0xff
wiblocks_328.bootloader.high_fuses=0xde
wiblocks_328.bootloader.extended_fuses=0x05
wiblocks_328.bootloader.path=optiboot
wiblocks_328.bootloader.file=optiboot_atmega328.hex
wiblocks_328.bootloader.unlock_bits=0x3F
wiblocks_328.bootloader.lock_bits=0x0F
wiblocks_328.build.mcu=atmega328p
wiblocks_328.build.f_cpu=12000000L
wiblocks_328.build.core=arduino

[Reply #1 on:]

There are parts of the Arduino core that only work at 16 or 8 MHz.  If you pick a different clock rate you will run into trouble with delay(), delayMicroseconds() and other time-sensitive code.

The bootloaders are pre-compiled for a particular clock rate.  The bootloader baud rate is calculated assuming that clock rate.  If you run a 16MHz bootloader on a 12MHz crystal your baud rate will be 25% slower.  If you run an 8MHz bootloader on a 12MHz crystal your baud rate will be 50% faster.  To get the right baud rate you would need to compile a special bootloader.

[Reply #2 on:]

As far as I am aware, all of the distributed Arduino code should cope with 12MHz. The core code and libraries use the f_cpu constant tp determine speed and these have been correctly altered in boards.txt. Note that some third party libraries may cause problems if they don’t correctly use the f-cpu constant.

As johnwasser says, the bootloader will not be set up for your altered clock speed so you either need to modify the bootloader or tweak the baud rate to run faster to compensate for the slower clock.

[Reply #3 on:]

As far as I am aware, all of the distributed Arduino code should cope with 12MHz. The core code and libraries use the f_cpu constant tp determine speed and these have been correctly altered in boards.txt.

Perhaps you should take a look at hardware/arduino/cores/arduino/wiring.c and look particularly at the implementation of  delayMicroseconds().

[Reply #4 on:]

Perhaps you should take a look at hardware/arduino/cores/arduino/wiring.c and look particularly at the implementation of  delayMicroseconds().
[/quote]


That was supposed to be addressed a year ago : http://code.google.com/p/arduino/issues/detail?id=256

Hans-Juergen Heinrichs  created and excellent set of delay routines that were  suggested as replacement for the current Arduino implementation of delayMicrosecond.

An include file with proper implementations for _delayNanoseconds and _delayMicroseconds can be found here: http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/include/delay.h

Johnwasser, thanks for pointing that out. Lets hope that the Arduino distribution will have something like that soon.

[Reply #5 on:]

Thanks for the replies so far Bummer though, thought it would be easier. For now I am just running it at 5v at 16mhz to maintain my speed. I don't know how to rewrite the bootloader if I want to give this a go some other time, do you guys know any write ups or places to begin if I want to get going at it?

[Reply #6 on:]

Thanks for the replies so far Bummer though, thought it would be easier. For now I am just running it at 5v at 16mhz to maintain my speed. I don't know how to rewrite the bootloader if I want to give this a go some other time, do you guys know any write ups or places to begin if I want to get going at it?

Unless you are looking forward to tinkering with non-standard bootloaders and software that is not properly handling CPU speed, you may be better of sticking with 8MHz and looking to make your application efficient enough to run at that speed. What is it that you want to do that 8MHz can’t cope  with?

[Reply #7 on:]

Did you change the CPU frequency in the Makefile when you made the 12MHz bootloader?

When I burn the bootloader for the wiblocks boards I use a Makefile that has the frequency
set to 12MHz. The Makefile I use is at http://wiblocks.luciani.org/docs/app-notes/bootloader.html

(* jcl *)

[Reply #8 on:]

Depending on what you're up to, you may simply be able to ignore the out to lunch millis/micros values.
Using an ISP programmer removes the need for the bootloader to use a "proper" baud rate, if you don't use serial at all that doesn't matter either.
My PWM fan controller project runs at 6.49MHz, using goofy millis numbers takes some getting used to, but as long as the chip doesn't have to talk to anything that expects a specific speed it works fine.

[Reply #9 on:]

Kind of forgot about this so I thought I would just post an update. I was using the standard SD card library at the time to log data taking 0.3s for each iteration, a speed I could barely handle, and 0.6 would be catastrophic. In the meantime I have done a lot of development, and after I came across this thread, http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293975555 , I have been able to write an iteration of data in less than 30ms, meaning I could probably go down to 8mhz by now.

I am not sure whether or not the sd card is expecting data at a "proper" baud rate, but my limited knowledge would make me guess "no", as I assume the clock signal comes from the arduino - But I haven't looked into detail about that. I would assume I would have to look into the SPI protocol to find out. In general, serial would be nice (to monitor when debugging) but is not a must

[Reply #10 on:]

Assuming you are driving the uSD card from the SPI port the clock sign comes
from the SCK pin. The frequency is set by changing values in the SPCR.
The range of division values varies from 2 to 64 (by 2's).
The SPI freq is fosc / divisor (where fosc is the XTAL pin freq).

(* jcl *)