I see that some of the Atmel AVR chips, like thew 644P and the 1284P, can clock up to 20MHz. I also noticed this old forum post that talks about ruinning just above 18 MHz:
Someone also told me that the Arduino libraries are coded to run at 16 MHz. I'm wondering, what would I need to change to increase the speed beyond 16 MHz? I think the serial code that sets baud rate would have to change. What else is keyed to the clock speed?
You only need to change one thing - the value of the F_CPU constant when compiling the code. You will, however, need to recompile the Arduino libraries for the newer F_CPU - if you don't already know how to do this, there isn't much point. The 4MHz gain is essentially negligible - speed issues are more likely introduced by communication lag or sensor update rates rather than the actual clock speed of the microcontroller.
Aeturnalus:
You only need to change one thing - the value of the F_CPU constant when compiling the code. You will, however, need to recompile the Arduino libraries for the newer F_CPU - if you don't already know how to do this, there isn't much point. The 4MHz gain is essentially negligible - speed issues are more likely introduced by communication lag or sensor update rates rather than the actual clock speed of the microcontroller.
I don't believe there is a need to recompile the libraries, that is done on every compile. However the big issue is the bootloader as it's 'hardcoded' at a fixed baudrate assuming the standard speed for that board selection. Recompiling the bootloader is a more complex process I believe, or one could play with the uploadspeed variable in the boards.txt with the equivalent speed for the existing bootloader being run at a higher then specified board speed, it that makes sense.
Aeturnalus:
You only need to change one thing - the value of the F_CPU constant when compiling the code.
Thats fantastic, thank you! If I do this will the code be smart enough to figure out the correct settings for all baud rates or are there only certain values that will work correctly?
You will, however, need to recompile the Arduino libraries for the newer F_CPU - if you don't already know how to do this, there isn't much point.
Well I can probably figure it out, if not there is probably some info somewhere.
The 4MHz gain is essentially negligible - speed issues are more likely introduced by communication lag or sensor update rates rather than the actual clock speed of the microcontroller.
In general I agree. I would expect that the vast majority of sketches spend most of there time spinning around waiting for some data to come in that they need to do something with. However I have an application where I am at the edge of being able to process my incoming data quickly enough, so I don't miss other data. Its true much of my app is gated by how fast I can write to an SD card, but even most of that activity is filling buffers. I do a lot of floating point math and trig, much of which I am working to eliminate or replace with int math. And i am building a make sile to see if i can get the -O3 compiler flag to do me a nice favor.
Still, if I can get a 20% performance improvement in the parts of my app that would be improved, that would be a nice win for me.
The code is written in terms of the F_CPU constant, and so should adjust automatically.
As a general rule of thumb, you should clean up and fix your existing code to be as efficient as possible before changing hardware - you don't know, for example, if any third-party libraries you are using happen to use F_CPU or just assume it has a value of 16000000L.
I believe that you may be able to simply modify boards.txt and copy the Arduino Duemilanove or Uno sections into a new one, and change the F_CPU in there to 20MHz - I stopped using the actual Arduino IDE a long time ago, so you'd have to take a look at this yourself. Pololu - 3. Configuring the Arduino Environment details how to do this for a hardware programmer and the Baby Orangutan, which has a 20MHz crystal on it - it may prove helpful for your endeavours.
-- edit -- @retrolefty, I believe the optiboot distribution already provides 20MHz bootloaders - in any case, its quite simple to modify the Makefile to generate one (I have attached one that I dug out of my optiboot directory, which I believe works)
-- edit 2 --
The attached bootloader is for an ATMega328P with a CPU speed of 20MHz, using an upload baud rate of 115200 baud.
Awesome, thanks everyone! I'm in the process of building a unique board based on the 1284P (with a LOT of help from CrossRoads). I'll try to stick a 20 MHz crystal on it and see what happens.
Skyjumper has posted elsewhere that 20MHz crystal was working, he was checking if baud rates, timers, were still operating correctly. Maybe in the thread with "1284 evaluation" in the title? Has been in the last day or 2.
CrossRoads:
Skyjumper has posted elsewhere that 20MHz crystal was working, he was checking if baud rates, timers, were still operating correctly. Maybe in the thread with "1284 evaluation" in the title? Has been in the last day or 2.
I did tell Crossroads I got it working, but a closer examination was that it did not run stable with Arduino code out of the box. The baud rates were not exactly right and the timeing in delay() and millis() was impacted enough to be a problem.
From a hardware standpoint it was not a problem.
From a bootloader standpoint, the bootloader when rebuilt for 20 MHz also worked reasonably well, although the baud rate issue occasionaly caused errors when uploading code and the code had to be re-uploaded. The bootloader is easy to hack to fix the baud rate because it always uses a fixed baud rate anyhow, so I just need to do the timing for any particular baud rate, set the numbers and compile the code.
Off the shelf Arduino cores probably should not be used because there will be some libraries what do depend upon the timing. I'm working on some hacks to the cores that will allow 20 MHz to work correctly.
But off the shelf, you can't just drop in a 20 MHz crystal and expect everything to work perfectly.
From what I've seen, the 328P chips can generally run rather faster than 20mhz as well, 25mhz is quite doable and 32mhz seems to be as well for many(though probably not all) chips.
To deal with the bootloader issue the easy solution to my eyes is to buy a USBTinyISP or somesuch and ditch the bootloader all together. Presto! No bootloader, now issues
Bobnova:
To deal with the bootloader issue the easy solution to my eyes is to buy a USBTinyISP or somesuch and ditch the bootloader all together. Presto! No bootloader, now issues
But then it would not be an Arduino. We can make a chip work at any clock speed it is rated for (and as you said, then some more) for any single purpose, but the issue is a general purpose device that someone can put any code into.
You can use an usbtinyisp or arduinoISP to upload via the IDE to a non-bootloader 328. I've done it, works great. Full IDE functionality, no bootloader to object to odd frequencies.
Bobnova:
You can use an usbtinyisp or arduinoISP to upload via the IDE to a non-bootloader 328. I've done it, works great. Full IDE functionality, no bootloader to object to odd frequencies.
Does that only requires adding a new entry into the boards.txt file to change the clock frequency and upload using entry?
Perhaps a posting of a 328 board type set-up for USBtiny programmer and running at 20mhz would be useful for some (like me ) ?
EDIT: On second thought I would guess other entries in the board type would also needing changing, fuse values to reclaim bootloader memory space, total flash memory size avalible, any others?
You an also use AVR Studio to upload any code you like. But if the code is based on Arduino then changes will be needed tot eh cores to fix the baud rate of the app itself and the timeing.
) ?