Hacker News new | comments | show | ask | jobs | submit login
Contiki: The Little-Known Open Source OS That Rules the Internet of Things (wired.com)
328 points by maaarghk 1056 days ago | hide | past | web | 79 comments | favorite



>> Contiki will soon face competition from the likes of Microsoft, which recently announced Windows for the Internet of Things [0]. But while Microsoft’s new operating system will be free for devices less than 9 inches in size, it won’t be open source. And Contiki has an 11-year head start.

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.

[0] http://www.wired.com/2014/04/free-windows/


Well, it's Wired. You shouldn't be surprised, as it's how the do it all the time :)


Unless Microsoft throws everything out and starts fresh, it's doubtful they'll ever have a serious contender for the embedded market.


Agreed, though Microsoft is trying to push into the area of IoT - I believe part of their plan is to be a vendor of the backend cloud services, running on Azure.


I don't know what the current Windows embedded offering is, but Windows CE has a long history of running on fairly small devices. I've seen it on printers, in-flight entertainment systems, ATMs, oscilloscopes, etc. It's heavier than Contiki, sure, but on par with Linux, from what I've seen.


Yeah it's not really Windows for the IoT, it's Windows for semi-embedded.


Isn't that Windows CE?


No, Windows CE doesn't exist any longer.

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).

http://www.microsoft.com/windowsembedded/en-us/windows-embed...


That struck me too. 'Oh boy I bet the Contiki crew is shaking in their boots: "MSFT is gonna crush us like they crushed iOS & Android!"' lol... if history is any indicator, they don't have much to worry about.


It's interesting to see that Contiki is taking the lead in this space, since it was once going toe-to-toe with another open source OS for wireless embedded networked devices, TinyOS. TinyOS had a large following in the research community and I believe it was used in several commercial sensor network deployments by Dust Networks and Arch Rock and at least one other Korean startup company -- that i believe is still using it in their deployments.

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.


I think a major factor is that TinyOS is written in nesC, so to bootstrap it on a new device you first have to get the nesC compiler ported, then get the OS working. Contiki, meanwhile, is written in fairly vanilla C.


Output of the nesC compiler is one big C-file, so no problems there.


Note that it's got a pretty good emulator, with a VM image to get you up and running fast:

http://contiki-os.org/start.html

(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!)


Yeah - that emulator looks amazing. But dealing with large scale enterprise application in my day job I was struck with the desire to have a wee physical device (or devices) to play with - and the small scale of Contiki really appealed.


I bought a calculator for that (HP 50g) then found it had 1700-odd pages of manuals and reference information!


I saw that; it looks incredibly excessive. If the emulator runs as a Java app, is it really not enough to just download a .jar and run it on whatever OS I happen to be running on my workstation? Or are there so many custom dependencies and configuration requirements that such an approach is infeasible? They could probably shave that footprint down considerably if they didn't bloat it with an Ubuntu VM.


You can just download the source package and do a simple `ant run` if you just want the emulator. Initial build took less than 15 seconds on my machine and didn't require any extra user action.

The Instant Contiki package also includes toolchains for several platforms, which probably is the biggest value it provides.


The last time I read about Contiki, all of the screenshots were running on a C64. And it looked awesome! It made me want to play with it on my C64. The current website is all boring network simulation stuff. Looks like a corporation.

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


proprietary and unmaintained software that is potentially broken in subtle (or not so subtle) ways

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.


The leap I was assuming everyone here would be able to make is that if a device is running broken Open Source software, it can be fixed. If the software on it is proprietary and the vendor has discontinued support or no longer exists as a company, the device will be broken forever. In the embedded space, a system may run for decades...that's plenty of time for a company to go belly-up, or be acquired, or any of dozens of other outcomes that lead to the source code for the device being lost to the sands of time.


It seems hard to impossible to flash new software on your washing machine, even if it's open source and you can download a patched version from somewhere.


Right, major micro/CPU manufacturers, especially TI, occupy a unique position regarding software tools. They have a long history of very high quality tools with thorough documentation. And when bugs do occur the level of detail in the errata always surprise me. The quality of output from TI, ST or Intel is on a totally different level from anything I've seen in the open source world. I think the established HW vendors have a different mindset from SW companies, where open-source now is often the better choice.

Having said that CCS is based on Eclipse, at least when I used it a few years ago.


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.


Almost forgot, yes it's Eclipse based now; we switched to another platform right before that happened so I have only used the proprietary CCS.


It's about who has got the knowledge and is in control: the manufacturer or you, the user. That's what Free Software is about. http://fsfe.org/about/basics/freesoftware.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

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 :)


Even "Hello World!" can have issues if your compiler and/or libc has issues ;-P


Like you, I became enthralled with Contiki (1.0) when I saw demonstrations of it running on the Oric Atmos machine, a feat I considered fundamentally astounding, given that it was a network stack and .. albeit very little .. some room for further app development. A 30-year old machine, being revived with a modern OS stack .. contiki is indeed a delightful bit of code, too.


I love this, I remember back when Adam Dunkels came up with this and feeling proud that he was from Sweden.

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. 
So no wonder he made such compact C code for the C64.


Slightly OT, but I'm constantly amazed what swedes manage to pull off, considering their small population size they have a lot of impact.


Their government pays people to write free software.


What? I have never heard of this as a Swede, what are you referring you?


In the same way polar bears roam the streets.


The platform I learned to develop on was a very small cellphone; learning to live in tight resources is a skillset that sadly not enough people practice. Even today on much larger systems I still out of habit minimize code and resources more than I need to.


I was never forced to write like that but I have the same habit of wanting to minimize the resources I use and the dependencies.


I'm using this wonderful operating system for my own sideproject for LED juggling props.

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.


Those props sound interesting! Are you embedding the LEDs and circuitry in the juggling apparatus itself, or putting them in some stage props?


https://www.youtube.com/watch?v=OMzgp7xTp1k

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 :)


I am unsure about this. It's big advantage is its size and that it does not require as much HW support like Linux (like a MMU). The disadvantage is that it's not a *nix and you loose the whole ecosystem (no Posix).

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.


> The disadvantage is that it's not a nix and you loose the whole ecosystem (no Posix).

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.


The "Internet of Things" is marketing fluff, like "information superhighway". What they mean is "we want to charge you for more shit with silicon on it so we made up a new term". Raspberry Pi is waaayyyyy too big [and pricey] for devices that are nothing more than a sensor and a gprs module.


I doubt that. I know there is research in sensor network (e.g. at my university) and they say they want ulta-small low-power devices but the experiments I have seen were never in need of that much small devices.

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.


I guess there's always some wiggle room on most deployments. However, where I used to work, some of the guys at that department were conducting research on flying foxes as their migration patterns southern to northern parts of Queensland (Australia) were pretty much unknown (IIRC). The requirements there gets pretty tough. Also, the power consumption becomes a major factor as it will limit the amount of useful work the device can do, ie sensing, communication etc.

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


That's really funny because something similar was done at my unversity (I think with bats, or maybe even flying foxes). I declined because although the devices were really small and they assured me that the animals did not come to harm I doubted that. It's like carrying around a big backpack.

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.


Looks like there's a huge difference between small Linux and something like Contiki. Any time you run out of on-chip SRAM without an MMU (e.g. anything really low power) Linux is not a good fit. That non-Linux space is gigantic and there's room for something like Contiki as well as much lighter systems that have some form of non-IP networking. We evaluated a bunch of small kernels (ended up with uc/OS) but there are dozens of open and proprietary kernels that fit specific needs both larger and smaller than Contiki that are non-Linux for good reasons.


Yeah, uClinux is what i'm used to for MMU-less platforms. Then there's RTOSes, where you're looking at VxWorks/QNX/LynxOS for commercial support, or RTLinux/FreeRTOS/ChronOS for something unsupported. The Raspberry is a neat platform with plenty of uses, but custom tailored electronics often have exotic hardware with unique software constraints.


Not if you're a hobbyist developing the stuff for your own use though? Aren't the dev kits for this hardware more expensive than a Raspberry Pi + WiFi dongle?


It is not just about price. Power consumption is also a massive factor in designing internet of things. And anything running linux will inherently have a lot higher power consumption than something running contiki.


Not being a *nix is actually not a disadvantage at all in this context. You'd be surprised how little of an OS you actually need, and how inapplicable most libraries designed for PCs are.

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.


An alternative is something like ucLinux, which runs on MMU-less processors (think 68000/Coldfire or Cortex-M). Pretty much a functional POSIX/Linux EABI with only a bit of pain getting to work.

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.


Wow I'm impressed Qt runs acceptably on a Cortex M3, how much RAM do you have?


32MiB of SDRAM, believe it or not.

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:

https://www.kickstarter.com/projects/830019875/icon-the-endl...

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.


So what kinds of things are people actually using this for here? Anyone doing something interesting with it?


I am currently working with a startup company developing controls for solar water heating system, commercial lighting/climate control/monitoring and finally monitoring for large conventional water heaters - exciting i know ;) -.


I'm writing a system to take the Solar Thermal (and other technologies) UK installation standards and automate a lot of it,

Bureaucracy as a Service ;).

Where in the world are you, I'm in the UK.


I am in the US, get in touch with, We could collaborate maguirre at automatid com


I'm really unimaginative and can't picture what kind of hardware we are talking about? What kind of controllers/processors, what type of periphery etc.


Atmel AVR micros for the nodes and an ARM SBC to run Linux on as the border router for the controllers As far as the peripherals are concerned temp sensors/light sensor/humidity sensor for monitoring. For control mostly our own hardware Relay or PWM output to control/dim ballasts or LED fixtures etc


This is well known in IoT field I assume, I used it a few years back, after comparing with tinyos and such. Basically you have Linux, then FreeRTOS, then Contiki, from large system to the tiny devices.


Based on this embedded systems survey [1], FreeRTOS is actually quite popular.

http://www.freertos.org/

[1] http://www.eetimes.com/document.asp?doc_id=1322014&print=yes


Can anyone recommend hardware for trying this out? I'm tempted to get a Redwire Econotag II....


When I was looking to experiment with Contiki I realized that most of the supported micro controllers are a lot more powerful than an Arduino or something comparable, and a lot more expensive for a development board.

There are some ports to low cost hardware - the arduino port for atmel chips [1] and a port to the TI launchpad [2], which is a $3 chip.

https://github.com/contiki/contiki-arduino https://github.com/msloth/contiki-launchpad


If you are comfortable with it, I think assembling your own openmotes[1] is the cheapest option. The actual parts on there are relatively cheap and hand solderable if you are okay with CFN components. In addition, there are other cheap and relatively easy options available in the community if you are feeling more adventurous. [2]

[1] http://www.openmote.com/openmote-cc2538/ [2] https://github.com/dmarion/cc2538-dev


Arduino is pretty workable. Add shields, off you go .. See this: https://www.youtube.com/watch?v=OSTGMvvjDHE


I don't quite understand how helpful an OS like this is in the kind of programs you write for the Arduino (say a single loop or timer acquiring temperature and publishing via radio).

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...)


Microcontrollers are very useful if you have very tight power constraints because they have much less complexity than application processors and thus require much less power. For instance, the CC2538 uses ~1uA when sleeping whereas the best I have seen quoted for a Raspberry Pi (using a SleepyPi module), is ~500uA. [1]

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.

[1] http://spellfoundry.com/sleepy-pi/sleepy-pi-faq/#What_Is_The...


you get multi threading, which is helpful for reading sensors and listening to the radio at the same time, or prioritzing urgent tasks.

the hardware abstractions look like they allow you to reuse application code with different hardware drivers too, which is nice.


Not very many people are using it, making it extremely expensive to develop for. Or extremely limited hardware, or extreme labor costs. As you specify its hard economically to specify contiki rather than RasPi or Arduino.

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)


> the kind of programs you write for the Arduino

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. :)


If you are in the US, I'd say that's one of the best bets. Although it's a little expensive I think it's one of the best supported platforms.


The Econotag II is $65 - http://www.redwirellc.com/collections/frontpage/products/eco... - do you need their router to do anything useful with this?


if you want to be able to get your data out into the web then the answer is: yes


Please remove the facebook tracking snippet from the url before posting on HN.


Thanks. We removed it.


Suported hardware: http://contiki-os.org/hardware.html. Lot of major players in there it seems.


The part I'm interested in for now. It will be fun to have it running inside a C64 emulator on a $50 Android tablet http://contiki.cbm8bit.com


I wonder about name liabilities with the other famous Contiki.

http://www.contiki.com/


It worked out okay for Python.


Little-known ?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: