[vardump]

You don't need a full IP stack in order to do something useful. 32 kB flash and 4 kB RAM is more than enough for basic IP-networking.

http://www.rowley.co.uk/msp430/uip.htm - requires less than 2 kB RAM, 12916 bytes of flash.

http://dunkels.com/adam/miniweb/ - a minimal "web server", supports only one connection at a time among other restrictions. But it needs only 30 bytes of RAM. Yes, 30 bytes, not kilobytes.

[adunk]

Author of miniweb and uIP here. uIP is a real IPv4 stack, with all the needed bells and whistles, but miniweb really is only a super-specific proof-of-concept that is not particularly useful for anything else than demonstrating that it can be done.

While something like uIP definitely can be used (and is being used) for IoT applications, uIP only is an IPv4 endpoint. Most IoT applications have a wireless communication medium which by its nature is fluctuating and unpredictable, so you'll typically want to have support for a self-healing wireless mesh network. Such a mesh network adds a bit of complexity, code footprint, and memory usage. And since existing low-power meshing standards like IETF RPL are defined for IPv6 and not IPv4, you need to have support for IPv6 as well. So in the end, the nice and small footprint of uIP will have grown. Also, the footprint for uIP given on the Rowley page are for the stack alone, and does not include things like radio drivers or an OS scheduler.

For a full-mesh low-power IPv6 IoT system, a more realistic figure is what we have in Thingsquare Mist (http://thingsquare.com/mist/), where mesh nodes with a full Contiki OS and IPv6 support have a code footprint closer to 50k than 12k. That said, we have successfully been running Thingsquare Mist on devices with 32k flash and 4k RAM, like the KL02 ARM device in the article. But this has been for non-mesh fringe nodes that only used UDP/IPv6 multicasts to communicate with its immediate neighbors, and no mesh networking.

[carterschonwald]

very cool. thanks for sharing. Whats a good starting point to understand the network engineering going on at this resource regime?

[adunk]

Just a few quick pointers from the top of my head:

Nice starting point to get a feeling for power/throughput trade-offs in low-power wireless networking: http://sing.stanford.edu/pubs/sing-08-00.pdf

Sensys 2008 paper about web services for tiny IoT systems: http://research.microsoft.com/en-us/um/people/zhao/pubs/tws0...

Proceedings of the IEEE 2010 article on IPv6 for low-power wireless: http://www.cs.berkeley.edu/~jwhui/pubs/jhui-ieeeproc112010.p...

Sensys 2011 papers on trade-offs and interoperability of RPL mesh routing for low-power IPv6 and on TCP for low-power wireless: http://dunkels.com/adam/ko11beyond.pdf http://dunkels.com/adam/duquennoy11lossy.pdf

There are also two books on the subject and a bunch of relevant papers on the Contiki website: http://6lowpan.net/the-book/ http://www.thenextinternet.org/ http://www.contiki-os.org/support.html

(Full disclosure: I'm a co-author on a bunch of those last pointers.)

[carterschonwald]

Thanks! (Thats part of why I asked!)

I'm actually slowly spending a bit of time on the side chewing on how to write a simple user land network stack (mostly because I want to really understand standard transport protocol semantics and performance), so looking at the low power / embedded regime and trying to understand that piece too is just kinda fun :)

[LatvjuAvs]

It made 50% sense to me, but thanks for being awesome :D You sounds like a nice person!