[Contiki-developers] About Contiki

[Chris W. <ch...@ox...>]

I'll add what I can about Contiki...

   - Structure (how is the structure, architecture, applications (why
   Contiki exists?) ...)

In my opinion, Contiki is a kernel that is optimized for memory constrained
systems. It has the minimum functions of an OS, without the overhead of a
full-blown pre-emptive OS. In my opinion, it really shines for protocol
stack design that will be run on systems that have low resources (ie: little
RAM and flash). At least this is what I am using it for.

 The normal OS candidates (Linux, eCOS, VxWorks, etc...) are large and
require a lot of resources to run. For Linux, you would usually need around
10-20 MB of flash and at least 1 MB of RAM to run properly. If you are
thinking about using a normal 8-bit processor, they usually have around
32-128 kB of flash and 2-8 kB of RAM. On these systems, you would not be
able to run one of these OSes, however Contiki can easily handle systems
with these kinds of resources. 

As an aside, Contiki also can run well on a 32-bit processor such as an
ARM7. Most of the ARM7 processors come with 8-32 kB of RAM and 32-512 kB of
flash. At the high end, you can start using the lighter OSes like eCOS, but
Contiki can easily run on the low end with 8kB RAM/32kB flash. From a
manufacturer's standpoint, the less resources you need to use, the cheaper
your product will be. This means that most electronics will gradually spiral
down to the minimum resources they can use in order to perform the required
function. 

Also, Contiki is a stackless OS. When a normal OS changes threads or
processes (context switch), it will push the contents of the registers and
the stack into memory and then load the regs with the info from the new
process. This is how it can remember the context of a different process and
pick up where it left off.

On the other hand, Contiki uses pseudothreads, which are just pointers to
where the thread left off previously. A context switch just consists of
jumping to the next pointer in the queue. There are some things you need to
be careful with this architecture such as loss of automatic variable data,
however there is a really great benefit which is that you can run the OS
inside of another OS. This is unheard of in a standard pre-emptive OS, but
running Contiki inside of Windows/Linux saved my ass more than a couple of
times because its so much easier to debug in a PC environment, rather than
in hardware.

- Processes (scheduling, supported thread types, how are processes
   synchronization)

As mentioned, Contiki uses protothreads to emulate processes and threads.
The scheduling is standard FIFO type event scheduling, where events get
posted to the event queue, and they get called in a first-come fashion.
There are various synchronization mechanisms such as semaphores that are
supported, however I haven't really used them much.

Contiki is a non-preemptive OS which means that each process runs to
completion or to a blocking event before another event can be called. If
you're in a situation where you are using a pre-emptive OS that uses
priority for processes or threads, then Contiki wouldn't be ideal, but for
applications with loose or no real-time requirements, then Contiki should be
fine.

- Memory (how it is managed, swapping, virtual memory)

The memory in Contiki is statically allocated, and is based on memory pools.
I don't think there is any swapping or virtual memory. I'm not an expert on
the Contiki memory handling so it's probably best to ask one of the
developers about this.

That's about it for me. If anyone finds fault with anything I said, please
correct me. 

Chris Wang (aka Akiba)
FreakLabs
Open Source Zigbee Development
http://www.freaklabs.org