Re: [riot-devel] Border Router and SLIP
Hello Francisco, You do not need RPL for your setup: * Start your border router application and tunslip6 (e.g. beef::1/64) * configure beef::2/64 on interface 6 at the border router and add beef::1 to the neighbor cache on interface 6 (these steps are outlined in the border router README) * add abcd::1 to interface 5 of the border router * connected 6lr applications (e.g. the microcoap example) should receive a RA that contains information about the prefix (abcd::/64) and they configure a global ipv6 address automatically * now you should be able to do a ping6 from/to your microcoap examples. You might however follow the discussion in [1], because there might be problems with IPHC/NHC for this setup. PS: You can use ethos [2] to reduce the number of UARTs for your border router. [1] https://github.com/RIOT-OS/RIOT/issues/4462 [2] https://github.com/RIOT-OS/RIOT/pull/4438 Best, Cenk On 19.01.2016 19:13, Francisco Javier Acosta Padilla wrote: Hello RIOTers! I'm trying to make a small network with 3 samr21 boards, one as a border router connected to my PC via SLIP (using the example gnrc_border_router), and the other two as CoAP servers (using microcoap_server example). My goal is to reach both boards from my PC using Firefox with Copper. For now, I succeeded creating a RPL network with the BR and the two boards (ping6 is working on all boards, the BR as the root). I followed the steps in [1] to configure RPL and [2] for the SLIP interface. I also added a route: fibroute add :: via dev 6 on the BR. Afterwards, I connected the SLIP interface through an USB-Serial cable which is connected directly to the 2nd UART on the samr21 board, but I cannot make work the SLIP interface with tunslip6 (I cannot ping any board from my PC, even the BR). I'm thinking about modify the slip implementation to use only the main UART interface, but as far as I know some people is already working on this. So, my questions are: is there a tutorial or step that I'm missing? Is actually possible to do what I want? Thanks in advance! Cheers! Francisco. [1] https://github.com/RIOT-OS/RIOT/wiki/Tutorial:-RIOT-and-Multi-Hop-Routing-with-RPL#routing-with-rpl-using-the-iot-lab-testbed [2] https://github.com/RIOT-OS/RIOT/blob/master/examples/gnrc_border_router/README.md ___ 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] Border Router and SLIP
Hello RIOTers! I'm trying to make a small network with 3 samr21 boards, one as a border router connected to my PC via SLIP (using the example gnrc_border_router), and the other two as CoAP servers (using microcoap_server example). My goal is to reach both boards from my PC using Firefox with Copper. For now, I succeeded creating a RPL network with the BR and the two boards (ping6 is working on all boards, the BR as the root). I followed the steps in [1] to configure RPL and [2] for the SLIP interface. I also added a route: fibroute add :: via dev 6 on the BR. Afterwards, I connected the SLIP interface through an USB-Serial cable which is connected directly to the 2nd UART on the samr21 board, but I cannot make work the SLIP interface with tunslip6 (I cannot ping any board from my PC, even the BR). I'm thinking about modify the slip implementation to use only the main UART interface, but as far as I know some people is already working on this. So, my questions are: is there a tutorial or step that I'm missing? Is actually possible to do what I want? Thanks in advance! Cheers! Francisco. [1] https://github.com/RIOT-OS/RIOT/wiki/Tutorial:-RIOT-and-Multi-Hop-Routing-with-RPL#routing-with-rpl-using-the-iot-lab-testbed [2] https://github.com/RIOT-OS/RIOT/blob/master/examples/gnrc_border_router/README.md ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
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
[riot-devel] drivers/SAUL
Dear all , I would like to ask you if there is any example of the drivers/saul . Thank you in advance! ___ 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
