BeagleBone Black GPIOs | Hacker News Reader

BeagleBone Black GPIOs

kilobaser.com

63 pointseurg22 comments

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

Derek Molloy has several video tutorials: 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.

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

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.

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.

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/

I have a project/cape that I want to move from BB to BBB, and it's the stuff you describe that makes me put it off. Thankfully there's no rush.

Ew. This is sold as a better RaspberryPi but the experience you describe is far from that.

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... ?

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.

>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)

hardware bug, wontfix only workarounds in blob firmware

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.

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...

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

I will second that.

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

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.

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.

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

"... anyone who tried to use the Pi for long-running reliable applications and failed has this knee-jerk reaction. ..."

Curious, do you have any cites/examples? I run my Pi's 24/7 and the system software is rock solid with uptime of weeks sans power outages. Applications I write might be another thing.

When you mention applications is that "user created applications?" or a "hardware/software combination?"

I don't disagree, but it definitely sends the message 'Beagle Bone is like a Raspberry Pi but not as popular' when you can't mention the former without taking a dig at the latter.

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 :).

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.

Reply on news.ycombinator.com