sdramThing4.5 "Logic Analyzer"

Now implemented.

It's funny, it worked surprisingly-well pretty much off-the-bat. And then... I tried to switch out the 16MHz crystal oscillator with a 22... then a 20... then a whole slew of others, including an 8... Nogo.

Tried *another* 16MHz... nogo.

Tried that first one, again, and it seems OK.

Strange. And I guess lucky that that seems to be the only one I have in my collection that works right, and just happened to be the one I was using at the time.

mmmm kay...

So, my logic-reasoning seems, at least, 1/3rd correct... Switching to the 74HC series has made it functional in "one-shot-bypass" mode. Which, it shoulda done *ages* ago. I still don't understand how it could've *not* worked, previously... The 'scope showed it OK, and, if I understood correctly, the clock-rate was *much* slower than the delays... But, switching to HC's seems to have made it work as expected. Might, plausibly, also have been related to the valid Vih/Vil conditions at these unspec'd voltages... OTOH, again, I *did* 'scope it, and it *did* appear to be correct.

Fine, I know I was stretching limits... and I know I was *really* stretching 'em, in this case. I am glad it's finally functioning as it should've... what.. week*s* ago?

I shall repeat what I said in my description-update. If you're doing something *simple* with some glue-logic... then don't be afraid to *try* using 5V TTL chips at 3.6V... Yahknow, if you've already got 'em on hand. I mean, an inverter for lighting an LED, or maybe even an AND, etc. gate here-and-there might *likely* be functional... I *have* in fact, been using 5V TTL chips rated for 4.5-5.5V from the early 1980's in simple 3.6V circuits for a couple years. But, yahknow, just don't expect it to be *perfect*. And, definitely, don't design a circuit expecting to use them permanently/professionally.

So, obviously, there's a non-insignificant bit of daisy-chained logic involved in my new circuitry, so, maybe it makes sense that using 3.6V-capable devices (the 74HC series) makes some amount of sense that it's now working as expected from the start.

I haven't, yet, attempted to test the one-shot circuitry--only currently testing in one-shot-bypass mode--so, that's next.

I guess the next step is using one-shot mode with the same SDRAM/uC clock-rate. It may (should?) add a one-column offset in read/write... OTOH, it might be cancelled out because the Read/Write command and the corresponding DQM strobe would *both* be shifted by one clock-cycle.

This will be a little bit of work...

Before: Chip-Select-Enable was activated, then Chip-Select was strobed

Now: Chip-Select will be activated, then Chip-Select Enable will be strobed.

(Chip-Select is bi-directional, whereas Chip-Select Enable is always an output from the uC).

It sounds easy, but the CS_En bits feed through quite a bit more logic... so there's quite a bit of potential for delays.... (and I *just* located a 130MHz crystal oscillator on an old motherboard, with-which every tiny delay will have a huge influence.)

So, there's a bit of coding to be done. As far as I recall, there are three places where an old chip-select strobe will have to be replaced by a CS_En strobe (and CS will have to be set up ahead of time): once in a Macro, which may be used in a few places... The other two are in inline-assembly... in the Read and Write functions. (What happens in the "startFreeRunning()" function?)

I *so* want to code this up and try it *right now*, but it's already 3:30AM, and... admittedly... I can't exactly focus, at the moment. We're talking, probably, 4 hours worth of work, just to get to a point to *try* the new code... and there's some amount of thankfulness that I'm (atypically) not in the mindset to be able to pull that off, right now.

OTOH, it's somewhat hard to accept the fact that it works *now* with the 74HC's. I know that seems obvious, but I 'scoped that shizzle!

I've seen bidirectional "bus switch" type chips, before... but in my experience they've generally been found to be quite slow... Plausibly, I was somehow stuck on something like the 4066, which wasn't really designed to switch data, but analog/audio?

Needed to switch out my 5V old TTL chips with 3.6V compatibles; it's time to eliminate variables. Again, 'scoping my 5V logic running at 3.6V shows they seem to be doing their job, but there are some atypically (for me) timing-critical aspects in this project, so maybe the lower-than-spec'd-voltage is causing slower propagation-delays, etc...

(I'm saying: From-experience: Don't be intimidated to use 74xx 74Sxx 74LSxx chips, maybe even the 74Fxx, in 3.6V circuits, if you're not worried about timing or doing something too complex (or professional). Seriously, I've been using these 5V chips from the 1970's/80's in various 3.6V circuits for a couple years, now... It's certainly worth a try if it's all you got!)

That said, it's time to eliminate variables, and this one-shot circuitry is pretty complex, in comparison to other such TTL-limit-stretching circuits I've done.

THAT said, Keep your old motherboards and old-dead PCBs from things you take apart. I've got more than I should, probably, but with four boxes (20+ years of taking broken things apart), I can usually find just about any common-enough component I need, or something similar-enough to do the job. This time, a bunch of 74HC-series would come in handy...

And low-and-behold, there's an old Pentium 166 laptop's motherboard in the top of the top box. Littered with 74HC chips, as well as others that could come in quite-handy some day...

AND easily a half-dozen "CBT3384"s on just one side of the board... Didn't know what they were, but there were so many it was worth looking up. This is a game-changer, here. That's the SN74CBT3384A, from TI. And, basically, it's a high-speed bidirectional bus-switch. Bidirectional, in this case, NOT requiring a direction-change control-signal. Handy for AVR IOs. Propagation-delays of ~0.25ns. (I've never even seen a Tpd < 1ns in *any* chip, before). This thing looks Quite Handy. And I've got *a lot* of them.

I've already a bunch of ideas where they could be used... partially from exploring *now that I have 'em* but also from numerous previous designs where I thought "yahknow what'd be nice..."

Here's a quick idea: You've got a bus with a parallel FLASH chip, and a parallel SRAM, they both share the same I/Os for data, on the AVR... (Bidirectional). Now, say they're both a little slow, so enabling/disabling the output on one may take several AVR clock-cycles. Throw a bus-switch between each and the bus, and you can set-up a read from the flash, and while waiting for it to retrieve the data, also do a write to the SRAM...

It's just one idea. These things are, allegely, SO fast they could be used in all sortsa switching-environments nearly completely invisible to the peripherals... I dunno, maybe use that SPI port to read/write to an SD-card, and switch the bus over to something entirely different...

Or, in the case of this "logic analyzer": use them to switch the sample/repeat mode, or who knows. It's not perfect for this system, as-designed, but I likely would've designed it differently if I'da known I had these. (Though, I was originally trying to keep it as simple as possible, with as little external logic as possible, so who knows). Either way, they definitely are going in the Useful Tools category. And, despite their tiny-spacing, I've managed to figure out a way to put 'em on bigger-spacing breakout-boards without much difficulty (sacrificing 4 switches in the process, but not bad considering they have 10).

So, there's that.

Other useful things I've found in large-quantities on old dead laptop-motherboards: high-current P-Channel MOSFETs, which are excellent for power-switching. And despite their SMD footprint, because they share so many pins for the same purpose they're pretty easy to use on regular breadboards, or even just attach some big-ol' wires, and heatshrink for prototyping...

As far as the project goes... I've done write/read, and have gotten some weird results. Thus soldered-up these 74HC's to replace the 74S's. We'll see where this goes.

I might as well rename this project from "mishmash" to "sdramThing3.5", since the original mishmash of project-ideas has been put on hold for so long... Ah well.

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.

I've finally reimplemented Read!

Yep... I've been working with this thing without the ability for the uC to *read* data written by the uC to the SDRAM...

Way back in the day, I had READ... I needed it to verify that the data was being written correctly. Turned out, way back then, that the problem was noise on my SDRAM's Clock line... I shielded that cable and found that the reliability was impeccable (zero errors in dozens of tests of 128MB)... So, It's not exactly that I *got rid* of READ, but that the software kept getting improved, and the hardware, as well, and at some point the old code for readback was no longer compatible with the new hardware... and, well, it was working so well for so long and continued to do-so for so long that I didn't bother to update the readback code to make it functional with the new designs.

So, now, it's reimplemented.

(As another beneficial aside, I've finally put the free-running sdram interface in my commonCode. It's designed, specifically, for Free-Running. But, now that READ's been reimplemented, there's no reason it couldn't be used as a *huge* (and plausibly somewhat slow) RAM for any project, free-running or not, only requiring a single 7451.)

The results?

It seems to work perfectly in the old configuration (with the one-shot circuitry removed from the system).

With the one-shot circuitry in logical-bypass mode (the old-configuration's signals going through an AND gate whose other pin is always active)... not so much.

I haven't analyzed it much, yet... it's late. But, of course, this would be the one tool that's probably the most important in debugging this thing... and I put it off for quite some time, doing all sorts of seemingly unrelated things (like commonCoding it, improving the comments, cleaning it up *substantially*, etc.)

Onward!

(Wait, wasn't this project supposed to get me working with a stepper-motor-driver? Man, I almost completely forgot about that).

Much like my project, I keep meandering around the details I intend to work on... ...with my project logs. What my last project-log was *intended* to be about was regarding the irony that I've managed to get this entire crazy thing working to the extent that it does... (sdramThing 1.0, 2.0, 3.0, each of which functioned great for the purpose)...

...and yet, something as simple as the logic/math to move a couple cursors around on a screen eluded me for *hours upon hours*.

Seriously, the concept's pretty simple. There're two cursors, they move up and down, left and right. The "lower" cursor shouldn't cross over the "upper". They shouldn't be allowed outside the limits of the screen. The step-size is variable... 2^n pixels. Not so complicated, really...

...but the actual process... Eluding me.

E.G. the upper cursor is located on line 10, the bottom cursor is located on line 15 (the screen draws Y downward). The step-size is 128, and I try to move the lower cursor upward. A) It shouldn't cross past line 0. B) It shouldn't cross past the upper cursor... Not so difficult. Right?

E.G.2: Both cursors are in the same positions as before; upper is somewhere mid-line on line 10, lower is somewhere mid-line on line 15. But this time both are selected, and I try to move them upward. What should happen? Doesn't really matter to me, at this point, as long as they don't cross 0 and don't cross each other.

E.G.3: Same as above, except the upper cursor is, say, at (10,128), and the lower cursor is at, say, (15, 25)... Now both are moved upward, simultaneously, with a step-size of 128... Now, what should happen? Again, they shouldn't *cross*. The "upper" should stay left of the "lower", if they're on the same line...

Now, it seems a bit more complicated, but not horrendous... But then, I've come up with so many such weird-cases that it's just been overwhelming.

Throw in the mix that the "upper" cursor has to lie in a certain range of pixels, which varies depending on which line it's on... and it's somewhat sporadically-placed along each line... and it's significantly more complicated... (move both cursors right, they're only 10 away from each other when they start, but the left cursor can't be at the requested-position, so must be shifted 20... now they've crossed-over.) So many weird cases.

I've wound up with a while loop that just keeps trying and trying until it gets there... it's horrendous, and huge, and filled with so many steps, and in the end the motion is darn-near unpredictable. Move up, and it ends-up moving up and left. WEE!

It's just funny that something seemingly so simple as moving around a couple cursors is so hard to wrap my head around. Maybe it's still not my month.

I bit off a huge sub-project looking into this cursor-thing...

See, the thing is, "Free-Running" works by pre-loading each page in the SDRAM with instructions to begin reading the next page...

These instructions are near the end of each page (1024 columns of data... bytes, words, etc. depending on the SDRAM's layout).

Starting "free-running" takes quite a few CPU instructions, as it requires sending the "read-burst" command/address on the same pins that the SDRAM will eventually use to send commands to itself.

So, that means starting the read-burst, then changing the directions of a whole bunch of pins, and a few other things before the read-bursted-commands can actually be fed back to the SDRAM's command/address lines.

So, I thought, maybe there was some issue starting the read-burst from an arbitrary location in the page that's too close to the fed-back commands.

E.G.

If the cursors are allowed to be placed *anywhere* on the screen, then it's entirely plausible a "free-running" read-burst (in the sample/repeat mode) would be started from column 1020... and, well, columns 1020-1022 contain commands... and it takes more than a half-dozen cycles for the CPU to switch the port directions etc. So those commands would be lost, and the system would crash.

That was the thought.

It took *days* to rewrite this code to handle that safely. And it didn't solve the underlying problem... WEE!

It *will* be necessary when the SDRAM runs faster than the uC, but we're not there yet.

I'm still avoiding doing read-back/verification of the written-data. I don't know why. It seemed so daunting at first, so much *ancient* code that hasn't been used for *years*. But, the more I think about it, and the more I avoid it with hugely-complicated things like this, the simpler that seems.

...worked surprisingly well, considering how convoluted the concept and the code.

I've been hacking at this thing for what seems like ages... I think I said that once before, and *that* seems like ages-ago.

This thing is *huge*. I can't believe I wrote all this code.

Currently, got a bit side-tracked...

I *still* can't get it working through the one-shot circuitry 9 times out of 10, even with it in *bypass* mode. Absurd: bypass-mode sets one input of an AND gate high, so that the other input goes in and comes out just like it went in. Physically bypassing that gate, by pulling the chip and shorting its input to the output, works.

I, once, figured there was something to do with code--buried somewhere I couldn't find--that set *another* pin too closely to the passed-through signal... and that the passed-through signal was being delayed slightly by the gate, which somehow allowed an overlap. But, I've gone over this code with a fine-toothed-comb, and now understand that part of it inside-and-out (again). I've also rewritten a bunch of it to make it more clear and even less-likely to have issues due to gate-delays.

I've 'scoped it, I've done durn-near everything I can think of. Still ain't working through the bypass gates. ONE idea I have yet to test:

There is another AND gate, in the chain (which works when the *other* AND gate is physically-bypassed) whose output is *disabled* by having one input tied-low. The other input to this gate could *float*, briefly, at times... And the amount of time it floats *might* be a tiny-bit longer, due to the "one-shot bypass" AND-gate. Or something. So, I've actually been looking into the specs of TTL ICs...

The idea: It's *plausible* that a floating input on an AND gate, even when the *other* input is tied-low, *might* allow for a high output.

Theory:

TTL AND:
In0   In1   |  Out
-------------------
0     0     |  0
0     1     |  0
1     0     |  0
1     1     |  1
0     Float |  could be 1 ????

I don't exactly understand the logic of a "dual-emitter" BJT, but maybe...

So, I might end up trying this out, throwing together something on a bread-board with a slow sine-wave input... Seeing whether there're any glitches on the output (it should *always* be low, logically, right?).

I've a few other ideas as to why the bypass circuitry doesn't work, but most aren't being clearly-corroborated... (the power-supply/voltage-regulator might be having problems with the excess current-draw? 'scoping looks alright.)

And a few other tests to try (the obvious one being to set-up read-back of the written-data, for verification...)

It's just so strange.

In the meantime, I've been avoiding the verification-step, not exactly sure why... (now that I re-understand the WRITE code, inside-and-out, updating the *ancient* READ code shouldn't be too difficult).

In my avoidance, looking into other things, which are plausibly only *tangentially* related to the bypass-problem...

Now I'm revising the code for the cursors...

And have run into another *entirely weird* non-functionality.

As @davedarko and I have agreed... maybe this just ain't the month for development.

Been hacking at this thing for seems like ages...

I've revised nearly all the code, just to try to get it working in a way it *should've* worked from the start...

Seriously, logic-wise, the only change that should've been necessary to the code would've been to set one pin low. Then it should've worked *exactly* the same as before.

I realize I'm pushing certain limits with the use of 5V TTL chips at 3.6V and a few other things, but this is getting ridiculous. The 'scope traces look good. The only piece of circuitry that's causing problems is an AND gate (or daisy-chained NANDs).

One signal in that AND is driven by a steady-state High. The other signal toggles, but does-so *around* another signal that actually handles the timing. So, basically, this AND gate's output acts as an output-enable for another bit of circuitry which already works.

Looking into the code, quite a bit, it seems the only places it's used is *far before* the signal which is being enabled, so even if the AND gate introduced a *huge* delay, it shouldn't matter. Further, I've added delays to account for it and still am not getting a functional system.

Then, to take it a step further, I've 'scoped the actual signal that's being output-enabled, both its input and its output... and it's functioning well within expectations. So, it's not like the AND gate is outputting too low of a voltage to trigger the output-enable.

So, it seems to me, there must be some tiny piece of code somewhere that I just manage to keep overlooking. This bit of code must have the output-enable and the actual signal right near each other... e.g. "enable output-enable; strobe-output; disable output-enable" back-to-back.

But, I've looked over the code extensively and just don't see it.

On the plus side, as usual, doing this has refamiliarized me with the code, which *will* have to be changed to make use of the one-shots. It's also given me the opportunity to revise it quite a bit, which will also lend itself well to conversion to one-shots.

E.G. Previously, each command sent to the SDRAM (Read, Write, Precharge, Activate...) had a function with its own setup-instructions. (I.E. turn the Command Port into outputs, Drive the Chip-Select Enable, Strobe the chip-select) that might as well be the same for *every* command.

(Originally, I tried to minimize the number of CPU cycles on each command, based on assumptions about the previous state, knowing that certain functions are only called immediately after others, etc. I did this because load-times were nearly 5minutes. But, doing it this way means that changing over to One-Shots would mean revising code for *every* function.)

Instead, I've combined all that into a single "set-up for command" function, that *should* work no matter the previous state, but is also quite a few more instructions than necessary in most cases.

And, again, doing-so was beneficial, because it made me look into every function, which is good for refamiliarizing myself with how it worked, and led to quite a bit of cleanup of code and notes that still existed all the way back to the completely incompatible sdramThing1.0 days.

Still... Surprised it doesn't work.

Finally getting into looking into the old code... It's not as bad as I remember, but it is pretty dense. Doing a bit of cleanup, etc. (which also serves as a good memory-refresher) before getting into the nitty-gritty of trying to get the one-shots working (even in bypass mode).

When working with SDRAM read/write procedures:

Don't Forget That SDRAM RETAINS ITS DATA for NEARLY A MINUTE (or more?) even when powered-down.

So, when doing a test of a new write-procedure, power that thing down for a minute after each successful test.