According to the data sheet for the Tiny, the internal PLL will multiply the internal RC oscillator frequency by 8 to provide a clock source for fast PWM. This means you can readily get a 64 MHz PWM output at 1 bit precision. However, the data sheet also says that there is a register which is used to calibrate the RC oscillator itself and that the PLL will follow that frequency up to a point (85 MHz). Therefore, if one were to change that register and alter the base frequency of the RC oscillator, one could get a PWM square wave of 85 MHz. But the sheet remains silent as far as I can tell, regarding how to manipulate the register bits to achieve a desired frequency.
The register I'm talking about is OSCCAL and changing it can give you up to 200% of the nominal frequency (nominal being 8 MHz). Since this is well beyond what the PLL is capable of locking to, all I'm interested in is getting 10.625 MHz or something close to that on the low side, as this will result in a PLL frequency of about 85 MHz. Does anybody know how to program this register?
Furthermore, the data sheet says that no more than a 2% change in frequency can be made at a time AND all the changes need to be made while the chip is in reset BUT every time the chip resets, the RC oscillator is automatically re-calibrated to nominal values. This part confuses me because not only am I unaware of how to change a register in software when it's in the middle of a reset cycle but also how to keep the changed values when the chip is reset. It's pretty unclear just be reading the data sheet so I'm hoping somebody has tinkered with this register before and knows how to tune it.
Based on section 20.3.2 of the data sheet, in addition to what you've already read, it looks like the OSCCAL register isn't meant to be changed by software. There are calibration bytes that can be written by an external programmer, and that calibration byte is automatically loaded into OSCCAL at reset.
Indeed I missed that. Thanks for the supplementary info. Do you think this external programming would be possible with an Uno (via spi) or using AVRdude or do I have to buy something to accomplish this?
Based on supplementary info provided in this thread (thanks Jiggy), it looks like the most important information resides in memory address 0x01 of the Device Signature Imprint Table. The data sheet explains that the calibration contained in this byte of memory is loaded into the calibration register, OSCCAL on reset, making the goal to modify the DSIT byte 0x01 rather than OSCCAL directly. However I still cannot find any explicit mention of how this can be accomplished. I assume that once a means of writing this byte is established, the contents itself are none other than that in the graph above... a simple 8 bit number representing the x coordinate on the frequency curve which gives you the desired y-coordinate (the frequency) of that RC oscillator. In this case, a number like 200 (0xC8), might do the trick for maxing out the PLL frequency.
So there's some conflicting information I'm seeing, or we're just interpreting stuff wrong. AVR055: Using a 32kHz XTAL for run-time calibration of the internal RC, section 7.1 mentions settling time when changing OSCCAL. No special procedure or caution is mentioned for changing the value, so maybe you can change it while running without consequence.
You guys need to go back to the datasheet and review the nomenclature used by Atmel here; you are both conflating different, related things here.
To nudge the speed of the internal oscillator, you change the OSCCAL register - you can read and write to OSCCAL like any other register (eg, OSCCAL=0xF0;), you'll need to experiment with what value gets you the desired frequency with your specific chips; it would also be prudent to ramp it up, rather than slamming it to some value far from the default frequency in one go. I think they comment on this - Atmel did somewhere, either in the datasheet for an AVR, or in an app note.
Make sure you have a good solid 5v supply with proper decoupling. Maybe even kick it up a few tenths of a volt.
You CANNOT permanently change it to a different value with an external programmer; it will always reload the pre-programmed value on startup (and you can't write to that, though you can read it, with external programmer), but you can change it from your sketch.
Atmel does not guarantee what speed the PLL will saturate at, only that it will be at least 85mhz.
One wonders what happens when you set the PLL as your system clock source, then set OSCCAL to something way higher than normal such that the PLL saturates and loses lock...
"Losing lock" just means the frequency is not properly in phase with the input signal, and is probably not at the right frequency that you would expect from the multiplier. The microcontroller will probably still work, but timing will be messed up.
Also I looked into that (speeding up the cpu) and there is a hardwired divider of 1/4 so that a 64 MHz PLL will give a cpu clock of 16 MHz. Theoretically then we could achieve 20 MHz, which is a speed which is supported by the chip, and if it's like any other CPU, you might even get away with 21 or 22 MHz but at that point your PLL is above 85 MHz anyway so that's your bottleneck regardless. I have no idea what changing the cpu speed would do to screw up the code and how it behaves but the digispark is already 16.5 MHz instead of 16 and I haven't noticed anything weird going on so maybe it's fine for most applications?
Shall I go and buy the smallest heatsink+fan ever made to glue onto the ATTiny85 chip?
I have no idea what changing the cpu speed would do to screw up the code and how it behaves
As long as the clock pulses stay within the required limits of minimum high and low time and maximum transition time, it won't screw up any code execution. But anything that's being timed by an erratic and unstable clock will obviously be inaccurate.
