Money!

Its popularity, of course, comes with good reason: The cost barrier for getting involved with embedded device programming has traditionally been pretty high. Getting involved with desktop development, web design, etc is pretty simple. All you need is motivation and time. Even getting involved with mobile app development is simple if you already have a smartphone. Plus, all these fields have a strong developer community so getting help and getting started is quite straightforward.

The Raspberry Pi promises to change all that. The RPi foundation decided to price the boards at a ridiculously affordable rate. A USD 25/INR 1250 board is quite within the reach of people like me: i.e. It's something I could've afforded it back when I was in high school/college in India (if only it had been around back then!). Opening up this industry to the entire world is going to be an absolute game changer. Developers the world over have already started coming up with really cool things, like a mind-controlled Lego NXT robot! I, for one, can't wait to see what else people are going to think up.

Community?

That said, at the moment I am being cautious. What will really make a difference is going to be a strong developer community. Also, hopefully a lot of schools and colleges the world over are going to get students involved with development. I think the real growth of this device is going to kick off once the current demand for devices is met and enough people get involved in the entire field to create that community.

The Raspberry Pi is not the 'first' ever to do this kind of thing. Many organizations have tried to create such cheap devices and a lot of those exist in the market today. None of them are quite as cheap as the RPi of course but they do exist and can be very useful in their specific markets.

In fact, and now we get to the actual point of this article, I personally believe that having just "one device" for the whole world isn't really going to help. I'd love to see people start off with the RPi and then move on to other alternatives that are more suited to the application at hand.

Finally, the Alternatives

Here are a few such alternatives to the Raspberry Pi. Most of these are targeted towards specific applications, which I've tried to describe. These are roughly in chronological order of when I heard of them, so the order is basically meaningless.

If you know of more, please email me (srikanthnv[at]gmail[dot]com) or leave a comment here and I'll add them to the list:

Gumstix

Not similar in terms of price, but very similar in terms of size. I first heard of this device way back in 2004 on slashdot, when the editors really wanted to stick these device in your collar. A tiny x86 device that could do all sorts of things that were almost unimaginable.

The Gumstix suite of devices is now huge and has all kinds of applications ranging from hobby stuff to education and infrastructure.

Arduino

Seemingly the favourite of people with artistic inclinations - this device has become very famous as the best way to interface the "real world" with computers.

Beagle Board

The Beagle Board has a powerful OMAP 3 processor, making this ideal for multimedia applications - including entertainment, vision, robotics, etc. The Beagle Board did make a huge change in getting people involved with embedded. The $150 price was still high, but a far cry from the $500+ EVMs that were traditionally available. In a way this was the original Raspberry Pi.

The BeagleBone is a pared-down variant of the Beagleboard. At $90, this is definitely more approachable for beginners.

Panda Board

Beagle board on steroids. Features the OMAP4 and the board of choice for HD entertainment, stereo/3d vision applications, etc.

These instructions are modified from the ones here to reflect what I actually did:

• http://tinyprod.net/repos/debian-dev/
• http://code.google.com/p/tinyos-main/source/checkout
• http://docs.tinyos.net/tinywiki/index.php/Installing_TinyOS_from_Source_on_Fedora_13_64bit

Environment

I'm using this Lubuntu 11.10 virtual machine, running under VMWare

user@lubuntu:/$ cat /etc/lsb-release

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.10
DISTRIB_CODENAME=oneiric
DISTRIB_DESCRIPTION="Ubuntu 11.10"@@

user@lubuntu:/$ uname -a

Linux lubuntu 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 
14:50:42 UTC 2011 i686 i686 i386 GNU/Linux

Prerequisites

Make sure you have the following packages installed, if you don't, install them with:

sudo apt-get install automake gcc g++ gcc-multilib g++-multilib python2.7-dev

Setup instructions

• Remove the previously installed tinyos packages:

sudo dpkg -P `dpkg -l nesc '*tinyos*' | grep ^ii | awk '{ print $2 }' | xargs

• Add the following line to /etc/apt/sources.list:

deb http://tinyprod.net/razvanm/debian squeeze main

• Install the new tinyos packages:

sudo apt-get update
sudo apt-get install nesc msp430-tinyos avr-tinyos tinyos-tools

• Install subversion:

sudo apt-get install subversion

• Go to the directory where you want to get the TinyOS source

cd /opt

• Download the source and set dir name as you would like

svn checkout http://tinyos-main.googlecode.com/svn/trunk/ tinyos-main-read-only
mv tinyos-main-read-only tinyos-rev5889

• Set up your environment - create a file called tinyos.sh with these commands adapted appropriately

#!/bin/sh
export TOSROOT=/opt/tinyos-rev5889
export TOSDIR=$TOSROOT/tos
export CLASSPATH=$TOSROOT/support/sdk/java/tinyos.jar:.
export MAKERULES=$TOSROOT/support/make/Makerules

• Source this file to setup your environment

. tinyos.sh

• Build the tinyos tools

cd $TOSROOT/tools/
./Bootstrap
cd platforms/mica/uisp;./bootstrap; cd $TOSROOT/tools/
./configure
make
sudo make install

..and that's it! You should be good to go.

Bugs?

Found issues with this guide? Let me know and I'll fix it. srikanthnv[at]gmail[dot]com

Who is this for?

• General C developers
• Devs working in small (2-10) member teams
• Devs working with code that was handed down to them
• Devs working on embedded devices

Who is this not for?

• "Enterprise" scale software developers. Really - you probably need a lot more than this.

The Info

• General C
  • C lets you obfuscate a lot of things - ranging from file names to variable names. Often times, code that is heavily optimized can be cryptic to read. As a rule of thumb, always prefer understandability over optimization. You are likely to rewrite/refactor code a million times - you will waste more time trying to figure out cryptic looking code than you will gain in efficiency.
  • NEVER, EVER typecast. Every typecast is a disaster-during-development waiting to happen.
• Software process/architecture
  • Always start with use cases. Understand your entire system later - first you need to understand how your users will interact with your system. Document them in detail.
  • Whatever task you've set out to do, you probably don't know how to do it - yet. You will learn over time and any design you start out with will probably go wrong. My advice: prototype. Always put together a quick-and-dirty demo before you sit down to iron out an architecture.
  • Iron out an architecture. After you finish setting out the demo, step back and create a design with a block diagram and clear APIs of each and every block. Double/triple-check your APIs for consistency. Use the use cases
  • Create tests from your use cases first, and then add test cases from your architecture. Test for positive cases first. Maintain a regression test suite. If you think you don't have the time to do this - you will pay for it later.
  • Schedule code reviews and stick to them. PLEASE.
  • Maintain an issue tracker - preferably one that's integrated with your version control and e-mail system. Also ensure that reviews are part of your check-in process.
  • Set aside time periodically to create a "getting started" guide - the guide should be good enough to get a complete newbie up to speed with development on your system.
• General Coding
  • Design, publish, and maintain a coding standard. If you don't want to roll your own then just steal the linux kernel coding guidelines.
• Dev/debug environments
  • Automate, automate, automate! C can become a very unmanageable beast if things are left to manual intervention. Make sure you can automate as many things as humanly possible. Everything from checkouts to builds to checkins to deployment to debugging - everything can be automated to some extent. Rule of thumb - if you do something more than 5 times, then you have a candidate for automation.
  • Use an IDE! Do not attempt to use vim/emacs unless you have no other option. As a hardcore vim-junkie, I can tell you that you will save a huge amount of time if you figure out how to get an IDE to work with your code. Ideally, see if you can get Eclipse running for you, somehow.
  • DO NOT start raw code development until you have a debugger. New platform? The first thing you should port (after porting your Linux Kernel onto it) is gdb!.
  • Make sure your debug cycle is not overly complicated. You shouldn't have to take 20 minutes to test a single-line code change. Set up your environments such that you can deploy/test code in seconds. Do this EARLY in your development cycle.
• Hardware/setup
  • Make sure your entire team is either using the same hardware, or clearly knows the difference between their units. You may end up spending hours to figure out why only Raju Coder sees a bug and you don't if you don't do this.
  • Save the hardware! Use ESD protection and be careful with your devices.

See more at the Scribe website.

This focuses on contests that are among one or more of the following categories

• Students/Corporates/non-students
• Allow international participation
• Have some kind of prize associated with them

Engineering

• IEEE Presidents Change the World competition
• Intel/Cornell embedded design cup
• Disney Imagineering

Hack-a-thon style

• Trojan Hack

Programming

• ACM ICPC - The mother of all coding competitions and probably the single toughest and most prestigious in the world.
• CodeSprint
• Facebook Hacker Cup

Training/Practice for programming contests

• UVA problem sets
• Project Euler
• TopCoder

This is a brief summary of "Routing Without Routes: The Backpressure Collection Protocol".

Background

Traditional routing protocols, such as link state or distance vector routing protocols work by explicitly calculating a route in the network from one node to another.

While these protocols work very well (as proven by the fact that they are deeply established in today's networks), they are not the "ideal" protocols for all network topologies. Specifically, they do not necessarily provide a globally optimum distribution of congestion in many-to-one transmission topologies, often leading to possible bottlenecks.

BCP is an implementation of Backpressure Routing - a completely different routing mechanism - for wireless sensor networks. BCP implements backpressure routing on wireless sensors to try to achieve the globally optimum distribution of traffic across the sensor network.

The core concept behind Backpressure routing is simple. Consider a network where all the nodes (sources) are trying to send data to one of the nodes (a sink). This is a typical data collection application. Assuming all nodes are transmitting data at roughly equal rates and are overall transmitting data "faster" than the sink can process, it will soon reach a state where data is backlogged at each of the nodes. Also, the farther away a node is from the sink the more data is likely backlogged at that node.

Now, if a congested node tries to send more and more data along the same path, it might cause congestion bottlenecks - leading to dropped packets.

However, instead, if the node sends data to a less-congested neighbour, who in-turn passes it on to a less-congested neighbour, and so on - chances are that the load will get evenly distributed over the network, and then data will eventually reach the sink. Any node that gets too heavily backlogged will be applying a "backpressure", and will not accept more data to forward.

This is a bit of an over-simplification of Backpressure. A more rigorous mathematical treatment of this stochastic network optimization can be found under the general class of "Utility Optimal Lyapunov Networking" algorithms.

Overview of operation

The "business logic" of BCP is elegantly simple.

• Each node that has data to send calculates a weightage to each of its neighbours. It then sends to the best neighbour based on that weightage
  • The weightage is calculated as a combination of the link quality between the two nodes, and the queue size of that node. This is a critical part of BCP's operation. Details are in the paper.
  • Nodes learn their neighbours backlogs by "snooping". Nodes listen to all nearby packet transmissions that contain the backlog. Nodes also disseminate their backlog so that other nodes can pick them up.

Work in progress

This is a brief summary of "RCRT: Rate-Controlled Reliable Transport for Wireless Sensor Networks".

Background

Wireless sensor networks? are often used for carrying data that cannot tolerate losses. Such data typically needs a reliable transport mechanism. Also, since sensors might generate data in bursts, there is a need for ensuring that there is no congestion. WSNs can typically carry very low bit-rates, usually of the order of a few hundreds of bytes per second, congestion could cause a serious problem.

RCRT is a protocol that tries to solve both problems.

Overview of operation

How does RCRT solve this problem? IT does a few things:

• First off, the protocol is "centralized". The network's behaviour is controlled by the 'sink's. Sinks are nodes that collect data from all the sensors. It is assumed that the sinks are a lot smarter than the sources.
• Reliability is achieved by making the sink explicitly request missing packets from sensors
• Congestion control is done by controlling data send rate. The rate control mechanism decides on rate increase/decrease based on congestion detection.
• Sinks detect congestion in a very interesting way - they check the time needed to repair a lost packet and compare it to the typical Round Trip Time (RTT) between the sink and that sensor that sent the packet. If the time taken to repair is much higher than the RTT then the network is most likely congested.
• Rate control is done by rate adaptation.
• Rate adaptation done on a network-wide basis.
  • RCRT uses additive-increase multiplicative decrease , like TCP, However, this is done at the SINK, and not the source (unlike TCP)
  • It is done on the “total” of all flows coming into the sink, and not on a per-flow basis (unlike TCP)
  • The sink has a better picture if it uses the overall total!
  • The increase factor is constant but Decrease is time-dependent!

Details and results

There are a lot more details in this PDF of a presentation I made on RCRT for EE652 at USC. rcrt-summary.pdf

I'm now a grad student. Yes. After the 5 amazing years at Ittiam I'd decided I want to find out if a research kind of world is better for me, so now here I am - doing my Masters in CS at USC.

More updates will come soon of course, as I try to figure a life out here.

Check it out!

Seems to work like a charm

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras ac leo massa, at tempor eros. Nam tincidunt porttitor purus non auctor. Integer elementum nulla at elit varius ultricies. Nulla tristique metus a dui rhoncus a tristique odio lacinia. Mauris sapien sem, molestie sed cursus quis, sodales quis neque. Donec auctor luctus justo eget dictum. Nullam quis varius sem. Proin in urna nisl. Suspendisse iaculis, lorem nec elementum dapibus, nisi odio convallis dolor, eu hendrerit ligula turpis non sapien. Curabitur vulputate imperdiet nisl, ut auctor lectus rutrum ac.

Sed pretium ullamcorper diam sit amet luctus. Etiam sapien urna, facilisis dignissim consectetur sed, viverra sed enim. Nam at lorem id justo tincidunt vehicula dapibus at nisl. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Nullam cursus tellus ac neque consequat quis cursus nisi iaculis. Nunc vitae quam nibh, vitae varius mi. Vestibulum elementum lacus lacinia erat consectetur eu interdum felis venenatis. Proin tincidunt justo ipsum, ac suscipit dui. Donec et neque non est imperdiet aliquet quis a odio. Nullam sed mauris turpis, nec dapibus mi.

Fusce iaculis congue massa, in rhoncus eros bibendum at. Nulla hendrerit arcu at odio faucibus gravida. Duis at vehicula lectus. Aenean bibendum, enim vitae feugiat tristique, risus libero congue dui, sit amet facilisis nibh elit quis nisi. Aliquam scelerisque, eros quis rutrum sollicitudin, ipsum nisl bibendum dui, id porta ipsum ante ac est. Phasellus posuere ullamcorper augue, et lacinia nulla euismod et. Mauris tellus ligula, sodales id fringilla mollis, gravida eget neque. Sed ut ligula enim, non vestibulum ipsum. Pellentesque lobortis fermentum ornare. Suspendisse ac blandit massa. Suspendisse consectetur placerat elit at pharetra. Mauris dapibus dignissim sodales. Sed sit amet massa id nibh malesuada vulputate. Donec dui magna, eleifend vitae commodo in, scelerisque eget lorem. Phasellus porta vestibulum sem ullamcorper scelerisque.

Proin ac nibh nulla. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse purus mi, sodales id hendrerit at, interdum commodo mi. Morbi fermentum ipsum aliquam nulla dapibus sed scelerisque lorem semper. Nunc et nunc sed nisi iaculis eleifend. Ut ligula lectus, mattis id molestie nec, tincidunt nec mauris. Curabitur venenatis ante ut lorem scelerisque at bibendum eros luctus. Suspendisse scelerisque accumsan elit. Sed sagittis malesuada dui, ut adipiscing ipsum dapibus ut. Curabitur id eros nec risus molestie eleifend. Donec consequat, mi ut rutrum feugiat, massa est consequat arcu, nec consectetur lorem tellus eget lorem. Proin nisl neque, feugiat vestibulum semper a, ullamcorper sed felis. Suspendisse ac nunc dui. Phasellus sapien magna, rutrum sit amet feugiat rutrum, elementum eu diam. Donec ac feugiat quam. Nulla ac enim vel dolor pharetra iaculis. Donec ut lacus tellus, in varius enim. Sed purus massa, semper vel scelerisque ut, dapibus quis elit. Proin sed fringilla nisi. Nullam laoreet risus velit, sit amet congue lacus.

Ut odio nisi, venenatis ac venenatis id, fringilla vitae arcu. Aenean fringilla neque at orci pretium dictum. Nulla laoreet, velit non rhoncus porta, purus arcu commodo lorem, vitae blandit turpis ligula quis est. Sed et leo ac arcu condimentum volutpat nec vitae augue. Etiam rutrum lorem eget felis laoreet pretium. Ut in accumsan mauris. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Donec sodales nulla at magna posuere venenatis. Ut a ipsum urna. Aliquam eget arcu erat.