These things seem to run at 40 MHz.... And almost at 48!

[SpenceKonde]

Throughout the readme I was throwing around 48 MHz (since that's the highest I thought was plausible and hence bothered to handle), but warning people how it would probably be unstable, and that even 40 was unlikely to work.

In the unit I tested at that speed, we seem to be right on the edge. It almost works, About 1 in every 50 delay() calls seems to terminate instantly (using blink with delay changed to 100ms, and printing millis at start of loop) between calls to delay every 100ms, and the printing (but not the blinking) stops after a few thousand print's. The 40 MHz one worked like a charm!

Anyone got a benchmark that's known to be good at crashing overclocked AVRs? I'll bet if you binned them you could find some that would run at 48.....

I've ordered some of the high-temp spec'ed ones to see if they will run at higher speeds (if they're just getting them by binning the chips and calling the ones that come out better E-spec and the rest I-spec, E-spec should work at higher speeds, right?), and I've got some 32, 40, and 48 MHz crystals that will fit the footprint on my new AVR128DB64 breakout boardsso I can compare with clock generators.

Those will be listed in the store, but only after some more qualification tests (need to see which board features work and can be bragged about: the two interesting ones being the support for MVIO voltage control by the chip using an external regulator IC (I found this baller regulator IC, the idea would be you run the AVR from 5v, and that's Vin for the reg, and can turn the reg on and off and switch it between a few voltage options using three digital pins ) and rthe slot for an ESP8266 wifi adapter for internet connectivity).

[SpenceKonde]

I did finally make one part of these things misbehave due to clock speed. At the undocumented 4x multiplication factor, the PLL clocked from external 40 MHz clock and used to drive TCD0, glitches sometimes! Can you belive it? What a shoddy piece of engineering! I'm not even exceeding the rated max PLL speed by a factor of 4!

[wa2mze]

I assume you're talking about the AVRxxxDB series. I just ordered ten of the 128kb parts in assorted pin sizes (3 28-pdips, 3 48-tqftp, 4 38-tqftp). I have a TON of 25mhz crystals in the junkbox, and some 24.5mhz ish ones too. So I'm guessing that the 25mhz crystals won't be enough of an overclock to stress these things even a tiny bit. Can you provide info on how to tweak the dxcore code for "custom" clock rates? I suspect that some careful adjustment might be needed for the _delay_xx code to keep that accurate, but that the usart baud rate code, SPI, Timer, and I2C calculations will just eat the F_CPU constant and be spot on ("or close enough for government work").

[SpenceKonde]

They don't already have support for 25 MHz in the dropdown menu? The speeds available on megaTinyCore are supposed to be a subset of the ones available here - all the code for those speeds was already written for megaTinyCore (though I thought I copied it all from DxCore!)

[wa2mze]

Actually, no. The menu lists 20 and 24mhz crystals, and various options from 28mhz and up to 48 mhz, but NOT 25mhz. Is it just a matter of moding "boards.txt" to change the F_CPU number? I know 25mhz isn't much of an overclock, I just happen to have a lifetime supply of these crystals!

I added these lines to "boards.txt" just before the 28mhz section:
avrdb.menu.clock.25crystal=25 MHz crystal (overclocked)
avrdb.menu.clock.25crystal.build.f_cpu=25000000L
avrdb.menu.clock.25crystal.build.speed=25
avrdb.menu.clock.25crystal.build.clocksource=1

Does any code have to change in the lib's or 'drivers'? Maybe in the delay functions?

[SpenceKonde]

That may be all that's needed. If more is needed, timing will be fucked up and you'll get warnings printed - anything that needs to be brought over is already written for megaTinyCore and porting between them., I consider this to be a bug that will be dealt with in the next version, which should actually be soon because I am not going to work on anything hard over here since I have someone waiting on 2.0.0 ATTinyCore. #130

[SpenceKonde]

And by the way, at least on the first E-spec part I tried, 48 MHz external clock worked beautifully. :-P

Still looking for code that's good at crashing overclocked AVRs. :-)

[wa2mze]

The parts I ordered were I spec, not E, but I would expect that the very small overclock I have in mind will not upset the applecart here.
I did notice in the eratta sheet that operating the PLL from the external (or crystal) clock might not work, but it looks like the PLL is ONLY used for one set of timers, and those timers should work off of the CPU clock. I'd guess that the ADC or DAC systems might fail first when overclocked.
It would have been nice if the PLL could be used to generate the main system clock, like with their ARM Cortex M parts......

[wa2mze]

Doesn't work correctly, delay() produces wrong period for 25mhz crystal, but does work for 24mhz settings. Code in cores/dxcore/wiring.c needs a case for 25mhz F_CPU or it does wrong action.

[SpenceKonde]

ugh thern i need to port changes from megaTinyCore back to here.

[SpenceKonde]

``

It would have been nice if the PLL could be used to generate the main system clock, like with their ARM Cortex M parts......

No need for PLL, internal oscillator already covers the whole operating range of the core - and well beyond it. I suspect that under the hood, the same sort of technology as is used in PLLs is used to generate the internal oscillator frequencies, all multiples of 4 MHz, plux 1, 2, and 3 MHz.....

[XFer012]

Still looking for code that's good at crashing overclocked AVRs. :-)

Don't know if you're still interested after all this time. There's Coremark:

https://github.com/PaulStoffregen/CoreMark

May or may not need some tweaking to run with AVRs

[steve-chamberlin]

I'm very interested in this, and I'd love to know more about the details of the overclocking tests. What supply voltage were they run at? Were there any external devices connected other than a serial connection?

My intuition is that a test run at 3.3V with nothing but a serial port may not be demanding enough to prove much. A harder test would be run at 5V, with maxed out IO. Although the CPU core may run at a lower voltage, all the IO buffers run at VCCIO and power increases with the square of voltage. A harder test should also have all the IO pins connected to external devices, driving signals at 32-40-48 MHz.

[SpenceKonde]

Probably true, though IIRC this wasn't really a thing on classic AVRs.

But definitely let me know the results of any tests like that that you run.

[SpenceKonde]

All I can say is that I run them at 32 very often, and have neopixel controllers with LCD screens for UI running at 40