ASSERT operational

what did you do in your Ph.D. again?

Recently I was asked to provide an overview of what I did through my Ph.D. in UTD. Although my research work is mostly wireless networking, I realized the “embedded systems” topic fits my development expertise the best. I will repeat that summary here too.

My experience with programming embedded systems can be divided into two parts: sensor devices and our testbeds.

  • Sensor Networking Applications

My main platform for research projects and papers is coding in nesC language for MICA2 devices. nesC is an extended C based language which supports event triggers.

The resulting image from the above code is one single binary file that includes all the drivers to interface underlying hardware. I sometimes have to change the way those drivers work, for example when I am altering the MAC protocol. Per usual definitions, this is a pure “firmware” for MICA2 devices.

I also have some experience with coding firmware for Ember 2420 based sensor devices in C++. However, this is not my main platform of work and I do not consider myself an expert on those.

  • Testbed Design and Implementation

For ASSERT testbed our hardware was a custom platform consisting of a Lattice FPGA and an i.MX27 Freescale processor and some peripherals. A custom RF board would control units under test. We wrote distributed software in C, running on the processor that controlled the RF board’s functionality through the FPGA. Control PC part was written in C++ and Java. Nodes boot using TFTP and RedBoot.

We had to develop and maintain the Linux driver. For the prototype our code worked on Atmel’s NGW100 mkII, an AVR32 microprocessor based development kit. I was one of the three Ph.D. students who designed ASSERT’s architecture and oversaw software development.

Successor to ASSERT, we are designing WiNeTestER. This generation is capable of larger frequency range, phase-shifting and other features. Hardware for this phase is based on and FPGA board, WARP. Since we do not have a separate processor, most of the computation will happen on the PowerPC “on” the Virtex-4 FPGA.

In this phase I had to learn some primitive FPGA design to create my own reference design (due to some licensing issues and incompatibilities). Nodes will boot using TFTP and U-boot. I am one of the two Ph.D. students who work on the software aspect, and cooperate with our hardware team on the design requirements.

For both testbeds, we cross-compiled the Linux kernel for the processors (AVR32, i.MX27 and PowerPC) and created a driver for our custom hardware. Embedded part of the code is written in C and cross compiled as well. As a result, this part is not pure “firmware” and is more like porting our own code to different architectures. The control logic, running on a control PC, is written in C++ and Java.

ASSERT is fully functional and used on a daily basis. WiNeTestEr, funded by NSF, is currently being developed.