Many legacy applications are built on Contiki, and many papers on IoT are written around tests done on Contiki. Contiki also has a quite large community who work with applications on the platform.
Because of this it would be useful to have a way of running Contiki applications and projects under RIOT with minimal porting effort.
Contiki is effectively running on the hardware as a single thread with some preprocessor magic to make the protothread functions behave as if they are cooperatively multitasked threads, which makes it quite doable to run Contiki as a subprocess/thread inside a RIOT system.
It would also be possible to use Contiki's uIP as an alternative network stack to gnrc, just like the lwIP port in https://github.com/RIOT-OS/RIOT/pull/3551.
Some important points to know about Contiki from a RIOT perspective: - Tick-based (platform specific, but usually 64 Hz) - Cooperative scheduling of protothreads, which are not "full" threads, but more light weight, no individual stacks etc. - There is a native port which runs on Linux, just like RIOT native. - Contiki's network stack is somewhat modularised to allow for swapping radio devices, mac layer etc. - No real time guarantees, as far as I know.
A starting point might be to use the native platform and to apply an adaptation layer to allow netdev2 devices to be used as output by Contiki's uIP stack. Another way would be to write an adaptation layer between Contiki uIP and RIOT conn, to use gnrc instead of uIP.
Benefits from this would be that we could for example use 6TSCH in uIP on RIOT and/or the lwm2m and IPSO smart object implementation from Contiki. Since RIOT is, in my opinion, way superior with regards to hardware support and its hardware abstraction layers, and with many drivers for common sensor devices already implemented it might attract some Contiki users to try RIOT for their IoT projects.
I would like to hear any ideas and opinions on this list on how to effectively implement this.
Best regards, Joakim