If you have a BeagleBone, you already have a lot of tools. We’ve seen them used in driving hundreds of LEDs at a very high frame rate, used as a video card for ancient computers, and as a software defined radio. For his entry to The Hackaday Prize, [Kumar] turned his BeagleBone into a 14-channel, 100Msps logic analyzer that’s good enough to debug just about all those hobby electronics projects you’re working on.
The BeagleBone is only able to have this sort of performance as a logic analyzer because of its PRUs, those fancy peripherals that make the Beagle great at blinking pins really, really fast. [Kumar] is using both PRUs in the BeagleBone for this project. PRU1 reads from the input probes, and PRU0 writes all the samples into DDR memory directly. From there, the samples are off to kernel modules and apps, either sigrok, dd, or something you coded up in Python.
Compared to the cheap logic analyzers we have today like the Salae Logic and the DSLogic, [Kumar]’s project is just as good as any commercial offering (provided you can live with 14 channels instead of 16), and because it’s based on a BeagleBone, the software is infinitely expandable.
UPDATE: After this post was written but before it was published, [Kumar] finished up a blog post on how he’s building a logic analyzer with the BeagleBone’s PRUs. It’s a true tutorial, with enough code demos to allow anyone to build their own 8-bit analyzer on a BeagleBone, and there are more updates coming.
A better way:
http://www.frank-buss.de/parallella/sampler/index.html
PRUs are pretty anemic compared to a full FPGA fabric coupled with faster cores.
Could you elaborate a bit on why a FPGA fabric coupled with fast cores are better suited for such a task than e.g. PRUs coupled to a single fast core?
For comparision :
Frank’s Logic Analyzer does 100Msps , Kumar’s too
64 Channels on Franks , 14 on Kumars
32k Samples Memory on Franks, Kumars around 170M Samples
So which way is now ‘better’ ? It really depends on the use case , I would prefer Kumars solution right now because of the memory depth (albeit Franks LA is great too , btw. Hi Frank ;) )
The FPGA fabric in a Zynq have direct AXI bus access to DDR ram so memory depth and speed in basically only limited on how much memory you can allocate and how fast the DDR controller is
The ‘better’ really comes down to scaling.
The PRUs are better than using a simple processor to directly sample a pin (which would be frequency and pin limited). FPGAs are better than using PRUs (more pins, higher frequency, more customisation for what happens behind the pin). But the flip-side is development time increases; compared to using a core directly (think arduino), you have to program the PRUs and going up to FPGAs means you have to write HDL that goes in that.
So better is really if you need, in the words of the internet: “moar” (higher speeds, more control such as complex triggers and filters before capture…). Short of going to a fully customised ASIC, commercial logic analyzers use FPGAs as their front-ends.
I’m surprised Frank’s solution with the Parallella doesn’t have a greater sample depth as 32k samples and, without looking in greater detail at his code, it sounds like it’s using the block-RAM that is part of the FPGA fabric rather than the main system RAM. For a pure FPGA solution, look up the “Open Bench Logic Sniffer” which uses a lowly Spartan3E FPGA and has up to 16k samples, up to 200Msps and up to 32 channels (note the use of “up to” – some features reduce others).
While the PRUs can be good at sampling, implementing triggering in this case may be best left to the 1 GHz ARM core i.e. software triggers. The big buffer size can still give ~3.4 seconds (8bit, 100Msps) of data to sift through. The sigrok support for BeagleLogic implements them.
In the PRU datasheet, there’s a mode which the PRU supports (synchronous capture) in which it can capture data synchronized to either the falling or rising edge of an external clock – the pins are still sampled at 200 MHz. This is yet to be tested.
FPGA or ASIC based usually also come with more fancy trigger capabilities than a single signal level matching. They have a more complex state machine that let you chain multiple events/conditions for triggering. Most of the time, the user would just grab maximum buffer size and manually sort it.
FPGA also comes with additional bonus of flexible configurable I/O. If designed correctly, you can probe a 1.2/1.5/1.8/2.5V logic level or HSTL or LVDS by recompiling the FPGA HDL code.
While this is a nice device, it’s pretty far from the whole “Improve the World” topic of the contest I think.
Then it’s cool we’re not just doing an ‘improve the world’ theme. There’s also a best product category! $100k, tons of contacts, 6 months of living in Pasadena at our Hackerspace.
Seems to me that making useful tools more accessible generally improves the world. This does that by making an multi-channel logic analyzer using a relatively affordable general-purpose module. Because the BBB is general purpose, the cost is lowered further because it doesn’t have to be dedicated to a single purpose. Moreover, it makes things more accessible in another way, because it is open source, others can learn from the code and improve it.
In so doing, it enables more people to improve the world in their own way.
Usually I found most of the “logic analyzers” lacking on the input side and mostly are just connected to the chips directly. Here is a list I think are important (descending order).
Does the inputs has some form of protection? At least some Bus Switch logic and/or series resistors with diode clamps/TVS are required.
This is a bare minimum requirement. Last thing you want is that your probes came off in a slight mishap and touched a trace you shouldn’t have and blow up the analyzer. Things do happen in the lab.
Are the inputs fully buffered and have proper terminations?
Does it have programmable input threshold?
What is the loading on signal you are probing? capacitive load=?? pF
When you are trying to play with the big boys and claims you are sampling at 100MHz plus, you have better start to do all the right thing about signal integrity. Last thing you want is signal reflections, crosstalk, undershoot/overshoot (e.g. your unbuffered 12″ of loose wire dangling off the DUT), excessiving capacitive loading is/are the cause of glitches or unrelated flakiness or causes artifacts in the measurement.