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

  • Joe Desbonnet: Ya, I can recommend the low melting point solder. I used brand 'ChipQuik' and it's amazingly easy to use.
  • Jerome: I need a new BusPirate for the Fablab ;) Many thanks!
  • Max: Seems like an unexpectedly violent way to remove the chip indeed. A hot air station should of course do the job just fine, but in...
  • jose: Part removal described here is pure butchery, the cheapest hot air station will do a fast and clean job removing the QFP, heat air to...
  • Cody: Yes please