Switching between CPU clocks for debugging was fine before I needed serial-printout... But now that I've got write-read verification, I need some way to *see* what's happening. Thus, serial-printout. But that makes things difficult, or at least annoying, when switching clocks.
Spent a few hours developing "autoBaud", a soon-to-be commonThing.
Simply, upon boot the device transmits a simple serial bit-pattern recognizeable to my now autoBaud-capable serial logger: "serialThing". If serialThing detects that this bit-pattern is for a different baud-rate, it switches to that baud-rate.
-----------
I know modems have a similar feature... I also know that that feature is more fully-featured than autoBaud. I dunno exactly how they do it (Transmitting "A", I believe?). But this gets-er-done.
I'm working with two crystals, (and often do) so sdramThing is now coded for the faster 16MHz at 9600bps. The slower 8MHz crystal is exactly half that, 4800bps. (couldn't find a 10MHz crystal to go with my 20MHz).
The transmitted bit-pattern is a valid serial-frame in both bit-rates, so autoBaud does its thing and serialThing does its thing in response.
Handy.
I definitely see myself using this in other projects in the future.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Heh... stepped away for a few hours... came back, turned it on... and now it's darn-near working perfectly. Very Strange.
A bit reminiscent of the ol' sdramThing1.0 days, wherein I ended-up replacing the Clock wire leading from the crystal to the SDRAM with a shielded-wire, and suddenly it worked perfectly for years and through many revisions.
The clock has been extended to the one-shot circuitry, also via shielded-cable... so I can't pin it down to that, exactly. Though, maybe there's too much loading due to fan-out...? That might make sense: Now connected: the SDRAM DIMM (with 8 chips all requiring a clock), AVR, (a TTL 4-bit counter), and an additional four TTL (NOT CMOS) latches. That's a bit of loading, and may have something to do with the other oddity: That it works at 16MHz, but not 8MHz (seems backwards).
I've located a new 16MHz oscillator, with longer leads, so all my old experiments, with the old 16MHz oscillator, may no longer be relevent...
Still a bit confused as to how this would relate to the original problem... that it worked with *AND Gates* electrically-bypassed (the additional loading on the Clock doesn't change, in that case).
... and, now, it doesn't work again. No other changes than trying the older 16MHz=nogo, then reverting to the newer and again nogo.
So weird.
Are you sure? yes | no