
BeagleLogic: A BeagleBone Based 14-channel 100Msps Logic Analyzer - jcr
https://github.com/abhishek-kakkar/BeagleLogic/wiki
======
seanp2k2
I've got an eye on the DangerousDSO:
[http://dangerousprototypes.com/docs/Dangerous_DSO](http://dangerousprototypes.com/docs/Dangerous_DSO)

" Dangerous DSO is a new logic analyzer/oscilloscope prototype we've been
using in the lab. It combines a 16 channel logic analyzer with one 50MHz
oscilloscope channel with +/-10volt DC range. The combined tool shows what
your signal does between 0 and 1, which helps pinpoint noise and other
electrical glitches.

Our goal with the D-DSO is to make the simplest possible oscilloscope
reference design. It doesn't have range selection or AC coupling, it's a basic
design that shows the bare minimum needed to capture an analog signal. "

They also have the Logic Pirate for $30 which does SUMP:
[http://dangerousprototypes.com/docs/Logic_Pirate](http://dangerousprototypes.com/docs/Logic_Pirate)

Logic Shrimp for $35:
[http://dangerousprototypes.com/docs/Logic_Shrimp_logic_analy...](http://dangerousprototypes.com/docs/Logic_Shrimp_logic_analyzer)

And of course the Open Bench Logic Sniffer for $50:
[http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer](http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer)

------
ChuckMcM
This is really neat. but it isn't a logic analyzer. I realize that is more
than a bit pedantic but let me explain.

The feature this provides is really a binary oscilloscope. One picks a sample
rate, and perhaps a trigger pattern and then once you get triggered you copy
the state of the binary bits into memory at the pre-determined rate.

What you get is samples of the pins across a period of time, and you have no
idea really what the state was of the pins when you "weren't looking". Which
is to say between samples.

Logic analyzers actually work a bit differently. A logic analyzer is sensitive
to the _transition_ of the bit regardless of when it happens. Time is the
_dependent_ variable, rather than the _independent_ variable.

The reason analyzers work that way is because digital logic is very sensitive
to clock _edges_. That is when the magic happens, falling clocks, rising
clocks, either way stuff happens relative to the clock edge.

One of the more common problems in logic is a propagation delay causing
spurious outputs. Think of it this way, lets say changes in signal A and
signal B are racing toward an exclusive OR gate. The change is said to be
propagating through the logic. And lets say the change has both signal A and
signal B set to the same value, but it opposite their current value. If signal
A arrives at its place at the gate 5 ns before signal B does, then when it
arrives, the gate output will change from '0' to a '1' state, and then when B
catches up 5ns later, it will change back to 0. Logic down stream of the gate
will see a 5ns "pulse", the output will go high, and then low again 5ns later.
This is a "propagation glitch".

If you sample these pins, once every 10ns, you have a good chance of seeing
exactly what you expect, the pins are one state, the output is 0, the pins are
a different state, the output is still zero.

However if you have a free running clock and you capture exactly the time the
pins change and you see that the output actually changes twice before your
sample period is over. You might imagine an implementation of this as some
number of input capture pins each sharing the same 32 bit nanosecond scale
clock running. When ever the pin changes you copy the clock value into memory.
If the pins don't change you don't copy anything, and every 4 seconds you push
a marker (clock overflow for a nanosecond clock). You read back all of that
data, a series of time stamps for the pin changes, and you can line them all
up on the display and verify things like setup and hold times, worst case
propagation delays, signal skew across different length traces. All the things
that help you analyze how the logic is working.

That isn't to say that a "binary" oscilloscope isn't useful, it very much is.
But you have to understand what you can't see in order to know where your
blind spots are. My manager at Intel way back in the day always had an
oscilloscope run at 16x the speed of the fastest clock to minimize this
effect. And Tektronix made a very expensive instrument called the DAS9000 to
try to catch these sorts of glitches in the wild.

So whenever you are sampling the signal, rather than capturing the signal, try
to keep in mind what is happening when the sampler isn't looking. :-)

~~~
kumarabhishek
Hi, developer of BeagleLogic here! Thanks for sharing your insight on logic
analyzers here, it was really helpful (and something to keep in mind for v2 ;)
).

I've tested BeagleLogic with 24 MHz SPI and I think that's the best I can
expect this to capture, so it's something that's mostly intended for hobby
use, plus you can connect it over your network for remote debug - but that's
not something I've looked into much as of now (though you can use netcat). And
BeagleBones are getting popular today so you can use something you have around
as a potentially useful debugging tool, to me that sounds awesome.

The objective I had while building BeagleLogic is to showcase an application
of high-speed DAQ with the PRUs on the BeagleBone Black (and now the Green as
well). The biggest USP is that the PRUs are able to capture data directly into
512 MB of RAM, so there's a lot of samples one can potentially capture. Plus
the samples are exposed to userspace via '/dev/beaglelogic' once it's running
on the BBB so you can write your own code to capture data and process it the
way you want.

I know that there are still a lot of rough edges but what you can expect to
see the BeagleLogic ready-to-run image for the BeagleBones getting released
more frequently. If there's anything you'd like to see in the project, have
suggestions or ideas, please let me know at feedback AT <name of project> DOT
net . Thanks! --Abhishek

PS: If you'd like to read what happens under the hood you might want to see
this blog post - [http://theembeddedkitchen.net/beaglelogic-building-a-
logic-a...](http://theembeddedkitchen.net/beaglelogic-building-a-logic-
analyzer-with-the-prus-part-1/449)

For those who are on hackaday.io, you can follow BeagleLogic at
[https://hackaday.io/project/4395-beaglelogic](https://hackaday.io/project/4395-beaglelogic)

~~~
ChuckMcM
It is a very cool project Kumar, and as you have pointed out an excellent
example of high speed data acquisition. Doing this with the Beaglebone and a
cape is much more cost effective than some of the rather expensive instruments
you might buy to work with LabView or similar packages.

With a small bit of work and a flash 10 bit ADC you could have a very nice 10
- 50Mhz oscilloscope data gatherer as well. I've seen similar units used in
test systems where a test waveform is programmed and the samples are compared
to insure they are within bounds of the test, an indication is raised when
they are not allowing an automated process to take action.

I have a number of Beaglebone boards and look forward to playing around with
your code.

------
tostitos1979
Talk that goes into the details of the Beaglebone's PRU:
[https://www.youtube.com/watch?v=ZNz45v9Uesg](https://www.youtube.com/watch?v=ZNz45v9Uesg)

------
revelation
That's quite smart, using the two 200MHz PRU cores to do the capture. It's
also a sad commentary on the state of CPU designs, where we now have GHz
processors that can't sample the state of an IO pin in 200ns to save their
life.

~~~
msandford
> It's also a sad commentary on the state of CPU designs, where we now have
> GHz processors that can't sample the state of an IO pin in 200ns to save
> their life.

Not really! It's much closer to a general purpose microprocessor than a
microcontroller. How many desktop PCs can sample GPIO pins at all? Much less
at some kind of rate that you find reasonable. You're going to use the
parallel port? Sorry, that's about three layers of abstraction away from the
actual processor.

Complicated things are complicated and the beaglebone is a full, real
computer. I think it's comparable to desktops around the turn of the century.
I don't think a PIII could sample GPIO pins at 100MHz even if it had any,
which it didn't.

~~~
tostitos1979
PRUs give you good latency because of no/shallow pipelines (CPUs have a
pipeline to increase throughput). Also ... no interrupts!

