Close

autoBaud! A new tool.

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

eric-hertzEric Hertz 03/02/2015 at 01:201 Comment

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

Eric Hertz wrote 03/02/2015 at 09:47 point

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