Eric HertzIf you're already toggling CKE... why not just multiplex the SDRAM's clock-input between two clock-sources, one for communication with the host, and one for sampling...?
.........
Am thinkink:
Case 1: Communication with e.g. an AVR (where the exact cycle-count is possible) this is doable... sans one-shots... rendering the sdramThing3.0->3.5+ transition utterly unnecessary (woo!).
Case 2: Communication with a host that can't keep an exact cycle-count between signal-transitions, not-so-much. BUT: THEN: Most hosts have e.g. SPI, which could be wired to, say, CKE or /CS... and then you know exactly how many cycles between a rise/fall. Hmmm...
Oy.
..........................
(In other words, it's entirely plausible none of the developments from sT3.0-4.5 are necessary, especially one-shots. Oy).
..........................
That said... I'm not of the mindset to figure that out right now... But there's something I saw here, which is along those lines:
I'll give yah a hint... it's at the /CS strobe...
Yah see it...?
/CS needn't be a single clock-cycle for read or write!
Why? Because repeated read/write commands can be sent back-to-back (even when in burst-mode).
So, say /CS is active for a really long time... The end-result is that column 0 will be repeatedly "output"... (but masked by DQM) Then when /CS is released, the burst will continue.
And, in fact, that might remove the need for the second CKE strobe... (?)
The same is true for WRITE:
So, now...
The only thing is, we're not so lucky with some other commands (Load Mode Register, Row-Activate, Precharge-Row, Auto-Refresh... not sure *which* off-hand, except for the last, which I'm almost certain of, and likely the first.
But, then... What's that mean...?
Maybe nothing... Or maybe it will help in "Case 2" mentioned earlier,
Especially: Starting "Free-Running" requires sending an initial "Read-Burst" command...
Free-Running will definitely be running at a different clock-rate than the host-communication...
So, plausibly... especially if we're now multiplexing the SDRAM's clock-input between two speeds... We could still *start* free-running at the SDRAM's clock-speed without a one-shot on the /CS line.
Plausibly2.0: the /CS one-shot (likely-necessary for host-communication, but plausibly replaceable with e.g. a host SPI) only needs to be as fast as the host-communication-clock, even when entering/exitting(?) free-running...
OTOH2.0: With CKE and clock-speed-switching, free-running could be entered at the host-bus-speed, then paused, then resumed at the full-speed.
So, maybe this observation isn't helpful... but I'mma throw it in the bag o tricks and redraw those timing-diagrams accordingly.
........
(Ah Hah! the CKE transition from high to low, at step 4, could occur earlier than the /CS transition? Hmmmm.... And then....?)
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Honestly, I don't see an issue with making sdramThingZero dependant on features of the Pi Zero. E.g. SPI or PWM. The Pi Zero then becomes the general purpose, independant, IO device that talks to the host. And it can talk via ethernet, wifi, serial, USB, watever... the "host" could be a web browser on the local network hitting a web page served from the Pi Zero.
The advantage is reduced hardware requirements, which is /always/ a good thing. e.g. do it in software if you possibly can.
Are you sure? yes | no
Interesting point... For some reason I saw e.g. the Pi Zero as being *the* system it would run on... e.g. having an LCD attached... keyboard, mouse... But there's no reason it *has* to be that way.
I do, however, want to keep this particular part of this system "host"-independent. Even without a uC/SBC, it could be attached to an Arduino, Pi, ESP, or (maybe) even a parallel port... And highish-speed direct to a computer via something like an FT2232H.
Heck, some claim the PiZero is a unicorn, or maybe more like the sword in the stone...
If, later, something like a Pi becomes the de-facto host for it, then maybe I can step back and reduce some circuitry making use of things like SPI-hacks.
Interesting idea turning it into more like an embedded-system--rather than a peripheral--which might then transmit the information in different ways to another system, or even do some processing and present it in another form.
Are you sure? yes | no
... The idea of sdramThingZero is to make it completely independent of specific requirements from the host... using just GPIOs. So, even though e.g. an RPi has an SPI peripheral (or, heck, even PWM) which *could* be used for strobing the /CS (and/or CKE) pins, that wouldn't be doable with merely GPIOs.
And... Since GPIOs on many hosts aren't capable of being timed *precisely*, we're back to using one-shots. OK.
Coulda been done on sdramThing4.5, but wasn't.
So, one-shots. OK.
Spent a day or so trying to see about extended-Chip-Selects... And that's all well-and-good, but we still need single-shot /CS during certain instructions, especially those used to *initialize* the SDRAM... So, yeah. extended-/CS experiments were rather unnecessary. However, in those experiments, I realized I made some mistakes in my timing-diagrams. So, now, I think I'm certain-enough about how to write to the *real* column-zero... which is important.
Are you sure? yes | no