AttoDuino, Arduino 1.6.x and Linux

Last year I crowdfunded an interesting project called AttoDuino. The project itself calls it “Arduino on steroids” and its Texas Instruments ARM® Cortex®-M4F processor, which includes a math coprocessor that runs at 80 MHz. The AttoDuino is completely wireless, with built-in bluetooth, and can be programmed via bluetooth as well.


With some delays it was only delivered this week and following the instructions from their website I found out that with the recent Arduino IDE changes, it’s not recognised as a third party hardware anymore and that there wasn’t a Linux version of the tools included.

It’d been a very long time since I spent time into setting up a cross compiling chain and I’d never before done any modifications to Arduino software, but I thought to give it a try. AttoDuino and its computing power could prove to be a solution to a hardware project of mine and if not, at least I could learn something.

New 3rd party hardware specification

The first issue, i.e. getting AttoDuino recognised by the Arduino IDE, was rather easy. A small search on the internet showed that now the hardware architecture is addressed with subdirectories. The original structure was:

        +-- cores/
        +-- libraries/
        +-- system/
        +-- tools/
        +-- variants/
        +-- boards.txt
        +-- platform.txt
        +-- programmers.txt

Creating a directory called cortex-m4 and moving all files there is the next step:

        +-- cortex-m4/
                      +-- cores/
                      +-- libraries/
                      +-- system/
                      +-- tools/
                      +-- variants/
                      +-- boards.txt
                      +-- platform.txt
                      +-- programmers.txt

The file boards.txt needs also some editing, as a Linux section is missing completely and some new variables were introduced to it.  Please note that the usage of runtime.hardware.path instead of runtime.ide.path is needed if the attoDuino directory is copied into Sketchbook’s hardware directory, which is the preferred way, IMHO:

# uses the linker with the x2800 program offset
# uses linux version of the g++
############################################################## Pro BT (linux)
#atto need to find actual max size (minus bootloader)

Adding Linux tools

The second last line of the file boards.txt already shows where the Linux tools will be expected. As for the other operating systems, the directory lm4f-linux must be created within tools :

     +-- lm4f-linux/

I searched the internet for suitable tools but wasn’t lucky enough to find already compiled ones, so I extended my search to generic cross compiling chains. As it seems, there’s an Ubuntu package called gcc-arm-embedded, where ARM developers contribute and which seems most up-to-date. Some further research unearthed this blog post: Building gcc-arm-embedded on openSUSE 13.1. That’s where my work is based on. Some of the instructions there seem to be outdated. There isn’t a file to patch zlib and instead of patching the shell script, creating documentation can be prevented by using the option


Building gcc-arm-embedded

Before anything else, some development packages of the used Linux distribution should be installed: autoconf, m4, automake, libtool, patch, make, makeinfo, flex, bison, termcap, ncurses-devel, mpfr-devel, gmp-devel, mpc-devel, gcc-c++ and python-gdbm. Errors during compilation may be related to missing packages.

From a temporary directory, download the most recent sources from gcc-arm-embedded. At the time of writing this, the appropriate link was After downloading the tarball, run

tar -xvjf gcc-arm-none-eabi-4_9-2015q1-20150306-src.tar.bz2
cd gcc-arm-none-eabi-4_9-2015q1-20150306/src
find . -name "*tar.bz2*" -print | xargs -I% tar -xvjf %
find . -name "*tar.gz*" -print | xargs -I% tar -xvf %

to unpack all the needed sources. Then move one directory level up and run the following scripts, which will not create any Windows binaries or any documentation. I also disabled Python support for GDB because the compilation kept running into an error, which I couldn’t get rid off. Depending on the computer, this will take some time:

./ --skip_steps=mingw32 2>&1 | tee log.prereq
./ --skip_steps=mingw32,manual,gdb-with-python 2>&1 | tee log.toolchain

Assuming that all needed packages were in place and no errors occured, the Linux tools we need can be found in the directory install-native:

                          +-- install-native/
                                          +-- arm-none-eabi/
                                          +-- bin/
                                          +-- lib/
                                          +-- share/

The 4 directories arm-none-eabi, bin, lib and share are the ones that should be copied into AttoDuino’s tools directory:

cd install-native
cp -r *  /path/to/arduino/hardware/attoDuino/cortex-m4/tools/lm4f-linux/.

Additional modifications

With everything in its place, trying to compile the AttoDuino example sketch results to this error:

stdlib.h:184:8: error: conflicting declaration of C function 'char* utoa(unsigned int, char*, int)'
char * _EXFUN(utoa,(unsigned, char *, int));

As it seems, the funtions utoa and itoa are already defined in stdlib.h and therefore I commented the 2 lines defining itoa and utoa in attoDuino/cortex-m4/cores/lm4f/itoa.h out:


//extern char* itoa( int value, char *string, int radix ) ;
extern char* ltoa( long value, char *string, int radix ) ;
//extern char* utoa( unsigned long value, char *string, int radix ) ;
extern char* ultoa( unsigned long value, char *string, int radix ) ;
#endif /* 0 */

Now the example code should compile within the Arduino IDE.  The next step is to compile the flashing tool and edit the platform.txt for its usage.

 Compiling and setting sflash

This is quite easy. Just copy the directory sflash-mac to sflash-linux, change into that directory and run the following commands:

rm a.out
rm sflash
rm *.o
rm Makefile
gcc *.c -o sflash

Issuing ./sflash --help should return

Usage: sflash filename -p [program address] -r [execution address]
    -c [tty] -d -l [Boot Loader filename] -b [baud rate]
    -s [data size]

-p [program address]:
    if address is not specified it is assumed to be 0x00000000
    if there is no 0x prefix is added then the address is assumed to be 
    in decimal
-r [execution address]:
    if address is not specified then no run command will be sent.
-c [tty]:
    This is the name of the TTY device to use.
-l [Boot Loader filename]:
    This specifies a boot loader binary that will be loaded to the device
    before downloading the application specified by the filename parameter.
-b [baud rate]:
    Specifies the baud rate in decimal.
-d  Disable Auto-Baud support
-s [data size]:
    Specifies the number of data bytes to be sent in each data packet.  Must
    be a multiple of 4 between 4 and 252 (inclusive).

    Example: Download test.bin using COM 1 to address 0x800 and run at 0x820
        sflash test.bin -p 0x800 -r 0x820 -c 1

Now edit platform.txt to look like this:




tools.sflashlinux.upload.pattern="{cmd.path}" "{build.path}/{build.project_name}.bin" -p 0x2800 -c {serial.port} -b {upload.speed} -d -s 220
#tools.sflashmac.upload.pattern="{cmd.path}" "{build.path}/{build.project_name}.bin" -p 0x2800 -c {serial.port} -b {upload.speed} -d -s 220
#tools.sflashwin.upload.pattern="{cmd.path}" "{build.path}/{build.project_name}.bin" -p 0x2800 -c {serial.port} -b {upload.speed} -d -s 220

I couldn’t find out (yet) how to prevent the IDE to try the mac version of sflash and ended up commenting out the last 2 lines.

Connecting via Bluetooth

Right now my Thinkpad W510 sees AttoDuino and I was able to pair it multiple times. Unfortunately the connection drops after a few seconds. I can’t tell what the reason is but a recently bought Bluetooth dongle did not work, neither did 2 different Laptops using Linux.

AttoDuino confirmed that the used BT module is a BT33  made by Amp’ed RF Wireless Technology. Given the issues that mac users have when they try to connect with AttoDuino, I suspect that BT33 does not work well with *nix-flavored OS.

Experimenting with Windows

I have VMWare Workstation 11.1.0 with and Win7 OS installed on my laptop and after I unchecked “Share Bluetooth devices with the virtual machine” in VM->Settings->USB Controller, I could pair AttoDuino. It shows up as a headset, but activates 2 virtual COM ports. COM3 is an outbound device and named “attoradio292 ‘AMP-SPP’. This was also the one I tried with success after I installed Arduino IDE 1.5.8 and the needed software as described here: AttoDuino Getting started.

As it seems, everything works fine when using Windows. I compiled and flashed the sample. For my further research, I flashed the following small sketch, which prints once a second the voltage of the battery on the serial port via Bluetooth and blinks the red LED:

#include <AttoDuino.h>

#define PR(x) Serial.print(x)

void setup() {}

void testAnalogIn() {
  // set A11 as analog input
  pinMode(11, INPUT);

  // note, can use either "A0" or just "0" to refer to a pin
  PR( "BATT: " ); PR( 2.0 * analogReadVolts( A11 ) ); PR( "\n" );
  digitalWrite( RED_LED, 1);
  delay( 1000 );
  digitalWrite( RED_LED, 0);

void loop() {

Experimenting with Linux

Using bluetoothctl helps to find more information about what is happening. As  I already could see with KDE’s Bluetooth applet, the device is paired and only connected for a short period:

#:~$ bluetoothctl 
[NEW] Controller 00:27:13:F4:09:3A [default]
[NEW] Device 00:04:3E:08:7B:69 attoradio292
[bluetooth]# paired-devices
Dev[bluetooth]# info 00:04:3E:08:7B:69
Device 00:04:3E:08:7B:69
        Name: attoradio292
        Alias: attoradio292
        Class: 0x240404
        Icon: audio-card
        Paired: yes
        Trusted: yes
        Blocked: no
        Connected: no
        LegacyPairing: no
        UUID: Vendor specific           (00000000-deca-fade-deca-deafdecacaff)
        UUID: Serial Port               (00001101-0000-1000-8000-00805f9b34fb)
[bluetooth]# connect 00:04:3E:08:7B:69
Attempting to connect to 00:04:3E:08:7B:69
[CHG] Device 00:04:3E:08:7B:69 Connected: yes
Failed to connect: org.bluez.Error.NotAvailable
[CHG] Device 00:04:3E:08:7B:69 Connected: noice 00:04:3E:08:7B:69 attoradio292

Running sdptool search SP shows that Attoduino sends information about its serial port:

#: sdptool search SP
Inquiring ...
Searching for SP on 00:04:3E:08:7B:69 ...
Service Name: AMP-SPP
Service RecHandle: 0x10000
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1

If I use rfcomm then I can create a serial port, but still I can’t upload a sketch. Whether sflash or the BT stack is the issue, I can’t tell yet:

#:rfcomm bind rfcomm0 00:04:3E:08:7B:69
#:/etc # ls /dev/rfcomm0

I can select that serial port in Arduino IDE but uploading fails with:
        at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(
Caused by: upload.pattern
        at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(
        ... 6 more

Compile and send the example sketch

This will have to wait until I manage to establish a reliable connection between my laptop and AttoDuino.