I'm currently using Python's RPi.GPIO module to toggle some pins, and I want to know how quickly it can do this. I need the pins to be toggled on the schedule of a ~50 mhz FPGA clock, which I'm worried is too fast for the Pi (I need 8 pins toggled). I'm using the Pi 3b+, and I've seen estimates for speed varying from .3 mhz to 30 mhz, and that's just with Python - they vary even more widely when I look at other languages/packages.

What is the fastest that the GPIO pins on the Pi 3b+ can be toggled with Python's RPi.GPIO module? With any language/module? Will this be able to keep up with my FPGA clock? (The Pi is being used to feed inputs to the FPGA.)

  • Comments are not for extended discussion; this conversation has been moved to chat. Please consider that an opportunity too cool down the heated discussion. Thanks! – Ghanima Aug 7 at 21:55
  • 1
    It is unlikely that any complex real time operating system, such as Linux, will be able to dependably / directly control a General Purpose I/O pin at maximum speed. Consider using an alternate dedicated platform such as an Arduino. – st2000 Aug 8 at 0:19
  • what problem are you trying to solve? .... you have not described the project. – jsotola Aug 8 at 2:03
  • @st2000 tbh the usual Arduino at 16 MHz (or twentyish) clock frequency (AVRs max out at 32 MHz) will also have a hard time to get anywhere near the desired 50 MHz, not to mention that besides toggling a pin at max rate one would usually burn up cycles to do anything useful with that pin state. EDIT (per st2000's comment): it would seem that I overlooked non-AVR Arduinos ;) – Ghanima Aug 8 at 4:55
  • @Ghanima, there are many different processors used on many different types of Arduino boards. I think the ubiquitous ESP8266 can be over clocked beyond 100MHz. – st2000 Aug 9 at 2:48
up vote 3 down vote accepted

There are some benchmarks from Henner Zeller's repository on GitHub which claimed that directly outputting data to the GPIO could achieve up to 65.8 MHz on a Raspberry Pi 3 (not B+, mind, but I suspect the figures won't be that far off). The code used is available here in C and the author gives the following pseudocode equivalent:

// Pseudocode
for (;;) {
    *gpio_set_register = (1<<TOGGLE_PIN);
    *gpio_clr_register = (1<<TOGGLE_PIN);
}

I suppose you can treat that as an upper bound to the possible speeds you will get. Python is going to be significantly slower than that, though.

For comparison, Joonas Pihlajamaa tested a Pi 2's ability to toggle GPIO pins quickly using various libraries. The values were as follows for RPi.GPIO:

  • Pi 1: 70 kHz
  • Pi 2: 243 kHz
  • Change: 2.5x

While there's clearly a significant difference between the Pi 1 and 2, it is not even close to your target of 50 MHz (over 200x too low, in fact).

You might like to run the benchmarks from the two sources above on your own Pi to get a definitive answer, though they'll be on the same order of magnitude as the data above anyway.

As noted above the fact that Raspbian (and any major multitasking OS on the Pi) uses preemptive multitasking means that there's little guarantee that you'll be able to consistently output a certain frequency. You are entirely at the mercy of the scheduler so if your application needs a consistent, fast output, the Pi is likely not well-suited to your needs. You'll probably have to consider an alternative option instead for your FPGA.

If you want to synchronously transmit data at 50MHz frequency (that's how I read "pins to be toggled on the schedule of a ~50 mhz FPGA clock"), you will absolutely need to use the same clock source for the FPGA and whatever device you connect to it. RPi doesn't have programmable clock inputs/outputs, so it's absolutely not up to the task.

Your best bet is to keep the high-frequency blocks of your design inside the FPGA, and export standard interfaces for data exchange. That is, if you wanted to use the RPi to stream data from an SD card, find an IP core for your FPGA which implements the SD interface and use it instead.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.