Arduino UNO @ 20MHz

Did you change the xtal to a 20MHz one?

would you not just change the crystal to a faster one?
do you really need to change the code?

devobtch

gvi70000:
Did you change the xtal to a 20MHz one?

Yes, 20MHz crystal bought from Tayda Electronics. I tried 2 just to be sure. I also tried putting the chip on a breadboard with 20MHz crystal, caps, ... but got the same error. I can upload sketches through my USBasp but can not make a serial connection.

I would like to revisit this thread(yes I know it is old) as it seems to have encountered the most untimely death,

So, because it is still completely unclear to me(noob), perhaps someone will be kind enough to comment on these....

  1. whether or not you can actually operate the ATmega328p on a breadboard with a 20Mhz crystal, while all the things requiring timing remain correct,
    2)If so, what is the general step by step procedure to do this. To clarify....I would assume most people capable of using this forum would be able to cut and paste something like a boards.txt file. However, I would less likely assume the same people looking for help on this forum to be able to correctly modify the contents inside. Same goes for Makefile, Optiboot, etc. files.

Many Thanks!

  1. whether or not you can actually operate the ATmega328p on a breadboard with a 20Mhz crystal, while all the things requiring timing remain correct,

You can certainly operate on the faster crystal. As for the "things requiring timing" there are two parts:

  • The bootloading process
  • The running sketch

In the running sketch the simplest thing would be to compensate internally. For example, to wait one second you wait for:

delay (1000UL * 20 / 16);

That would increase the number of "wait ticks" because each one will come faster. Similarly for things like setting the baud rate.

To upload sketches what I would personally do is use the ICSP uploader (I use another Uno for that) in which case it doesn't particularly matter what the clock speed of the target chip is.

Hi,
Thank you Nick for the help.
I would not exactly be too keen on trying to remember to "adjust" for the timing in sketches, unless as an absolute last resort.
I remained confused enough as it is....just trying to do very simple sketches from the examples menu right now in order to learn how Arduino functions. I think this would only complicate matters. For example....the "UL" that you placed behind 1000 is new to me, what does it do? Otherwise, delay(1000 * 20/16) does actually make a little sense to me.

Same goes for the ICSP. I haven't a clue what that is.( in spite of many, many previous searches on the topic) My conclusion is that it is just "another" method to program Arduino that I need not concern myself with right now.

I am sorry if this is redundant, but allow me to ask my questions in another way:
Considering that I am using an UNO r2 to burn the bootloader to bare chips on the breadboard right now......and then using an FTDI usb adapter to connect the "new" breadboarded Arduino to a pc......and I have both 16 and 20Mhz crystals available to me.

  1. is there a proper bootloader that I can install onto a bare ATmega328p(on a breadboard with 20Mhz crystal) that will allow me to load sketches from the IDE without requiring to account for the timing differences within the sketches?
    2)is there a proper boards.txt file that I can replace the existing one with that will allow me to load sketches from the IDE to the same breadboard with 20Mhz crystal without requiring to account for the timing differences within the sketches?
    3)is there any other files, ie, Makefile, optiboot, etc. that would need to be changed as well to allow me to load sketches from the IDE to the same breadboard without accounting for the timing differences from within the sketches?

or put more simply....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?

thanks again for your patience,

billcat:
I think this would only complicate matters. For example....the "UL" that you placed behind 1000 is new to me, what does it do? Otherwise, delay(1000 * 20/16) does actually make a little sense to me.

Read this:


Same goes for the ICSP. I haven't a clue what that is.( in spite of many, many previous searches on the topic)

This summarizes programming methods: Gammon Forum : Electronics : Microprocessors : Solving problems with uploading programs to your Arduino

My conclusion is that it is just "another" method to program Arduino that I need not concern myself with right now.

Using ICSP programming the exact clock speed won't matter, so maybe you should. If you up the frequency then the bootloader won't work unless you compensate.


  1. is there a proper bootloader that I can install onto a bare ATmega328p(on a breadboard with 20Mhz crystal) that will allow me to load sketches from the IDE without requiring to account for the timing differences within the sketches?

There may be, I'm not sure where it is. Otherwise take the standard bootloader, and try compensating in the boards.txt file (make a copy of the relevant entries and increase the baud rate by a factor of 20/16.

fasteruno.name=Arduino Uno at 20 MHz
fasteruno.upload.protocol=arduino
fasteruno.upload.maximum_size=32256
fasteruno.upload.speed=144000
fasteruno.bootloader.low_fuses=0xff
fasteruno.bootloader.high_fuses=0xde
fasteruno.bootloader.extended_fuses=0x05
fasteruno.bootloader.path=optiboot
fasteruno.bootloader.file=optiboot_atmega328.hex
fasteruno.bootloader.unlock_bits=0x3F
fasteruno.bootloader.lock_bits=0x0F
fasteruno.build.mcu=atmega328p
fasteruno.build.f_cpu=20000000L
fasteruno.build.core=arduino
fasteruno.build.variant=standard

That might work, I haven't tested it. I increased the bootloader baud rate to 144000 which is 115200 * 20 / 16


3)is there any other files, ie, Makefile, optiboot, etc. that would need to be changed as well to allow me to load sketches from the IDE to the same breadboard without accounting for the timing differences from within the sketches?

By changing f_cpu above it might compensate. However some testing I did in the part meant that the simple change actually threw up a lot of compiler errors for non-obvious reasons.

Someone else may be able to offer better advice.

thank you Nick,
I have read every bit of the information you have included and linked, but comprehended maybe 10%, hehe.
I certainly have no idea what all is happening regarding makefiles, optiboot, boards.txt, etc, when I "burn bootloader". These are just terms I have come across while attempting to learn about this. I simply know that I have been able to successfully install the bootloader using the UNO to ATmega(16Mhz) on breadboard a couple of times. Not even enough times to have the process committed to memory yet.

But I am especially unclear of this. You mentioned issues with the bootloader. (with 20Mhz breadboard)
Is the issue with the ability to actually load a sketch, or does it simply affect how the sketch functions after it is loaded? Or both?

I have found the boards.txt file that came with the IDE, and could cut and paste the fasteruno code you posted into it, but I am not sure that is what you are suggesting that I try, especially regarding your following "compiling errors" comment.

cheers!

The bootloader is called (usually) when the chip resets. If it finds incoming suitable data it uses that to reprogram the lower part of the flash memory (not itself, of course). Once done, or if it finds nothing, it jumps to address 0 to start the "real" sketch. Thus the bootloader is only important for changing the existing sketch, and you don't even need it for that if you use ICSP programming instead (via the 6-pin SPI header).

I have found the boards.txt file that came with the IDE, and could cut and paste the fasteruno code you posted into it, but I am not sure that is what you are suggesting that I try, especially regarding your following "compiling errors" comment.

You could copy and pasting my suggestion to the end of that file, and restart the IDE. Then choose "Arduino Uno at 20 MHz" from the Boards menu. If that doesn't work, oh well, don't choose it again. It might.

I hope your end application is worth all this pain. You are going to quite a bit of effort for only a 25% speed increase. With most applications the chip is sitting around waiting for input, the raw chip speed isn't all that important.

I've been following this thread with some interest.
I have built several of my Arduinos and have never used a bootloader (only ICSP) so the higher clock speed won't be a factor, however I'm confused about timings relating to other functions.
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?

WhatEver.upload.speed=144000
        :
        :
WhatEver.build.f_cpu=20000000L

Is the baudrate edit also required?

True, for most applications it wouldn't be of much use but when generating video (especially VGA it will be very handy.

Well I tried just that for my VGA output and got a bit frustrated with it.

However, re-testing with my suggested setup seems to work (however not on a Mac).

On the Mac, it didn't seem to like that baud rate for the sketch upload:

Binary sketch size: 2,594 bytes (of a 32,256 byte maximum)
avrdude: ser_setspeed(): tcsetattr() failed
avrdude: ser_open(): can't set attributes for device "/dev/cu.usbserial-FTFAYL28": Invalid argument
ioctl("TIOCMGET"): Bad file descriptor
avrdude: ser_close(): can't reset attributes for device: Bad file descriptor

On Windows however it did, and I got the ASCII table sketch to work, however not at 115200 baud. At 9600 baud it worked fine.

Here is my setup:

Hi Nick

I see your setup is different to mine, I use a AVRMKII ISP from Atmel but can't test it until I'm back at the office.
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?
I will try get some other standard crystals at 20.48MHz and 19.8MHZ and test.

Another way is of course writing the sketch for 20MHz, uploading with the 16MHz crystal connected, then switching off and replacing the crystal with the 20MHz one.

CrystalSelector.jpg

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.