I’ve recently bought a Beaglebone Black (BBB) and an RS232 cape (BB-BONE-SERL-03). Mine is revision A1 (important to know which, see later).
At the time of writing this and at the time I bought it, I did not realise that the cape was not yet supported in the Angstrom release. Because of the move to kernel 3.8, the majority of capes available need some software modifications to get them working. A list of compatible capes can be found here.
What follows is a summary of how I got the RS232 cape working, my trial and error can be found, if desired, here.
I started by following the instructions found here with modifications to suit my requirements. We want to create a device tree overlay which will be automatically loaded by the system when it detects the cape is attached.
We need to create a compiled device tree blob object file so first we have to create a device tree source file as follows:
Connect to your bone via ssh (ssh email@example.com) and then create a file called BB-BONE-SERL.dts (I find nano easy to use on the bone).
Put in the following code:
Differences between my code here and the original instructions:
- I am using uart1 instead of uart5 (I got pin conflicts when trying uart5 because I have an LCD3 cape attached)
- I have therefore changed the addresses of the pins (0x0180 and 0x0184)
- and changed the MODEs of the pins since accessing uart1 needs MODE0
- by default, the OS will assign ttyO0 for uart1 but this is already used (not entirely sure why, tty0 is console but what it ttyO0 ?) so in order to force the OS to use ttyO1, I have lied in the fragment above to say we are using uart2
After saving that file, we compile it using the device tree compiler (comes pre-installed in the Angstrom image).
dtc -O dtb -o BB-BONE-SERL-03-00A1.dtbo -b 0 -@ BB-BONE-SERL.dts
Notice the file name of the compiled device tree blob object! – If this is to be automatically loaded by the OS when it detects the cape, the name is very important. It needs to start with BB-BONE-SERL-03 since that is what is in the EEPROM for the RS232 cape and then it also needs to include the version number of the cape (in my case A1) hence -00A1.dtbo (if you have a cape of a different version then change this).
Assuming that compiles ok then you will have a binary file called BB-BONE-SERL-03-00A1.dtbo which need to be copied to the /lib/firmware directory so it can be found on boot.
cp BB-BONE-SERL-03-00A1.dtbo /lib/firmware
Assuming all that has gone ok, reboot
If you then run dmesg and have a look through, you should find something like:
I have not yet figured out what the error: -19 message is but the subsequent line says that it has assigned ttyO1 to UART1
If you then run:
you should see that the cape is assigned to a slot (slot1 in my case). I also have an LCD3 cape so I get:
Notice that the EMMC and HDMI are in slots 4 and 5 – these are virtual capes on the BBB and can be disabled if the pins are required for othhr things.
If you also run:
you should get:
and if you do:
ls -al /dev/ttyO*
you should get
You can then try sending characters from the BBB to CuteCom (or another terminal) – by default use 9600 baud, 8 data bits, 1 stop bit and no parity. Remember to move the jumpers on the cape to position uart1 (by default they are uart2).
echo hello > /dev/ttyO1
And you can check that you can receive characters from CuteCom if you simply cat the serial port as follows:
I hope this helps someone else out – I also have an RS485 cape which should work with a few simple modifications to this procedure (see edit below).
EDIT: David Anders kindly pointed out that the two control lines (DriveEnable and ReceiveEnable) that the RS485 cape requires are used by one of the virtual capes (specifically the eMMC virtual cape) so that virtual cape will need to be disabled first – i.e. it will be necessary to boot from an external SD card.