I'm not particularly proud of the .vimrcs. They're a giant mess, as of now. I should clean them up into one good one soon.

I just realized that all the comments were chock full of spam, so I erased all of them and I've put a captcha in place. Sorry about that.

There's also a git script thingy running in the background to upload my entire site to a remote git server. If anyone's interested, let me know and I can put the script up. It's pretty trivial, though.

http://www.srikanthnv.net/rfc_viz/

Visually Navigate through the dependencies between RFCs

Client commands

Setup

 git config --global user.name "Firstname Lastname"
 git config --global user.email "user@example.com"

Clone a new remote repository

 git clone git_user_on_server@this.is.server.net: /full/path/to/repository/on/server.git local_directory

Clone a new remote repository WITHOUT any files

 git clone --no-checkout git_user_on_server@this.is.server.net: /path/on/server.git local_directory

Create a new local branch

 git branch -b new_local_branch_name

Delete an existing local branch

 git branch -d local_branch_name

Delete local branch and lose all unmerged changes

 git branch -D local_branch_name

Create new local branch to track a remote branch

 git checkout --track -b new_local_branch_name remotes/origin/remote_branch_name

Switch to a branch

 git checkout branchname

Push existing local branch to remote

 git checkout branchname
 git push branchname new_remote_branch_name

Delete branch from remote (you have to discard local commits manually)

 git push branchname :remote_branch_name

List all local branches

 git branch -l

List all remote branches

 git branch -r

List all branches

 git branch -a

Switch to a remote branch

 git checkout remotes/origin/branchname

Diff with last committed version:

 git diff ./path/to/file.c

Overwrite with last committed version:

 git checkout ./path/to/file.c

Add file to index (must be committed later)

 git add ./path/to/new/file.c

Remove file from index (must be committed later)

 git rm ./path/to/old/file.c

Check status of repository

 git status

Commit changes

 git commit

 # Commit with commit message inline
 git commit -m "commit message"

Push committed changes from local to remote

 git push origin <branchname>

Discard local commits and resync with remote

 git reset HEAD ./path/to/file.c

Graph branches

 git log --graph --all
 git log --graph --format=oneline --all

Server commands

Create a git 'remote' repository

 sudo su - gituser
 cd git/root/dir
 mkdir repo.git
 cd repo.git
 git --bare init
 git config core.sharedrepository 1
 git config receive.denyNonFastforwards true
 find objects -type d -exec chmod 02770 {} \;

Mirror a bare remote repository to another remote repository

 sudo su - gituser
 cd git/root/dir
 git clone --mirror user@remote-repo

Periodically update the mirrored repository

 git fetch --all [-q]

Check if a repository is 'bare' or not

 git rev-parse --is-bare-repository

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.

Updated on 1st March 2013

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

• http://tinyprod.net/repos/debian/
• http://docs.tinyos.net/tinywiki/index.php/Installing_TinyOS_from_Source_on_Fedora_13_64bit

Environment

I'm using:

• 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

• Linux Mint

$ cat /etc/lsb-release 
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=14
DISTRIB_CODENAME=nadia
DISTRIB_DESCRIPTION="Linux Mint 14 Nadia"
$ uname -a
Linux <host> 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 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 lines to /etc/apt/sources.list:

deb http://tinyprod.net/repos/debian squeeze 
deb http://tinyprod.net/repos/debian msp430-46 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