What? Why even mention windows here, these two OS's aren't even close to being in the same category other than they share the price tag of "free". I'd like to see windows try to run in under 128mb let alone the 1mb for linux or the mere kilobytes need for Contiki. A windows mention here seems very out of place.
CE has become Windows Embedded Compact; and there is a Windows Embedded Standard as well (stripped down components of the desktop OS, if I recall).
Adam Dunkel has done a nice job of pulling Contiki from the obscure research community and into the commercial space and is riding the "internet of things" wave right now. We'll see if it lasts. I'm not familiar with what developments have taken place on their OS since maybe 2010 or so.
(ironically a 1GB download for a Micro-OS)
The emulator lets you do interesting things, like experimenting with mesh networking, that would require quite a lot of hardware to try for real. (Plus it's a lot quicker than flashing 15 nodes every time you make a bugfix!)
The Instant Contiki package also includes toolchains for several platforms, which probably is the biggest value it provides.
But, I'm happy to hear Open Source continues to make inroads into the embedded space. There's billions of devices out there that sometimes people's lives depend on running a terrifying array of proprietary and unmaintained software that is potentially broken in subtle (or not so subtle) ways.
Edit: Here's all the stuff about ports to a variety of awesome hardware: http://hitmen.c02.at/html/tools_contiki.html
You almost make it sound like proprietary per default is or can be broken while open source is not, that's a bridge too far :P
Don't forget that big companies like TI make money of both the hardware and the software (Code Composer Studio IDE which is used for pretty much all there DSPs etc) and do put lots of effort in making everything run properly. Anyway, bugs are everywhere.. Anecdote: I have used CCS for years while not encountering any problems at all, while in the same timespan I used open source toolsets I did find some bugs. Then again, same timespan in using other closed source toolsets there wre bugs as well so there's no clear winner imo.
Having said that CCS is based on Eclipse, at least when I used it a few years ago.
To me, this speaks volumes: it clearly shows that open source is as good (and in many cases better) than closed proprietary. Granted, as you said, code quality has more to do with the people behind the code than anything else, but it still stands that at least with open source, you're not SOL when (not if) something goes wrong.
Personally, I figure it might as well be; no way to fix it. I'd rather drive a beater that I know I can fix myself (or take to a local auto shop if I can't) if it breaks down than a high-end sports car that has to be taken to the dealer for something as trivial as an oil change.
No software is perfect (beyond a trivial "Hello, world!" exercise); that's why being able to look for and potentially fix flaws is important :)
Here's a quote of his I kept with me from those days, paraphrased.
When I program I always try to code as if I'm writing for a PDP-11.
Aside from the strong hardware support and large community behind it, Thingsquare has recently released it's slides from their training classes on Contiki that give an excellent overview. Porting an already existing platform to my own custom hardware has been relatively painless compared to Linux or an RTOS, though it is difficult to make Contiki's makefile based workflow work well in an IDE.
Cooperative protothreads are surprisingly easy to work with, and the IP/mesh networking stack is highly configurable at each layer. Combined with an excellent overall code quality, this is the very first open-source project I've ever really wanted to get involved in.
Some example of Contiki running and browsing the internet on 20 year old hardware with 64k of ram (Apple IIe)... video is a few years old but still impressive.
I think I want to try and get this running on some atmel hardware just for fun :)
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.
Bureaucracy as a Service ;).
Where in the world are you, I'm in the UK.
There are some ports to low cost hardware - the arduino port for atmel chips  and a port to the TI launchpad , which is a $3 chip.
And if you're using something bigger, like a Raspberry Pi, you would use Linux anyway.
(But people are using it, so it must be useful. I just don't imagine the kind of applications...)
This sort of OS is very useful in situations like wireless mesh networks where the code is more complex than would be suitable for a super-loop architecture, but the system is too resource-constrained to run something like Linux because it is trying to hit power requirements.
the hardware abstractions look like they allow you to reuse application code with different hardware drivers too, which is nice.
It mostly fits for people needing exotic mesh networking and not much else. "Much else" would imply just running it on a Pi.
If you want to play with the hardware you have to bite the bullet and get used to device costs being 2 to 10 times the cost of microcontroller or Pi unit costs. Contiki hardware is extremely expensive.
If you want to play with the software run emulators / simulators with contiki on desktop hardware, this cost is basically free (other than 100 watts per desktop etc).
If you want to play with mesh networks the best bet is something like WRT54GL with ham radio mesh software on it aka HSMM for $50 per node (at least its $50 Amazon Prime delivered, maybe more or less for you)
There's the rub. I've seen Arduino's be turned into real development environments, with a keyboard and mini-display, and onboard editor for Assembly, to boot! So I don't think the Arduino is 'mini' in any way; maybe the demo's of Arduino you've seen are one thing, but actually the Arduino is a kick-ass machine. Some people treat them like an Atari. :)