Turn your Raspberry Pi (or nearly any Single-board or even regular computer) into a 133MS/s 32-bit Logic Analyzer, or a 3-channel 10-bit 'scope, etc.!
This project and its "father" were blogged at Hackaday!
(Thanks Al Williams!)
(Thanks Brian Benchoff!)
And, was chosen as a finalist for The Prize!
(Thank you, judges!)
Here's how I see it:
Add this ten-gallon "hat" to your PiZero, load a piece of software, possibly supply your own old SDRAM DIMM, wire it up to your 3.3V logic-to-be-analyzed, and you're ret-to-go.
(WHAT?! You're sticking an SDRAM DIMM on a single-board computer with already more/faster memory than that?! Why???)
So, here's the deal...
(I'll use the Raspberry Pi as an example of the sorts of device this is intended to work with)
The Raspberry Pi is, essentially, a single-board computer. Its end-goal isn't interfacing to hardware at the bit-level, as much as it is to be a tiny full-fledged workstation...
This is different than, say, the BeagleBone, which (as I understand) is designed for high-speed interfacing with the outside world (For a great example of what it's capable, see @Kumar, Abhishek's #BeagleLogic. If you're looking to build an embedded-logic-analyzer, that's probably a better way to go!)
So, it's taken a few great minds*, here at Hackaday.io, to bring me to the conclusion that sampling data straight from most (but not all) Single-board-computers' GPIOs into their internal RAM causes a bit of a bottleneck.
* (Thanks especially to @usedbytes and @Vikas V over at #Operation: Try to Bare-Metal the Pi and #Logic analyzer using raspberry pi)
Enter External Memory...
By adding a bit of memory between the "real world" (logic analyzer inputs, ADCs, etc.), it's possible to sample data *really quickly,* then read that data into the RPi at whatever rate possible. Then, after it's read-in, it can be displayed, manipulated, zoomed, etc.
This isn't unlike most logic-analyzer peripherals.
SDRAM is, as far as I'm concerned, the last of the "easy-ish" memories to interface-with... It runs at 3.3V, doesn't require complex timing schemes (and huge sensitivity to skew) to handle data on each edge, etc... (At another level, it allows bursts longer than 8 data-locations, allows for somewhat-arbitrary clock-halting, and more).
Besides all that, it's pretty easy to find SDRAM DIMMs unused in piles... Why limit yourself to a single 16-bit-wide 16MB chip, when you can easily have 32 parallel bits and 64MB already wired-up for 133MHz speeds?
sdramThing is a (series of) project(s) I've been working on for several years. The latest version, prior to this, acts as a 30MS/s 32-bit "Logic Analyzer", of sorts, when connected to an AVR and an Oscilloscope.
The basic idea of all versions of sdramThing is to connect the SDRAM's "command"/address pins directly back to its data pins... Thus, by filling data-locations with specific instructions to be fed-back to the SDRAM, the SDRAM itself can "Free-Run" at the highest-speed its capable (133MHz, soon?), independent of a controller. It's definitely a loop, and definitely a "loopy" explanation. :)Check out: #sdramThing4.5 "Logic Analyzer" and the home-page (
a bit outdated) at: https://sites.google.com/site/geekattempts/home-1/sdramthing for detailed explanations of how this "Free-Running" is possible.
Note that "Free-Running" uses one of the two "banks" of memory on a DIMM to store/repeat the commands. This bank, and thus half the available memory, can't be used for sampling data (however, it can be used for *outputting* data, arbitrary-waveforms, etc.). It may seem a bit wasteful, in a logic-analyzer-sense, but consider the alternative is a dedicated controller with 20+ GPIOs capable of precision timing at these speeds (which we've already determined the Gigahertz+...Read more »
has anyone tried to scale this?
1. in terms of memory size, for example 4 x 1024 MB total memory, giving 2 GB payload size. or even more crazy: use the SDRAM as "state machine memory" to generate address signals, and write the payload data to an SSD hard drive, connected via SATA3 (500 MB/s) or M.2-NVMe (2 GB/s) - no filesystem, just write the raw data to consecutive addresses. use two or more SDRAM modules to decouple write/read operations (like video memory)
2. in terms of frequency, what [esot.eric] calls >>"DDR" emulation: Simply connect two opposite-edge-triggered D-latches to each input-signal, fed into two separate SDRAM pins, and now we're talking 16ch 266MS/s :)<<. how would i distribute/rotate the input signals to get 4 x 133 MHz = 533 MHz? (or even more)
also, could this work with an external clock? so we have synchronous sampling, and can avoid oversampling