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. 

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,

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.