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

Ooh, from my tests I'm going to say yes, because the gpu performance was being affected when the CPU was getting hot on my benchmark post, for an actual test I'll have to acquire a 4k screen....

Good point, I do have a 7" screen lying around so I can test this out.

However I can say that you can power the Pi 4 from 2.5A, so long as you don't try to draw too much power from the USB ports. Pi 4 only needs 3A, not 3.5A.

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,

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

I'd like to see it tested with a large heatsink AND thermal paste. The tests I've seen so far did not use thermal paste and the pi4+ heatsink was thus hotter than the no-heatsink pi4. Also, with a heatsink+ thermal paste AND cooler.

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

I'm curious to see its ability to absorb shock such as constant vibration and potential drops if it already hasnt been done or suggested.