UnoDueTre:
As regards your sketch not working at 115200, could it be that at 20MHz there is no division ratio that will generate that baudrate closely enough?
Looks like 230400 is the only bad choice...
http://www.wormfood.net/avrbaudcalc.php
UnoDueTre:
As regards your sketch not working at 115200, could it be that at 20MHz there is no division ratio that will generate that baudrate closely enough?
Quite possibly.
UnoDueTre:
Is it necessary to compensate in the code for example, delay(1000*20/16) for a 1 sec delay, or will a simple edit of the boards.txt file be sufficient?
Neither works perfectly. The millis / micros code is designed to only work correctly at 1, 2, 4, 8, or 16 MHz. millis is fairly easy to correct (I know of two proposed solutions). micros not so much. Serial has the same problems at either clock speed (some baud rates are too far from the target speed).
Is the baudrate edit also required?
The other choice is to rebuild / re-upload the bootloader built for 20 MHz. Either method works.
Reply #40 on: Today at 03:27:49 am
Reply #41 on: Today at 03:28:01 am
Twelve seconds. Close enough. I call jinx! Bwahahaha!
The calculator that Coding Badly linked to states that 115200 @ 20MHz
UBRR and clock speed are between 1% and 2% off
Could that be it?
Doubt it though as those percentages are too low.
OK so judging by the replies here, using a crystal of 20Mhz (or any other then the standard Arduino ones) would require changes to serial functions, millis, micros and possibly others like Tone, delay and maybe even the SPI functions (under rare circumstances).
The bootloader would also need changing.
I think it's more hassle then it worth it, too much messing about and too much stuff that would be non standard.
In a lot of cases any short comings of 16MHz versus 20MHz could possibly be made up by using direct register manipulation and/or the use of inline assembler.
On a side note, I can't be the only one that thinks that the gcc syntax for inline asm is just plain weird, so it would be nice to be able to use say AVR Studio to compile a function in pure asm then taking that binary (not the intel hex) and being able to include it as part of the sketch (similar to the POKE in Basic).
Anyone know if this is possible and how one tells the compiler (avr-gcc) to keep the position of this included binary code without trying to move it to where it thinks it should go and messing it up?
Maybe as part of a function?
The only disadvantage found so far with higher speed is serial communication
see this thread Software Serial delay table - Programming Questions - Arduino Forum
If you need more speed like i do for my DSLR remote control + Star Tracker then i will experiment with this setup.
ATMEGA328 is rate at 20MHz as maximum speed, but at this moment i have 4 who work just fine at 24MHz with the condition that i have to keep the serial speed under 115200.
the things you need to do this are posted here http://www.grozeaion.com/index.php?option=com_content&view=category&layout=blog&id=49&Itemid=110 including how to burn bootloader using one arduino board (no extra programmer needed).
Hi gvi70000
Thanks for the input, will slowly digest all of it.
I remember in the "old" days one could coerce a bit more speed from some of the Phillips 8051 derivatives by using a higher speed xtal and increasing the supply by 0.5V or so.
The current went up but never popped one.
Never tried it on an AVR, maybe one day I'll throw caution to the wind, connect something like a 25MHz (or higher) xtal and see if it works, what the extra current will be and how long it survives.
EDIT:
Just looked at the Mega2560 datasheet and the supply is rated to 5.5V
I wonder if there will be any advantage when running at high speed?
I'm also thinking that perhaps using an external TTL/CMOS level xtal osc may enable the AVR to go even higher.
UnoDueTre:
OK so judging by the replies here, using a crystal of 20Mhz (or any other then the standard Arduino ones) would require changes to serial functions
Your sketch would need to be changed if you use 230400 baud. Otherwise you should be fine. The same sort of problem exists when the processor is running at any clock speed (poison baud rate).
, millis, micros
Yes.
and possibly others like Tone,
No.
delay
No.
and maybe even the SPI functions (under rare circumstances).
The bitrate is specified indirectly by divisor so the only issue is if the final bitrate exceeds the slave device's maximum bitrate.
The bootloader would also need changing.
Only if you can't multiply by 20 then divide by 16. 
...so it would be nice to be able to use say AVR Studio to compile a function in pure asm then taking that binary (not the intel hex) and being able to include it as part of the sketch (similar to the POKE in Basic).
I believe the Arduino IDE uses the assembler for sketch files that end in dot-S (I believe the S must be capital). Just create a new "tab" and end the file name with dot-S.
Edit: minor correction
Thank you for all the info Coding Badly.
I will look at the .S files.
I am thankful that more information on this subject has been presented here, but I can honestly say I still am unclear as to the answer of my previous question......
billcat:
...If I am dead set on using a 20Mhz crystal on a breadboarded Arduino, and not being required to account for this in any way every time I load a sketch...is this even possible?
I can speculate that it was answered by Coding Badly in reply #48, but can not say for sure.
If it is possible, I still do not know what I need to do to do so.
My reasons for wanting to use 20Mhz stem from a desire to build the Gen7 electronics for RepRap: Generation 7 Electronics - RepRap ....which calls for a 20Mhz oscillator....and is also the very reason I got started recently with Arduino......I understand most all parts of the hardware for Gen7, but nothing about the software.
So I have these 20Mhz crystals at my disposal, I'd like to use them if I could, but its obviously not a big deal since they are quite inexpensive.
It would be more realistic to ask myself is Arduino worth all this pain? I would estimate that I have spent at least 30-40 hours a week now for several months reading online tutorials, real books, forum posts, and related information, and still do not really understand the most basic of the Arduino examples, given the information supplied. Almost any application that I can immediately think of having a personal interest in using Arduino for........I can already accomplish using readily available hardware alone.
I am hopeful, yet still very uncertain, that eventually this will change........which is the sole reason I am still hanging on, at least for a little while longer.
anyhow....the rants over......again, thanks to all of you who give your time trying to help.
Cheers,
billcat:
I would estimate that I have spent at least 30-40 hours a week now for several months reading online tutorials, real books, forum posts, and related information, and still do not really understand the most basic of the Arduino examples, given the information supplied.
Learning curves are always very sharp at the beginning. Especially with technology. New terminology alone can be a huge burden. Give your brain time to digest.
billcat:
I am thankful that more information on this subject has been presented here, but I can honestly say I still am unclear as to the answer of my previous question......billcat:
...If I am dead set on using a 20Mhz crystal on a breadboarded Arduino, and not being required to account for this in any way every time I load a sketch...is this even possible?
delay / micros will not work correctly (the delay time / micros value will have a small error). millis can be made to work with a relatively minor modification. Most everything else should work as you would expect it to work.
The first step is decide how you will be programming the "target" (the processor running at 20 MHz). Do you plan to use a bootloader or ISP (in-circuit serial programming)?
billcat:
I am thankful that more information on this subject has been presented here, but I can honestly say I still am unclear as to the answer of my previous question......billcat:
...If I am dead set on using a 20Mhz crystal on a breadboarded Arduino, and not being required to account for this in any way every time I load a sketch...is this even possible?I can speculate that it was answered by Coding Badly in reply #48, but can not say for sure.
Without re-reading all 4 pages, I think I responded earlier it should be possible if you change the boards.txt file, eg. to add:
##############################################################
uno20mhz.name=Arduino Uno @ 20 MHz
uno20mhz.upload.protocol=arduino
uno20mhz.upload.maximum_size=32256
uno20mhz.upload.speed=144000
uno20mhz.bootloader.low_fuses=0xff
uno20mhz.bootloader.high_fuses=0xde
uno20mhz.bootloader.extended_fuses=0x05
uno20mhz.bootloader.path=optiboot
uno20mhz.bootloader.file=optiboot_atmega328.hex
uno20mhz.bootloader.unlock_bits=0x3F
uno20mhz.bootloader.lock_bits=0x0F
uno20mhz.build.mcu=atmega328p
uno20mhz.build.f_cpu=20000000L
uno20mhz.build.core=arduino
uno20mhz.build.variant=standard
I have done this myself as part of testing VGA output. In fact I had it running using this method at 20 MHz, 24 MHz and 25 Mhz.
Serial output looks OK (in other words the baud rate is correctly calculated). A timing test shows that delay(500) seems to take a bit longer (533 mS). A test running at 25 MHz also gives a longer delay than expected (640 mS). However this is the inverse of what you would expect, right? A delay would be shorter if the code hadn't compensated. I'm not sure why delay is out in this way but I suspect rounding errors in the calculations for the timer interval.
Caveat: This only works on Windows, the Mac doesn't like the non-standard baud rates. I can't comment on Linux.
So I don't know why we are on page 4 of this thread. It looks like reply #5 described the changes required.
It would be more realistic to ask myself is Arduino worth all this pain?
The Arduino is fine. It is targetted at beginners. However you are not planning to use one, right? You are planning on a breadboarded Atmega328 setup with a non-standard crystal. Of course this is harder than buying an Arduino board and experimenting with it. Having said that, though, I have one working right here blinking an LED for the timing test. I posted a photo of it in reply #38.
How about actually assembling something like that and letting the fun begin? Asking on a forum if something will work, when you can find out for yourself, is surely not as satisfying?
I am grateful for your advice Nick, I am sorry you are frustrated with the length of this thread. I don't intend to bother anyone. I am happy with the effort you have made to help me. If reply #5 was clear to me, then of course I wouldn't continue asking. I am well aware that you are very busy helping many people here, and if you wish to ignore my replies in the future, I would not be offended, you've been more than generous with your time.
And I appreciate your pic on post #38. I examined it very closely. It also left me with questions. You have + / - one or two components in your circuit(resistors and caps, cant remember) than there were in the schematic I followed when I finally got my homemade board going. I bought this: http://www.digikey.com/product-detail/en/UM232R/768-1019-ND/1836397 for the usb connection to the breadboard. I figured it must serve the same purpose as your FTDI cable, but could not tell you the difference between the two. It took a lot of plain ol' guesswork on my part to get it working.
The point being that I have actually "assembled something like that" as you recommend, check the pic.
Thanks for the clarification about the timing issues. I've taken some replies in the thread to indicate that it could be done somehow that would eliminate the timing issues. I do not really understand how to use any of the timing functions right now anyway, except for maybe delay() and delayMicroseconds(). However, I do know that timing is of real concern involving machine motion control, thus my concerns with the 20Mhz crystal used for the 3d printing application.
About the programming the target; I am not sure........if you use an Uno with the ISP sketch on it to load a sketch onto the breadboarded target(or my homemade board), is this considered using ISP or considered using the bootloader? Would this be the situation where you do not have to worry about the altered boards.txt, optiboot, etc files, and where only the timing functions within the sketch need to be adjusted like delay(xxUL* 20/16); ?
Hello all,
In the second half of this page Overclocking ATMega328P i have posted an update for micros and also for software serial,i hope it will help you.
Hello all,
First of all I'm sorry I revive such an old post. I am also not sure if I should open a new topic or write a reply on this one. I hope I chose correctly.
I am trying to program a ATmega328 chip with a 20 Mhz crystal with an FTDI board. I have no problem at all to burn the bootloader or upload a sketch by using the cheap USBasp ISP solution. I also have no problem to burn the bootloader with ISP and upload a sketch with FDTI but with a 16 MHz crystal.
The problem appears when I try to upload a sketch with the FTDI on a chip with 20 MHz crystal. More details about my setup.
First of all, I am using Ubuntu (14.04).
I 'make' the bootloader using the optiboot make file. The added lines:
# ATmega328 @20MHz
uno20: TARGET = uno_20mhz
uno20: MCU_TARGET = atmega328p
uno20: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200'
uno20: AVR_FREQ = 20000000L
#uno20: LDSECTIONS = -Wl,--section-start=.text=0x7e00 -Wl,--section-start=.version=0x7ffe
uno20: $(PROGRAM)_uno_20mhz.hex
uno20: $(PROGRAM)_uno_20mhz.lst
uno20_isp: uno20
uno20_isp: TARGET = uno_20mhz
# 2.7V brownout
uno20_isp: HFUSE = DD
# Full swing xtal (20MHz) 258CK/14CK+4.1ms
uno20_isp: LFUSE = C6
# 512 byte boot
uno20_isp: EFUSE = 04
uno20_isp: isp
Which are basically a copy of the "pro20" entry, already existing in the make file. To compile:
make uno20 AVR_FREQ=20000000L
Which successfully create the desired .hex file and .lst file in the folder.
Then I modify the boards file to create "my" board.
##############################################################
uno20.name=Arduino Uno @ 20 MHz
uno20.upload.tool=avrdude
uno20.upload.protocol=arduino
uno20.pload.maximum_size=32256
uno20.upload.speed=115200
uno20.bootloader.tool=avrdude
uno20.bootloader.low_fuses=0xC6
uno20.bootloader.high_fuses=0xDD
uno20.bootloader.extended_fuses=0x04
uno20.bootloader.unlock_bits=0x3F
uno20.bootloader.lock_bits=0x0F
uno20.bootloader.file=optiboot/optiboot_uno_20mhz.hex
uno20.build.mcu=atmega328p
uno20.build.f_cpu=20000000L
uno20.build.board=AVR_UNO
uno20.build.core=arduino
uno20.build.variant=standard
##############################################################
Here I have to inform you that I am not sure about the configuration of the fuses. In fact this is my first encounter of "playing" with bootloaders and the majority of the information I gathered were from this forum.
As I already mentioned, the bootloader is successfully burned using ISP. And the next step is to upload the sketch with FTDI. The verbose output is
avrdude: Version 6.0.1, compiled on Mar 16 2016 at 09:54:07
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/home/esaii/arduino-1.6.5/hardware/tools/avr/etc/avrdude.conf"
User configuration file is "/home/esaii/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyUSB2
Using Programmer : arduino
Overriding Baud Rate : 250000
avrdude: serial_baud_lookup(): Using non-standard baud rate: 250000avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
....
Programmer Type : Arduino
Description : Arduino
avrdude: Send: A [41] . [80] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [81] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [98] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
Hardware Version: 3
Firmware Version: 4.4
avrdude: Send: A [41] . [84] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [85] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [86] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [87] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [89] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us
avrdude: Send: A [41] . [81] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00] [20]
avrdude: Recv: . [10]
avrdude: stk500_initialize(): (a) protocol error, expect=0x14, resp=0x10
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude: Send: Q [51] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
Of course, I researched the given error, and the majority of the solution had to do either with the reset pin or the baud rate. The reset pin of the FTDI is going to pin1 of the chip through a 100nF capacitor and from pin1 of the chip goes a 10K resistor to 5V. I remind you here that the chip with 16Mhz crystal works with this configuration.
With the baud rate issue... I tried different baud rates from 115200 and 144000 up to 500000. The problem is that avrdude on linux has standard baud rates. In fact, from the ser_posix.c file of avrdude,
/* There are a lot more baud rates we could handle, but what's the point? */
static struct baud_mapping baud_lookup_table [] = {
{ 1200, B1200 },
{ 2400, B2400 },
{ 4800, B4800 },
{ 9600, B9600 },
{ 19200, B19200 },
{ 38400, B38400 },
#ifdef B57600
{ 57600, B57600 },
#endif
#ifdef B115200
{ 115200, B115200 },
#endif
#ifdef B230400
{ 230400, B230400 },
#endif
{ 0, 0 } /* Terminator. */
};
So every time I was using any non-standard baud rate the "programmer was not responding" and kept trying for 10 times (the usual reaction in such cases). I also tried to patch the ser_posix.c file by simply adding something like
#ifdef B250000
{ 250000, B250000 },
#endif
but without any luck. So I suppose the only two options of baud rates I have is the 115200 and 230400. For both of the cases, I compiled a bootloader and in both cases I have the same result (the verbose output above). I tried with different chip, as well as with different socket chip with exactly the same result.
I really have no clue where is the problem that's why decided to revive this post. I suspect is one of the three. Fuses setup, baud rate or reset pin. Any idea would be much appreciated!
Sorry for the looong post. 
Diego.
Overriding Baud Rate : 250000
avrdude: serial_baud_lookup(): Using non-standard baud rate: 250000avrdude: Send: 0 [30] [20]
Looks to me like "non standard" baud rates are supported by avrdude.
The avrdude output clearly indicates the bootloader and avrdude are communicating.
Here I have to inform you that I am not sure about the configuration of the fuses.
Did you use the same old values that were already in boards.txt?
Thanks for the response and sorry for the late response. Busy days before Easter week.
After all these changes and tries I've made I didn't realize that the baud rate of 250000 was accepted. I guess the patch did work after all Weird thing though, following the same -patch- steps on my laptop at home today (also Ubuntu) and it was not accepted again...
It doesn't matter though, as I managed to upload a sketch after all. I made a boot loader but not from optiboot but rather from the original atmega folder. All I had to do is to create a new entry copied from atmega328 one, change the AVR_FREQ to 20Mhz and that was it. Simple as that 
For any future reference, the entry in the make file.
uno20: TARGET = uno_20Mhz
uno20: MCU_TARGET = atmega328p
uno20: CFLAGS += '-DMAX_TIME_COUNT=F_CPU>>4' '-DNUM_LED_FLASHES=1' -DBAUD_RATE=57600
uno20: AVR_FREQ = 20000000L
uno20: LDSECTION = --section-start=.text=0x7800
uno20: $(PROGRAM)_uno20.hex
uno20_isp: uno20
uno20_isp: TARGET = uno_20Mhz
uno20_isp: MCU_TARGET = atmega328p
uno20_isp: HFUSE = DA
uno20_isp: LFUSE = FF
uno20_isp: EFUSE = 05
uno20_isp: isp
And the change on the boards.txt,
##############################################################
atmega328_20.name=Arduino Uno @ 20MHz
atmega328_20.upload.tool=avrdude
atmega328_20.upload.protocol=arduino
atmega328_20.upload.maximum_size=32265
atmega328_20.upload.speed=57600
atmega328_20.bootloader.tool=avrdude
atmega328_20.bootloader.low_fuses=0xFF
atmega328_20.bootloader.high_fuses=0xDA
atmega328_20.bootloader.extended_fuses=0x05
atmega328_20.bootloader.unlock_bits=0x3F
atmega328_20.bootloader.lock_bits=0x0F
atmega328_20.bootloader.file=atmega/ATmegaBOOT_168_uno20.hex
atmega328_20.build.mcu=atmega328p
atmega328_20.build.f_cpu=20000000L
atmega328_20.build.core=arduino
atmega328_20.build.board=AVR_UNO
atmega328_20.build.variant=standard
I did try to change the baud rate as well, to 115200 (curiosity..) with the same fuse setup and it didn't work. But since I am able to upload sketches, the speed of it is not of that importance for me, therefore I stop "investigating" more.
Thank you again for your time!
Diego.