Which build would you recommend?

It has been awhile since I have done much with my BBBk. Over the last several months I have been playing around with some other boards such as the Odroid U2 (have a U3 on order) as well as an Intel NUC. But am thinking about moving the BBBk that I was starting to use on a Rover to a 4DOF hexapod. Should be straight forward as I have 2 RPIs running my Phoenix port. One is on a 3DOF Lynxmotion T-Hex and another is on a Trossen PhantomX Hexapod. But I have not tested my 4dof support in the port, so am thinking of trying my Lynxmotion 4DOF round hex out on the BBBk.

My question is, which distribution/build would you recommend at this point. I believe the emmc has an Angstrom build dated back to 2013 06 20. I know around this time I was having issues that if you do something like an apt-get update/upgrade at times it would corrupt the image.

I am not using any shields (other than the prototype shield). I have been using a few of the usarts for XBee and before to talk to motor controller. But for Hex will probably want to talk to SSC-32 (Atmega chip) so I will either use USB to serial converter or probably would need to use a TTL level shifter.

So again would like to know if you would recommend sticking with Angstrom on the EMMC or go to a different distribution? Do any others fit on the EMMC?

Thanks in advance

Kurt

P.S - Do wish the BBBk came with a larger 4 or 8 gb emmc. (I have an 16 on ODroid, 128 on NUC) Would have easily paid more for it

Hi Kurt,

If you use a large uSD and boot from it you can use the instuctions at http://elinux.org/Beagleboard:Expanding_File_System_Partition_On_A_microSD to resize your rootfs to use the remainder of the space. As for the OS not really sure, i was using Angstrom from day one up until about two days ago when i switched to Debian Wheezy. I had angstrom all set up the way i wanted it but was just trying Debian and was really pleased at how easy it was to get set up how i wanted it and my wifi adapter worked right out of the box.
Some one else might be able to guide you better since i am currently not working with any hardware, i can not suggest What OS to use.

-Wil

Thanks,

I know asking for which OS to use is a loaded question, that usually has the simple answer, of which ever one works for you…

So after reading through the Angstrom/Rants thread, plus some others, decided to also try out Debian Wheezy, which I installed off of:
http://elinux.org/BeagleBoardDebian. I installed the EMMC version, which is great.

Now starting to fumble my way through to get the system configured up. I now have the wifi working, which is great. Yep driver just worked. Only thing I needed to do was to figure out how to configure it for my WPA… Now working. Took me a few minutes to figure out what IP address it has, as did not see anything in the dmesg output. Also dont have ifconfig… But found it looking at my DHCP servers log output.

Next up: find where I put my 3.3v FTDI cable and look at seeing what I need to do again (if anything), to enable the usarts through the device maps. Was using a couple before for XBee and the like.

Again thanks,
Kurt

Thanks,

I know asking for which OS to use is a loaded question, that usually has the
simple answer, of which ever one works for you...

So after reading through the Angstrom/Rants thread, plus some others,
decided to also try out Debian Wheezy, which I installed off of:
BeagleBoardDebian - eLinux.org. I installed the EMMC version, which is
great.

Now starting to fumble my way through to get the system configured up. I
now have the wifi working, which is great. Yep driver just worked. Only
thing I needed to do was to figure out how to configure it for my WPA... Now
working. Took me a few minutes to figure out what IP address it has, as did
not see anything in the dmesg output. Also dont have ifconfig...

use the full path for non root/sudo users..

/sbin/ifconfig

But found
it looking at my DHCP servers log output.

Next up: find where I put my 3.3v FTDI cable and look at seeing what I need
to do again (if anything), to enable the usarts through the device maps.
Was using a couple before for XBee and the like.

Regards,

Thanks, forgot to look in /sbin

Making some progress, found my 3.3v FTDI cable so have the debug setup. Am now downloading source and the like to the board and installing build-esentials.

Next up see if using same steps as before (need to find them) to setup for the ttyOn devices.

Just ran into having the WLAN dropping me and then reconnecting a few minutes later. I remember these issues from from before, maybe something like it powers itself down… Need to investigate. After that, at the end of dmesg I see:
[ 2039.185393] wlan0: deauthenticated from 30:46:9a:02:49:a8 (Reason: 2)
[ 2039.231769] cfg80211: Calling CRDA for country: US
[ 2040.111858] hub 1-1:1.0: transfer → -71
[ 2040.125075] wlan0: authenticate with 30:46:9a:02:49:a8
[ 2040.150919] wlan0: send auth to 30:46:9a:02:49:a8 (try 1/3)
[ 2040.178916] wlan0: authenticated
[ 2040.186600] wlan0: associate with 30:46:9a:02:49:a8 (try 1/3)
[ 2040.198275] wlan0: RX AssocResp from 30:46:9a:02:49:a8 (capab=0x431 status=0 aid=6)
[ 2040.208995] wlan0: associated

In case anyone looks, from earlier on in dmesg:
[ 7.302088] RTL8192cu 1-1.2:1.0: usb_probe_interface
[ 7.302117] rtl8192cu 1-1.2:1.0: usb_probe_interface - got id
[ 7.330628] rtl8192cu: Chip version 0x10
[ 7.664443] rtl8192cu: MAC address: 80:1f:02:9a:9b:e6
[ 7.669813] rtl8192cu: Board Type 0
[ 7.696119] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 7.724885] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
[ 7.757493] usbcore: registered new interface driver rtl8192cu

Kurt

Some mainline "reverse engineered" wifi drivers need:

sudo iwconfig wlan0 power off

Regards,

sudo iwconfig wlan0 power off

Thanks, it appears this device does not support that:

kurt@arm:~/Raspberry_Pi/Phoenix$ sudo iwconfig wlan0 power off
Error for wireless request “Set Power Management” (8B2C) :
SET failed on device wlan0 ; Operation not supported.

On other note, looking back up where I used to get information about setting up ttyO1…

It looks like since I last did this, there was another way (Angstrom), by adding the info to:
“just add you BB-UART2 to /media/BEAGLEBONE/uEnv.txt, with the key capemgr.enable_partno.”

with This Debian build my /media directory is empty. Should creating this directory and file work here as well? The only place on my machine I found uEnv.txt is in the /boot/uboot directory.

Or should I try the way I was doing before, something like: echo uart2pinmux > $SLOTS
where $slots was defined earlier on as**:**

export PINS=/sys/kernel/debug/pinctrl/44e10800.pinmux/pins
export SLOTS=/sys/devices/bone_capemgr.9/slots
(the .9 sometimes changes, earlier I had .8)

Probably the easiest thing for me to do is to try it out and see what happens.

sudo iwconfig wlan0 power off

Thanks, it appears this device does not support that:

kurt@arm:~/Raspberry_Pi/Phoenix$ sudo iwconfig wlan0 power off
Error for wireless request "Set Power Management" (8B2C) :
    SET failed on device wlan0 ; Operation not supported.

darn, i know it works for some devices.. I usually just run Atheros chipsets...

On other note, looking back up where I used to get information about setting
up ttyO1...
    Pignology News: Getting UART2 (/dev/ttyO1) Working on BeagleBone Black

It looks like since I last did this, there was another way (Angstrom), by
adding the info to:
"just add you BB-UART2 to /media/BEAGLEBONE/uEnv.txt, with the key
capemgr.enable_partno."

with This Debian build my /media directory is empty. Should creating this
directory and file work here as well? The only place on my machine I found
uEnv.txt is in the /boot/uboot directory.

There's a hint here, "/boot/uboot/uEnv.txt"

root@beaglebone:~# cat /boot/uboot/uEnv.txt | grep cape
#optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

Or should I try the way I was doing before, something like: echo uart2pinmux

$SLOTS

where $slots was defined earlier on as:
     export PINS=/sys/kernel/debug/pinctrl/44e10800.pinmux/pins
     export SLOTS=/sys/devices/bone_capemgr.9/slots
(the .9 sometimes changes, earlier I had .8)

Yeap, never hardcode .8 or .9 in your script, always check..

Regards,

darn, i know it works for some devices… I usually just run Atheros chipsets…

I am trying to remember which wireless I was using back earlier… I remember it took me a long time to get one working then. I believe I had to build the driver for it. Right now I have one of those cheep Edimax plugs, which appeared to work right out of the box. Could try different ones if this becomes an issue.

There’s a hint here, “/boot/uboot/uEnv.txt”

root@beaglebone:~# cat /boot/uboot/uEnv.txt | grep cape
#optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

Thanks for hint, yep edited the file added the capemgr.enable_partno= the two usarts and rebooted and the devices showed up in the /dev directory so making progress.

Now to try to build my Phoenix hexapod code base again. I see I need to either disable some of my code in this or need to install (and or build) a few more things like alsa and potentially espeak. luckily I still have notes on how I did this before on both RPI and BBBk. Before on BBBk ahd to build and install ALSA, but maybe this time will get lucky and can simply install.

I also should update my readme.md file on my github project with notes from setting this up on Debian.

Again thanks a lot!

Just thought I would mention, I am making more progress :slight_smile:

Using the debian release is nice as like when compiling on the RPI, I could install PCM and espeak, by simply doing apt-get install and the packages were installed. On Angstrom I had to find sources build and install. No big deal but it is nice.

Next up is to start connecting it up to hardware. XBee will be easy, connect to TTL usart like before, as it is 3.3v. But not sure which way I will go to talk to SSC-32. Could USB to serial adapter or could connect to another USART through level shifter. The SSC-32 is a 5v ATmega based board.

Another thing I want to investigate more is in my code, I like to reference devices by a name such as: /dev/ttyXBee instead of by some actual hardware name. When it is /dev/ttyUSBn it also had the complication that if you rearrange things and/or add devices your device may change names. ttyUSB0 today may be ttyUSB1 tomorrow… So I used UDEV rules to do the mapping. Something like:

SUBSYSTEM==“tty”, ATTRS{idVendor}==“0403”, ATTRS{idProduct}==“6001”, ATTRS{serial}==“A800fclo”, SYMLINK+=“ttyXBEE”

But at the time was not sure of the best way to simply map ttyO1 to ttyXBee. When I tried it the last time was not sure, so I simply added a line to my .profile file that did something like: ln -s /dev/ttyO1 /dev/ttyXBee

But my gut tells me there is a cleaner way. So will probably play a little with this, before I simply fall back to doing what I did before.

Again having fun

Kurt

P.S - the Wifi has stopped twice now. Could be related that I am powering board through USB (1 amp wall wart) instead of DC power input. Will change soon

I will answer my own question, on the off chance someone else is wanting to do the same. Actually I did it two ways:Another thing.

One example /etc/udev/rules.d/99-tty-serial.rules Looks like:

SUBSYSTEM==“tty”, KERNEL==“ttyO1”, SYMLINK+=“ttyXBEE”
SUBSYSTEM==“tty”, KERNEL==“ttyO2”, SYMLINK+=“ttySSC-32”

I also was able to do it like:
SUBSYSTEM==“tty”, ATTRS{port}==“0x0”, ATTRS{line}==“1”, SYMLINK+=“ttyXBEE”
SUBSYSTEM==“tty”, ATTRS{port}==“0x0”, ATTRS{line}==“2”, SYMLINK+=“ttyRCLAW”

Earlier I was using a Roboclaw motor controller on this.

Kurt

“Using the debian release is nice as like when compiling on the RPI, I could install PCM and espeak, by simply doing apt-get install and the packages were installed. On Angstrom I had to find sources build and install. No big deal but it is nice.”

Actually, it is a hugely big deal. With the packages already built there should be some minimal testing already done that you wont get when you build it yourself.

Just as a for instance, I had the need for Nodejs on my BBB’s( still do actually ), and I was running Wheezy with no actual apt-gettable package. No big deal I thought, the Nodejs github page has instructions for building Nodejs from source . . . my first attempt failed, but I quickly found older instructions that gave me some insight to a single command line switch to make Nodejs compile for ARM . … With this step out of the way I proceeded to get a Nodejs package manager working, compiled in the sources, etc, got it installed, and then went to download a common package. The package manager started pulling in x86 compatible only code . . .

Anyway, none of this was a super huge hassle by its self, but by the time I got everything worked out and running the way I wanted, 2-3 days had passed.

Very glad to see you seem to be pleased with how Debian is working for you ! I felt the same way, and still do.

Yes, it is working good for me. :slight_smile:

But after reading the happy new year message, I have also been wondering that if the standard release will be Debian, should I try building my own images from the links that were listed there for both the actual image and kernel?

But if I do, should I stick with the 3.8 kernel? Or 3.12 or 3.13?

My assumption is the build scripts assume I am running linux. Can dual boot to this on my main dev machine to Linux Mint, or could use my NUC which I think right now I have running Ubuntu 13.04.

A few more things to investigate:

  1. If I build an image and write it to an SD card, can I try it out (boot off of it) without it overwriting the EMMC?

  2. I am trying to learn ROS and convert my code of at least one of my robots to use it. I tried building it on my BBBk, but don’t think 2gb is enough storage to build even the minimal install from sources. Some options to look at:
    a) Is there some place to apt-get install from? I saw a posting for downloading on Angstrom and maybe Ubuntu… More to look at.
    b) Run off of SD card with more storage?

  3. Boot off of EMMC, but have more storage external. SD or USB thumb???

Sorry about the rambling, just thoughts about things for me to try out

Yes, it is working good for me. :slight_smile:

But after reading the happy new year message, I have also been wondering
that if the standard release will be Debian, should I try building my own
images from the links that were listed there for both the actual image and
kernel?

But if I do, should I stick with the 3.8 kernel? Or 3.12 or 3.13?

If you want 'full' cape support stick with 3.8.. If you are just using
usb/ethernet with simple capes* (usart/i2c/spi) use 3.13 (i'm working
on adding most capes to 3.13 at the moment..) ignore 3.12.. :wink:

My assumption is the build scripts assume I am running linux. Can dual boot
to this on my main dev machine to Linux Mint, or could use my NUC which I
think right now I have running Ubuntu 13.04.

The scripts assume linux, mostly tested on debian jessie, but works in ubuntu..

Note the "image-builder" works best native on arm hardware.. (qemu is
too bit rotten for 100% reliably between distro versions)

A few more things to investigate:
1) If I build an image and write it to an SD card, can I try it out (boot
off of it) without it overwriting the EMMC?

There will be a traditional "flasher" which will overwrite the eMMC
and a secondary "4gb img" which you can dump to your microSD and it'll
run on that.

2) I am trying to learn ROS and convert my code of at least one of my robots
to use it. I tried building it on my BBBk, but don't think 2gb is enough
storage to build even the minimal install from sources. Some options to
look at:
a) Is there some place to apt-get install from? I saw a posting for
downloading on Angstrom and maybe Ubuntu... More to look at.
b) Run off of SD card with more storage?
...

This is the most reliable.. (then you can usb for something else..)

3) Boot off of EMMC, but have more storage external. SD or USB thumb???

Sorry about the rambling, just thoughts about things for me to try out

Regards,

Robert, OK so maybe I am a bit slow on the uptake on this conversation, but does the fact that you’re trying to write in most / all capes indicate that device tree will not happen in 3.12/3.13 ?

If this is right, does this mean the “old style” will be re implemented ?

Oh it's device tree based... The 'old style' is gone forever... It's
just not 100% dynamic and endlessly configurable like 3.8 was...

Lets just call it dtb patching with a reboot...

Regards,

I supppose I will have to download one of your images and start poking around. Maybe I’ll be able to reverse it well enough to document some stuff.

Just start with wheezy:

http://elinux.org/BeagleBoardDebian#Debian_7_.28wheezy.29

install v3.13-rcX
wget http://rcn-ee.net/deb/wheezy-armhf/v3.13.0-rc7-bone3/install-me.sh
sudo /bin/bash install-me.sh

sudo reboot

then read up on:
https://github.com/RobertCNelson/rscm

Regards,

Will do, thanks Robert.

I also notice that SPI is missing from rscm ? Not a complain mind you, just an observation.

Oh SPI is enabled by default, see:

http://elinux.org/Basic_Proto_Cape

for the "default" setup..

It just doesn't like being patched in/out in my initial idea utilized
in that repo.. (aka it hard crashes)

Regards,