Arduino on CentOS-6

I decided it was high time that I found a way to turn on my new TV automatically. After much research I decided that an arduino based IR Blaster was the way to go. I happen to have a Freetronics LeoStick which was given out a LCA in Ballarat a few years ago.

I recall at the time I could not get the arduino software to work on Linux (CentOS-5) so I resorted to using a Windows VM with USB passthru.

That was not going to cut it this time. I was going to use my full stubbornness to get it working on CentOS-6.

First of all, I had to get a copy of the IDE in RPM format. There was talk on the internet about just such a thing but I could not find an EL6 version. In the end I selected the Fedora 19 version which is suitable. The files needed are:

• arduino-1.0.5-6.fc19.noarch.rpm
• arduino-doc-1.0.5-6.fc19.noarch.rpm
• arduino-core-1.0.5-6.fc19.noarch.rpm

There are also a number of other dependancies because the IDE does not actually do much. Luckily the other bits are all in CentOS-6 or EPEL so using yum you can get it installed without too much trouble.

Running the IDE however is rigged with rubbish about adding your user account to certain groups. This seems antiquated to me and I refuse to do it. There must be a better way.

An ideal solution would be that the USB devices are assigned to the console owner and it would just work like any other peripheral. The way to implement that changes with every version of RHEL/CentOS but after some sleuthing, I found the answer for version 6 and it is no too difficult.

To get this working there are four jobs:

• Make sure the USB device ID is known to the USB TTY driver
• Set the appropriate permissions with udev
• Remove the restrictions on locking the device
• Configure the IDE

The first job is not immediately obvious and may not be applicable on all versions of Linux. On CentOS-6 (6.5) is was necessary. As if by magic or just infuriating design, the USB device ID of your arduino can change depending on what it is doing. This can be exploited for good, say if you wanted to build a USB keyboard or mouse but if you are using the default serial emulation then it seems unnecessary. For me, the default id used by the boot loader (26ba:0002) is automatically recognised as a serial device and /dev/ttyACM0 is created (by the cdc_acm driver) but when my sketch is running, the id (26ba:8002) is not recognised. This means the device goes away which confuses the arduino tools (and me). This is easily fixed by running this command as root:
echo "0x26ba 0x8002" >> /sys/bus/usb/drivers/cdc_acm/new_id
For your board, the IDs may well be different so you much check with dmesg or lsusb.

This needs to be done after every reboot so it should be added to an init script
modprobe cdc_acm
echo "0x26ba 0x8002" >> /sys/bus/usb/drivers/cdc_acm/new_id
TODO: is there is proper place for this? modprobe.conf? /etc/sysconfig/modules/arduino? For now, /etc/rc.d/rc.local will do.

Device permissions on CentOS-6 are managed by udev. Most devices use the traditional user, group and permissions. However, devices which are shared (for example, with console users) are managed using ACLs. (check with ls -l /dev/ | grep +).

In order to set the permissions, the correct devices must be identified. For me, the device name is /dev/ttyACM0 but this does not hang round for long (remember about the changing ids?). It is only present while the arduino bootloader is running. dmesg can give you a hint but the easiest way to check the device name is the plug in the stick and immediately run ls -l /dev/tty*

Once you know the device name you can interigate it with udev
udevadm info -a -n /dev/ttyACM0
Again you must run this immediatly after plugging in the USB stick.
It will output many properties of the device from which you must find something unique. At first I though that 'ATTRS{manufacturer}=="Freetronics"' was a good value to check for but it turns out that when your sketch is running, that string is not present. Better is to use the USB vendor ID 'ATTRS{idVendor}=="26ba"'.  While I was at it, I also added the Arduino vendor code of 20a0. I could then make a new udev rule by creating the file:
/etc/udev/rules.d/52-arduino.rules
and adding the contents:
ATTRS{idVendor}=="26ba", ENV{ACL_MANAGE}="1"ATTRS{idVendor}=="20a0", ENV{ACL_MANAGE}="1"

Some sources also recommend preventing the Modem Manager from probing the device. You can do that by adding this line too

ATTRS{idVendor}=="26ba", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="20a0", ENV{ID_MM_DEVICE_IGNORE}="1"
Once the file is in place, you can force the rules to be applies with the command
udevadm trigger

Now check the device with ls -l again (immediately after plugging in the stick) and it should look like this (with a + sign)
crw-rw----+ 1 root dialout 166, 0 Apr 24 23:08 /dev/ttyACM0

If so, check the ACL with  getfacl /dev/ttyACM0
getfacl: Removing leading '/' from absolute path names
# file: dev/ttyACM0
# owner: root
# group: dialout
user::rw-
user:jnewbigin:rw-
group::rw-
mask::rw-
other::---

Note that my username jnewbigin is granted access. You should of course see your username there. If so, job done.

The next headache is device locking. The default rxtx library wants to write to a directory it does not have permissions on. Fixing this was painful. All I wanted was a simple way to skip the locking phase in the rxtx library. I had hoped that there would be an environment variable which could tune the locking. According to the documentation, the only way to turn locking off is by recompiling. Luckily the srpm is easily modified. You can download my lock free version of rxtx from http://www.chrysocome.net/download

Almost done. I would have though that configuring the IDE should not be required but as it happens, you must edit ~/.arduino/preferences.txt and change
serial.port=/dev/ttyACM0

So now we have removed the requirements to add your user into the unnecessary groups. The script which runs the IDE (arduino) however still complains that you are not a member. The best solution would be to rebuild the rpm without that check (and add in the udev rules) but for now you can either select Ignore or edit /usr/bin/arduino and change the line
for group in dialout lock; do
to
for group in ; do

Perhaps I will repackage it with these changes.


And stay tuned for the working IR blaster code!