Eric HertzThoughts have been bouncing around regarding sdramThing over the past few months... If you hadn't noticed, it's been on hold for quite some time... its original motive-for-revisit which advanced it from 2.0 to 4.5 was actually due to my plans to build a CNC machine (maybe a PCB-router)... I didn't have any motor-driver chips, at the time, so was planning to use sdramThing as a logic-analyzer to figure out what signals to send to a motor-driver I found in an old printer. Whew. I wasn't able to get it fast enough to read those signals (whoa, 18+bit SPI at > 30MHz?!), probably due to the ratsnest of wires... But I did eventually get some motor-driver chips, and went on with my original goal of working toward the CNC machine... So, sdramThing reached a pretty decent stopping-point. Definitely functional, definitely usable, proof-of-concept regarding one-shots and separating the uC clock from the SDRAM's clock definitely proven...
But, it's been bouncing-'round the ol' noggin' again recently... thanks in part to interest from folks like @James Newton and @frankstripod. I had it in my mind that maybe, even, it could be run from a PiZero (inspired by the Adafruit PiZero contest at: https://hackaday.io/contest/9326-adafruit-pi-zero-contest, and some insight in the comments there from @nistvan.86). Running on a more-powerful processor like that would open up new doors as far as actually *processing* the data, nevermind displaying it... Got some excellent information on just how different the GPIOs on a PiZero are than those on an AVR, from @usedbytes and @Vikas V, and some others.
As it stands, sdramThing4.5 requires *precision* timing on the part of the microcontroller. For the AVR this is (comparatively) easy. Using assembly, it's possible to determine *exactly* how many CPU-cycles occur between, say, the rising-edge and falling-edge on a pin. Apparently that's not exactly possible (or at least not as easy) with more "sophisticated" processors that use things like cache, branch-prediction, MMUs, Flash-based execution vs. executing from RAM, etc. (check out some very informative commentary/explanations by @usedbytes at #Operation: Try the Pi).
SO.
There seems to be a multitude of strikes against porting sdramThing to other architectures... Oh, the other was... what about using this as an oscilloscope-shield for arduinos...? I'm not too familiar with Arduino and its libraries, so I can't vouch for what I'm about to say, but it seems like precision-timing to the extent of using Assembly, shutting off the system's timer-interrupts during the five minutes it takes to "boot" the SDRAM, and whatnot, maybe not so Arduino-friendly.
So, now, I guess there's a theme... it took me a while to piece-together. But basically: can this be accomplished on other systems, especially those where timing is imprecise...?
One thought was to go back to (or start a new branch from) sdramThing1.0, wherein this level of precision-timing is unnecessary. sdramThing1.0, though, uses *quite a few* pins... Surely more than available GPIOs on a RPi. So, then, latches and buffers... and now we're at the point where it'll take multiple cycles just to load a single data-byte to the SDRAM.
So, was about to count-out all the necessary pins, see if there's a way to reduce the pin-count, or at least see whether *either* system could possibly fit in so few GPIOs (FYI, sdramThing4.5 requires at least 23 GPIOs, does the Pi even provide that many?!)...
But then it occurred to me... CKE, the Clock-Enable input. I never used this pin for anything before... For the most-part it seems like it's intended for putting the SDRAM in "sleep" mode, but it appears that it *can* actually be used to essentially halt the SDRAM for individual clock-cycles. Huh!
So, this whole time, instead of using *multiple* one-shot circuits, I might've been able to use *just one* attached to CKE! Further, doing-so might mean that precision timing is completely unnecessary. Just set-up the command with CKE disabled, then set up your data, then enable CKE (via the one-shot) for one cycle whenever that data is ready.
Well, shit...
Still not sure about that GPIO count, but reducing the number of one-shots is quite helpful, and relieving the timing-requirements means it should be able to run on any system, even programmed in C rather'n assembly, maybe even Python.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
HAH! So, all's not lost... apparently CKE on DDR works as I misperceived it to for SDRAM...
"Unlike SDR SDRAMs, DDR SDRAMs require CKE to be active at all times an access is in progress, from the issuing of a READ or WRITE command, until completion of the access. Thus a clock suspend is not supported."
...So... should I ever move on to ddrThing, many of the techniques used so far (up to sdramThing4.5) are actually necessary with DDR.
I did, actually, do quite a bit of sdramThing's design with ddrThing in the noggin'... but I don't think the choice to not use CKE was one of them. And, if you look at my thoughts on ddrThing, you'll see it's quite a ways off. One of the bigger limitations being DDR is limited to burst-lengths of 8 "columns" (whereas SDRAM can do 1024), which means quite a bit more overhead to merely get it "Free-Running" at all, let alone additional space for things like the differing commands for sample/repeat modes, etc. Further, as it stands, reads/writes occur 20+ columns *after* the requested-location, due to the amount of time it takes to switch the uC's pins from writing the *command* to outputting data that is to be loaded. Getting around that would require loading all that stuff ahead of time... at the very least we're talking latches latches latches.
Also, the DDR specs explicitly state a limit of >=85MHz... so one-shot circuitry is an absolute necessity in that case... something that works, now, but nowhere near 85MHz, yet. Then, there's the factor of data's being output on both edges (whereas instructions are only accepted on one edge), which might mean that the fed-back instructions, stored *in* the memory, might have to be stored in *two* adjacent memory locations (so as not to be sampled incorrectly).
...So... ddrThing is definitely a ways off, but it's kinda reassuring that the techniques I mistakenly overengineered for sdramThing could be useful later down the line...
Are you sure? yes | no