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

It took me a while to figure this out, so here are my notes:

1. Install Scratchbox as described here. This greatly simplifies cross-compiling things. It also provides you a way to run the compiled ruby interpreter on a bigger host machine using QEMU. This is essential because I rely on rubygems, and the Chumby is too small to execute the gem install commands. Besides, at least for the sqlite3-ruby and mongrel gems, I need to compile native code.
2. Install dependencies. I found the following libraries necessary:
   • OpenSSL 0.9.8n – avoid the 1.0.0 version, it causes problems with the Ruby interpreter.
   • Zlib 1.5.3 – same as installed on the Chumby.
   • Readline 6.1
   • A recent version of sqlite, since I need it for my gems later on.

   Compile the libraries and install them into /mnt/storage (use –prefix where necessary).

3. Adjust the environment to use the new libraries:
   BASEDIR=/mnt/storage/usr
export PATH=$PATH:$BASEDIR/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$BASEDIR/lib
4. Install Ruby and rubygems. I was not able to compile Ruby 1.8.7, but Ruby 1.8.6-p399 works nice. To configure everything, I use the following commands:
   export ac_cv_func_getpgrp_void=yes
export ac_cv_func_setpgrp_void=yes
./configure --target=arm-linux --host=arm-linux --disable-pthread --enable-wide-getaddrinfo --enable-zlib --with-zlib-dir=/mnt/storage/usr --enable-readline --with-readline-dir=/mnt/storage/usr --prefix=/mnt/storage/usr --with-openssl-dir=/mnt/storage/usr && make && make install

5. Install rubygems:
   
/mnt/storage/usr/bin/ruby setup.rb --prefix=/mnt/storage/usr
mkdir -p /mnt/storage/usr/lib/ruby/gems/1.8

6. Afterwards, the necessary gems can be installed using the gem command. It might be necessary to provide additonal path information to the gems that compile native extensions, for example
   gem install sqlite3-ruby -- --with-sqlite3-dir=/mnt/storage/usr

The result is an image with Ruby installed, and all necessary gems for my project. The tarball can be downloaded here. To install, scp it to the Chumby and log in:

scp *tarball* root@*chumby-ip*:/mnt/storage
ssh -l root *chumby-ip*
cd /mnt/storage
tar xvzf *tarball*


Now you have a directory /mnt/storage/usr with all tools permanently installed on your Chumby. In order to use it, please adjust your PATH and LD_LIBRARY_PATH appropriately:

export BASEDIR=/mnt/storage/usr
export PATH=$PATH:$BASEDIR/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$BASEDIR/lib


/me mumbles more automation needed. But not today.

All the electric power generated from renewable energy is good – no additional CO2 is produced. Saving energy in general is also a good idea – what you don’t consume, you don’t need to produce. But energy savings require you to understand your own energy consumption – you can’t improve what you can’t measure. A simple energy cost monitor is available for 10 Euro, but it requires you to plug it into different appliances in order to figure out what a specific device consumes. And only the more expensive ones log the power consumption over time, which is pretty interesting.

An alternative to the simple energy meters are smart meters. In Germany, utility providers need to offer their customers the replacement of old (typically black) meters with shiny new digital “smart” meters. Actually, there is nothing smart about them – they just transmit the energy consumption of the household via powerline or other technologies to the utility provider. The utility provider does not need to visit the household in order to get the reading. And, in some cases, customers can have a look at the realtime energy consumption of their household.

The benefit of the realtime data is that you can assess the impact of your actual energy use very quickly. Google.org is offering the PowerMeter, which works for example with the smart meters offered by Yello Strom. An interesting open-source alternative is the Flukso.

The Flukso is a little WLAN router with some additional circuits to measure your power consumption. You install it in your breaker box. Depending on the configuration of your breaker box you need one or three current clamps. These clamps just go around the cables that supply your household – it is not necessary to re-cable the breaker box. I have a three-phase supply, so my installation consists of three current clamps and the Flukso itself. David Rowe has a nice writeup on the installation.

The Flukso then measures the power and transmits the data over the WLAN to the Flukso website. Once you’re logged in you can see your own energy consumption as a realtime graph. It is quite fascinating to find out how your energy consumption is composed. Here is one of my charts:

The graph shows time on the X-axis and my energy consumption in Watts on the Y-axis. The peak (1) shows that I was getting up in the middle of the night, preparing some tea and switchin on my computer. I had a pretty decent jet lag that night. In the morning I got up again around 8:00 (2). Apparently I used my coffee machine and switched on some lights, but I left shortly afterwards. The regular power consumption (3) originates from my fridge which draws power in regular intervals. Around 18:00, I got home again, switched on lights, prepared tea etc (4).

The graph is very interesting and really helps to improve your energy usage. But it also scares me – as I demonstrated above, a lot of information is stored in such a graph. Honestly, I don’t want my utility provider to know this. And I definitely do not want Google to know that much about my life. Or would you like to see advertisements for sleeping pills after a night of jet lag?

The picture at the top is CC-BY BK59 on flickr, thanks!

Green energy is good. Finally, people around the world begin to realize that the climate change is a serious problem for mankind. Driving with a car harms the environment – more efficient cars (or electric vehicles) are the new SUVs. On the other hand, a lot of energy is consumed in private households. In Germany, energy-efficient remodeling is rewarded with cheap credits. Often, solar power is used to heat water and generate electricity. More and more wind parks are built which also draw their energy from the sun, indirectly.

Unfortunately, renewable energy source create problems for the conventional power grids. In a power grid, demand and supply of electricity must match at all times. If a consumer draws power from it, the exact amount of power needs to be fed back into the power grid as fast as possible. There is almost no reservoir for electrical power (except for pump storage hydro power plants, but the capacity is limited). Since renewable energy sources such as solar and wind power cannot be planned additional power capacities need to be in place in order to compensate for the lack of power.

In the German research project “mySmartGrid” I am working on another technique to alleviate the erratic nature of these power sources. Instead of adding more production capacity or storage capacity we want to control the demand for power. In addition to the not-enough-power-available problem we currently have another problem: the too-much-power problem. When wind blows over Germany, significant power is generated – whether it is needed or not. Often, wind parks need to be shut down when too much power is generated. This is clearly not desirable from an ecological point of view.

To put it simply: We have either too much energy available, or not enough. It is rare that we have exactly the right amount of energy at our hands. This situation is shown here:

We can influence this only to a certain degree. BUT: We can change the way we consume the energy. For example, think of your fridge: It doesn’t matter whether it draws power now or five minutes later. The temperature change is inert. Thus, it is easy to move the demand – not save any power, but shift the demand for electricity by some time. In other words: switch the fridge of when the supply is short. Then, when the supply exceeds the demand, switch the fridge on again – it will draw more power since the internal temperature was raised. This is what we do:

Of course, this is only the simplified version of what we are doing. In reality, we must ensure that food doesn’t go bad. In addition, controlling a single fridge has almost no impact. But if you aggregate lots of households, the impact can be significant. Heat pumps consume a lot more energy and can be controlled in a similar way. If you can combine lots of households with heat pumps, fridges and freezers, the impact on the demand side is serious.

In the mySmartGrid project we combine up to 1000 households. We intend to control the energy consumption of household appliances as described above. The following picture shows a high-level overview of the architecture:

We combine the predicted power supply information for a period with statistical models of the power consumption of our households. This gives us an understanding when too much energy is available. We create schedules that contain information when a household should maximize its energy consumption. The schedules are then distributed to the households. The so-called “Kundenhub” is currently an iPod which offers a user interface. Household members can always override the schedule we propose.

The iPod uses various mathematical models to determine how to switch appliances on or off. It executes the strategies locally: there is no direct remote control over household appliances. The commands are sent to connectors close to the appliance which then can control the appliance.

This research project contains a lot of challenges – but I save this for another post.

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.

• Ruby 1.8.6: 21 minutes, 55 seconds
• Ruby 1.9.0: 22 minutes, 13 seconds

I certainly did not expect any wonders, but in theis case, the runtimes are about the same. So I’m investigating further, using the ruby 1.8 profiler on a smaller test problem:


% cumulative self self total
time seconds seconds calls ms/call ms/call name
33.20 32.96 32.96 661 49.86 77.25 Marshal.load
17.80 50.63 17.67 6365 2.78 14.96 Array#each
17.52 68.03 17.40 601659 0.03 0.03 IO#getc
9.19 77.15 9.12 660 13.82 13.82 Marshal.dump
6.01 83.12 5.97 187158 0.03 0.03 Float#+


My code spends 42.39 percent of its runtime doing marshalling operations. For Ruby 1.9, the code spends 48.98 percent of its runtime doing marshalling. This is somewhat disappointing. In a second round I changed my code to not relying on marshalling – basically, I am using clone on essential internal datastructures. All other information can be reconstructed afterwards. This means that I need to recompute certain values, but evidently this is a much faster approach:

• Ruby 1.8.6: 1 minute, 34 seconds
• Ruby 1.9.0: 1 minute, 17 seconds

Note to self: always use a profiler before refactoring code for performance reasons.

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.

I resumed my code katas – this time, I’m using Erlang to solve the problem:

By listing the first six prime numbers: 2, 3, 5, 7, 11, and 13, we can see that the 6th prime is 13.
What is the 10001st prime number?

It seems to be clever to have a prime number generator for Project Euler anyway. My implementation is based on the Sieve of Erathosthenes and uses the Prime Number Theorem for an estimate on the size of the sieve. The code is pretty easy:

[viewcode]src=pe7.erl [/viewcode]

HTML code generated by vim-color-improved v.0.4.0.Download this code: pe7.erl

In the erathosthenes function, a list comprehension is used to purge all multiplies of the current Index value. My first attempt didn’t include the Index variable – I simply decreased the boundary. The disadvantage of this method is that it keeps the list of primes bigger over the runtime: Instead of removing the multiples of 2 at the very beginning, they get removed as the last multiples. The size of PurgedNumbers stays bigger, which leads to a runtime of 6.7 seconds. When I use the Index variable, the multiples of 2 get removed first which avoids copying them all the way. The runtime decreases to 1.2 seconds (on my Mac Mini).

Since all variables in Erlang are bound only once, I don’t know how to optimize this further. In C, I would use a bit array to further reduce the memory footprint. But: the Erlang code is much easier to read and write. I think Erlang is just not made for low memory bandwidth requirements :-)

The picture above is an representation of the Ulam spiral, CCed on flickr by no_typographic_man.

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.