Difference between revisions of "BeagleBone Black"

From Klaus' wiki
Jump to: navigation, search
(45 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
Find below my experiences with the BeagleBone Black (BBB) revision 3.
 
Find below my experiences with the BeagleBone Black (BBB) revision 3.
  
==First Boot==
+
* At [[BBB First Boot]] you can read about the first boot of the BeagleBone Black
 
+
* Add a [[BBB New User]] on your BBB
First boot with BeagleBone Black is best done by using a serial communication program like CuteCom or Putty.
+
* Getting [[BBB Internet over the USB cable]]
 
+
* Set your [[BBB timezone]] to match your local timezone
Attach the USB connector to your PC and issue this command to find the tty-port that will be created:
+
* I talk about adding a WiFi adapter over at [[BBB WiFi]]
 
+
* Customising your prompt. Look over at [[BBB Customised prompt]]
<source lang="bash">
+
* The [https://yoctoproject.org Yocto Project] will enable you to build your own distribution for the BBB. See [[BBB Yocto Project]] for further details.
$ ls -lart /dev
+
* Cross compilations means that you develop software on one type of CPU architecture, e.g. Intel X86_64, for execution on another architecture, e.g. the ARM architecture. Se [[BBB Cross Compiler]] for more.
</source>
+
* Having developed a program on the laptop it would be nice to be able to execute it on the BBB and debug it. See [[BBB Remote Debugging]] for details about this.
 
+
* Enabling peripheral devices like the OneWire is relatively easy. See [[BBB and OneWire]] for further details.
<source lang="text">
+
* Thoughts on enabling PWM can be found over at [[BBB Enabling PWM]]
drwxr-xr-x.  2 root root            80 Aug 16 13:19 bsg
+
* Linux software is under constant update. If not the kernel, then other utilities are updated either to improve the existing functionality, to remove bugs or to give even more functionality. Jump to [[BBB New Debian Image]] if you would like to run on a new image.
crw-rw----.  1 root disk      21,  1 Aug 16 13:19 sg1
+
* Working on bren for development but debugging the BBB next to you is possible, see [[BBB Reverse SSH Tunnelling]]
drwxr-xr-x.  2 root root          3900 Aug 16 13:19 char
+
* Over at [[BBB Developing Device Drivers]] there are some words about device driver development.
drwxr-xr-x. 22 root root          3560 Aug 16 13:19 .
+
* [[BBB WebSockets]] are relatively easy to implement in a C or C++ program if you are in need of transporting data between the BBB and a web client.
brw-rw----.  1 root disk        8,  16 Aug 16 13:19 sdb
+
* Over at [[BBB Kernel Modules]] I discuss different aspects of extending the kernel by developing a specific device driver.
drwxr-xr-x.  6 root root          120 Aug 16 13:19 disk
+
* Real men don't backup! They occasionally cry. The rest of us makes regular backups. Take a look at [[BBB Backup your work]]
drwxr-xr-x.  2 root root          200 Aug 16 13:19 block
+
* A quite comprehensive C++ Library for the BBB is available over at [http://blacklib.yigityuce.com/index.html BlackLib]
crw-rw-rw-.  1 root dialout  166,  3 Aug 16 13:19 ttyACM3
+
* Using the PRU's? Take a look over at [[BBB PRU]]
crw-rw-rw-.  1 root tty        5,  0 Aug 16 13:20 tty
+
* Sometimes you don't need the HDMI, so you can [[Switch off the HDMI]] and thereby free a lot of IO pins for other purposes
crw-rw-rw-.  1 root tty        5,  2 Aug 16 13:21 ptmx
+
* [[Remote monitoring]] of ethernet traffic using Wireshark
</source>
+
* Realtime programming in C and Assembler is done in the [[CCS]]
 
+
The above list show the devices created when attaching the USB cable. The line of interest here is the '''ttyACM3''' - might differ on other systems.
+
 
+
Since normal users normally not are member of the '''dialout''' group the quickest way to gain access to the tty-port is to issue this command:
+
 
+
<source lang="bash">
+
$ sudo chmod o+rw /dev/ttyACM3
+
</source>
+
 
+
This will give a normal user access to the port.
+
 
+
Alternatively modify the /etc/group to allow the login to be member of the dialout group.
+
 
+
Now open the CuteCom or Putty port on a serial line using '''/dev/ttyACM3''' and '''115200 bps''' as settings.
+
 
+
An output like this can be seen:
+
 
+
<source lang="text">
+
Login timed out after 60 seconds.
+
 
+
\0x1b[r\0x1b[H\0x1b[J
+
 
+
Debian GNU/Linux 7 kolles-beaglebone ttyGS0
+
 
+
default username:password is [debian:temppwd]
+
 
+
Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian
+
 
+
The IP Address for usb0 is: 192.168.7.2
+
kolles-beaglebone login:
+
</source>
+
 
+
Now login using the defaults given.
+
 
+
Also try to issue
+
 
+
<source lang="bash">
+
$ ssh debian@192.168.7.2
+
</source>
+
 
+
This will open an '''ssh''' connection over the USB cable, which also supports networked traffic, to the BBB.
+
 
+
==Yocto Project==
+
 
+
The Yocto Project, see the [http://yoctoproject.org/ home page] for further details, can create a distribution for the BBB.
+
 
+
For instructions on how to build a personal Yocto Project Distribution see [[Yocto Project Build Instructions]].
+
 
+
===Creating the boot SD===
+
 
+
There are several methods to create a bootable SD card.
+
 
+
The easiest way is to use a graphical interface, e.g. '''gparted'''
+
 
+
[[Image:Gparted.png|500px]]
+
 
+
Create two partitions, one size 40, or more, megabytes for u-boot and one for the rest of the SD card - here 7+ GB.
+
 
+
Label the boot partition '''boot''' and the other partition '''root'''.
+
 
+
The boot partition shall be a primary partition of type FAT32 while the rest is a ext3 or ext4 file system. Format the partitions to the designated file system types and set the '''boot''' flag for the boot partition.
+
 
+
====Alternative method====
+
 
+
Here is an alternative method only using the console if no graphical environment is available:
+
 
+
<source lang="bash"> 
+
$ export DISK=/dev/sdc
+
$ umount ${DISK}1
+
#<<<Note the addition of the '1'
+
$ sudo dd if=/dev/zero of=${DISK} bs=512 count=20
+
$ sudo sfdisk --in-order --Linux --unit M ${DISK} <<-__EOF__
+
1,12,0xE,*
+
,,,-
+
__EOF__
+
$ sudo mkfs.vfat -F 16 ${DISK}1 -n boot
+
$ sudo mkfs.ext4 ${DISK}2 -L rootfs
+
</source>
+
 
+
Here's whats happening:
+
 
+
* Provided that the newly inserted SD card is /dev/sdc - could be another e.g. sdb depending on the disks in the PC - tell the rest of the script where the device is located (the DISK variable)
+
* unmount if automount mounted it
+
* dd is a very effective utility to create files and much more - here zeros is copied from /dev/zero (if=/dev/zero) to the disk (of=${DISK} i.e. /dev/sdc) with 512 bytes block size (bs=512) for 20 blocks (count=20)
+
* Next rather than calling the fdisk the sfdisk partition table manipulating program is used with a HERE script (the part from __EOF__ to __EOF__)
+
* With the partition the next is to make a file system with mkfs both vfat and ext4 file systems and at the same time labelling the partitions
+
 
+
===Transfer binaries to the SD card===
+
 
+
Mount the two SD card partitions. On some Linuxes it is easily done by removing the SD card and reinsert it and automount will automagically mount the disk partitions.  
+
 
+
From the Yocto Project distribution copy the ''MLO'' and the ''u-boot.img'' files to the boot partition.
+
 
+
In order to populate the root file system to the root partition untar the compressed root file system that bitbake produced.
+
 
+
<source lang="bash">
+
$ cd <the mounted root partition>
+
$ sudo tar xf <path to poky>/beaglebone/tmp/deploy/images/beaglebone/core-image-sato-beaglebone.tar.bz2 .
+
$ sync
+
</source>
+
 
+
This is what is happening:
+
 
+
* First change to the root partition on the SD card (on Fedora it is typically mounted /run/media/<username>/root)
+
* Then untar the compressed root file system from where bitbake built it (here it is the graphical core-image-sato distribution)
+
* Finally issue '''sync''' to let the kernel write everything to the SD card - when sync returns unmount the SD card.
+
 
+
===Windows and Mac users===
+
 
+
You will have to figure out from the descriptions above how to format and create the filesystems on the SD card and how to copy the files to the card.
+
 
+
==Booting the BBB with Yocto Project==
+
 
+
Insert the SD card into the slot for it on the BBB. Press and hold the button on top of the board near the SD card in order to boot from the SD (otherwise the BBB will boot from the built in eMMC). Apply power through the USB connector.
+
 
+
===Monitor the boot process===
+
 
+
Only if the u-boot causes problems a serial connection may be helpful, otherwise it is usually enough to wait until the USB interface becomes available in the boot process.
+
 
+
So if the u-boot messages should not be monitored, just connect the USB cable to the PC and start the favourite serial communication program, e.g. CuteCom, Putty or screen. Wait until the tty USB device becomes available. The USB interface will become available when the system is near the end of the boot process - and at that time the u-boot messages are long gone.
+
 
+
If, for some reason, the board won't boot, a serial cable need to be connected to the board. Get a PL2303 cable - or build one your self...
+
 
+
Connect the serial cable to the port to J1 as shown below.
+
 
+
[[Image:RPI_Serial.png]]
+
 
+
'''PL2303 USB to serial cable'''
+
 
+
  Board      Wire    Function
+
  Pin 1.....Black.....Ground
+
+
  Pin 4.....Green.....Receive
+
+
  Pin 5.....White....Transmit
+
  (Where pin 1 is the one near the white dot)
+
 
+
[[Image:Serial2BBB.png|500px]]
+
 
+
'''Connecting the pl2303 cable to the BeagleBone Black'''
+
 
+
====Stop u-boot====
+
 
+
Using a serial interface it is possible to monitor the boot process.
+
 
+
Here the command
+
 
+
<source lang="bash">
+
$ screen /dev/ttyUSB0 115200
+
</source>
+
 
+
is used to connect to the serial line (use Ctrl-a+k to kill the window). Putty or CuteCom can show the same.
+
 
+
Immediately after applying power and e-boot presents it self on the serial interface, hit any key on the keyboard to stop the boot process.
+
 
+
This is a typical output from the early boot process:
+
 
+
U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
+
reading args
+
spl_load_image_fat_os: error reading image args, err - -1
+
reading u-boot.img
+
reading u-boot.img
+
+
+
U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
+
+
I2C:  ready
+
DRAM:  512 MiB
+
NAND:  0 MiB
+
MMC:  OMAP SD/MMC: 0, OMAP SD/MMC: 1
+
*** Warning - readenv() failed, using default environment
+
+
Net:  <ethaddr> not set. Validating first E-fuse MAC
+
cpsw, usb_ether
+
Hit any key to stop autoboot:  0
+
U-Boot#
+
 
+
Here the u-boot has stopped and are awaiting a command.
+
 
+
==Enabling the DS18B20 thermometer==
+
 
+
The version of Debian that my board was supplied with uses the Flattened Device Tree in order to ease the access to GPIO's and other hardware. This are so for the most modern Linux distributions for the ARM processors. The reason for this is mainly because Linus Thorvalds did not want to include the large amount of device drivers for the ARM processor family in the kernel. Se more about the Flattened Device Tree (FDT) on [http://elinux.org/Device_Tree this] site.
+
 
+
From [http://www.hobrasoft.cz/en/blog/bravenec/beaglebone-black-ds1820 this] site I was inspired to set-up the correct dts file enabling the usage of GPIO pin 2 for the 1Wire interface.
+
 
+
Create a file name DS1820-00A0.dts with this content
+
 
+
<source lang=text>
+
/dts-v1/;
+
/plugin/;
+
 
+
/ {
+
    compatible = "ti,beaglebone", "ti,beaglebone-black";
+
    part-number = "DS1820";
+
    version = "00A0";
+
 
+
    exclusive-use = "P9.12";
+
 
+
    fragment@0 {
+
        target = <&am33xx_pinmux>;
+
        __overlay__ {
+
            ds1820_pins: pinmux_ds1820_pins {
+
                pinctrl-single,pins =  <0x78 0x37>;
+
            };
+
        };
+
    };
+
 
+
    fragment@1 {
+
        target = <&ocp>;
+
        __overlay__ {
+
            onewire@0 {
+
                status          = "okay";
+
                compatible      = "w1-gpio";
+
                pinctrl-names  = "default";
+
                pinctrl-0      = <&ds1820_pins>;
+
                gpios          = <&gpio2 28 0>;
+
            };
+
        };
+
    };
+
};
+
</source>
+
 
+
Compile the specification into a dtbo binary file
+
 
+
<source lang=bash>
+
dtc -O dtb -o /lib/firmware/DS1820-00A0.dtbo -b 0 -@ DS1820-00A0.dts
+
</source>
+
 
+
Finally in order to enable this part of the device tree perform at every boot this command
+
 
+
<source lang=bash>
+
echo DS1820 > /sys/devices/bone_capemgr.*/slots
+
</source>
+
 
+
The thermometer should now show up in the /sys/bus/w1/devices folder
+
 
+
drwxr-xr-x 2 root root 0 Jan  1  2000 .
+
drwxr-xr-x 4 root root 0 Jan  1  2000 ..
+
lrwxrwxrwx 1 root root 0 Feb 21 10:49 28-000005a7ce64 -> ../../../devices/w1_bus_master1/28-000005a7ce64
+
lrwxrwxrwx 1 root root 0 Feb 21 10:49 w1_bus_master1 -> ../../../devices/w1_bus_master1
+
 
+
the 28-00000nnnnnnn is the thermometer - they are all uniquely identified, so the n's will vary.
+
 
+
=== Test with Python===
+
To check that the thermometer work correct prepare this short test program in a file named test.py where you of course will adjust the thermometer ID to suit your set-up:
+
 
+
<source lang=python>
+
import time
+
 
+
w1="/sys/bus/w1/devices/28-000005a7ce64/w1_slave"
+
 
+
while True:
+
    raw = open(w1, "r").read()
+
    print "Temperature is "+str(float(raw.split("t=")[-1])/1000)+" degrees"
+
    time.sleep(1)
+
</source>
+
 
+
Execute the program
+
 
+
<source lang=bash>
+
python test.py
+
</source>
+
 
+
you should get something similar to this
+
 
+
root@klaus-BBB:~/ds18b20# python test.py
+
Temperature is 24.0 degrees
+
Temperature is 24.0 degrees
+
Temperature is 24.062 degrees
+
Temperature is 24.062 degrees
+
^CTraceback (most recent call last):
+
  File "test.py", line 8, in <module>
+
    time.sleep(1)
+
KeyboardInterrupt
+
root@klaus-BBB:~/ds18b20#
+
 
+
===Test using Bonescript===
+
 
+
This source first locates the attached thermometer and then uses it for temperature reading.
+
 
+
This code is only able to handle one thermometer at a time, or in fact only one 1-wire device at at time.
+
 
+
<source lang=javascript>
+
//
+
// Interface for the thermometer
+
// Author  : Klaus Kolle
+
// Date    : 2015 02 22
+
// Revision : 0.0.3
+
 
+
var b = require('bonescript');
+
var f = require('fs');
+
 
+
//console.log('Hello, Thermostate.');
+
 
+
var temperature;
+
 
+
// Read from the 1-wire thermometer
+
// The 28-00000nnnnnnn will change depending of the device connected
+
//
+
var oneWireDir;
+
 
+
locateThermometer();
+
 
+
function locateThermometer()
+
{
+
  var initialDir = '/sys/bus/w1/devices/';
+
  var regExpr = '28-00000';
+
  var dir = [];
+
  var i;
+
  // Get all files and directories in the dir
+
  var dirs = f.readdirSync(initialDir);
+
  // Did we gat anything - if not the cape manager is probably not initialised
+
  // with the dtbo compiled device tree
+
  if (dirs.length > 0)
+
  {
+
    for (i = 0; i < dirs.length; i++)
+
    {
+
      // Only select the directories matching the pattern
+
      if(dirs[i].match(regExpr))
+
      {
+
        dir.push (dirs[i]);
+
      }
+
    }
+
    // Currently the code only accepts one thermometer
+
    oneWireDir = initialDir + dir + "/w1_slave";
+
  }
+
}
+
 
+
function readTemp()
+
{
+
  // Callback function for the timer
+
  b.readTextFile(oneWireDir, printTemp);
+
}
+
 
+
// The 1-wire returs this when reading the device
+
// klaus@klaus-BBB:~$ cat /sys/bus/w1/devices/28-000005a7ce64/w1_slave
+
// a5 01 4b 46 7f ff 0b 10 f7 : crc=f7 YES
+
// a5 01 4b 46 7f ff 0b 10 f7 t=26312
+
// Therefore a split is needed. We need the string after the second =
+
 
+
function printTemp(x)
+
{
+
  // We receive the data i x
+
  if (x.data != '')
+
  {
+
    var stringToSplit = x.data;
+
    // Split at = - three resulting strings are returned
+
    var arrayOfStrings = stringToSplit.split('=');
+
    // We are only interesd in the last
+
    temperature = (arrayOfStrings[2]) / 1000;
+
    console.log("Temp: " + temperature);
+
  }
+
}
+
 
+
setInterval(readTemp, 5000);
+
</source>
+
 
+
Expect a readout like this
+
 
+
Temp: 24.687
+
Temp: 24.75
+
Temp: 24.75
+
Temp: 24.687
+
Temp: 24.75
+
Temp: 24.75
+
Temp: 24.75
+
Temp: 24.687
+
 
+
==Development on a PC host and remote debugging ==
+
 
+
A few things are needed in order to set-up development of programs, that shall execute on an ARM platform. You'll need a cross compiler - a compiler that can generate ARM executable code while the compiler is executed on the PC platform, which is typically a Intel X86_64 architecture.
+
 
+
===Cross Compiler===
+
 
+
The Fedora package system does not contain a suitable compiler for the ARMv7 processor.
+
 
+
Luckily Linaro, does maintain a toolchain suitable for us. At [http://releases.linaro.org/14.11/components/toolchain/binaries this] point you can find the newest binaries for your operating system. Go up the directory structure to discover if a newer compiler has been released.
+
 
+
The following is suited for [http://releases.linaro.org/14.11/components/toolchain/binaries/arm-linux-gnueabihf Fedora Linux] and other Linux'es as they are rather generic.
+
 
+
<source lang=bash>
+
]$ cd ~/Downloads
+
$] wget http://releases.linaro.org/14.11/components/toolchain/binaries/arm-linux-gnueabihf/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.tar.xz
+
</source>
+
 
+
which will download the newest version on the time of writing this.
+
 
+
I keep downloaded tools in the /opt directory rather than in the /usr/local or other places in the /usr tree.  
+
 
+
<source lang=bash>
+
]$ cd /opt
+
]$ mkdir toolchains
+
]$ cd toolchains
+
]$ tar Jxvf ~/Downloads/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.tar.xz
+
]$ ln -s gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf/ gnueabihf
+
]$ file gnueabihf/bin/arm-linux-gnueabihf-gcc
+
</source>
+
 
+
These commands will create a toolchains directory in /opt and unpack the downloaded binaries into a structure. A symbolic link '''gnueabihf''' is created. This link can later be changed if a newer version of the compiler and libraries are downloaded.
+
 
+
The last command is just for ensuring that you've got the correct package downloaded. Expect something like this:
+
 
+
[klaus@klaus-x230 bin]$ file arm-linux-gnueabihf-gcc
+
arm-linux-gnueabihf-gcc: '''ELF 64-bit LSB executable, x86-64''', version 1 (SYSV), dynamically linked, interpreter
+
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=71722376ff3af9eee5caf7bdfa2ecc350db0a590, not stripped
+
[klaus@klaus-x230 bin]$
+
 
+
===Develop a Cross Compiled Program===
+
 
+
Start Eclipse and create a new project:
+
 
+
[[File:RemoteDebugging.png | 400px]]
+
 
+
'''''Notice the settings for the Cross GCC'''''
+
 
+
On one of the next dialogues you have to specify what the prefix for the cross compiler tools are and where they resides.
+
 
+
[[File:RemoteDebugging1.png | 400px]]
+
 
+
In the project create a new C source file and fill in some "Hello World" stuff.
+
 
+
Save and compile (Ctrl+S, Ctrl+B).
+
 
+
In a console go to <path to your project>/Debug
+
 
+
<source lang=bash>
+
]$ file <your binary (project name)>
+
</source>
+
 
+
Expect something like this:
+
 
+
[klaus@klaus-x230 Debug]$ file TestRemoteDBG
+
TestRemoteDBG: '''ELF 32-bit LSB executable, ARM,''' EABI5 version 1 (SYSV), dynamically linked,
+
interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.16, BuildID[sha1]=e8baff7637d637533f3730021407ffdc6d4c314e, not stripped
+
[klaus@klaus-x230 Debug]$
+
 
+
This tells us that the compiler has produced ARM executable code.
+
 
+
===Remote Debugging===
+
 
+
In order to be able to debug remote the remote board needs a suitable '''gdbserver'''. There is one already onboard - or it can be downloaded using apt-get, but that one does not operate correct with the toolchain downloaded previously.
+
 
+
But luckily there is a suitable gdbserver included with the gnueabihf tools.
+
 
+
<source lang=bash>
+
]$ scp /opt/gnueabihf/bin/gdbserver <username>@<your BBB IP>:~/
+
</source>
+
 
+
If you set-up password-less login over SSH (see [http://klaus.ede.hih.au.dk/index.php/Linux_hints#Copy_your_credentials_to_a_remote_host this] page for details) your life will be much easier.
+
 
+
You can test your newly developed ARM program on your BBB.
+
 
+
<source lang=bash>
+
]$ scp <path to your project>/Debug/<yourbinary> <username>@<Your BBB IP address>:~
+
</source>
+
 
+
Log on to your BBB and try
+
 
+
<source lang=bash>
+
]$ ./<yourbinary>
+
</source>
+
 
+
and inspect the output.
+
 
+
Next thing is to set up remote debugging.
+
 
+
In Eclipse select the '''Run''' menu and select '''Debug Configurations'''
+
 
+
[[File:RemoteDebugging2.png | 500px]]
+
 
+
First mark the C/C++ Remote debugging and then click on the new button to the upper left corner of the dialogue.
+
 
+
You'll get a dialogue like this:
+
 
+
[[File:RemoteDebugging3.png|500px]]
+
 
+
Press the '''New''' button to the right of the ''Connection'' line.
+
 
+
This will open a dialogue for setting up the connection to the BBB. We'll use SSH.
+
 
+
[[File:RemoteDebugging4.png | 500px]]
+
 
+
You can use the local IP address or any other configured for the BBB.
+
 
+
[[File:RemoteDebugging5.png | 500px]]
+
 
+
Returning to the main Debug Configuration dialogue you'll see that the Connection now has been filled in with the details you just provided.
+
 
+
[[File:RemoteDebugging6.png | 500px]]
+
 
+
Next you'll have to specify the complete path of your program to execute on the BBB. The program will be sent over the SSH connection before launching the gdbserver - so any changes made on the development host will be reflected on the binary on the BBB.
+
 
+
Here I just placed the binary in my home directory, but it could be anywhere suitable.
+
 
+
[[File:RemoteDebugging7.png | 500px]]
+
 
+
Next thing to do is to click on the Debugger tab in the top of the dialogue. In this part of the settings you'll have to specify a complete path and name of the debugger - in this case we'll use the Linaro supplied residing in /opt/toolchains/gnueabihf
+
 
+
[[File:RemoteDebugging8.png | 500px]]
+
 
+
Also click on the '''Shared libraries''' tab and click '''Add''' and navigate to /opt/toolchains/gnueabihf/libc/lib and add that. This will remove some error messages during debugging.
+
 
+
[[File:RemoteDebugging16.png | 500px]]
+
 
+
Adjust the path to the gdbserver on the BBB.
+
 
+
[[File:RemoteDebugging15.png | 500 px]]
+
 
+
You are now ready to debug. Press the '''Debug''' button.
+
 
+
[[File:RemoteDebugging9.png | 500px]]
+
 
+
You're asked a password for your login on the BBB.
+
 
+
[[File:RemoteDebugging10.png | 500px]]
+
 
+
And the you're told what system you're debugging.
+
 
+
[[File:RemoteDebugging11.png | 500px]]
+
 
+
And finally the debugger launches the program that has been transfered to the remote BBB and the gdbserver is launched with the program a a parameter and you can debug you application just like any other application.
+
 
+
This set-up has been heavily inspired by [http://linuxembeded.blogspot.dk/ this site] and the video by D. Molloy at [https://www.youtube.com/watch?annotation_id=annotation_4233682927&feature=iv&src_vid=vFv_-ykLppo&v=hzZHcH5quow YouTube].
+
 
+
==Installing a new distribution==
+
 
+
Download from the [http://beagleboard.org/latest-images BeagleBoard.org] site or elsewhere a fresh image suitable for the BBB.
+
 
+
You will typically get a file named like this
+
bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz
+
Date and version number may vary.
+

Revision as of 15:01, 16 February 2018

Find below my experiences with the BeagleBone Black (BBB) revision 3.

  • At BBB First Boot you can read about the first boot of the BeagleBone Black
  • Add a BBB New User on your BBB
  • Getting BBB Internet over the USB cable
  • Set your BBB timezone to match your local timezone
  • I talk about adding a WiFi adapter over at BBB WiFi
  • Customising your prompt. Look over at BBB Customised prompt
  • The Yocto Project will enable you to build your own distribution for the BBB. See BBB Yocto Project for further details.
  • Cross compilations means that you develop software on one type of CPU architecture, e.g. Intel X86_64, for execution on another architecture, e.g. the ARM architecture. Se BBB Cross Compiler for more.
  • Having developed a program on the laptop it would be nice to be able to execute it on the BBB and debug it. See BBB Remote Debugging for details about this.
  • Enabling peripheral devices like the OneWire is relatively easy. See BBB and OneWire for further details.
  • Thoughts on enabling PWM can be found over at BBB Enabling PWM
  • Linux software is under constant update. If not the kernel, then other utilities are updated either to improve the existing functionality, to remove bugs or to give even more functionality. Jump to BBB New Debian Image if you would like to run on a new image.
  • Working on bren for development but debugging the BBB next to you is possible, see BBB Reverse SSH Tunnelling
  • Over at BBB Developing Device Drivers there are some words about device driver development.
  • BBB WebSockets are relatively easy to implement in a C or C++ program if you are in need of transporting data between the BBB and a web client.
  • Over at BBB Kernel Modules I discuss different aspects of extending the kernel by developing a specific device driver.
  • Real men don't backup! They occasionally cry. The rest of us makes regular backups. Take a look at BBB Backup your work
  • A quite comprehensive C++ Library for the BBB is available over at BlackLib
  • Using the PRU's? Take a look over at BBB PRU
  • Sometimes you don't need the HDMI, so you can Switch off the HDMI and thereby free a lot of IO pins for other purposes
  • Remote monitoring of ethernet traffic using Wireshark
  • Realtime programming in C and Assembler is done in the CCS