Here’s another diary entry.. Hence this is more for me when I later do a similar project and run in to the same head-aches. But maybe this will help someone else too.
After much pain updating a well-endowed development environment configured for a work project, I ran in to various annoyances getting CDT for Eclipse working with the Arduino Due under Ubuntu 14.04. Below’s my approximate notes on how I navigated this delightful shitshow.
Getting to the point of seeing this beautiful sight was
fucking horrific quite satisfying:
My environment would initially fail to compile an Arduino sketch, mainly throwing this:
"/bin/arm-none-eabi-g++" -c -g -Os -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -MMD -mcpu=cortex-m3 -mthumb -DF_CPU=84000000L -DARDUINO=10606 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON '-DUSB_MANUFACTURER="Arduino LLC"' '-DUSB_PRODUCT="Arduino Due"' "-I/home/dev/.arduinocdt/packages/arduino/hardware/sam/1.6.11/system/libsam" "-I/home/dev/.arduinocdt/packages/arduino/hardware/sam/1.6.11/system/CMSIS/CMSIS/Include/" "-I/home/dev/.arduinocdt/packages/arduino/hardware/sam/1.6.11/system/CMSIS/Device/ATMEL/" -I"/home/dev/.arduinocdt/packages/arduino/hardware/sam/1.6.11/cores/arduino" -I"/home/dev/.arduinocdt/packages/arduino/hardware/sam/1.6.11/variants/arduino_due_x" -MMD -MP -MF".ino.cpp.d" -MT".ino.cpp.o" -D__IN_ECLIPSE__=1 -x c++ "../.ino.cpp" -o ".ino.cpp.o" -Wall
/bin/sh: 1: /bin/arm-none-eabi-g++: not found
Much of the pain comes from missing environment variables that cause various crucial toolchain programs being called from paths they do not exist in. However just fixing the environment variables proved remarkably hard as I couldn’t get the changes to persist. I went so far as to find the actual files storing the variables and adding the ones I wanted by hand, but they still got nuked. So that’s probably a symptom of the real problem here, I only know a work-around:
This disgusting command puts a symlink to the bossac binary to the broken path it gets resolved to, which is /bossac.
sudo ln -s /home/shartkitten/.arduinocdt/packages/arduino/tools/bossac/1.6.1-arduino/bossac /
Similarly, this symlinks all the arm-none-eabi programs to the incorrect path they end up resolving to of /bin:
sudo ln -s /home/shartkitten/.arduinocdt/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-* /bin/
Now I can actually build and push to my Arduino Due from Eclipse. But this work-around is quite sketchy. I tried and tried and tried to get Eclipse to store updated environment variables so I didn’t have to hack it like this, but they never persisted. I imagine someone will eventually fix the actual bug, for now, I’m unstuck and moving on.
The environment variables I think need to be set are as follows:
A.RUNTIME.TOOLS.ARM-NONE-EABI-GCC.PATH = /home/shartkitten/.arduinocdt/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1
NOTE above I use a fictional home directory, you’ll have to alter the commands as you use them to use your actual path, unless you’re awesome enough to have a user actually named shartkitten.
Annnnd a money-shot:
After getting the tools working, I ran aground in another area. bossac would begin flashing my ARM chip, but would die at random points during the upload. I work with VMs and forward through USB devices. I’ve done plenty of very low-level work this way (lower-level than this for sure). It’s worked great, but I’ve always been aware it’s something extra to go wrong. Well today it struck. I decided to run up my development VM using VMware Fusion rather than the typical Virtual Box that I use (and yes, it was up to date). VMware Fusion handled the USB device fine and the uploads to the Arduino Due started actually working. NOOOow for my actual work to begin!