What would you like to see tested on the Raspberry Pi 4?

I'd like to see the maximum digital  IO toggle rate from a C programme.

MK

When there wasn't anything like a raspberry pi GPIO library I wrote my own. You had to run that as root: It mmap-ed the GPIO module hardware. Then you'd be able to get into the tens of MHz range, maybe even hundreds (but the physical pin hardware will stop responding before that!)

When you go through the Linux GPIO driver, I'd expect something in the order of 100-1000 kHz....

Update:
Ran the test. With "wiring pi" (blink example from: https://elinux.org/RPi_GPIO_Code_Samples  ) you get 10MHz. It seems to do the mmap that I thought would get decent performance.

I tried a second "gpio access method"  (BCM library), but that failed the test (as in I couldn't get it to work on short notice).

I think there maybe was a hard 250MHz physical I/O ceiling, because on an old Pi (I think Pi 2), in C code, with the WiringPi library (which offers an Arduino-like API) I was able to get a signal of approx 5.8MHz by toggling a pin up and down using the digitalWrite command (and compared it with Python etc here:  Raspberry Pi GPIO Explained  ) but the jitter was on certain discrete boundaries, i.e. the I/O seems to be clocked out at some rate of 250MHz, too fine to be from just usual context switching. I couldn't find any documentation at the time to support or un-support this theory though.

Sorry, just saw your update. Very cool, 10MHz sounds about right, given the Pi 2 managed 5.8MHz.

Thanks for the info - I'll take a look at that.

I've finally bought a PI - CPC had 2GB Pi 4 in stock. I've got it booted up and now I had better make it do something.

MK

Just FYI: This sounds plausible: The GPIO module is probably clocked at that 250Mhz. On simpler ARM processors like the STM32 family the same happens: the CPU core runs at some frequency and then you get a bunch of choices for the IO module clocks and bus clocks. Sometimes completely separate from the CPU clock sometimes your choice is restricted to "div2" or "div 1 or div2 as long as the result is below xxx". For the BCM2711 hardware running the IO modules at 250MHz base clock sounds reasonable.

Using the link you provided I've got direct register access pin toggling working from C.

Early days yet and I'll post some scope traces once I've made some high speed Pi compatible probes.

First thing:

The peripheral base address is 0xFE000000. It  took some time to find this - as ever the official documentation is poor (absent - there are broken links in the hardware documents on the RPi site). On the plus side it was on the RPi forum that I found the answer:

https://www.raspberrypi.org/forums/viewtopic.php?f=33&t=244031

I tweaked the code (from https://www.element14.com/community/external-link.jspa?url=https%3A%2F%2Felinux.org%2FRPi_GPIO_Code_Samples )  to make a burst of 4 pairs of:

GPIO_SET = 127;

GPIO_CLR = 127;

I'd set this up so I could only reach it with a 200MHz scope with cheapo probes.

The pins/probe/scope  can't toggle anything like fast enough but it looks as if the best interval between peaks is 10ns, implying a peak pin update rate of 200MHz and a toggle rate of 100MHz.

I'll need to make a probe that plugs directly onto the header and move the whole caboodle to somewhere near enough to the 1GHz scope to measure the best that can be done.

MK

Nice work! :-)

I'd recommend not letting this run for minutes at a time. Consider running it for one second, and then let things cool for say ten. It is possible you'd overheat the IO pad if you keep going. When you toggle the IO pin at 100MHz oir more, the "outside" acts as a short. So for the chip it "feels" as if you order it to make the pin high, but then short the pin to ground. You wouldn't be surprised if that breaks things, so you shouldn't be if you try to toggle at 100MHz.

Stuff like PCIE gets low swing output pads, and an encoding that ensures the pads get the lowest possible number of transitions to encode the datastream. 

Nice work! :-)

I'd recommend not letting this run for minutes at a time. Consider running it for one second, and then let things cool for say ten. It is possible you'd overheat the IO pad if you keep going. When you toggle the IO pin at 100MHz oir more, the "outside" acts as a short. So for the chip it "feels" as if you order it to make the pin high, but then short the pin to ground. You wouldn't be surprised if that breaks things, so you shouldn't be if you try to toggle at 100MHz.

Stuff like PCIE gets low swing output pads, and an encoding that ensures the pads get the lowest possible number of transitions to encode the datastream. 

I've made a little matching pad and coupled the port to the 50ohm input of a fast scope with 1k in series, then 51R to ground (using GPIO7 means there is an adjacent ground pin) then 1m co-ax to scope.

Getting reasonable waveforms  - rise and fall times about 5ns.

The code sends 10 bursts of 4 pulses - it's pretty obvious that there is a synchronisation between processor clock and IO clock causing variations in high and low times.

The IO clock is a bit slower than I thought - perhaps 120MHz but quite respectable.

The interface pad looks like this:

The gunk is needed to stop the co-ax from breaking the 0603 resistor between the socket pin and the BNC.

It looks to me as if one might just about manage a 5MHz bit banged 8 bit bus with handshake !

What's the fastest clock anyone has made SPI go at from a Pi ?

MK

Hi Michael,

It seems 32MHz may be feasible on SPI, using a driver, it is open source, referred to as 'notro' tft driver. I don't know if that is bit-banging, or using any SPI peripheral in the SoC. The 32MHz is mentioned by people in several places as possible for driving TFT over SPI, but I have not seen it confirmed anywhere with a 'scope trace.

Hi Michael,

Incidentally (not sure if it will help), in user-space if any context switching is getting in the way over the longer term time period (it won't help with the high/low time variations in your scope trace of course), this code can try to influence the scheduler a little bit - I found it useful when sending multiple bytes over a serial interface, to reduce jitter from byte to byte (not bit-to-bit).

It is discussed here: Miniature Solar Cells and Improving Real-Time GPIO Performance

Hello Shabaz,

Thanks for that.

I'm working on a 16 bit // interface with a few (5) handshake signals to an FPGA clocked at 100MHz.

I'm hoping for a burst rate of > 20Mbyte/s.

Mostly I would want to transfer much less data, just do it at reasonable (to me) speed.

So, for example, I might want to send a command containing 32 bytes of parameter information, or read 4096 bytes from the FPGA,

which should take about 2us and 210us respectively.

SO far I've defined the bus, written some FPGA code, and made the wiring loom - I'm using a Lattice Brevia board.

Might have some results today.

MK

Oh dear, spoke much too soon.

Got the write to fpga working first and it is much slower than expected, the problem is that there are two reads of the FPGA handshake signal per cycle and the Pi's read is horribly slow.

For a quick test I added four reads to each bus cycle like this:

volatile uint32_t d

volatile uint32_t *gpio_in = mapped read address of pi input register

d = *gpio_in;

d = *gpio_in;

d = *gpio_in;

d = *gpio_in;

These reads add 600 ns to each cycle, no significant jitter, so each read takes about 150ns.

All is not completely lost, but I shall have to almost give up on the full handshake.

Currently the Pi is the bus master, to send data it sets up the data and asserts MR, the FPGA responds to MR asserted by reading the data and asserting SACK, the Pi de-asserts MR and the FPGA de-asserts SACK and we are ready to go again. If Linux on the Pi goes off for a couple of seconds to something else, at any time in the bus cycle, it doesn't matter. But this scheme needs the Pi to read twice to check that the FPGA has seen the data and is read for some more. These two reads cost about 300ns, which is alkot when I want a complete bus cycle of 100ns.

Scheme 2 relies on the FPGA never to go off watch:

The Pi sets up the data and asserts MR (simultaneously), and repeats this n (n probably = 3, might be 4), then it puts the next data word on the bus and simultaneously clears MR, and repeats this for n times. This means that during a burst of data each word will be presented for at least n cycles, which is about 10ns * n. The FPGA looks for changes in MR and uses the data which precedes the change by one FPGA clock cycle (= exactly 10ns). If the Pi goes off to do other stuff in the middle of set of n - it doesn't matter. The FPGA isn't allowed to relax and must always be ready for data. I think this will allow me to send data from Pi to FPGA at an average rate close to 10 * n (it will be a bit less because the Pi doesn't always manage three or four output cycles at the full rate.)

When the FPGA must send data to the Pi we can't help at least one Pi read per bus cycle so that's 150ns gone - but it looks as if the Pi always takes 150ns - so I can try asserting MR, then reading after p more asserts, adjusting p until the reading s are never wrong. (There is a smart way to do this which some ADCs use - you need some extra bits in the data and adjust the delay (p in our case) until  the sequence of the extra bits is error free. I'll adjust p by hand !)

So - it's harder than I hoped and I'm adjusting my target to 20Mbyte/s Pi to FPGA and 10Mbyte/s FPGA to Pi.

MK

Some progress in writing data from Pi to FPGA, I'm able to send packets of 2048 words (16 bits wide) in a typical time of about 175us. No errors so far but I've only sent a small number of packets.

Rate = 23.4 Mbyte/s.

Next to try and get FPGA -> Pi up to a reasonable rate.

I'm not quite as fast as PCie () but this works without modding the Pi !

MK

Hi Michael,

Wow, that's very interesting : ) It's making me think all sorts of things to interface to the Pi : )

Well, I have the ability to send data packets in both directions and I don't get errors.

The sad news is that Pi Reads of the IO seem to top out at about 264ns - the code loop is very simple:

while(word < n_words)

adding the commented out statements or changing the level of compiler optimisation make no difference at all to the speed, the MR pulses remain at 264ns and the period at 528ns.

This looks like 32 - 33 cycles of the IO clock (assuming it is 120MHz or 125MHz - I've seen both claimed.)

It would not surprise me if there is a setting in the processor that could change this - so if any RPi bods are reading this - please let me know !!

As it is I can transfer 7.575 Mbyte/s into the Pi from the FPGA. It would be so nice to go at twice that speed .

@ Christopher Stanton - do you have any RPi contacts you might ask ?

MK