10/27/23: This has been sitting as an unfinished draft since 3/9/16... 7 years. heh.

Herein, it seems is the beginnings of #sdramThingZero - 133MS/s 32-bit Logic Analyzer 

...........

Thanks to @Vikas V, @usedbytes, @James Newton, @frankstripod, and a few others I'm sorry I'm forgetting by-name, for bringing to light that this project may not be as... obscure...? niche...? or something... as I had thought!

In this era of *really fast* single-board computers, and 100+MHz microcontrollers like the ARM and PIC32 (which I'm becoming familiar with)... nevermind BeagleBones, Raspberry Pis, etc. with built-in memories larger than most SDRAM DIMMs... It was easy to think "sdramThing is really just a hack to make a lowly 8-bit uC do way more than might be expected"...

That's true, actually... I kinda went into it with that goal in mind... Really, the main goal was to see whether the SDRAM could control itself, and what could be done by doing-so... in which case the lowly-AVR is merely an initializer, or a boot-strapping device...?

I kinda figured maybe others might see value I hadn't predicted in this "Free-Running Mode" and take it on in their own projects, now that things like Arduino are accessible to the creative-masses beyond just engineers. But, I did kinda figure it would be a bit niche... It has its limitations, for sure... It's not quite the same as merely plugging a huge amount of RAM onto a 'lowly-AVR,' usable for any purpose one might need a huge amount of RAM for...

Instead, "Free-Running" SDRAM is really best-suited for huge(/fast) *bursts* of raw data I/O... and my creativity-level hasn't really thought of much beyond either a video-framebuffer (and a stationary-image, at that), a logic-analyzer, or an oscilloscope (being like a logic-analyzer with an ADC attached to its inputs).

I had some other non-raw-burst ideas that are a bit "out there," including things like creating complicated jump-tables that could plausibly turn Free-Running SDRAM into something a bit like a processor. E.G. certain "pages" in the memory could be certain functions, a "NOP" being the easiest, where the only thing stored in that page is a "jump" back to its beginning. A separate source (e.g. a microcontroller, or a bit of logic combined with a multiplexer) could reroute that "jump" command to another location entirely... Anyways, it's totally vague and a bit "out there".

Or, similarly, several separate data-bursts could be stored in different locations for different purposes. A simple example, from my experience with sdramThing, is the use of the framebuffer connected to an LVDS-LCD display. One possibility is to store the entire image-frame ALONG WITH the necessary horizontal/vertical porches and sync signals. In other words, every row of image-data *also* stores the horizontal porches. Then the entirety of the RAM is dumped sequentially. Another way of doing this would be to have one "page" (or group of pages) in memory devoted to the horizontal porches. Each row of image-data, then, would eventually jump back to this single "horizontal-porch" memory location, and an external multiplexer would reroute the "jump" at the end of the horizontal-porch to the next row of image-data. Thus, then, the source of that jump-reroute (e.g. a microcontroller) only needs to increment its address-routing bits once per row, and the entirety of the row-drawing itself is handled by the Free-Running SDRAM, alone.

So, that thought-process could surely be extended to other things, but I've yet to think of *what* exactly... And... I digress.

SO... new fast single-board-computers with huge amounts of RAM kinda makes sdramThing seem a bit ridiculous, even as a logic-analyzer or 'scope... BUT it appears there may still be a use...

Apparently, from what I've read/understand, the Raspberry Pi is a great example... This guy has a ton of RAM, but that RAM is not really accessible to the outside world at a low-level, nor even through its few GPIOs and DMA. So, we have a *really fast* computer, capable of doing things like HDMI video output (and not just stationary-images!), tons of RAM available for computing, nevermind tons of instruction-cycles available as well... but, the only access to high-speed data I/O (e.g. for logic-analyzing) is pretty high-level (e.g. USB, Ethernet, etc.). So, we have the GPIOs, which, it seems to me, are about the equivalent of a PC's Parallel Port... They can be accessed at the bit-level, but it's not particularly fast.

So, then, maybe something like sdramThing is still a decent idea, despite this device already having more memory than an SDRAM DIMM... We've basically got a low-speed communication to the processor, just like the case with an AVR, but can (ideally) use Free-Running SDRAM at its full-speed to (e.g.) sample a huge amount of parallel data at 133MHz... Then, maybe, load that data into the RPi at whatever rate is achievable... and have full-access to the processing-power (and video capabilities) of the RPi to process/display that data.

At some point, I suppose, sdramThing becomes something like a logic-analyzer peripheral which could be connected to whatever computing-device via whatever interface...

At some point we've got to step-back and think about the goals... What are the goals...? ... As a logic-analyzer peripheral, there're better ways to achieve this... USB2.0's pretty durn fast (though I know ziltch about how to program it), an FPGA connected to DDR3, and a bit of knowledge/time... and you're done. Connect it to any computer, RPi or desktop. Bam! I'd go so far as to say it's been done much better than I'd be able to by people much better at it than I.

...

The goals mentioned earlier... pushing the limits of what an AVR's capable,