Close

Zero Acquired!

A project log for sdramThingZero - 133MS/s 32-bit Logic Analyzer

Add an old SDRAM DIMM to your SBC for a 133MS/s 32-bit Logic Analyzer, add ADCs for a Scope...

Eric HertzEric Hertz 10/09/2016 at 08:136 Comments

Overly-wordy, too long, and much too blurry "proof" of this mythical electronic creature... If you believe the Sasquatch, UFO, or Unicorn-sighting videos, you'll believe this one!

A slow flakey-net upload causing me to ponder why I'm not *doing* the bare-metal Pi examples as we speak...

For sdramThingZero, I can't really think of a particular benefit to bare-metalling... My original interest was in light of the thought that the GPIO-access would be faster (and more deterministic) without an OS running... But, now that I (think I) understand the system better, I have a feeling that'd be a minor issue. Thanks again to all the folk who helped me come to that conclusion over at #Operation I HATE Digitizers hahahaha that's not the right link, but I gotta check that page. The link is #Operation: Try to Bare-Metal the Pi, for some really smart folks' comments/explanations/links.

And, ultimately, I think it'd be somewhat ridonculous to connect a logic-analyzer to a single-board-computer without the intention of attaching a display and running something like sigrok... turning the whole combo into a stand-alone piece of test-equipment I can turn on any time in the next twenty years and expect to work...

But, my brain seems to be on the level of not downloading linux, installing it to an sdcard, etc... So maybe I'll start this way:

https://github.com/dwelch67/raspberrypi/issues/24

Discussions

Steven Gann wrote 10/09/2016 at 15:24 point

I've only had to worry about GPIO timing/latency for one application, so I slapped together a Python script and made the function as terse as possible. I got within 7ms on a Pi 1, which was enough for my application. I'm sure with C or even Assembly, you could get much more precise.

  Are you sure? yes | no

Eric Hertz wrote 10/10/2016 at 08:52 point

Indeed, for most purposes the timing of the GPIOs is *plenty fast* and plenty precise.

This particular project has been a bit of a rollercoaster in terms of timing-precision. And there's plenty more info 'round this project-page regarding that, but a brief explanation:

At the start of this project, it was necessary to know the *exact* number of clock-cycles between the rising-edge and falling-edge of a GPIO's pulse. That was found to be exceedingly difficult in basically any micro[processor/controller] more sophisticated than most 8-bitters, due to cache, branch-prediction, memory-mapping, the fact that the core-speed is faster than peripheral speeds, etc.

I managed to find a workaround for this project where knowing the *exact* number of clock-cycles is no longer necessary... which is why bare-metal is no longer an important consideration for this project... but even with bare-metal, it might be the case that it wouldn't've worked without this workaround.

I've read that Pis' GPIOs can be toggled at up to around 50MHz, with some work, even with Linux (rather'n bare-metal)... There's lots of information of people's having run experiments, their implementations and the limitations on the ol' internets.

...

what, no project-page for your Pi project(s)? You know there's a contest for Pi-Projects going on, right?

  Are you sure? yes | no

Steven Gann wrote 10/10/2016 at 15:14 point

The project I mentioned before is closed-source, since it is something I'm developing at my day job. Other than that, my Pi project have always been scrapped shortly after either working or being shelved, so I can reuse the Pi and other parts. Today's post about Tensflow on Pi inspired me to resurrect my little robot, though, right after I finish rebuilding my LPKF PCB mill (project page next weekend if things go well).

  Are you sure? yes | no

Steven Gann wrote 10/10/2016 at 15:17 point

Just a thought, and I've never strayed far into high-frequency logic, but I'm wondering if you could use some old-fashioned latches, counters, and shift registers between the SDRAM and the Pi/MCU. Offload the pulse counting and timing to discrete chips, or even a CPLD or FPGA. I'm not sure how well these things work at such high frequencies, though.

  Are you sure? yes | no

Eric Hertz wrote 10/10/2016 at 16:16 point

Comment-threads only go so deep, so in answer to your replies...

Latches, etc: Yeahp! You're *right on track*. Actually that's pretty much the design-intent of this project.. 74xxyy-series chips, a little bit of glue, and nearly everything else handled as much as possible by the SDRAM itself (e.g. the SDRAM has "latches" and "output-enables" at its data-I/O pins, they're just a bit wonkily-named and buried a bit behind an internal state-machine)... the internal state-machine handles things like counting through the memory-addresses. There'll definitely have to be some added latches, etc. to interface all those control/data signals with the Pi's limited GPIO's, and the Pi's GPIOs themselves peak-out at around 50MHz, which is slower than the intended maximum SDRAM speed of 133MHz, so glue-logic/latches are used inbetween. This is all well (as in overly-wordily) explained throughout this project-page/logs, but it's buried here and there. Check out the newly-submitted video!

Cool about the Pi projects... I totally understand taking old projects apart to reuse the parts. FYI, if you feel like sharing what you've done with the world: project-pages don't have to be about open-sourced projects, but some competitions require it of their submissions. Looking forward to see your new project-page[s].

  Are you sure? yes | no

Steven Gann wrote 10/11/2016 at 00:51 point

You know, I'm in the process of retrofitting an LPKF Protomat C40 PCB mill with Arduino and GRBL. I could definitely toss in a Pi and enter that contest. I'll make a project page either way.

  Are you sure? yes | no