External 3.6864Mhz

Hello,

I am trying to launch my atmega328p with external crystal - frequency 3.6864 Mhz. I modified boards.txt:

atmegasa16.name=3.66 Mhz external
atmegasa16.upload.protocol=arduino
atmegasa16.upload.maximum_size=32256
atmegasa16.upload.speed=115200
atmegasa16.upload.tool=avrdude
atmegasa16.bootloader.tool=avrdude
atmegasa16.bootloader.low_fuses=0xfd
atmegasa16.bootloader.high_fuses=0xdf
atmegasa16.bootloader.extended_fuses=0x07
atmegasa16.bootloader.path=optiboot
atmegasa16.bootloader.file=optiboot_atmega328.hex
atmegasa16.bootloader.unlock_bits=0x3F
atmegasa16.bootloader.lock_bits=0x0F
atmegasa16.build.mcu=atmega328p
atmegasa16.build.f_cpu=3686400L
atmegasa16.build.core=arduino
atmegasa16.build.variant=standard

Burning bootloader is successful, but unfortunately when I am trying to upload sketch there is sync problem. I don't know if bootloader file is okay? Or should I use a different one?

With internal 1 Mhz everything is okay. I used for it modified bootloader file which I found there:

Thanks for help

Did you used the bootloader compiled for 3.6864 MHz? It would be a problem if not.

No, unfortunately I have problem with compiling it. I changed makefile and then I am getting something like this:

C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\optiboot>omake atmega328_3

C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\optiboot>..\..\..\tools\avr\utils\bin\make OS=windows ENV=arduino atmega328_3
system cannot find the path specified

You have to have the path defined to the toolchain files. Try to use just make:

make OS=Windows ENV=Arduino ATmega328P AVR_FREQ=3686400

Still getting "system cannot find the path specified".

First, try simple commands from the optiboot folder if it works, e.g. "make --version" and "avr-gcc --version".

I figured out that I simply didn't have make in "\tools\avr\utilis\bin". I downloaded some old version of Arduino and copied it there and finally have some progress. But still I am not able to compile that bootloader.

../../../tools/avr/bin/avr-gcc -g -Wall -Os -fno-inline-small-functions -fno-split-wide-types -mshort-calls -mmcu=atmega328p -DF_CPU=3686400L  '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200'   -c -o optiboot.o optiboot.c
process_begin: CreateProcess(NULL, ../../../tools/avr/bin/avr-gcc -g -Wall -Os -fno-inline-small-functions -fno-split-wide-types -mshort-calls -mmcu=atmega328p -DF_CPU=3686400L -DLED_START_FLASHES=3 -DBAUD_RATE=115200 -c -o optiboot.o optiboot.c, ...) failed.
make (e=2): Nie można odnaleźć określonego pliku.
make: *** [optiboot.o] Error 2

Still something is missing. The avr-gcc?

I can't help with your build environment problem (I have one really hackjobbed build environment in windows that I have no idea how I got working and building with modern compiler, but I remember it involved making a deal with the devil, or a minion of his) - for some things I'm still not able to make them build under windows and have a linux box for that.

115200 baud is too fast at 3.6mhz I think. Try 57600.

micros() and delay() will be fucked up when running at a weird speed, you have to modify wiring.c in the core and come up with a hand-tuned combination of add/subtract/bitshift to deal with cases where 64 does not divide evenly into the number of clock cycles per microsecond (you can't use floating point division because it takes forever on longs) See ATTinyCore/wiring.c at master · SpenceKonde/ATTinyCore · GitHub for example of how I worked around this for specific speeds in my core.

  1. You will certainly need to rebuild optiboot to support the new crystal rate,
  2. omake and ENV=Arduino have been broken since the IDE 1.5.x moved all the binaries around (and stopped including "make" at all.) If you downloaded 1.0.x to get make anyway, you should be able to do the build in the 1.0 directory hierarchy.
  3. the 3.6...MHz clockrate is one of the magic multiples of common baud rates. According to the usual (wormfood) BRG calculator, 115.2kbps should work fine.

If you are using anything but 8MHz or 16MHz you have a complex task to get things right,
you'll need to re-implement millis() and micros() for one thing.

MarkT:
If you are using anything but 8MHz or 16MHz you have a complex task to get things right,
you'll need to re-implement millis() and micros() for one thing.

No - millis comes out right.

It's delay() and micros() that are busted.

I agree with westfw. I'm recommending to download Arduino SW v1.0.6 and overwrite the Atmel 8bit toolchain with the newest since the tools and libs are very old. Just unzip and copy it to the forlder structure. Two or more version of IDE can coexist on your OS. I'm still using v1.0.6 with avr-gcc v4.7.2. The most recent is gcc 4.9.2 and library v2.0.0 in the Atmel Toochain for Windows 3.5.3.