6 ms·

How We Turned 8 Popular STM32 Boards into Powerful Logic Analyzers

54 points by sysprogs 10y ago

dragontamer 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
- patrickg_zill 10y ago
  If you ran a different OS on the Pi, would you get the consistency? For instance, FreeRTOS has been ported (unsure of quality) https://github.com/jameswalmsley/RaspberryPi-FreeRTOS https://github.com/jameswalmsley/RaspberryPi-FreeRTOS .
  - dragontamer 10y ago
    You'd get more consistency for sure, but nothing that approaches the 75MHz (13 nanoseconds!!) needed to capture data from the GPIO pins. From my understanding of the Raspberry Pi, the GPIO pins simply weren't designed for that level of speed. Which is fine, the Raspberry Pi was designed for other stuff. Its all about tradeoffs.
    - snovv_crash 10y ago
      Maybe not capture, but you can write to the pins at least that quickly. I've seen projects that use the gpio of a raspberry pi to drive an FM transmitter at 100MHz.
      - megous 10y ago
        The project you're thinking about uses internal PLL in the SoC. This has nothing to do with GPIO reading/writing. http://www.icrobotics.co.uk/wiki/index.php/Turning_the_Raspberry_Pi_Into_an_FM_Transmitter http://www.icrobotics.co.uk/wiki/index.php/Turning_the_Raspb...
        snovv_crash 10y ago
        Ah, my bad. I was actually thinking afterwards about how they could be doing the frequency shifts and what kind of sampling speed they would need for accurate, small frequency shift adjustments.
megous 10y ago
Anyway, excellent project. I hope to try it. :) Have you looked into using opensource protocol analyzers, or adding support for sigrok?
- sysprogs 10y ago
  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 10y ago
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.
jhallenworld 10y ago
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/MachXO3LFStarterKit.aspx http://www.latticesemi.com/Products/DevelopmentBoardsAndKits... 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/ProductImages/DesignSoftwareandIntellectualProperty/Diamond/featuresreveal.JPG?la=en&d=20140819T155508 http://media.latticesemi.com/~/media/LatticeSemi/Images/Prod... (it would be a lot better if it had a superspeed USB connection- they should make a version with Cypress FX3)
- dragontamer 10y ago
  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 10y ago
    > 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.
    - 10y ago
revelation 10y ago
You can turn a BeagleBone black into a 100Msps logic analyzer, no USB mess: http://beagleboard.org/project/beaglelogic/ http://beagleboard.org/project/beaglelogic/
ChuckMcM 10y ago
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

54 points by sysprogs 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.
patrickg_zill 10y ago
If you ran a different OS on the Pi, would you get the consistency? For instance, FreeRTOS has been ported (unsure of quality) https://github.com/jameswalmsley/RaspberryPi-FreeRTOS https://github.com/jameswalmsley/RaspberryPi-FreeRTOS .
- dragontamer 10y ago
  You'd get more consistency for sure, but nothing that approaches the 75MHz (13 nanoseconds!!) needed to capture data from the GPIO pins. From my understanding of the Raspberry Pi, the GPIO pins simply weren't designed for that level of speed. Which is fine, the Raspberry Pi was designed for other stuff. Its all about tradeoffs.
  - snovv_crash 10y ago
    Maybe not capture, but you can write to the pins at least that quickly. I've seen projects that use the gpio of a raspberry pi to drive an FM transmitter at 100MHz.
    - megous 10y ago
      The project you're thinking about uses internal PLL in the SoC. This has nothing to do with GPIO reading/writing. http://www.icrobotics.co.uk/wiki/index.php/Turning_the_Raspberry_Pi_Into_an_FM_Transmitter http://www.icrobotics.co.uk/wiki/index.php/Turning_the_Raspb...
      - snovv_crash 10y ago
        Ah, my bad. I was actually thinking afterwards about how they could be doing the frequency shifts and what kind of sampling speed they would need for accurate, small frequency shift adjustments.

megous 10y ago

Anyway, excellent project. I hope to try it. :) Have you looked into using opensource protocol analyzers, or adding support for sigrok?

sysprogs 10y ago
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 10y ago

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.

jhallenworld 10y ago

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/MachXO3LFStarterKit.aspx http://www.latticesemi.com/Products/DevelopmentBoardsAndKits... 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/ProductImages/DesignSoftwareandIntellectualProperty/Diamond/featuresreveal.JPG?la=en&d=20140819T155508 http://media.latticesemi.com/~/media/LatticeSemi/Images/Prod... (it would be a lot better if it had a superspeed USB connection- they should make a version with Cypress FX3)

dragontamer 10y ago
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 10y ago
  > 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.
  - 10y ago

revelation 10y ago

You can turn a BeagleBone black into a 100Msps logic analyzer, no USB mess: http://beagleboard.org/project/beaglelogic/ http://beagleboard.org/project/beaglelogic/

ChuckMcM 10y ago

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