I’ve just handed off my BBBlue to a student team to interface it to SparkFun robot[1].
Where should I point them to get current information on the Blue? For example, what image should they be running?
Thanks…
–Mark
I’ve just handed off my BBBlue to a student team to interface it to SparkFun robot[1].
Where should I point them to get current information on the Blue? For example, what image should they be running?
We can discuss here, but be sensitive to the idea that no one else has one of these yet. Well, almost.
You can grab a fresh IoT image from https://builds.beagleboard.org or one of the snapshots from Robert under his testing directory. He and I discussed updating http://beagleboard.org/latest-images this coming Monday.
You should check out http://GitHub.com/StrawsonDesign/Robotics_Cape_Installer and http://strawsondesign.com for setup/API information.
Let us know how it goes. Take pictures, but hold them close to the vest until the public beta.
Start with Last sunday's iot image.. (this sunday's will be better)..
then follow:
https://github.com/StrawsonDesign/Robotics_Cape_Installer
Regards,
Hi, I am one of the students who was given the BBBlue to interface with the robot, We have the latest image on an SD card in the BBBlue, on boot the leds appear to go through the normal boot routine. However we are unable to interface with it in anyway. Initially we tried to connect with the usb network cable, however it was not recognized as even being attached by Ubuntu or windows, where as the black normally will show up as a device. So we tried to interface with UART0 which we assume is the debug serial port, and the only thing we read was nonsense, using the same serial config that we use to interface with the black. So we are unsure if we are missing something or if there is maybe a problem with the board
Hi, I am one of the students who was given the BBBlue to interface with the robot, We have the latest image on an SD card in the BBBlue, on boot the leds appear to go through the normal boot routine. However we are unable to interface with it in anyway.
I shipped it with a working image on the eMMC. Is that still intact?
Initially we tried to connect with the usb network cable, however it was not recognized as even being attached by Ubuntu or windows, where as the black normally will show up as a device. So we tried to interface with UART0 which we assume is the debug serial port, and the only thing we read was nonsense, using the same serial config that we use to interface with the black.
Did you use proper grounding? Did you configure as 115200 baud N81? I’ve been using the serial port without issue.
So we are unsure if we are missing something or if there is maybe a problem with the board
I’m guessing you are missing something. Can you try to more clearly document what you tried?
Hi, I am one of the students who was given the BBBlue to interface with
the robot, We have the latest image on an SD card in the BBBlue, on boot
the leds appear to go through the normal boot routine. However we are
unable to interface with it in anyway. Initially we tried to connect with
the usb network cable, however it was not recognized as even being attached
by Ubuntu or windows, where as the black normally will show up as a device.
So, the USB interface to ethernet or serial are known as g_ether, and
g_serial respectively. These are USB gadget "drivers". Which have to be
enabled in order to be used. It sounds as though perhaps these may not be
enabled by default at boot. Either way, have you all tried to connect to
the beaglebone via the ethernet port yet ?
So we tried to interface with UART0 which we assume is the debug serial
port, and the only thing we read was nonsense, using the same serial config
that we use to interface with the black. So we are unsure if we are missing
something or if there is maybe a problem with the board
This sounds like a serial device misconfiguration. What you describe is
exactly what happens when you have the wrong baud rate set on one end or
the other. As Jason just replied the configuration must be 115200 baud N81
on both ends. The Linux image you're using probably already has this set
correctly. So this is probably a client side terminal app misconfiguration.
The two serial application I know work on Windows is puTTY, and the paralax
terminal application( Sorry cant think of the name off hand ). I do
personally use puTTY regularly on Windows though. You may even have to go
into device manager and change the settings there. Make sure flow control
is turned off. Becasue Widnows seems to like XON and XOFF for default
control flow. Make sure the other settings here reflect those already
discuses as well. As I believe everything by default will be correct,
except baud rate: Widnows defaults to 9600, and flow control: Which Windows
defaults to XON/XOFF. Your mileage may vary.
Additionally, from Linux in a pinch you can run:
$ sudo cat /dev/ttyO0
And cat should be able to view serial output. Assuming you have the baud
rate set correctly for this device. Or . . . if you're unsure where the
configuration is, or how to set that up. You can run screen like so:
$ sudo screen /dev/ttyO0 115200
The rest of the parameters should default too the correct values.
As with Windows, I have personally used both these Linux utilities, and I
do know they work. However, with screen or cat, eventually line breaks will
start to be recognized in the wrong part of the serial output. Making the
output slight harder to "parse". Visually, or programmatically.
Sorry I sort of mixed up my explanation a little.
So if you’re connecting to the serial debug port on the beaglebone to a Linux host machine. The beaglebone side interface would be /dev/ttyO0, where on the host computer side the serial interface would show up as something similar to /dev/ttyUSB0 or /dev/ttyACM0.
It depends on which serial to USB device you're using. Here, I use a PL2303hx based serial to USB cable, and that shows up as /dev/ttyUSB0.
Hello,
I am the other student working on the project. Thanks for the help you all have given. We were embarrassed to find out last Thursday that the USB cable we were using was off-spec and had no data wires so we were getting power but no communication.
I had no idea such cables existed but it’s something one should check for in the debugging process.
On the issue of the terminal connection on UART 1: I can connect to the beaglebone black using uart0 on the debug header, but we have had no such luck with the blue. This is less pressing to us now that we can communicate with the board but we will post when we get to solving that problem.
Id, double check and document everything when trying ot setup the serial debug port on the Beaglebone blue. Which to me going form pictures on the internet. Just seems to be another beaglebone, but with a blue PCB. In other words. It appears to be very similar to if not exactly the same as a beaglebone black, with a blue PCB, and a Robotics cape included with it.
However, with that said. There are typically “hooks” built into these images that check the eeprom to see which board it is. When uboot first comes up, before passing control to Linux.
So, being verbose on the groups here, for this problem, would be helpful.
On Mon, 24 Oct 2016 12:02:42 -0700 (PDT), Samuel Lawrence
<samuellawrence94@gmail.com> declaimed the
following:
I had no idea such cables existed but it's something one should check for
in the debugging process.
Sometimes found in "generic" USB phone charger kits. I have an old one
-- but it does have a sticker at one end that reads "charge only cable"
Id, double check and document everything when trying ot setup the serial debug port on the Beaglebone blue. Which to me going form pictures on the internet. Just seems to be another beaglebone, but with a blue PCB. In other words. It appears to be very similar to if not exactly the same as a beaglebone black, with a blue PCB, and a Robotics cape included with it.
Those were the prototypes, the actual BeagleBone Blue is at http://github.com/jadonk/beaglebone-blue
These students have a rev A1a board. We’ve tried to avoid getting pictures out on the Internet as that fosters stories that fosters questions that we aren’t ready to answer. Keeping questions to technical functionality is good for discussion here.