I don't see the point in using baremetal C code or interrupts. What you want to do here is to DMA the state of the GPIO pins into a memory buffer. If you can manage to use DMA, you can probably record 8 or 16 channels at 100 MHz and more.

The problem (at least for me) is writing the driver for the Linux kernel.

If the CPU is like your typical ARM chip, the GPIO inputs are probably in a 16 or 32-bit register mapped to memory. Telling the DMA-controller to copy that to memory will be the most efficient way to capture data.

50MS/s is a good throughput. I thought it would be less samples per second. Another option is a FPGA as frontend. It analyzes the input signals (with time stamp and compression), connect some buffer SDRAM and communicate with SPI and INT with the RPI. This will enhance the sample rate and maybe reduce the system load (of checking the IO's 50.000.000 times per second).

Thanks for your suggestion. The main goal of this project is to have as little extra hardware connected to the RPi as possible. If it seems impossible to do it just using (bare metal) software, then an alternate solution such as FPGA might have to be added.

I had a similar idea, but it's currently a bit above my head... @usedbytes gave some great info on my project-page, which maybe could be helpful to you... #Operation: Try the Pi

Thanks. That discussion was eye-opening. It seems there is more to it than I thought. I come from an AVR background and the ARM in the Pi has much more complicated microarchitecture which makes things complex. But even if the programming issues are resolved, I think the bottleneck for speed will still be the GPIO hardware inside the chip.

Similar story, here. But I'm sure it can be done! :) Those benchmarks you showed were a bit enlightening, as well... 22MHz is possible, that's pretty fast. No mention of whether that was bare-metal or not. I'm curious to try toggling a pin on a similarly-spec'd non-arm architecture and see what happens...

BTW, here are some more RPi bare-metal programming resources:

https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/

http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/

A fellow hacker @Kumar, Abhishek has designed a logic analyzer using the Beaglebone which goes upto 100MHz sample rate. The project is called #BeagleLogic and was featured on the blog. When I asked him about implementation of a similar thing on the raspberry pi, he said it was possible on the beaglebone because the GPIO is not directly handled by the main processor, rather a co-processor which runs independently and communicates with the main processor.

@esot.eric

Ah hah! It sounds like the BeagleBone is quite well-suited (if not *designed*) for high-rate I/O, plausibly even a connection of external bus like PCI... Whereas the RPi seems to be more of a "black-box" single-board *computer* with, essentially, the equivalent of a PC's parallel-port as the only means of *direct* bit-level communication. Another way, maybe, to look at it is as though the RPi is a bit like a low-pin-count microcontroller, like the AVR, at the bit-interface-level, but with a *really fast* core hidden in the background, fast enough, maybe for (Linux!) OS-overhead. while still accessing the bit-level interface at the rates of a uC... (as I see it, having *zero* Pi, not PiZero, experience ;)

@esot.eric Yeah. BeagleBone has what is called a PRU (programmable real-time unit) whose task is to handle high-speed GPIO (http://hackaday.com/2014/06/22/an-introduction-to-the-beaglebone-pru/).

About the RPi lacking such a thing, it kinda makes sense because the RPi was mainly designed to teach programming to kids. To achieve that, a high-speed GPIO is not needed but a high-speed processor core is (for OS overhead as you said).

BTW, this thought occurred to me of using interrupts on the RPi processor to trigger the acquisition of data. I have not done any research on this and am not sure how the cache, branch predictor etc.. will affect it but it might work. The idea is to run a counter and trigger an interrupt when the count reaches a value. This is commonly done in AVR as you might know. Need to read up on the processor architecture to see if it might work.

Curious to see what you find out about your interrupt-idea!

#BeagleLogic has an awesome explanation of the PRU system, thanks for that link!

@K.C. Lee mentioned on another project that it might be possible to use the RPi's SDIO interface as a, plausibly, 50MS/s 4-bit logic-analyzer...