by Martin Turon, Director of Wireless Software, Crossbow Technology, Inc.
Today we are lucky enough to have a quick lesson in programming
using
Crossbow's Imote2.Builder kit with Crossbow's Director of Wireless Software and our resident Programming Jedi - Martin Turon. Not only an expert in the field of
wireless sensor networks, Martin has been instrumental in simplifying
the WSN user experience with advancements in interface and server tools using his background in video game design, mobile phone software and operating systems. He is the current Chair
of the ZigBee WSN group which is working to establish the standard for
low-power routing while leading the Wireless software development team
at Crossbow for future product enhancement. Martin obtained degrees from University of California, Berkeley in
Electrical Engineering and Computer Science. He has also studied Artificial Intelligence at University of California, Los Angeles and received a certificate in Math for Financial Engineering from Haas Business School. Martin is an avid lover of indie rock and performs with various ad-hoc musical projects.
Embedded programming has historically involved pulling out your C compile, and writing detailed code that needs to carefully manage limited memory resources, hardware interrupts, and low-level bus interfaces. The benefits brought by newer high-level languages such as Java and C# have lagged entry into this
space by about 5-10 years. The delay can be attributed to limits to memory and processing speeds within the space due to aggressive cost requirements, and a lack of tools and software support for embedded platforms compared to PC/server platforms. More recently, the J2ME and Windows CE platforms have made Java and C# respectively available to smart phone and PDA application developers. But both of these environments continue to limit the amount of control the developer has over low-level interrupts and hardware resources. The Microsoft .NET Micro environment that powers the Crossbow Imote2 .Builder kit allows programming an embedded device with C#, while providing native control over hardware resources such as the I2C, SPI, and UART buses. Programming a native IEEE 802.15.4 radio driver for example is possible in this environment,
and the full source code for such an implementation is provided.
There are it seems endless sites that compare C# against Java. They can in many ways be considered the same language fundamentally, with C# being largely derived from its Java parent adding a few new keywords and constructs. The biggest difference comes with the libraries that the developer links
to, which can be very different depending on the version and underlying platform that is chosen. C# does have one essential advantage however for the embedded developer, and that is native handling of unsigned types. In Java all variables are signed, so in order to manipulate a 16-bit ADC value for example one needs
to jump through hoops:
// Java
code to read little-endian unsigned 16-bit data: complex.
public short
readShortLE() throws IOException {
int w, wlo, whi;
wlo = (0x000000FF & (int)super.readByte());
whi =
(0x000000FF & (int)super.readByte())
<< 8;
w =
whi | wlo;
return (short)w;
}
// C# code
to read little-endian unsigned 16-bit data: simple.
public ushort
readShortLE() {
return super.readByte()
| (super.readByte() << 8);
}
This example shows how much more intuitive and readable the embedded C# code is over Java due to the simple addition of ushort and uint types. Writing Java code that correctly handles unsigned types is actually fairly difficult to do, and the initial implementation of such code tends to have hidden bugs for certain portions of the data range.
In the following example, the start of a simple SPI-based sensor driver is presented. This driver sends low level commands over a SPI bus to a digital 3-axis accelerometer. The code shows how to initiate a SPI
configuration and how to read and write registers over the bus. The example also includes creating a property API for accessing a particular register on the digital sensor, in this case Accel_X. On node conversions and intelligence can be easily written right into the driver within the property code block.
using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using
Crossbow.platform.imote2;
public class AccelerometerSensor
{
internal
enum Reg : byte
{
//
Control
CTRL_REG1 = 0x20,
CTRL_REG2 = 0x21,
// Accelerometer
Data Registers
OUTX_L = 0x28,
OUTX_H = 0x29,
// ...More commands left out for brevity..
};
SPI _spi;
SPI.Configuration _spiConfig;
public void
Initialize(SPI.Configuration
spiConfig)
{
if
(spiConfig == null)
{
_spiConfig = new SPI.Configuration(
Pins.GPIO_PORT_SSP1_SFRM, // Chip select
port
false, // Chip select active state
20, // Chip select setup time
20, // Chip select hold time
false, // Clock idle state
true, //
Clock edge
986, // Clock rate KHz (986KHz)
SPI.SPI_module.SPI1 // SPI
port connected to LIS3L02DQ
);
}
else
{
_spiConfig = spiConfig;
}
try
{
_spi = new
SPI(_spiConfig);
}
catch
(Exception ee)
{
Debug.Print(ee.ToString());
}
//
Power up, no decimation, no self-test, enable x/y/z
WriteReg(Reg.CTRL_REG1,
0xC7);
WriteReg(Reg.CTRL_REG2,
0x04);
// Normal, continuous, little-endian, 4-wire,
// right justified, enable data-ready
}
internal
void WriteReg(Reg
reg, ushort data)
{
byte[]
write = new byte[]
{ (byte)reg, (byte)(data)
};
try {
_spi.Write(write);
}
catch
(Exception ee)
{
Debug.Print(ee.ToString());
}
}
internal
byte ReadReg(Reg
reg)
{
byte[]
read = new
byte[1];
byte[]
write = new byte[]
{ (byte)((int)reg
| 0x80), 0 };
try
{
_spi.WriteRead(write, read, 1);
}
catch
(Exception ee)
{
Debug.Print(ee.ToString());
}
return
read[0];
}
public ushort Accel_X
{
get {
ushort
accel_x = (ushort)ReadReg(Reg.OUTX_H) <<8;
accel_x |= (ushort)ReadReg(Reg.OUTX_L);
return
accel_x;
}
}
}
The Imote2 hardware provides arguably the highest performance mote platform while retaining good power characteristics, dwarfing other platforms with regard to processing speed, and memory and flash size (click on the table for more details).
This capable hardware coupled with the simple C# environment of Visual Studio and the Microsoft .NET Micro framework results in higher developer productivity. Creating advanced WSN (wireless sensor network) applications and test beds that involve in-network processing, high-speed sampling, and logging has never been easier.
The kit CD includes full C# source code for an Imote2 application that streams accelerometer data over the IEEE 802.15.4 radio. Two sample PC applications receive this data from an Imote2 base station and interpret it: MotePlot and MotePong. The former plots the real-time accelerometer data as a chart, and the later interprets the readings as control information to play a simple and familiar game.
To purchase a WSN-IMOTE2.Builder kit or receive further information on this platform, feel free to email Crossbow directly at sales@xbow.com. Additional details such as datasheets, manuals are available here on Crossbow's website. The Imote2.Builder simplifies and accelerates the design of wireless sensor applications. The level of performance and capability that the Imote2 brings to wireless sensor networks breaks the computational and memory limitations of current platforms by orders of magnitude for applications involving data-rich computations where there is a need for both high performance and high bandwidth.
InfoWorld has reviewed and featured Crossbow's Imote2.Builder kit in an article last week. The kit was reviewed by Strategic Developer Martin Heller who stated that, "The Imote2.Builder Kit makes creating wireless sensor networks a snap." From his article:
I spent several hours today exploring the Crossbow Imote2.Builder Kit,
a "complete development environment for high performance wireless
sensor networking (WSN) applications leveraging the Microsoft .NET
Framework," as the company describes it.
According
to the company, this is most likely a problem with the Microsoft
USBSPOT driver. Once I had a board programmed, it would be fine.
