Categories

BeagleBone Black GPIO Benchmark

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

beaglebone2-825x510

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

  • jeanmarc78: May be a free pcb for me :)
  • Jeff Tee: Still in the race?
  • Barry: Maybe not to late Need new project Free PCB Sunday
  • Sorin: I'll like one. Will save some time in producing myself.and your might have a better quality.. next project bus pirate!!!
  • Larry Couvillion: Please oh please oh pretty please!!!!