First I'd like to thank the whole team behind the original Beaglebone
"Classic" - an extremely impressive piece of hardware and BBB looks even
better. Doubling the amount of RAM is what I was really looking for and the
addition of HDMI and onboard flash makes it even more attractive for other
applications that we have in mind for the future.
We are currently running a beta system that we built around the original BB
that is using 16 GPIOs and 3 UARTS in an industrial applications. The GPIOs
used for the digital inputs/outputs are connected to PC817 optoisolators for
3.3 to 5 VDC level shifting and finally to Opto-22 4th generation solid
state relays to allow for a flexible mix of AC/DC (sometimes high current)
I/O. We are also using 2 dual-channel Analog Devices ADM3232 3.3/5 VDC level
shifters for 4 ports of serial communications to high speed laser scanners
communicating at 115 KBaud. We are using Robert C. Nelson's ( kudos and many
thanks Robert ) Ubuntu build of Ubuntu. The hardware and software
combination is rock solid.
I have two quick questions since it appears that I have a GPIO conflict with
the addition of the HDMI and eMMC hardware additions and I need to do a
quick test. We are in the process of building a custom cape that will make
fabrication much easier, and we are in final layout stages
I need to do a quick test with BBB where I essentially disable the HDMI and
eMMC devices and test my existing I/O map with the BBB. I just got my first
BBB boards today and checked out the SRM, so it looks like I can disable the
HDMI framer and empty the onboard 2GB flash so that I boot to external micro
SD with my current Ubuntu image - essentially making it operate as the
With last friday's upload (2013-04-26 (1)) the SD card image that is
created is compatible with the BBB's default bootloader stored in the
eMMC.. In which case it will load the OS (Ubuntu/Debian) from the SD
card after poweron. No pushing buttons required.
1: BeagleBoardUbuntu - eLinux.org
If you'd like to go even further, there is a script under:
That will transfer your live Ubuntu/Debian SD system to the onboard eMMC..
Can anyone give me some quick pointers to perform these two tasks ?
I also need to resolve an issue I had in my original design where I was
using only 2 GPIOs in each bank so that all 8 digital inputs could generate
interrupts. From my quick look today I'm not sure that this will still be
Thank you both very much for the timely response. Since I am running a headless system, not plugging in the HDMI cable is a simple solution that works for me. I would really like to try to take advantage of the eMMC, especially since Robert has already solved the “buttonhold down” problem that I anticipated having to deal with.
I am going to try to modify my I/O map to accommodate eMMC usage. It looks like I just need to stay away from P8-11 thru 17 and P8-19 thru 21. It does look like I will have to limit the interrupt capability to 6 versus all 8 of my digital inputs though, since GPIO0_26 and GPIO0_27 are used by eMMC and there is no additional access to Bank 0.
The 2 pins per bank that I am currently using are:
GPIO0_26 * conflict with eMMC
GPIO0_27 * conflict with eMMC
I am correct in terms of interrupt capability ?
Also just wondering if page 56 of SRM is correct in terms of GPIO signals for user LED control. It appears that this has changed from using GPIO1_21,22,23 and 24 to GPIO1_21 and GPIO2_22,23,24.
FYI - Pins P8 11-17 and 19-21 are listed as the eMMC pins in table 13 of the BBB SRM. However, Gerald has said in another thread that the table is incorrect and to look at the schematics instead. The schematics show that the Emmc signals are really on pins P8 3-6 and 20-25.
it seems this will be a source of confusion until they get an updated BBB SRM published that corrects table 13.
The SRM has been updated. I will release it in the next couple of days.
The SRM is based on the schematic. It basically puts into words, pictures, and table the schematic. So, you can always go back to the schematic and verify anything there. Or, you cam also look at the Table 10 in this instance as well that have the signal name on them and where they are connected…
Nice catch Dave - much appreciated.
Hi Robert. I just got a chance to try your latest image and the transfer script. Smooth as silk … Excellent work again.
FYI, here’s what I’ve been shipping in the on-board documentation (which I think is correct):
Thanks Jason. Could someone please address accessing UARTS from C. After using the live chat it appears that these are disabled by design and it sounds like it requires a recompile to resolve.
Robert - I may have this wrong, but it appears that the UART devices (ttyO1, ttyO2, etc. are not setup by design in the latest BBB kernel. Can you point me in the right direction to resolve. I don’t have much experience with pin muxing or something that they refer to as DTS.
Yeah, those other uarts are not muxed by default yet... I don't have
any wiki/guide ready yet for that, but i wonder if someone else on
this list has yet..