[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

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.

[patrickg_zill]

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 .

[dragontamer]

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]

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]

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_Raspb...

[snovv_crash]

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.