Thoughts 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).
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.
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.