Hi, Just on the subject on uIP: I'm currently working on an emb6 port (in parallel to the lwIP port), which is a proto-thread-less fork of uIP. But as discussed in [1] and by the advantages you have given additionally, it would definitely make sense to run Contiki in RIOT.
Cheers, Martine Am 19.01.2016 11:59 schrieb "Joakim Nohlgård" <joakim.nohlg...@eistec.se>: > 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 > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
