In my opinion the space that it occupies (the "Internet of Things"), is not well-defined and it may be probably cheeper to use something like a full-blown small computer (like the rasperry-pi) with Linux on it.
In my opinion, that's probably a good thing; less baggage that has to be maintained for POSIX compatibility.
Remember that Unix was originally designed for large, centralized timesharing systems. It has been adapted to the embedded realm throughout the last couple of decades, but starting from scratch to create an OS specifically for the embedded realm is ideal.
> may be probably cheeper to use something like a full-blown small computer (like the rasperry-pi) with Linux on it.
In some cases. In the case mentioned by the article, however, a Raspberry Pi (for example) would make for a rather large badger collar. IoT is indeed a pretty broad and vague concept right now, but it already does demand very tiny hardware with size constraints dictating available computational capacity. That's where Contiki comes in.
Of course there are applications were you want to go really low-power/extra-small, but in that case even a micro-controller capable of running Contiki OS is too big. What I want to say is, that the application space where you can't deploy a small machine with Linux on it BUT it is feasable to have a small machine with Contiki on it is pretty narrow.
Anecdote: I learned about another project where they studied opossums. They put a collar with a small wireless device around their necks to track their movements and habits, but couldn't understand why a disproportionate amount of opossums died for some reason.... The reason was that the device had a small red LED that would blink to indicate that it was working, and the opossum, being a nocturnal animal became quite visible in the night, to the joy of all predators :) :S
This is getting OT, but sensor network applications and discussions often neglect the problem of device recovery and I know there are projects were sensors are not recovered and after they did their work (sensing stuff and sending it to a post-processing node) they go out of energy and become ... highly toxic waste.
In other words, you're thinking like a hobbyist rather than a product designer, or someone making tools for products. That's fine, but realize that embedded development for actual products is a completely different world than hobby raspberry pi hacking. I think the hobbyist embedded development community is awesome, BTW, just rather different than commercial embedded development.
I'm using ucLinux on a Cortex-M3 (NXP LPC1788 @ 72MHz) and it's pretty reasonable. I did it primarily to use Qt as my UI framework, but if I was running in bare userspace I think it would work even better.
The core of the Linux kernel is running out of the onboard flash but the rest is all executing out of that RAM. Kernel drivers, userspace app, and 16-bit WVGA LCD framebuffer. And there's no I or D-cache on this part. =( My app is currently running with memory 75% full.
Just the other day some guy has launched a Kickstarter with a very similar design, but with a bit more breathing room memory-wise:
The trick to Qt on this part was to avoid QWidget and do everything in QGraphicsScene. For some reason it's just a lot easier on the processor. QML is a non-starter on a part this slow in case you were wondering, so Webkit and QScript and all of that is compiled out.