So, continuation of this project is going to necessitate quite a bit of flipping between various Crystal Oscillators...

(As I recall, I was last able to get it running with a 30MHz oscillator, but *not* with a 40MHz).

Also, there's a (selectable-output) frequency-divider between the oscillator and the AVR, so there will likely be *quite a bit* of frequency-switching as I try to stretch this thing's limits.

The first step was a bit 'o code on both the AVR and my PC's serial terminal emulator to automatically switch between 9600bps and 4800bps, for, e.g. when I switch between direct-oscillator connection and divide-by-two... (or divide by 2 and divide by 4). But that doesn't help when switching crystals...

Then I saw this: #April Fools' Pic Project. No kidding... @Brek Martin used his PIC's Watch-Dog Timer to detect the frequency of the external oscillator driving his PIC. Nice.

I had to see how accurate it could be... Could I use that method to get at least enough precision for 4800bps (transmission to the computer) with any reasonable clock-frequency I might encounter (in my test-environment)?

I started coding it up, got the basic proof-of-concept, then lost steam...

Then I saw this: #AVR temperature measurement without a sensor mentioned on the HaD blog. Wherein @Thomas Baum uses, again, the Watch-Dog Timer to detect apparently minor frequency-changes due to thermal drift of the RC oscillator used by the Watch-Dog Timer.

Well, thankfully, I don't need to worry *too much* about thermal-drift (or voltage-shift), as this is a prototype in a pretty stable test-environment. And, ultimately, I won't be needing this auto-frequency-detection scheme except during this phase of development... So, basically, using the WDT seems like a pretty decent "real-time" oscillator/timebase for a situation like this. Thanks to both these folks for the inspiration!

The basic idea is to run the WDT and count how many CPU-Clock cycles occur before the WDT times-out. Pretty simple, really. And looks to be quite the handy tool.

I finally got the calculations running, did a tiny bit of calibration, and got it to automatically configure the baud-rate, and the results are surprisingly accurate.

So far I've tested four crystals: 30MHz, 40MHz, 27MHz, and 16MHz. With the clock-divider, this gives me 5MHz, 6.75MHz, 7.5MHz, 8MHz, 10MHz, 13.5MHz, 15MHz, 16MHz, 20MHz. (This AVR is rated for 8MHz, but runs up to 20MHz, but no higher).

All except 8MHz resulted in something close-enough to 9600bps that the computer reads it glitch-free, all automatically-detected/configured. No kidding!

Currently, it's being tested in-system, so video wouldn't be too intelligible/convincing. I'll try throwing it on a breadboard, soon.