
How We Turned 8 Popular STM32 Boards into Powerful Logic Analyzers - sysprogs
https://sysprogs.com/w/how-we-turned-8-popular-stm32-boards-into-powerful-logic-analyzers/
======
ChuckMcM
This is awesome, thanks for sharing it.

It pains me though that you haven't experienced a 'real' logic analyzer (and
that is in quotes because they are all real but originally they were
different).

So originally, the way the logic analyzer worked was that you had a 'clock'
module and 'data' lines. The clock module fed a clock signal into analyzer and
you told it so sample the data lines on the rising, falling, or both clock
edges. It was done this way because all digital logic works on the clock
edges. You could also 'oversample' where you ran the system clock through a
clock doubler or quadrupler or octupler and used that as your clock source.
That would let you look at a signal multiple times. Most of the doubler
circuit patents[1] have expired so using them/building them is fine.

Given that setup you could analyze your logic using the clock the logic was
using and everything just worked. To translate back into 'real' time you
either had to measure the logic's clock or annotate the samples with a free
running clock built into the analyzer.

What you have built, and a lot of people have experienced on things like the
Rigol scope and elsewhere, is more like a 'digital oscilloscope' where you
digitally sample the inputs at a given frequency. This is fine for doing
serial bus decoding (especially if you can sample at 16x the bus frequency)
but it doesn't help on logic analysis if your tracking down timing issues.
Because the signal may have changed state at any time between the sampling
interval you can't check setup or hold times accurately.

[1]
[https://www.google.com/patents/US5111066](https://www.google.com/patents/US5111066)
as an example

------
dragontamer
There's been various discussions around here, and often the Raspberry Pi comes
up. The Raspberry Pi is a great board and everything, but this "Logic
Analyzer" use case is a great example of where a Microcontroller should be
used rather than a general-purpose computer.

The STM32F746G looks like a far "weaker" processor. 216MHz, only 320KB of
RAM... the "Computer" specs look utterly awful compared to the Raspberry Pi
Zero. Indeed, the Rasp. Pi Zero costs only $10 while the NUCLEO-F746ZG costs
$25.

However, what is important in this application is not necessarily raw speed...
but speed coupled with CONSISTENCY, as per diagram "B". The particular feat is
this:

> It can reliably read GPIO inputs every 3th or 4th clock cycle on many
> devices

You will never get this level of consistency from a Raspberry Pi. Indeed, it
looks like it was only achieved through careful programming + use of the DMA
channels + careful work thinking about who is using RAM and who isn't (to not
over-burden the on-board memory controller).

That's the world of microcontrollers in a nutshell. Its about the focus on
delivering consistent performance rather than high-performance.

~~~
megous
Perhaps not on Linux. You don't need to run Linux on SBCs. At least not
exclusively.

Some SBCs also contain additional non-ARM processors on the SoC, which could
be used for the purpose of data acquisition.

For example Orange Pi has H3, which contains OpenRISC core that can run at
300MHz or so from code located in internal SRAM. I haven't tried yet, but I
guess you can get pretty consistent results with this approach too: Main cores
running on Linux processing the data, OpenRISC accessing GPIO and reading the
data in a tight loop, throwing them to main memory into some ring buffer, or
into part of the SRAM.

~~~
dragontamer
Well, I was talking about the Raspberry Pi Zero specifically, which doesn't
have those RISC cores.

One particularly cool Single-board Computer (SBC) is the Beaglebone Blue. The
Beaglebone Blue came with "PRUs" (Programmable Realtime Units), which seem
similar to the OpenRISC core you are talking about. Such "embedded
microcontrollers" exist because the main computer. There are also a hell of a
lot more GPIO pins, ADCs, Servo-channels, Motor-controls, and other such stuff
to assist the robotic designers.

No need for "Realtime" Linux either, if you're focusing on the PRU /
alternative cores to do the heavy-lifting. So I didn't want to discriminate
against SBCs as much as I wanted to highlight the importance of low-latency
and consistent reads off of pins. Two things that the Raspberry Pi is pretty
dismal at doing.

\---------

In any case, previous discussions with the "Orange Pi" clearly don't "get" it.
[https://news.ycombinator.com/item?id=12890005](https://news.ycombinator.com/item?id=12890005)

Its fine, ycombinator is a web-technology, software-focused message board.
YCombinator cares about web-technologies, keeping up with Linux Kernel
patches, and the like. And that's good and important.

However, embedded and microcontroller features are often ignored, despite
embedded topics popping up around here pretty often. So I felt it necessary to
bring up the compare/contrast.

~~~
fnj
With regard to the PRUs, I don't think the BB Blue has anything the BB, BB
Black, and BB Green don't. They all have the PRUs. It's a function of the
AM335x Cortex-A8 SoC.

At this point, you need a time machine to get a BB Blue, anyway.

------
jhallenworld
8 Boards? How about turn one FPGA board into a logic analyzer. For example,
get the $25 MachXo3LF starter kit:

[http://www.latticesemi.com/Products/DevelopmentBoardsAndKits...](http://www.latticesemi.com/Products/DevelopmentBoardsAndKits/MachXO3LFStarterKit.aspx)

And that's pretty much it- Lattice includes "Reveal" a logic analyzer which
can run on the FPGA in their tools. It's intended to debug designs, but there
is nothing stopping you from capturing data from pins. Pretty sure it would
capture signals up to ~200 MHz.

[http://media.latticesemi.com/~/media/LatticeSemi/Images/Prod...](http://media.latticesemi.com/~/media/LatticeSemi/Images/ProductImages/DesignSoftwareandIntellectualProperty/Diamond/featuresreveal.JPG?la=en&d=20140819T155508)

(it would be a lot better if it had a superspeed USB connection- they should
make a version with Cypress FX3)

~~~
dragontamer
And how much RAM does that FPGA hold?

When your entire chip is programmable-logic, you don't have much room for RAM.
The MachXo3LF-6900 has a grand total of 240 kBITs, or 30kBytes of storage.

In contrast, the STM32F746G will get you 320kBYTES of storage, 10x the
capacity.

At 75MHz and 1-bit per cycle, that's still only 35ms of storage. Furthermore,
it'd be a lot easier to program a Microcontroller to compress the data as its
reading it, rather than use the FPGA.

The Microcontroller will still get you the Ethernet and USB connections too.

\--------

I think this is a job for a microcontroller, not an FPGA. FPGAs are nice and
flexible of course, but Microcontrollers offer you far more performance if
you're going to use the specific features.

The STM32F746G has GPIO -> DMA directly to its RAM, while the CPU can compress
1/2 of the signal and send it out while the GPIO pins are simultaneously
working. That's... pretty good. I have doubts that a cheap FPGA can accomplish
all that at the same speed.

~~~
vvanders
> I have doubts that a cheap FPGA can accomplish all that at the same speed.

A cheap FPGA can probably do that at 5x the speed. Parallel operations like
these are specifically what they're build for.

~~~
dragontamer
Speed isn't the only consideration here. 5x the speed needs 5x the RAM to
store it in. But FPGAs will NEVER have as much RAM as a dedicated
microcontroller.

Again, you're looking at ~320kBytes on the $25 STM32 microcontroller board,
against ~30kBytes on the $25 FPGA board. With 1/10th the RAM, the FPGA will
store far less useful data.

The typical Oscilloscope is like 100MHz. Getting a cheap 75MHz logic analyzer
is perfectly acceptable. Storing and processing all that data (ie: outputting
it to an Ethernet port) start to become the main issues once the speed issue
is solved.

In my experience, those small FPGAs run out of room rather quickly too. Throw
down something as simple as a Wallace tree multiplier and suddenly half your
LUTs are eaten up.

~~~
revelation
What are you even talking about? FPGAs routinely interface with DDR3 and other
"big buckets of memory" should you need them. Try that with your STM32.

~~~
dragontamer
What price point are we talking about here?

Throw down a single DDR3 Memory chip, and you've already eaten up like half
the $25 hardware budget.

[http://www.digikey.com/product-detail/en/micron-
technology-i...](http://www.digikey.com/product-detail/en/micron-technology-
inc/MT41K512M8DA-107-AIT-P/557-1762-ND/6036290)

The "embedded" solution is: buy embedded on-board SRAM when you need it, and
if necessary, buy an embedded on-board SRAM memory controller if you need it.
Building your own memory-controller out of an FPGA sounds like hell to layout.

Anyway, if we're talking about cheap stuff, DDR3L isn't the technology of
note. This is about simpler SDRAM-level stuff, maybe a few MB at a time is
sufficient.

\----

Furthermore: How many LUTs will your memory controller take up?

[http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/I...](http://www.latticesemi.com/en/Products/DesignSoftwareAndIP/IntellectualProperty/IPCore/IPCores01/DDR3SDRAMController.aspx#_D5983CCD053543DA9E0D5AC1F76E34D4)

According to this, Lattice's DDR3L 16-bit memory controller is 2500 LUTs. The
$25 FPGA only has 6300-LUTs, so you've already used up 40% of the chip on just
memory-interfacing!

Yeah, you can accomplish a lot with a $600 FPGA with a Million-bajillion-LUTs
and embedded cores. But at the $25 price point, FPGAs often run out of room.
You don't have many LUTs to work with.

Dollar-for-dollar, a microcontroller will outperform an FPGA in most tasks.
That's just the facts. ASIC-implemented memory-controllers and ASIC-
implemented large banks of internal SRAM just work better for computer-like
tasks.

FPGAs should be used for _custom_ logic that isn't typically handled by a
microcontroller / microprocessor. Not memory-controllers and ALUs that already
exist in an easily packaged form. There's a reason why high-level FPGAs have
embedded ARM cores and embedded memory-controllers in them (alas: such
technology is likely out of the reach of cheap $25 FPGAs)

~~~
zokier
Here is just a random FPGA board with onboard 32MB SDRAM. All with whopping
$17 BOM according to the author:

> Earlier this year, I calculated the part cost of the CAT Board with an HX8K
> at $17

[https://hackaday.io/project/7982-cat-
board](https://hackaday.io/project/7982-cat-board)

~~~
dragontamer
SDRAM is a simpler kind of RAM and is likely what would be used in the project
of the original post.

I seem to have gotten myself sidetracked by the DDR3 comment, but yeah, going
to SDRAM is a practical solution

------
revelation
You can turn a BeagleBone black into a 100Msps logic analyzer, no USB mess:

[http://beagleboard.org/project/beaglelogic/](http://beagleboard.org/project/beaglelogic/)

------
megous
Anyway, excellent project. I hope to try it. :)

Have you looked into using opensource protocol analyzers, or adding support
for sigrok?

~~~
sysprogs
Oh yeah, we looked into the open-source ones. The main problems there were
irregular sampling and software that will make you sweat before you get your
first reliable measurement. So we wanted to create something that will be
extremely easy to use and will reliably work out-of-the-box.

------
anfractuosity
The Cypress FX2 boards from eBay/Aliexpress seem popular for streaming logic
analysers too. I bought a variant which uses the FX2 chip along with an FPGA.

