Close

Auto CPU-Frequency Detection via WDT - Now Video!

A project log for sdramThing4.5 "Logic Analyzer"

An AVR, 128MB SDRAM DIMM, old laptop LCD, and a handful of TTL chips -- 30+MS/s 32-channel logic-analyzer interface for an analog 'scope

esot.ericesot.eric 05/06/2015 at 10:012 Comments

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.

Discussions

frankstripod wrote 05/12/2015 at 07:39 point

Hi Eric! Nice video. I also hate those short pins that just barely work. I couldn't believe I got past 7min in the video when you mentioned you couldn't believe it was already 7min in. A little long and dry for the kids, but makes the point.

  Are you sure? yes | no

esot.eric wrote 05/12/2015 at 10:00 point

Woot! Thanks for watching, Frank! Yeah, long-dry video, that's a good summary...

But dang it's gonna be handy... I think I'mma spend some time cleaning it up a bit and throw it in #commonCode (not exclusively for AVRs). 'course, that'd be exclusively for AVRs... ;)

  Are you sure? yes | no