BeagleBone Black GPIO Benchmark

Posted on Tuesday, April 26th, 2016 in hacks, R-Pi by DP


Joonas Pihlajamaa from Code and Life writes, ” I’ve previously made a GPIO benchmark of Raspberry Pi 1 and 2, and have always wanted to see how BeagleBone Black would stack against the Pis. I recently got one so the obvious thing to do was to see how fast the little thing could go.  Turns out, the little thing needed a bit more work than the Pi, but the results were quite interesting.”

More details at Code and Life homepage.

Via the contact form.

This entry was posted on Tuesday, April 26th, 2016 at 1:17 pm and is filed under hacks, R-Pi. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

4 Responses to “BeagleBone Black GPIO Benchmark”

  1. KH says:

    As an old skool dinosaur, I shook my head in dismay over and over as I browsed the link posting. Gentlemen, this is the world the Arduino and RPi fellows have wrought. I am being outnumbered by people using hardware badly! Oh woe… :-p

    • Drone says:

      +1 This is a “Benchmark” done badly. Anyway, these SoC on-die busses really make it a chore to get access to fast GPIO (if you can do it at all). I think ARM’s version is called the Advanced Microcontroller Bus Architecture, or AMBA (Google for more info).

      • KH says:

        No, AMBA is an interconnect spec internal to the SoC, like Wishbone. Bare metal would be really fast, but the inner loop would depend on clocks, caches, memory speed, OS, etc. Which means one cannot quote max toggling speed like 40MHz for some PIC32s.

        Like Max said, the fastest way is to use the PRU(s) on BeagleBone. GPIO using the Linux filesystem layer is a terribly inefficient method, can’t even reach audio rates never mind clock phase accuracy. It’s only good for your first blinking LED script. The Python library is also terribly slow, maybe the lib simply used the fs layer, because Python plus the C method should be quite a bit faster. Memory-mapped C works better, but due to the Linux layer, it can always be preempted, so this kind of user mode toggling will never be as good as a proper firmware.

  2. Max says:

    …so basically GPIO speed tested in all possible ways except the only sane one anyone should ever use on the BBB if they care about speed: USING THE $##%^&ING PRU…

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Recent Comments

  • Drone: The LM7171 used in this very simple design can be simulated in LTspice with reasonable results at 10MHz using the non-encrypted PSPICE model from TI...
  • Jon Jackson: I would be interested in 1 or 2 of your circuit boards. Jon
  • Max: An actual Saturday "detector" built with the same hardware would use the precisely timed slightly varying length of the day (and some built-in astronomy data)...
  • KH: In the old days, these things remained on paper forever as whimsical scrawls. Today, they are brandished about on blogs for the entire world to...
  • KH: So he doesn't really know what he's doing. Yawn. It's sensor-controlled. It's not an oscillator. A leaf covers the window, you're toast. TLV3702? Overkill. The...