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
    Commented Aug 7, 2018 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
    Commented Aug 8, 2018 at 0:19
  • what problem are you trying to solve? .... you have not described the project.
    – jsotola
    Commented Aug 8, 2018 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
    Commented Aug 8, 2018 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
    Commented Aug 9, 2018 at 2:48

3 Answers 3


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.

  • "mercy of the scheduler" but you can just tweak the scheduler to lower the scheduling delays, isn't that? Commented Sep 27, 2020 at 11:40

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.


We have recently benchmarked PIGPIO and RPi.GPIO with regards to the accuracy of reading inputs at different frequencies. The test was performed on a Raspberry Pi 3b, reading signals generated from a Lattice MachXO2-4000 FPGA

Both libraries perform well for frequencies of up to 5 KHz with accuracy above 99%. The accuracy of the Rpi.GPIO library deteriorates over 5 KHz and at 50 KHz it is incapable of performing this task.

The PIGPIO library performs comparably better, with its accuracy being above 99% for frequencies up to 20 KHz. Above that frequency, its performance gradually deteriorates and at 110 KHz it cannot read correctly any phrase at all.

You can find the exact test setup and results on this this post: https://atman-iot.com/blog/raspberry-pi-benchmark/

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