40Mhz GPIO read speed?

[signal]

I think this maybe a little over ambitious.

I need to capture 8bit @40Mhz data and not sure the RPi can handle that on the GPIO pins.
I would use the 8 GPIO's on P1 and put the clock on a GPIO on P5 for triggering.

Idea would be to either fill a buffer and save for analysis or stream the data through a socket on the ethernet port for saving by another system. From what I can tell, saving the data to the SD card in realtime won't work as it's too slow.

But first thing first, can the GPIO handle that speed?

[signal]

Based on the wiringPi speed test example (which tests 3 methods of accessing GPIO) it looks like you can get up to about 14Mhz reliably. Maybe a smidge faster with overclocking.

This would still be well under my 40Mhz need though.

Gordon at wiringPi pointed out that there are 32 GPIO lines to use though. Using something like a shift register to store x4 8bit samples would require 10Mhz to read. Well within the limits but unsure how to handle a read cycle to the RPi while we still have data coming in.

Digging into it a bit more.

[techpaul]

Personally at that data rate I would create external hardware or dedicated micro to acquire the data and transfer the data to the Pi as buffers.

How it is acquired depends on the characteristics of the datastream, clock synchronisation , and many other factors, like how bursty the datastream is.

[gordon@drogon.net]

Based on the wiringPi speed test example (which tests 3 methods of accessing GPIO) it looks like you can get up to about 14Mhz reliably. Maybe a smidge faster with overclocking.

This would still be well under my 40Mhz need though.

Gordon at wiringPi pointed out that there are 32 GPIO lines to use though. Using something like a shift register to store x4 8bit samples would require 10Mhz to read. Well within the limits but unsure how to handle a read cycle to the RPi while we still have data coming in.

Digging into it a bit more.

Possibly some confusion - there are 2 x 32-bit GPIO registers, however the 8 (to 21) avalable GPIO pins are all inside one of those registers, but not at consecutive bit locations.

So you could read the 32-bit input register in a single cycle, then shift the bits round to get the 8 bits you need - if you can do this fast enough then you might be in with a chance - but I wasn't clear if it was 40,000,000 bits/sec expressed as 5,000,000 samples of 8 bits a second, or a stream of single bits at 40MHz...

If the samples are coming in at 5MHz then you could possibly read the 32-bits into memory for each sample, then post-process it to extract the 8-bit samples, but it depends on how many samples you're after. (You'll run out of RAM quickly!)

-Gordon

[signal]

Ah.. thanks for the clarification.

I'll be able to hook up a decent logic analyzer to the device this weekend and see what's going on.

[Grumpy Mike]

Normally along with the data you will also have a signal of some sorts to tell when the data is valid. This can be called a strobe signal.
When receiving the data the Pi must look at this signal until it see it being valid and then when it is to read in the data. So it is not just a matter of reading the data, you have to read it at the right time.

[rgh]

Even using DMA to read the GPIO as fast as it can, I don't think you'll get much over 20M reads per second. Then what with contention on the memory and I/O bus, pauses while the DMA controller chains on to another control block, etc, you might well go a couple of microseconds occasionally without GPIO being read. Then, every 500ms, the GPU freezes everything for up to 16us while it adjusts the memory refresh rate based on temperature. You can disable that adjustment, read the Panalyzer thread for details. If you want to poll some strobe signal to see when data is valid then you can't use DMA, and the rate you'll get using the CPU will be much lower - with Panalyzer I concluded that I couldn't sample reliably above 1MHz. Panalyzer loops reading a counter that ticks over once a microsecond. Every time it ticks over, the code reads the GPIO pins, and this approach only works because it disables interrupts while it is sampling.

[ci.v.ic]

I was able to read and write a 5V SRAM with 25 MHz max. I used assembler code to maximize the bit banging method, however, 40 MHz seems not to be possible. Details here: http://d-fence.sytes.net/raspberry-pis-gpio-speed/

[joan]

I was able to read and write a 5V SRAM with 25 MHz max. I used assembler code to maximize the bit banging method, however, 40 MHz seems not to be possible. Details here: http://d-fence.sytes.net/raspberry-pis-gpio-speed/

What code did you use to read data? Or was this just a case of toggling gpios as fast as possible?

[ci.v.ic]

I'm sorry it was only bit banging (toggling pins). There is second memory interface but I'm trying to find a documentation about that interface for months. Probably it is only for sd cards but maybe it is really for a second memory chip.

[joan]

I'm sorry it was only bit banging (toggling pins). There is second memory interface but I'm trying to find a documentation about that interface for months. Probably it is only for sd cards but maybe it is really for a second memory chip.

You may have more joy using SPI. If I get a chance I'll connect two Pi's and see how fast I can push data between them. Might also try the same experiment with bit bang gpios.

[mikronauts]

How many consecutive samples must you read before you can have a break, and how long would the break be?

[joan]

How many consecutive samples must you read before you can have a break, and how long would the break be?

I'm not sure that ci.v.ic had a particular task in mind, the tone seems to be more one of experiment.

[mikronauts]

ah I thought he had a particular application, and I was trying to see if there was a large enough off the shelf FIFO he could use as a buffer, or if another microcontroller could help.

[jdb]

At 40MHz your prime concern will not be one of data acquisition rate.

The GPIO pins and trace routing are not designed to carry signals that fast with acceptable integrity. 25MHz is about as good as you'll get on the GPIO header.

If you try to sample an 8-bit bus at 40 meg then don't be surprised when you get data glitches, bit flips and other such nasties. The pins were never meant to go that fast and still transmit/receive valid logic levels.

[mikronauts]

Thanks jdb, that is good to know.

One of these days I'll have to 'deep dive' the BCM docs, however unlike the OP I have not had any need for more than 1MHz from the GPIO header for a serial port.

Mind you, one of these days I intend to find out how fast I can get /dev/ttyAMA0 to go reliably, for maximum comm rate with RoboPi.

At 40MHz your prime concern will not be one of data acquisition rate.

The GPIO pins and trace routing are not designed to carry signals that fast with acceptable integrity. 25MHz is about as good as you'll get on the GPIO header.

If you try to sample an 8-bit bus at 40 meg then don't be surprised when you get data glitches, bit flips and other such nasties. The pins were never meant to go that fast and still transmit/receive valid logic levels.

[danjperron]

Hi ci.v.ic

is 25Mhz the frequency you get from toggle on/off? if yes than you got 50M change per second.

Also you assembly will have been faster if you didn't recalculate the bit all the time.

Code: Select all

               __asm__(
            "mov r1,#1\n\t"
            "lsl r1,#17\n\t"
            "loop:\n\t"

            "str r1,[%0,#28]\n\t"     
            "str r1,[%0,#40]\n\t"     

            "b loop\n\t"
            :
            :"r"((uint32_t)gpio)
            : "r0", "r1"
            );

Daniel

[ci.v.ic]

is 25Mhz the frequency you get from toggle on/off? if yes than you got 50M change per second.

Also you assembly will have been faster if you didn't recalculate the bit all the time.

Hi Daniel,

according to the photo of the oscilloscope it was indeed 25 MHz. And you are right, my code is not optimal. But as far as I can remember, a few instruction more or less didn't make it faster or slower.

Hi mikronauts,
In fact I would like to add RAM that is shared with other components but doing this with bit banging is not the optimal way, so it was just an experiment. What do you mean by "break"?

[mikronauts]

I was wondering of you need to continiously sample, or had a number of samples before you could do some processing.

Hi mikronauts,
In fact I would like to add RAM that is shared with other components but doing this with bit banging is not the optimal way, so it was just an experiment. What do you mean by "break"?

[ci.v.ic]

A bit processing is possible between I/O commands without lowering the frequency, seems that the I/O commands block the execution until the pin can be changed. But that's just an observation.

[sibiquin]

I am left a bit confused by this discussion. One line indicates about 1MHz sampling on GPIO is the best that can be expected, other lines talk about 25MHz. What am I missing?

In my application I want to read 4 bits at 3MHz continuously - data is real time and fixed rate (e.g. no pause or gaps). With a bit of external hardware I can read 8 bits at 1.5MHz or 16 bits at 750KHz. There needs to be enough CPU cycles to write this data to a file without falling behind.

So what is the best approach? I have a bit clock (3MHz), 4 data lines, and a word clock (identifies 32-bit word boundaries in the data streams). I understand the software approach of sampling the bit clock and reading the 4 data lines on a clock change. Seems like very high CPU overhead. Next best would be the bit clock causes an interrupt and the interrupt routine reads the 4 data lines (can the interrupt be serviced reliably in the bit-time?). Is there a DMA solution?... I have no idea what the software side of that would look like...

Thanks for any ideas.
-Mark

[jdb]

I am left a bit confused by this discussion. One line indicates about 1MHz sampling on GPIO is the best that can be expected, other lines talk about 25MHz. What am I missing?

In my application I want to read 4 bits at 3MHz continuously - data is real time and fixed rate (e.g. no pause or gaps). With a bit of external hardware I can read 8 bits at 1.5MHz or 16 bits at 750KHz. There needs to be enough CPU cycles to write this data to a file without falling behind.

So what is the best approach? I have a bit clock (3MHz), 4 data lines, and a word clock (identifies 32-bit word boundaries in the data streams). I understand the software approach of sampling the bit clock and reading the 4 data lines on a clock change. Seems like very high CPU overhead. Next best would be the bit clock causes an interrupt and the interrupt routine reads the 4 data lines (can the interrupt be serviced reliably in the bit-time?). Is there a DMA solution?... I have no idea what the software side of that would look like...

Thanks for any ideas.
-Mark

The hardware constraint is likely to be around the 25MHz point, i.e. signals transmitted to GPIO inputs are likely to be corrupted if they are over 25MHz.

If you ran the ARM processor (and core clock speed) as fast as they could go, with an assembly-optimised reading loop then you can achieve some very fast sample rates, but ultimately the latencies within the chip limit you. I profiled how fast it took to a) reset the USB interrupt and b) flip a GPIO up and down and the answer is ~390nS, which includes FIQ entry time and a single function call from the vector table. Therefore 3MHz sample rate is probably out of bounds from software.

The correct way to do this would be to use a microcontroller that could read the data and buffer it internally. 4 bits at 3MHz translates to 12MHz single-bit, and there is dedicated hardware within the SoC to transfer data serially - SPI. If you have sufficient internal memory in the micro, then a simple FIFO interface exposed over SPI would give you the mechanism to transport data to the SoC.

If you want offline analysis then you just have to write that to a file. 1.5MB/s is well within the capabilities of the CPU.

[Sebaxus]

Just for anyone wondering here is a quick guide on how to change the speed.
Link: https://michaelfranzl.com/2016/11/10/se ... pberry-pi/