From the documentation on the SVP I can find no reference to a bootloader present on the main processor of the SVP. Only a bootloader for the ancillary processor is mentioned.
- From this, I assume that the ancillary processor is used to program the main processor in ISP mode, and the full 32kb / 128kb is available for the user. There is no main processor bootloader. Is that right?
- As (assumed) the main processor is programmed using ISP mode, there should be no limitation to change the clock frequency of the processor (by resoldering another crystal), either up or down. Subject to voiding warranty. Right?
There is no bootloader on the Orangutan SVP’s main AVR processor, so you can use the entire 32/128kB program space for your application. The auxiliary processor acts as an AVR ISP programmer.
Why are you interested in changing the oscillator?
The maximum frequency of the ATmega324/1284 is 20 MHz. The SVP ships with a 20 MHz oscillator, and its fuse bits are set so that it runs at 20 MHz. So I don’t think it’s possible or desirable to replace the oscillator with an oscillator of a higher frequency.
Note that AVRs are designed so that if the clock-related fuse bits are wrong, then you can’t program them. Therefore you’ll probably need to change the fuses before you solder in the new crystal. You should be extremely careful when changing the fuse bits because you could permanently disable the AVR.
The built-in programmer on the SVP does not allow you to change the clock-related fuse bits, so you will need to get an external ISP programmer (such as our USB AVR Programmer) to do that.
You actually probably might not have to change the fuse settings on the ATmega324p/1284p; it really depends on what you want to change your clock source to. The SVP is configured for a full-swing crystal oscillator (it happens to use a 20 MHz resonator). If you want to replace this with full-swing crystal oscillator that runs at a different frequency, you will not have to change the clock fuse bits. However, you will need to change the clock fuse if you replace it with a low-power oscillator. Please see the “System Clock and Clock Options” section of the ATmega328p/1284p datasheet for more information.
As David said, we do not recommend going to a higher-frequency clock because this puts the AVR out of spec and could lead to problems. If you go to a lower frequency, some parts of the Pololu AVR library will not work right (the library assumes that the system clock is 20 MHz). We provide the library source code, though, so you could always modify it to run properly at your new frequency and recompile it. For example, you would probably want to rewrite the delay_us() function so that it delays for 1 us when using your new clock speed.
The ISP frequency of the built-in programmer is fixed at 2 MHz, and the ISP frequency needs to be less than 1/4 the clock speed of the AVR that’s being programmed, so if you use a new clock that is 8 MHz or lower, you will need to use your own external programmer. Otherwise, the built-in programmer should work fine for you.
Thanks for the response. I’ll see how it goes at 22.1184MHz.
I am interested to change the frequency of the crystal oscillator to get a “nice” base frequency. Unfortunately, although 20MHZ (or 16MHz on an Arduino) sounds nice, from the point of view of integer programming, clock scaling, and UART interfacing, it is difficult to get nice numbers.
A small example.
20MHz scaled by 1024 = 19,531.25 so rounding gives 19,531 with an error term.
22.1184MHz scaled by 1024 = 21,600 with no error.
20MHz scaled to 115200baud = 173.6111111111 so rounding gives an error term.
22.1184MHz scaled to 115200baud = 192 with no error.
I’m not too worried about pushing specification on this project, as the 1284p is certified for an Operating Temperature -55°C to +125°C. Which is way outside my operating temperature… There are also reports of AVRs working successfully at 32MHz and beyond.
In the scheme of things raising the clock frequency by 10% to 22.1184MHz is no big deal. But, it will help to make clocking and clock division more accurate, and remove the need to provide error terms in calculations for I/O.
I understand that Pololu can’t provide a design out of specification, as you don’t know who’ll sue you when their “steel mill shovel loader” or similar project fails and someone gets hurt.
As I mentioned on your other thread, it might be a bit of a hassle to get a crystal and associated caps into that small resonator footprint. If you’re actually using 115.2kbps, the error is still quite small, and there’s often an option to count to some slightly smaller number than the full 1024 so that you can get good rounding. But, sounds like you know what you’re doing.
By the way, there’s no specific warranty on our products, anyway, and if you kill your AVR, we’d still probably help you get it replaced. Round-trip shipping from Australia doesn’t sound cheap, so be careful!
Thanks for your help with this idea.
Having received the SVP, I have to agree. Unless it is possible to get an oscillator with exactly the same footprint, it all looks too small to go playing with. Which makes the idea pretty dead.
However, for the record, could you quote the product number / footprint specification for the existing 20MHz oscillator, please?
The footprint is for a Murata CSTCE series resonator, which is in a 3.2mm x 1.3mm package. There are some slight variations in the packages for different speeds and accuracies; the footprint we use should handle a few of them.