The Contiki build system depends on some GNU utilities that are not installed. Using the following steps I was able to compile for the “native” (i.a. Mac OS) target:

1. Install GNU binutils using MacPorts.
2. Edit “cpu/native/Makefile.native” and adjust the “Compiler Definitions” section like this:
   
### Compiler definitions
CC = gcc
LD = gcc
AS = as
NM = nm
# Use GNU ar instead of /usr/bin/ar
AR = gar
OBJCOPY = objcopy
STRIP = strip
ifdef WERROR
CFLAGSWERROR=-Werror -pedantic -std=c99 -Werror
endif
CFLAGSNO = -Wall -g -I/usr/local/include $(CFLAGSWERROR)
CFLAGS += $(CFLAGSNO) -D_XOPEN_SOURCE=500 -O
# Simplify ld arguments
#LDFLAGS = -Wl,-Map=contiki-$(TARGET).map,-export-dynamic
LDFLAGS = -Wl


Another issue is the ELF binaries for the AVR Raven boards. These files contain all components of the programs: flash and eeprom
images as well as fuse settings. Unfortunately, avrdude cannot read the ELF format. So you have to extract the flash manually:


$ avr-objcopy -R .eeprom -R .fuse -R .signature -O ihex $NAME.elf $NAME.hex


It works similar for the EEPROM section (where the IP data is stored):

$ avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex webserver6.elf webserver6.eep


You can also check which fuse settings are used:

$ avr-objdump -d -S -j .fuse webserver6.elf
webserver6.elf: file format elf32-avr
Disassembly of section .fuse:
00820000 <__fuse>:
820000: e2 99 ff


The directory structure of Contiki is somewhat overwhelming. I am currently working in these directories:

1. contiki-2.4/platform/avr-ravenlcd: This is where the code for the ATMega3290p lives. Run make here and upload.
2. contiki-2.4/platform/avr-raven: The ATMega1284p code lives here, this is where most patches are. Don’t run make here!
3. contiki-2.4/examples/webserver-ipv6-raven: Run make here for the ATMega1284p code. This builds the webserver code and includes the platform/avr-raven dir.

In addition, I have a serial terminal for debugging output:
screen -U /dev/cu.SLAB_USBtoUART 57600

I live close to the DCF77 radio transmitter, so my signal was always pretty strong and clear. This is of course not the case for everybody :-) Gwen Roelants did run into problems. He writes:

Although your code works (thanks for that!) it looked like it was very sensitive to how the antenna was positioned.
I found that I did receive a signal every second, but that for the longer signals, I sometimes got a short flash interrupting it, causing the library to add 2 seconds instead of one. Since I got such a flash in almost every minute it could take a very long time before a proper sync was found, and because 2 seconds were counted the time would also drift during the time no new signal could be decoded.
I found a rather simple fix for your code that greatly improved the reliability and time to find a correct signal.

I don’t have an Arduino around so I did not test it, but the proposed changes seem to be reasonable. You can find the changes in the Arduino forums. Thanks, Gwen!

The photo was CCed on flickr by Nathan Gibbs.

I just released a new version of USBTemp. This one includes some minor bugfixes:

• The placement of C5 was wrong in the schematic.
• The host software now compensates for some USB hickups.
• The RRDTool graph generation script adds minimum, maximum and average temperature readings to the summary.

You can get the new version from the Mikrowerk page. The photo of the Galileo thermometer above was CC’ed on flickr by Nick Lawes.

Its this time of the year: I have time for a small project. This year I have built an USB-powered thermometer. Basically, you just plug it into an USB port. Then you can query the module via a small commandline tool. I wanted to be able to use my NSLU for creating temperature graphs. The image above is the temperature in Kaiserslautern, Germany – updated every 15 minutes.

The code and the schematic are open-source, licensed under the terms of the GPL. The code is available at the Mikrowerk code repository:

USBTemp start page at Mikrowerk

On these pages you can read more about the actual device and the software. This post describes how to use USBtemp to record temperature information continuously. Im am using my trusty NSLU running Debian as a host – any other Linux/Mac machine will work the same way. The NSLU is a NAS device. It is small and doesn’t consume too much power (about 20 W).

The USBTemp device is attached to the second USB port of the NSLU. Using the host software I can easily query the sensors of the device:

$ ./usbtemp sensors
2 sensor(s) found, querying
sensor 0: ID 9F17A5010800 type: (DS18S20)
sensor 1: ID B46865010800 type: (DS18S20)

The first sensor is soldered on the USBTemp board itself – it monitors the temperature in my office. The second sensor is attached to my balcony:

Actually the sensor is hidden in the white box to protect it from rain. The sensor is the second in the list above, so I can query it using the command

/usbtemp temp B46865010800
searching sensor with id B46865010800 - using sensor handle 1
reading sensor 1 (°C): +1.1875

In combination with RRDTool it is easy to create timeline graphs. The USBTemp package contains scripts that help you to do this. First, you have to edit the settings in etc/config.sh:


# This file contains the configuration. Adjust it to meet your needs.
SENSOR1_ID="9F17A5010800"
SENSOR2_ID="B46865010800"
TEMP_DATABASE="$HOME/usbtemp/temperatures.rrd"
GRAPH_DIRECTORY="$HOME/usbtemp/temp-graphs"

Then you must define the USB_HOME environment variable to point to your USBTemp installation directory, e.g. (for bash)

export USBTEMP_HOME=/home/md/Projects/usbtemp/trunk

As soon as you like the settings you can use bin/generate-db.sh to create the RRDTool database. Please review the script if you want to adjust some settings. I use the cron daemon to query the sensors periodically (every five minutes) and update the plots every 15 minutes. This is the crontab:

# Linux cron can handle environment variables
# set usbtemp path
USBTEMP_HOME=/home/md/Projects/usbtemp/trunk

# m h dom mon dow command
*/5 * * * * $USBTEMP_HOME/bin/log-temperature.sh > /dev/null 2>&1
*/15 * * * * $USBTEMP_HOME/bin/plot-temperature.sh > /dev/null 2>&1

I use another little script to upload the graphs of the external sensor to my webserver. For my personal use, I also generate graphs of my office temperature – but I don’t publish these :-)

Here are the currently available temperature plots.

FreeRTOS is an open-source realtime operating system for microcontrollers. The ATMega644 of ATMEL provides 64KB of flash program memory in a DIY-friendly 40-pin PDIP package. Read on for how to combine both to my new software development platform.

FreeRTOS provides a nice RTOS for embedded systems and is readily available for various platforms. One timer of the hardware is used to implement multitasking features. A library provides routines for creating tasks and synchronization. Unfortunately, FreeRTOS is currently only ported to the ATMega323 – so I created a basic port to the ATMega644 and stripped all unnecessary features.

Typically, the FreeRTOS demo shows how to implement various threads and let them access the hardware. While it is educating to read the code, it is too bloated to serve as a template for new developments. In addition, I prefer Peter Fleury’s UART library for serial outputs. So, I removed all threads and included the library. To make sure that two threads cannot write to the same UART at the same time, I introduced a mutex per UART to synchronize the output on a per-string basis. Please note that there is no Mutex to synchronize read access. The main program starts two tasks which print “foo” and “bar” to the serial line, respectively. I kept the task surveilance mechanism as implemented in the original FreeRTOS demo (this might become handy ;-))

Here is a peek at the main.c file:

[viewcode]src=freertos-atmega644-main.c [/viewcode]

HTML code generated by vim-color-improved v.0.4.0.Download this code: freertos-atmega644-main.c

You can get the whole package (GPL licensed) from the download page. Have fun! Kudos for the CC’ed chip bug picture go to oskay.

During the upgrade of my Arduino, I used the mySmartUSB programmer – initially on my Windows box, but since it’s USB and it mimics the AVR910 protocol, you can use it with avrdude on your Mac. Here’s how.

Note: This currently only works for PowerPC-based Macs. Silicon Laboratories is not able to get a Intel Mac driver out – see http://www.surveyor.com/cgi-bin/yabb2/YaBB.pl?num=1161916754/4

First of all, you need to install the USB driver for the chipset used in the programmer – it’s a CP2102 from Silicon Laboratories. You can download a driver from chip45. So go ahead and download it. Once it is installed, plug in the programmer. A file

/dev/cu.SLAB_USBtoUART

shows up – this is the USB-to-UART device that you can use with avrdude.I installed the latter using Macports, if you install it from another source, please make sure it is at least v5.3 – older versions do AFAIK not support the ATMega168.

By default, the avrdude.conf does not contain the right device code for the AVR910 protocol. Open /opt/local/etc/avrdude.conf and make sure the following line is in the ATMega168 definition:

avr910_devcode = 0x06;

When everything is set, you can use the command

avrdude -p m168 -P /dev/cu.SLAB_USBtoUART -c avr910 -t -u

to get to avrdude’s terminal mode – you can use e.g. ‘sig’ to print the signature of your ATMega chip.

You can buy the mySmartUSB programmer from myAVR – currently, it costs EUR 28,-.

I just upgraded by little Arduino to the ATMega168 – and basically doubled the memory. But, be warned: This is not a hassle-free procedure if you have not some experience with microcontrollers.

I bought a cheap serial programmer – only to figure out that the firmware is outdated and the ATMega168 is not supported. You can update the firmware – but you need another programmer for this *grmp*. So I bought a not-so-cheap mySmartUSB which runs over USB (so there is a chance it will work on the mac, I already found a driver for the USB chipset – stay tuned.)

Today, most programmers come with a 10-pin header (aka Kanda connector), but the Arduino uses the old 6-pin ICSP header. I soldered a converter to solve this. Once I succeeded with the electrical connection, I failed in using avrdude – programming went fine, but I wasn’t able to set the fuse bits. Finally, I have found AvrOspII which worked perfectly on my Windows box. Please read Wolf Paulus’ description to save yourself a lot of time (and broken ATMegas) – he has written a great article about the fuse settings.

If you’re interested in a pre-flashed Arduino, send me an email.

PS: picture CC’ed by opk on flickr.

The sketch for decoding the time radio signal DCF77 is greatly improved: I use interrupts for handling the signal and a backup timer has been added.

Note that there is no interface at the moment, the time is simply put to the serial line. But it should be easy to add a display to show the time. The sketch eats roughly 6000 bytes of memory – if you want to add a user interface, you should consider buying a 16 kb Arduino ;-)

Of course, you also need the DCF77 receiver module and a pullup-resistor, as described in my old post.

You can download the code here:

• arduino-dcf77-clock-0.2.0.tar.bz

BTW: The picture above shows a Nixie tube clock. I ripped the picture shamelessly from flickr, there’s a photostream showing the creation of the clock. Cool project.