HetNet: A uIP powered custom board

jacopo mondi
Suggestions, corrections, everything: jacopo.mondi[AT]gmail[DOT]com

Special thanks to Matteo Marras for the mobile application development and for his smartness

tags:IOT, Internet of things, networked embedded systems, uIP, Contiki, Atmel ATMega, enc28j60

Pre:

With embedded sensors becoming even more cheaper and even more numerous, needs for a more standardized form of communication arise day by day.
Standard protocols, like ZigBee are slowly moving away from the isolated sensor network communication model, embracing new paradigms based upon new standards and methodologies.
Thanks to the introduction of IPv6 and new network protocols, like 6LowPan, sensor networks are rapidly becoming first class citizens on the internet network.

Standard protocols and tools, employed every day on the internet, such as TCP/IP, network monitoring tools and network equipment, are now available also for sensor networks, since those are becoming everyday more integrated in the existing infrastructure.

HetNet (Heterogeneous Networking) is a simple custom board built to demonstrate the potential of IP-enabled networked embedded devices.
Using the uIP embedded TCP/IP stack, it is possible to build with few lines of code a working HTTP server or an SMTP clients, just to name a few of the existing examples.

The experiment is performed in conjunction with an augmented reality application, for a mobile device, that provides a visual feedback of a physical phenomenon, the distance between an hand and the board.
The test-bed is realized by means of standard network equipment and the interaction between the mobile application and the sensor board is performed with standard HTTP requests/responses.
The board also exposes an auto-refreshing web page that displays sensed data and is reachable with a standard browser.

Main inspiration for the experiment comes from SICS' demo presented at IPSN 2010.

Hardware building blocks

HetNet is an hand-made board, inspired by the numerous existing boards equipped with an Ethernet interface.
One of the most known is TuxGraphics's Ethernet board, but also the Arduino Ethernet shield is a known example.

To minimize the need of writing new drivers or porting existing code to a new architecture, standard components have been chosen as building blocks for the project.

It can seems strange speaking of wireless sensor networks, while employing an Ethernet enabled board, but as of today is possible to switch to another kind of network interface quite straightforwardly.
Many wireless interfaces that can be employed with micro-controllers exist today. Ranging from 802.11 radios, controlled by means of serial AT commands, to 802.15.4 interfaces sometimes integrated within the micro.
Switching to a new interface is simply a question of writing a new minimal device driver, with a minimal hardware integration effort.

Micro and Ethernet Controller

The board is built around two main components, an ATMega328p micro-controller and an ENC28J60 Ethernet controller based board by Olimex .
The board is also equipped with an RS232 connector to provide a serial debugging interface and an ISP connector to program the ATMega chip. To perform the translation from TTL logical levels found on the ATMega serial port a standard MAX3232 IC has been employed.
The total board cost is around 30E, if industrialized a board like this one can cost less that 10E.

Powering and Clock

The ATMega is powered at 3.3V for compatibility reasons with ENC28J60 chip, and is clocked using the internal 8MHz RC-oscillator.
This is usually a bad design choice, because RC oscillators provide less precision than external crystal resonators, but since this is a prototype board, designed to run for short periods, that setup will fit our needs in an acceptable way.

Sensors

The board is also equipped with an external range finder.
A range finder is a sensor that, by means of an internal sonar, is able to understand the distance between itself and an item residing in front of it. For the experiment an LV-MaxSonar-EZ1 manufactured by MaxBotix has been employed.
This sensor supports various output formats, such as serial digital output, PWM and an analog voltage output. The latter has been chosen because of its simplicity.

Software building blocks

The uIP embedded TCP/IP stack

The uIP TCP/IP stack has been designed in 2003 by Adam Dunkels, and is targeted specifically for networked embedded devices with few Kbytes of memory.
It provides and RFC-compliant implementation of the TCP/IP protocols, with a typical memory footprint of 200 bytes.
uIP targeted applications are built upon another software tool developed by Dunkels and others at SICS, protothreads and protosockets.
This software tools provide a sort of cooperative multithreading useful to develop applications abstracting from the explicit state machine style, that is typical of event based systems. Furthermore a 'BSD socket'-like interface is provided for the interaction with the network stack.


uIP is today part of RIME, the network stack of the well-known Contiki OS, stand-alone versions already exists, targeted to specific architectures.
This project is based on the avr-uip port, a stand-alone uIP implementation targeted to AVR cpus.
A customized version, with some additional applications and some fixes for the UART and 1-Wire library can be found on my github repo hetnet_avr-uip.

Threads and main loop

Applications for uIP are usually written using protothreads and protosockets, to communicate with the network stack and to support thread execution.
The application is composed by several concurrent threads:

- A thread for distance sensing
- A thread for blinking leds
- The network application thread

All that threads are scheduled by the main loop by means of successive invocations.
A protothread is simply a C function that exploits specific macros to release the execution until some specified condition do not evaluate to true.


The simplest possible thread, with minimal complexity is the blink thread:


static 
PT_THREAD(blink(void))
{
	PT_BEGIN(&blink_thread);

		printf("led ON\n");
		led_on();

		timer_set(&blink_timer, CLOCK_CONF_SECOND);
		PT_WAIT_UNTIL(&blink_thread, 
				timer_expired(&blink_timer));

		printf("Led OFF\n");
		led_off();

		timer_set(&blink_timer, CLOCK_CONF_SECOND);
		PT_WAIT_UNTIL(&blink_thread,
				timer_expired(&blink_timer));

	PT_END(&blink_thread);
}

This thread simply lights up a led, wait until a timer is expired and then switch off the led.
While thread is sleeping, another concurrent one can execute, when blink function is again invoked the timer is checked again, and if the condition evaluates to true execution proceeds, otherwise control returns to the calling function.

Main loop simply continuously calls protothread functions, performing a primitive scheduling between threads.


	while(1){
		blink(); /*thread*/
		read_distance(0); /*thread*/
		uip_len = network_read(); /*get packet from the network*/

		if(uip_len > 0) {
			if(BUF->type == htons(UIP_ETHTYPE_IP)){
				/* 
				 * IP Packet: process headers and call application thread
				 */
			}else if(BUF->type == htons(UIP_ETHTYPE_ARP)){
				/*
				 * ARP request: reply to ARP req
				 */
			}
		}else if(timer_expired(&periodic_timer)) {
			/*
			 * TIMER EXPIRED: ARP update and periodic poll
			 */	
		}
	}

Network Applications

When an IP packet is received it is passed directly to the network stack that performs some operations on the headers to determinate which kind of packet the application is actually handling.
When the network application is called it has to check which flags have been enabled by the stack, and act accordingly (ie. if a re-transmission is requested the application has to reproduce the lost packets).

Two different applications have been developed for this project.
The first is an auto refreshing page that displays real-time distances reading the range finder output. The second is a simple HTTP server, that gives back the distance or the temperature sensed by the uController using arguments passed by means of HTTP GET requests. Both the applications reside in the github repo, named simple_ajax and httpd_custom respectivly.

Testing and Demo

Since the board has been developed to perform a demo test in conjunction with a mobile application that performs an augmented reality animation, this specific use case will be described.
Since HetNet, as any other sensor board powered with uIP, Contiki can be connected directly to standard network equipment it is possible to use any kind of setup, totally wired or partially wireless, as we have done in our test-bed.

Test-bed setup

For the demonstration we have performed for the department Career Day event, a simple 802.11g access point has been employed. We have setup a standard wireless network and connected the board directly to one of the access point's Ethernet ports.
We have then connected the mobile device to the wireless network and used a simple printed tag to start the measurement.
The device start performing HTTP requests to the board's IP address, receiving back HTML text, that is parsed in order to extract relevant information.
The actual distance is then calculated and displayed in the animation.

The brief slides presented on 13-10-2011 are available here
A video of one of the preliminary test we have performed is available here (final verion works a lot better :).