Re: [riot-devel] Contiki as a RIOT thread
Hi, That's an excellent idea! Also as you are looking for implementation pointers, maybe it is worthwhile to look at what the company HiKoB did: - for their product, they modified Contiki to run on top of FreeRTOS - a derived version is available here: https://github.com/iot-lab/contiki ( shameless plug: ported to M3 nodes of http://iot-lab.info ) cheers, -- Cedric - Original Message - | From: "Emmanuel Baccelli" | To: "RIOT OS kernel developers" | Sent: Tuesday, January 19, 2016 1:18:57 PM | Subject: Re: [riot-devel] Contiki as a RIOT thread | Hey there, | +1 for the idea on my side too. | cheers | Emmanuel | On Tue, Jan 19, 2016 at 12:45 PM, Kaspar Schleiser < | kas...@schleiser.de > wrote: | | Hey, | | | On 01/19/2016 11:58 AM, Joakim Nohlgård wrote: | | | | I would like to hear any ideas and opinions on this list on how | | | to | | | | | | effectively implement this. | | | | | I really like the possiblity and always bragged that this way it is | | possble, but running RIOT as thread within Contiki is not (in any | | way that makes sense). | | | Kaspar | | | ___ | | | 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Contiki as a RIOT thread
Hey there, +1 for the idea on my side too. cheers Emmanuel On Tue, Jan 19, 2016 at 12:45 PM, Kaspar Schleiser wrote: > Hey, > > On 01/19/2016 11:58 AM, Joakim Nohlgård wrote: > >> I would like to hear any ideas and opinions on this list on how to >> effectively implement this. >> > > I really like the possiblity and always bragged that this way it is > possble, but running RIOT as thread within Contiki is not (in any way that > makes sense). > > Kaspar > > ___ > 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
Re: [riot-devel] Contiki as a RIOT thread
Hey, On 01/19/2016 11:58 AM, Joakim Nohlgård wrote: I would like to hear any ideas and opinions on this list on how to effectively implement this. I really like the possiblity and always bragged that this way it is possble, but running RIOT as thread within Contiki is not (in any way that makes sense). Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Contiki as a RIOT thread
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" : > 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
[riot-devel] Contiki as a RIOT thread
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
