

BeagleBone Black GPIOs - eurg
http://kilobaser.com/blog/2014-07-15-beaglebone-black-gpios

======
tmuir
Adafruit has a ton of tutorials for the beaglebone black. They even have their
own Python library.
[https://learn.adafruit.com/category/beaglebone](https://learn.adafruit.com/category/beaglebone)

Derek Molloy has several video tutorials:
[http://derekmolloy.ie/beaglebone/](http://derekmolloy.ie/beaglebone/)

Both of these resources have just about all of their source available on
Github.

Anyone whose done "little" embedded will be absolutely amazed by embedded
linux, once they can get a base level of proficiency. With smaller processors,
every bit of functionality in the code is there either because you had to put
it there yourself, or you cobbled it together from 7 different barely tested
libraries. If those libraries are any good, you may have paid thousands of
dollars each, plus 20% every year, for an RTOS, Ethernet, TCP/IP, USB,
filesystem, etc. Oh, whats that? You want to switch from Freescale to Texas
Instruments? Fuck you, pay me. You want to release two different products with
the same RTOS? Fuck you pay me. You want multiple developers using the same
libraries? Fuck you pay me.

With a beaglebone black, for free, immediately and in perpetuity, you have
TCP, UDP, HTTP, FTP, DHCP, SSH, SPI, I2C, UART, Filesystems, SDMMC, USB host
and device, HDMI, Threads, Processes, Semaphores, Pipes, Queues, Python, Java,
C/C++, Android, MySQL, and more. Additionally, just about all of these
features have been thoroughly tested because its all Linux. There are more
questions and answers on Google/StackOverflow, because there are more Linux
developers to chime in. Even if they've never touched a beaglebone, most of
their experience is still relevant. You can program, compile, and debug
directly on the processor, without needing an IDE or JTAG debugger. It's truly
an amazing device/experience.

------
chrissnell
I'm using the BeagleBone Black as the platform for my GoBalloon [1] project.
Overall, it's awesome: the GPIO and UART ports work as expected. One major
annoyance, however, is the lack of easy-to-use DC input current sensor. For my
battery-powered project, I want to be able to monitor the supply voltage that
the BBB is getting. I want to read this value in software so I can do things
like reduce the telemetry transmission rate if the battery starts to run low.
I also want to log the supply voltage so that I can compare the performance of
different battery technologies on subsequent flights.

I was chatting with the folks on freenode:#highaltitude and it turns out there
is a way to do this, but it involves soldering jumper wires onto pins of the
BBB's Power Management Controller and pulling resistors off the PCB. Yuck. I
decided to use a INA219 on my custom cape instead. Hacky.

Thanks for the writeup on the device tree overlays. That's going to be super
useful for me.

[1]
[https://github.com/chrissnell/GoBalloon](https://github.com/chrissnell/GoBalloon)

------
maho
I love the BeagleBone Black and I own several of them. I also bought some for
work. But I hate setting them up. I wasted days getting one to boot again,
after an update made booting from uSD impossible. Setting up the GPIO pins and
the PRUs (programmable real time units) is a pain in the behind, because the
set-up-method keeps changing. The article mentions device tree overlays, which
are relatively new, but these were actually thrown out of the latest Ubuntu
builds. And don't get me started on uEnv.txt. For beginner/intermediate users,
this is suboptimal.

~~~
heuermh
What is the best set up method at this point then?

I have a BeagleBone Black but it still hasn't made it out of its box. I'm
hoping to use it to write simple synths/audio effects and connect lots of
buttons/pots/switches/sensors and such to the GPIO pins.

In the meantime I've been using the Teensy to build I/O devices and then send
MIDI/OSC to and route audio through my laptop.

~~~
maho
If you are not using it online, then you might be better off not applying any
updates. In my experience, updates caused as many problems as they were
solving.

The 3.8 Kernel was the only one that supported Device Tree Overlays. I found
that to be easiest to work with, although there are a few bugs. Last time I
tried, removing overlays did not work reliably - a reboot was usually better.

I am currently on Ubuntu 14.04, which unfortunately does not support device
tree overlays. I installed it a few weeks ago and kept a few notes on the
process here:

[http://hoeckerson.de/notes/beaglebone-black-
overview/](http://hoeckerson.de/notes/beaglebone-black-overview/)

------
AceJohnny2
Tangential to the core topic of the post, it mentions problems with the
RaspberryPi's USB and Ethernet, referencing a 2-year-old Slashdot Post.

I've never encountered real issues with my RasPi, but I really haven't used it
significantly. Nevertheless, that's a long time to have issues with popular
hardware.

Have the USB problems been since corrected? What about the model B+, which
upgrades the USB controller from the LAN9512 to the LAN9514:
[https://learn.adafruit.com/introducing-the-raspberry-pi-
mode...](https://learn.adafruit.com/introducing-the-raspberry-pi-model-b-plus-
plus-differences-vs-model-b/usb-ports-hub) ?

~~~
gbl08ma
I have not had any problems related to USB with my B+, except that one time I
directly connected a device that uses the USB power for charging - the screen
went blinking black (not enough power for HDMI?), and the red power led
blinked a bit (meaning, inadequate power supply/too much demand) but no kernel
panics or reboots. I have since bought a more powerful power supply, it's
possible that the problem is gone (but I have not checked).

Ethernet is as fast as you'd expect from a Ethernet-over-USB-2.0 adapter
(read: no Gbit, but 100 Mbps). Plugging and unplugging USB devices has never
caused kernel panics or reboots for me, and for the model B I recall reading
these problems have been corrected, or at least significantly attenuated, a
lot of time ago, in the form of kernel updates. Stability also has a lot to do
with the quality of the power supply - from what I see, people using less
powerful power supplies tend to have more problems, especially when connecting
power-hungry devices.

I think calling such problems "major bugs" is exaggerated. At most, it's a
power management problem, but one must see that the RasPi has a microUSB
connector for power. This means people are possibly going to use a random
charger, which is not exactly prepared to power a mini-computer plus two (or
four, with the B+) possibly hungry devices, to power it. That's why a powered
hub, or at least a good power supply, is recommended.

In my opinion, the BeagleBone Black is, from the start, less prone to "power
abuse", because it has a traditional power jack (people are less likely to use
a random USB charger with it) and only one USB port (it's harder to pull a lot
of power from a single port, unless a non-powered hub is used). The amount of
people using the BeagleBone is, I think, also going to be much smaller: even
if the chance of failure is the same as for a RasPi, there will be less broken
devices around. Lastly, the people using the BeagleBone will likely be much
more tech-savvy (i.e., they hopefully will know what power supply to use, for
example), as it doesn't exactly appear to be targeted at people still learning
the basics about computers and coding.

~~~
gman99
>the BeagleBone Black is [..] less prone to "power abuse", because it has a
traditional power jack (people are less likely to use a random USB charger
with it)

Not quite true. The BBBlack can _also_ power itself from the mini-usb port
(and mine is currently powered up in exactly this way, off a normal usb phone
charger I had lying bout)

------
jwr
Thank you, this is very helpful for people who are experienced with embedded
work, but unfamiliar with the BBB. I wish I had this available a couple of
months ago, when after figuring things out on my own, I also ended up writing
an I2C library (something I never expected would be necessary, it's called
LsquaredC).

Platforms like the BBB and RPi have a lot of beginner-level tutorials, but as
soon as you try to do anything out of the ordinary (PWM a pin, or issue
repeated I2C start), you end up on your own.

~~~
tmuir
This tutorial has SPI, I2C, PWM, GPIO, ADC, and UART. Its in Python, but it
almost exclusively uses the sysfs interface, so porting it to C, or the
language of your choice, should be very simple.

[https://learn.adafruit.com/setting-up-io-python-library-
on-b...](https://learn.adafruit.com/setting-up-io-python-library-on-
beaglebone-black/)

I think they also have a similar library for the RPi.

------
panzagl
Nice article, but why does every post about the BeagleBone have to include a
swipe at the Pi?

~~~
jwr
I think anyone who tried to use the Pi for long-running reliable applications
and failed has this knee-jerk reaction. I certainly find it understandable.

~~~
lhl
While the BBB may be more reliable, it's still not rock solid - I've been
working on an embedded project w/ heavy USB usage and the BBB seems to have
occasional, but unavoidable and hard to diagnose hard lockups every couple
weeks. In the end we were forced to use a separate IP-switch device to power
cycle the BBB when it became unresponsive.

~~~
mik3y
Does the BBB not have a watchdog mechanism capable of triggering a board-level
reset?

------
curveship
Another great feature of the BBB GPIO pins is that you can map some of them to
a register on the PRU. Since the PRU runs at 200Mhz, this gives you some
really impressive real-time capability. The sysfs technique the article
outlines is definitely convenient, but latency can be high, as much as 1ms.
Mmaping the GPIO controller and using some real-time extensions to the kernel
can get that down to a few us, but using the PRU can take it down to a handful
of ns.

The PRU is the unrecognized gem of the BBB. As long as you're not scared of
assembly :).

------
tdicola
Good overview, as someone who's worked with the BeagleBone Black a bit it's
nice to see a single blog post that covers lower level GPIO access
comprehensively like this one does.

