GNU/Linux related material

The purpose of this page is to give some information on how to use the Dresden Elektronik radio/MCU modules with GNU/Linux (and probably also other Unix-like operating systems) by using open source software.

---

Toolchain

AVR

The AVR toolchain consists of following components:

• avr-binutils: linker, assembler, etc for the AVR platform
• avr-gcc: the GNU C cross-compiler for the AVR platform
• avr-libc: C libraries and header files for the AVR platform
• avrdude: for uploading the code to the chip

Using the Toolchain

The following command are used to compile and upload the files to the board (it is assumed that the C file to be compiled is called main.c). Also, a makefile can be used.

# Compile
avr-gcc -mmcu=atmega256rfr2 -Os main.c -o main.o
# Make the hex file
avr-objcopy -j .text -j .data -O ihex main.o main.hex
# Upload the code
avrdude -c dragon_jtag -p atmega256rfr2 -u -U flash:w:main.hex

Important: it may be necessary to upload the code as root (su, sudo) as the regular users do not have the rights in most linux systems by default.

Patching and Compiling the Toolchain

Apparently, as of October 2014 the ATmega256RFR2 microcontroller used in the lab is too new, so the packages of the toolchain in the default Linux repositories do not support it, which means that the toolchain needs to be at leas partially manually patched and compiled.

A general information about this can be found in this page.

However, it does not apply completely to the newest version of the toolkit and at least on Arch Linux, not all of packages had to be manually compiled, on other distributions, the mileage may vary.

Next, the information will be given on how test all the parts for the support of the ATmega256RFR2 and how to install the version that does support the chip.

Also, it should be kept in mind that, as the different parts of the toolchain depend on each other, so they should be installed in exactly the following order.

avr-binutils

Testing:

avr-as --help | grep -i rfr2

If the text returned contains "atmega256rfr2", avr-binutils has the ATmega256RFR2 support.

Installing:

The version in Arch Linux's repos already has the support (version 2.24-2). In case the version in your distros repos does not have the support, you should compile and install the newest version. Instructions are provided in the "general instructions" link above.

avr-gcc

Testing:

avr-gcc -mmcu=atmega256rfr2

It should not complain about an unknown MCU type

Installing:

The latest version of arv-gcc (at the moment of writing 4.9.1-1) does not have ATmega256RFR2, so it needs to be manually patched. The general process on how to do it is the same as in the "general instructions" link above, but in that document the older version of avr-gcc is used.

However, if newer a version is desired, the patch provided on the web page will not work, as the structure of the source file to be patched is modified. I made an upgraded patch file, based on the one in the general instructions link, that works with version 4.9.1-1, maybe also with newer ones. It can be downloaded from here.

It is possible to find and download the newest avr-gcc from here.

avr-libc

Testing:

Try to compile some of the Dresden's examples (using the commands specified above, the makefiles do not work correctly, as they are for another chip). The compiling process should end successfully and the compiler should not complain about any missing libraries or header files (especially ones with atmega256rfr2 in their name, such as atmega256rfr2.h)

Installing:

At the time of writing, the version in Arch Linux's repos does not work with the ATmega256RFR2, however, the SVN version does. You can get the latest SVN version using the following command:

svn co svn://svn.sv.gnu.org/avr-libc/trunk/avr-libc

The compiling / installing instructions can be found either in the "general instructions" link above or in the source folder in INSTALL file. No patching is needed.89

Also it should be noted that even if the avr-libc package in your distro's repos has the support, it may still be necessary to build it from source, as usually avr-libc depends on avr-gcc. Because avr-gcc was not installed using the package manager, or may not have the correct name / version / etc, the dependency resolution will probably fail and package manager will either give an error message or start installing the avr-gcc version found in the repos, which is unwanted.

avrdude

Testing:

avrdude -c stk500 -p atmega256rfr2

The command should not return any kind of error message saying that the device is not supported

Installing:

The version in Arch Linux's repos already has the support (version 6.1-1). In case the version in your distros repos does not have the support, you should compile and install the newest version. Instructions are provided in the "general instructions" link above.

ARM

TBD

Getting deNode's/deGateway's UART to USB to work on Linux

Dresden Elektronik's deNode and deGateway boards have a built-in FTDI chip that enables users to access the UART port on the MCU via the USB. It can be used for either debugging or some low-speed communication between a computer and the board.

Unfortunately this feature does not work out of the box in Linux and requires some configuration. There is some information about this on Dresden's website, but this does not work on kernel versions that are newer than 3.11.

For Linux systems with kernel 3.12 and newer the following procedure has to be used:

• Remove the FTDI module from memory

rmmod ftdi-sio

• Create the following file with some udev rules:

/etc/udev/rules.d/99-ftdi.rules

• The contents of the file:

ACTION=="add", ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="001d", RUN+="/sbin/modprobe ftdi_sio" RUN+="/bin/sh -c 'echo 1cf1 001d > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"

What it does is that it basically automatically adds the device's vendor and product ID codes into the known list of the FTDI driver every time the board is detected. It should work also with other Dresden's devices that are listed in the link provided above, it is just needed to substitute the ID-s with correct ones, although this is not tested.

• Restart the FTDI module

modprobe ftdi-sio

• (Re)plug the USB cable. Now it should create a new virtual usb port, usually /dev/ttyUSB#, where # represents an integer. The exact name of the port can be found using the dmesg command after plugging in the board.