Re: [riot-devel] RIOT/OpenWSN and TSCH support
Hi Adam! > What are the chances that there will be video of this talk available for > those of us who aren't so fortunate to live in the vicinity of IoT-Lab? Actually quiet high. We're planning to make a screencast of it. But I cannot promise a timeframe when this might happen. Cheers, Oleg -- /* Fuck me gently with a chainsaw... */ linux-2.0.38/arch/sparc/kernel/ptrace.c pgp6CS4MmlgrH.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT/OpenWSN and TSCH support
What are the chances that there will be video of this talk available for those of us who aren't so fortunate to live in the vicinity of IoT-Lab? On Thu Nov 06 2014 at 11:36:53 AM Oleg Hahm wrote: > Hey Thomas! > > > Happy to mention RIOT, I didn't know you were there :-) > > Yes, tomorrow I'll give a tutorial about RIOT on IoT-Lab. It was very nice > talk, by the way. Particular, taking the time of day into account. ;-) > > Cheers, > Oleg > -- > The best thing about declarative jokes is that you only have to prescribe > laughter, no need to actually tell the joke. > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] FIB redesign
Hi Martine & Martin, following a personal discussion, the approach of multiple FIB tables (per IF / protocol) is off the table, now. There will and can be only one FIB. Important for the next steps are discussion and conclusion about a viable (internal) data structure for the FIB ... it seems there are trade-offs between memory and processing constraints. Marin shall present proposals for a thorough review discussion soon. Cheers, Thomas On 05.11.2014 15:10, Landsmann, Martin wrote: Hi all, I started a prototype implementation [1] under consideration of the diagram on the wiki page [2]. - It provides a generic address handling and access - a basic FIB table management (add, remove, update) - collision detection for next_hops and resolving the conflict based on a preference table - reactive RP signalling using `msg_send_receive()` This prototype is not included between any RP and the `get_next_hop()` right now. Best regards, Martin [1] git pull https://github.com/BytesGalore/RIOT add_fib [2] https://github.com/RIOT-OS/RIOT/wiki/Rough-sketch-of-a-possible-FIB-modularization On 04.11.2014 11:05, Martin wrote: Hi Martine, thx for the input :) > Are you planning to only consider stateless compression (Prefix is assumed link-local) or also stateful compression (Prefix is determined by a 4-bit context ID [1] ... I plan to make it more generic, e.g. allow for providing even proprietary "solutions" for FIB table entry compression. LOWPAN_IPHC provides wonderful mechanisms to save bytes in transmissions, but there are probably (most likely) more possibilities to save bytes on the individual nodes RAM when maintaining a FIB table. Eventually the FIB will "resolve" the applied compression to provide the type required by a `get_next_hop()` request. >... we might want to consider to put those information into the same data structure (so the later of my 2 suggestions above would be) Indeed, that would by great. That's the reason I want to outsource the "Generic address" from the FIB table entry. These blobs can be shared among processes, e.g. FIB, routing protocol and ND. Liftime invalidation and such is controlled by the individual process. For instance, an expired FIB table entry would mark its internal structure as invalid and decrease the usecount of the "Generic address". > Also: have you considered Mesh-under routing [5]? (Do we have to consider this here I wonder myself? We don't have support for it anyways, so far.) [6] states some requirements for this. No, I only considered to "play" at the network layer level for now. But I will have a look. Best Regards, Martin Hi, I finally came to it to read your suggestions, too. Regarding the fact that you keep 6LoWPAN header compression in mind, too: Are you planning to only consider stateless compression (Prefix is assumed link-local) or also stateful compression (Prefix is determined by a 4-bit context ID [1], disseminated through the PAN via the context identifier option in RS [2]). Since Neighbor Cache [3], Prefix Information [4], Forwarding information, and Context Information are all very related, and we may want to save memory, we might want to consider to put those information into the same data structure (so the later of my 2 suggestions above would be). Keep in mind though, that both Prefix Information Base and Context information Base have their own lifecycles (see regarding RFCs). Also: have you considered Mesh-under routing [5]? (Do we have to consider this here I wonder myself? We don't have support for it anyways, so far.) [6] states some requirements for this. Hope this was more helpful, than confusing ;-). Cheers, Martine [1] https://tools.ietf.org/html/rfc6282#section-3.1.2 [2] https://tools.ietf.org/html/rfc6775#section-4.2 [3] http://tools.ietf.org/html/rfc4861#section-5.1 [4] https://tools.ietf.org/html/rfc4861#section-4.6.2 [5] https://tools.ietf.org/html/rfc4944#section-11 [6] http://tools.ietf.org/html/rfc6606 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT/OpenWSN and TSCH support
Hey Thomas! > Happy to mention RIOT, I didn't know you were there :-) Yes, tomorrow I'll give a tutorial about RIOT on IoT-Lab. It was very nice talk, by the way. Particular, taking the time of day into account. ;-) Cheers, Oleg -- The best thing about declarative jokes is that you only have to prescribe laughter, no need to actually tell the joke. pgpkcJqeeday3.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT/OpenWSN and TSCH support
I'd love to attend IETF93 if for no other reason than I have yet to get myself to Prague. Unfortunately, I don't think I'll be about to swing the US$1200 in airfare plus accommodations. I really need to find myself some wealthy benefactor interested in WSN research. On Thu, Nov 6, 2014 at 11:27 AM, Oleg Hahm wrote: > Hi Thomas! > > > Note that the 6TiSCH WG, in conjunction with ETSI, will organize a 6TiSCH > > interop event during IETF93 (July 2015, Prague) around 6TISCH technology, > > so including IEEE802.15.4e TSCH. You (and RIOT of course!) might be > > interested in participating. The plan is to come up with writing the test > > spec by March 2015. > > We will most certainly participate - and not only because Prague is just a > stone's throw (how RIOTy...) away from Berlin. ;-) > > > BTW, I happen to be giving a talk about OpenWSN in 90min ( > > > https://swarmlab.eecs.berkeley.edu/events/2014/8/22/5118/openwsn-technical-overview-status-and-road-ahead > ), > > which is streamed live online. I'll talk about the RIOT integration, so > you > > might be interested to listen. > > By the way, thanks for the nice mentioning of RIOT this morning at the > IoT-Lab > inauguration. > > Cheers, > Oleg > -- > /* panic?? These should never occur in our application. */ > linux-2.6.6/drivers/scsi/aic7xxx/aiclib.c > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT/OpenWSN and TSCH support
Oleg, Excellent, glad to hear that you plan on participating. Happy to mention RIOT, I didn't know you were there :-) Thomas On Thu, Nov 6, 2014 at 11:27 AM, Oleg Hahm wrote: > Hi Thomas! > > > Note that the 6TiSCH WG, in conjunction with ETSI, will organize a 6TiSCH > > interop event during IETF93 (July 2015, Prague) around 6TISCH technology, > > so including IEEE802.15.4e TSCH. You (and RIOT of course!) might be > > interested in participating. The plan is to come up with writing the test > > spec by March 2015. > > We will most certainly participate - and not only because Prague is just a > stone's throw (how RIOTy...) away from Berlin. ;-) > > > BTW, I happen to be giving a talk about OpenWSN in 90min ( > > > https://swarmlab.eecs.berkeley.edu/events/2014/8/22/5118/openwsn-technical-overview-status-and-road-ahead > ), > > which is streamed live online. I'll talk about the RIOT integration, so > you > > might be interested to listen. > > By the way, thanks for the nice mentioning of RIOT this morning at the > IoT-Lab > inauguration. > > Cheers, > Oleg > -- > /* panic?? These should never occur in our application. */ > linux-2.6.6/drivers/scsi/aic7xxx/aiclib.c > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT/OpenWSN and TSCH support
Hi Thomas! > Note that the 6TiSCH WG, in conjunction with ETSI, will organize a 6TiSCH > interop event during IETF93 (July 2015, Prague) around 6TISCH technology, > so including IEEE802.15.4e TSCH. You (and RIOT of course!) might be > interested in participating. The plan is to come up with writing the test > spec by March 2015. We will most certainly participate - and not only because Prague is just a stone's throw (how RIOTy...) away from Berlin. ;-) > BTW, I happen to be giving a talk about OpenWSN in 90min ( > https://swarmlab.eecs.berkeley.edu/events/2014/8/22/5118/openwsn-technical-overview-status-and-road-ahead), > which is streamed live online. I'll talk about the RIOT integration, so you > might be interested to listen. By the way, thanks for the nice mentioning of RIOT this morning at the IoT-Lab inauguration. Cheers, Oleg -- /* panic?? These should never occur in our application. */ linux-2.6.6/drivers/scsi/aic7xxx/aiclib.c pgpJNCQHF6j0d.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Periodical (virtual) meetings
Sorry to sound like a skipping record but what are the chances that there's a copy of the meeting archived somewhere. I've been ill the past few days and slept through the meeting. On Thu, Nov 6, 2014 at 4:48 AM, Teemu Hakala wrote: > > On 5.11.2014, at 17:56, Hauke Petersen > wrote: > > as Oleg promised below, we are going to try out Daviko's PlaceCam for > todays meeting. > > Hi all > > So, how did the PlaceCam work? I'm interested in joining your meetings and > naturally the forthcoming meeting about testing is if great interest to me. > How do you solve multiple persons in a location? Is it enough to just have > good speakers, what about microphones? > > - t > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] RIOT/OpenWSN and TSCH support
[was: Refectoring the network stack] Adam, all, I'm co-leading the OpenWSN project. CC'ing the OpenWSN ML. In 2014, the IETF 6TiSCH working group (which is standardizing how to use IEEE802.15.4e TSCH in combination with 6LoWPAN, RPL, CoAP) organized two "plugfests": - in London in March ( https://bitbucket.org/6tisch/meetings/wiki/140306a_ietf89_london_plugfest ) - in Toronto in July ( https://bitbucket.org/6tisch/meetings/wiki/140720a_ietf90_toronto_plugfest ) For those events, the RIOT team (Thomas Eichinger leading the effort) developed a mechanism to use the OpenWSN protocol stack in conjunction with RIOT's task scheduler. A very cool design, indeed! Following this success, the OpenWSN team is re-architecting its code so that the "kernel" can be dynamically changed at compile time. Choices will be openos (the native OpenWSN scheduler), RIOT and FreeRTOS. Lead on that project is Xavi Vilajosana, details at https://openwsn.atlassian.net/browse/FW-16. Note that the 6TiSCH WG, in conjunction with ETSI, will organize a 6TiSCH interop event during IETF93 (July 2015, Prague) around 6TISCH technology, so including IEEE802.15.4e TSCH. You (and RIOT of course!) might be interested in participating. The plan is to come up with writing the test spec by March 2015. BTW, I happen to be giving a talk about OpenWSN in 90min ( https://swarmlab.eecs.berkeley.edu/events/2014/8/22/5118/openwsn-technical-overview-status-and-road-ahead), which is streamed live online. I'll talk about the RIOT integration, so you might be interested to listen. Thomas On Thu, Nov 6, 2014 at 10:24 AM, Martine Lenders wrote: > > >> > >> Am 06.11.2014 18:38 schrieb "Adam Hunt" : > >> > > >> > Is support for TSCH in there somewhere? While I'm not entirely read > up on the spec it would seem to be fairly important these days. > >> > > >> > What is the current state of TSCH support in RIOT these days? I'm > stuck on my phone at the moment or I'd take a look for myself (really, it > probably has a bit more to do with my being hungover and slightly lazy this > morning). > >> > >> Currently use the already existing TSCH implentation OpenWSN. So that's > where it is hiding ;) > >> > >> Cheers, > >> Martine > >> > >> > > >> > --adam > >> > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
I expect to have some real hardware in hand (CC2538 based boards of my own design, and possibly some MSP430 boards after that) in the coming weeks (months if I don't get into gear). I'd be more than willing to contribute some whatever time is needed to running tests on real hardware if it's helpful (assuming that I have the gear, my LA isn't the greatest but that could change). On a related note, how much (if any) of RIOT's code base is covered by real unit tests? Has any thought been given to a TDD type of unit test battery? With the all the refactoring going on in the network stack this might be the perfect time to get serious about writing some tests. On Wed, Nov 5, 2014 at 10:58 PM, Teemu Hakala wrote: > On 5.11.2014, at 17:42, Martine Lenders wrote: > > 2014-11-05 16:24 GMT+01:00 Philipp Rosenkranz < > philipp.rosenkr...@fu-berlin.de>: > >> Dear RIOTers, >> >> in order to discuss possible enhancements to our current test >> setup I would like to invite you to a dedicated RIOT testing meeting. >> >> The main topics to discuss will be: >> >> * Automated hardware based regression testing. >> > > This is where we have existing code for Robot Framework. ELL-i is able to > run unit tests > in real hardware and apply tests with a logic analyser. > > > * CI systems: Jenkins / buildbot or both? >> * Simulations / Virtualization as part of our testing strategy. >> > > I'd like that whatever test system it is, an individual developer could > run it even offline. > For this goal, virtualization seems to be the easiest path. > > > We also should discuss robot framework [1] as suggested by ELL-i at the > workshop. I did not look into it too much, but from as much as I gathered > it might be helpful to automate a lot of already existing tests in our > `tests/` directory. It's also integratable into Jenkins if this is > important to you [2]. > > > RF is Python and its test cases are in wiki markdown format. This makes it > easy to separate test spec from the testing framework itself allows > nonprogrammers to participate in some of the generating of test cases. I'm > hoping Asif can join the meeting as he is the key RF person for ELL-i and > has written bidirectional Python<->C hooks for running unit tests against > the ELL-i emulator. The emulator itself is emulating a MCU including > register controlled peripherals so we have some interesting tests coming > up. It could be used in Riot OS context as well. > > - t > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Am 06.11.2014 18:56 schrieb "Adam Hunt" : > > I'm sorry, somehow I missed the point where you mentioned 802.15.4e. Feel free to ignore me. After last night I shouldn't be allowed to post in public forums full of people smarter than I. No need to be sorry. I'm guilty of this "falacy", too! xD > > --adam > > On Nov 6, 2014 9:46 AM, "Martine Lenders" wrote: >> >> Hi Adam, >> >> Am 06.11.2014 18:38 schrieb "Adam Hunt" : >> > >> > Is support for TSCH in there somewhere? While I'm not entirely read up on the spec it would seem to be fairly important these days. >> > >> > What is the current state of TSCH support in RIOT these days? I'm stuck on my phone at the moment or I'd take a look for myself (really, it probably has a bit more to do with my being hungover and slightly lazy this morning). >> >> Currently use the already existing TSCH implentation OpenWSN. So that's where it is hiding ;) >> >> Cheers, >> Martine >> >> > >> > --adam >> > >> > On Nov 5, 2014 9:15 AM, "Martine Lenders" wrote: >> >> >> >> Hi, >> >> as discussed on the virtual meeting we aim to have the new network stack running with the next release (end of November or before christmas). Currently, I'm the only one directly involved into the development (appart from several radio driver implementations), and while parts of the model come from me, Hauke is currently refining it. As for development it is clear, that I can't be the only one working on it. >> >> >> >> I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I still need some kind of way to communicate with the transceiver module for older boards (alternative would be to remove it, but for this we need #1772 and #1733 merged and all boards moved to the low-level driver model). I hope I have this done at the end of next week. >> >> >> >> All in all it's still a long way to the transport layer and to speed things up, I thought some of you guys may want to help me. I tried to split down the tasks at hand and assigned preliminary some people who might be able to do it. If you do not want/can not do this task, please notify this. Also if you want to take over a task do tell so too, please. Every assignment with a question mark is not fixed yet. >> >> >> >> * Model (Martine? and Hauke) >> >> * 6LoWPAN >> >> - backwards compatibility with transceiver module (Martine) >> >> - bug-hunting (Martine) >> >> - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, depends on a running ND for IPv6) >> >> - optional: Next header compression (Oleg?) >> >> * IPv6 >> >> - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) >> >> - consistent and extendable IPv6 Extension Header API (Martine?) >> >> - consistent and extendable ICMPv6 API (Lotte?) >> >> - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) >> >> * Transport layer >> >> - port to netapi and pktbuf (Cenk?) >> >> >> >> * optional tasks for full deprecation of `transceiver`: >> >> - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) and CCNlite to netapi or netdev >> >> - port boards that use cc110x to periph API or port cc110x_legacy and cc110x_legacy_csma to netdev >> >> - either removal or port to netdev of redbee-econotag >> >> >> >> >> >> ___ >> >> devel mailing list >> >> devel@riot-os.org >> >> http://lists.riot-os.org/mailman/listinfo/devel >> >> >> > >> > ___ >> > devel mailing list >> > devel@riot-os.org >> > http://lists.riot-os.org/mailman/listinfo/devel >> > >> >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
I'm sorry, somehow I missed the point where you mentioned 802.15.4e. Feel free to ignore me. After last night I shouldn't be allowed to post in public forums full of people smarter than I. --adam On Nov 6, 2014 9:46 AM, "Martine Lenders" wrote: > Hi Adam, > > Am 06.11.2014 18:38 schrieb "Adam Hunt" : > > > > Is support for TSCH in there somewhere? While I'm not entirely read up > on the spec it would seem to be fairly important these days. > > > > What is the current state of TSCH support in RIOT these days? I'm stuck > on my phone at the moment or I'd take a look for myself (really, it > probably has a bit more to do with my being hungover and slightly lazy this > morning). > > Currently use the already existing TSCH implentation OpenWSN. So that's > where it is hiding ;) > > Cheers, > Martine > > > > > --adam > > > > On Nov 5, 2014 9:15 AM, "Martine Lenders" > wrote: > >> > >> Hi, > >> as discussed on the virtual meeting we aim to have the new network > stack running with the next release (end of November or before christmas). > Currently, I'm the only one directly involved into the development (appart > from several radio driver implementations), and while parts of the model > come from me, Hauke is currently refining it. As for development it is > clear, that I can't be the only one working on it. > >> > >> I'm currently in the testing stage of 6LoWPAN but it is mostly done, > but I still need some kind of way to communicate with the transceiver > module for older boards (alternative would be to remove it, but for this we > need #1772 and #1733 merged and all boards moved to the low-level driver > model). I hope I have this done at the end of next week. > >> > >> All in all it's still a long way to the transport layer and to speed > things up, I thought some of you guys may want to help me. I tried to split > down the tasks at hand and assigned preliminary some people who might be > able to do it. If you do not want/can not do this task, please notify this. > Also if you want to take over a task do tell so too, please. Every > assignment with a question mark is not fixed yet. > >> > >> * Model (Martine? and Hauke) > >> * 6LoWPAN > >> - backwards compatibility with transceiver module (Martine) > >> - bug-hunting (Martine) > >> - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, > depends on a running ND for IPv6) > >> - optional: Next header compression (Oleg?) > >> * IPv6 > >> - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) > >> - consistent and extendable IPv6 Extension Header API (Martine?) > >> - consistent and extendable ICMPv6 API (Lotte?) > >> - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 > (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) > >> * Transport layer > >> - port to netapi and pktbuf (Cenk?) > >> > >> * optional tasks for full deprecation of `transceiver`: > >> - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) > and CCNlite to netapi or netdev > >> - port boards that use cc110x to periph API or port cc110x_legacy and > cc110x_legacy_csma to netdev > >> - either removal or port to netdev of redbee-econotag > >> > >> > >> ___ > >> devel mailing list > >> devel@riot-os.org > >> http://lists.riot-os.org/mailman/listinfo/devel > >> > > > > ___ > > devel mailing list > > devel@riot-os.org > > http://lists.riot-os.org/mailman/listinfo/devel > > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Hi Adam, Am 06.11.2014 18:38 schrieb "Adam Hunt" : > > Is support for TSCH in there somewhere? While I'm not entirely read up on the spec it would seem to be fairly important these days. > > What is the current state of TSCH support in RIOT these days? I'm stuck on my phone at the moment or I'd take a look for myself (really, it probably has a bit more to do with my being hungover and slightly lazy this morning). Currently use the already existing TSCH implentation OpenWSN. So that's where it is hiding ;) Cheers, Martine > > --adam > > On Nov 5, 2014 9:15 AM, "Martine Lenders" wrote: >> >> Hi, >> as discussed on the virtual meeting we aim to have the new network stack running with the next release (end of November or before christmas). Currently, I'm the only one directly involved into the development (appart from several radio driver implementations), and while parts of the model come from me, Hauke is currently refining it. As for development it is clear, that I can't be the only one working on it. >> >> I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I still need some kind of way to communicate with the transceiver module for older boards (alternative would be to remove it, but for this we need #1772 and #1733 merged and all boards moved to the low-level driver model). I hope I have this done at the end of next week. >> >> All in all it's still a long way to the transport layer and to speed things up, I thought some of you guys may want to help me. I tried to split down the tasks at hand and assigned preliminary some people who might be able to do it. If you do not want/can not do this task, please notify this. Also if you want to take over a task do tell so too, please. Every assignment with a question mark is not fixed yet. >> >> * Model (Martine? and Hauke) >> * 6LoWPAN >> - backwards compatibility with transceiver module (Martine) >> - bug-hunting (Martine) >> - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, depends on a running ND for IPv6) >> - optional: Next header compression (Oleg?) >> * IPv6 >> - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) >> - consistent and extendable IPv6 Extension Header API (Martine?) >> - consistent and extendable ICMPv6 API (Lotte?) >> - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) >> * Transport layer >> - port to netapi and pktbuf (Cenk?) >> >> * optional tasks for full deprecation of `transceiver`: >> - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) and CCNlite to netapi or netdev >> - port boards that use cc110x to periph API or port cc110x_legacy and cc110x_legacy_csma to netdev >> - either removal or port to netdev of redbee-econotag >> >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel >> > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Is support for TSCH in there somewhere? While I'm not entirely read up on the spec it would seem to be fairly important these days. What is the current state of TSCH support in RIOT these days? I'm stuck on my phone at the moment or I'd take a look for myself (really, it probably has a bit more to do with my being hungover and slightly lazy this morning). --adam On Nov 5, 2014 9:15 AM, "Martine Lenders" wrote: > Hi, > as discussed on the virtual meeting we aim to have the new network stack > running with the next release (end of November or before christmas). > Currently, I'm the only one directly involved into the development (appart > from several radio driver implementations), and while parts of the model > come from me, Hauke is currently refining it. As for development it is > clear, that I can't be the only one working on it. > > I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I > still need some kind of way to communicate with the transceiver module for > older boards (alternative would be to remove it, but for this we need #1772 > and #1733 merged and all boards moved to the low-level driver model). I > hope I have this done at the end of next week. > > All in all it's still a long way to the transport layer and to speed > things up, I thought some of you guys may want to help me. I tried to split > down the tasks at hand and assigned preliminary some people who might be > able to do it. If you do not want/can not do this task, please notify this. > Also if you want to take over a task do tell so too, please. Every > assignment with a question mark is not fixed yet. > > * Model (Martine? and Hauke) > * 6LoWPAN > - backwards compatibility with transceiver module (Martine) > - bug-hunting (Martine) > - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, > depends on a running ND for IPv6) > - optional: Next header compression (Oleg?) > * IPv6 > - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) > - consistent and extendable IPv6 Extension Header API (Martine?) > - consistent and extendable ICMPv6 API (Lotte?) > - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 > (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) > * Transport layer > - port to netapi and pktbuf (Cenk?) > > * optional tasks for full deprecation of `transceiver`: > - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) > and CCNlite to netapi or netdev > - port boards that use cc110x to periph API or port cc110x_legacy and > cc110x_legacy_csma to netdev > - either removal or port to netdev of redbee-econotag > > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Periodical (virtual) meetings
On 5.11.2014, at 17:56, Hauke Petersen wrote: > as Oleg promised below, we are going to try out Daviko's PlaceCam for todays > meeting. Hi all So, how did the PlaceCam work? I'm interested in joining your meetings and naturally the forthcoming meeting about testing is if great interest to me. How do you solve multiple persons in a location? Is it enough to just have good speakers, what about microphones? - t signature.asc Description: Message signed with OpenPGP using GPGMail ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Interested in implementing a driver for MRF24J40MA
Hi again, just saw that you mentioned the radio in the subject, never mind my question about the radio... Cheers, Hauke On 06.11.2014 10:24, Hauke Petersen wrote: Hi Guillermo, welcome to RIOT also from my side! Can you maybe provide some more details on the specific LPCxpresso board you are targeting, especially on the radio that is included? For you porting efforts, best keep close to the structure of the ARM Cortex-M based boards, as these are the newest and cleanest ports that keep to the intended board/cpu structure. For example the STM discovery or the iot-lab_M3 boards should give you a solid foundation. Be careful with the mbed_lpc1768 though, as this port is very rudimentary and does not fully comply with the structure we intend to use... Let us know if you need any assistance! Cheers, Hauke On 06.11.2014 06:45, Guillermo Reyes wrote: Hi people. New comer to RIOT, working on an LPCxpresso board, got RIOT running at some extend in the board. Now I'm interested on implementing a driver for this transceiver, hardware timers, rtc, spi, etc... but don't really know which APIs should I use. I have been digging the source, doxygen documentation, mailing list, issues, etc. and don't have a clear vision of direction the development efforts are leaning to... Should I start using the Peripheral drivers APIs? I think the APIs are some what clean and clear, but I can't seem to find any consumers of those APIs in the main tree. If those APIs are going to be the HAL for RIOT I could start using them and contribute some feedback and testing of hardware independent drivers with those APIs. Implementing a good HAL is fundamental to a portable OS, like *BSDs ( I specially like the NetBSD APIs), and for making RIOT a big player in the IoT. Could someone orient me in the right direction. Thanks. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Interested in implementing a driver for MRF24J40MA
Hi Guillermo, welcome to RIOT also from my side! Can you maybe provide some more details on the specific LPCxpresso board you are targeting, especially on the radio that is included? For you porting efforts, best keep close to the structure of the ARM Cortex-M based boards, as these are the newest and cleanest ports that keep to the intended board/cpu structure. For example the STM discovery or the iot-lab_M3 boards should give you a solid foundation. Be careful with the mbed_lpc1768 though, as this port is very rudimentary and does not fully comply with the structure we intend to use... Let us know if you need any assistance! Cheers, Hauke On 06.11.2014 06:45, Guillermo Reyes wrote: Hi people. New comer to RIOT, working on an LPCxpresso board, got RIOT running at some extend in the board. Now I'm interested on implementing a driver for this transceiver, hardware timers, rtc, spi, etc... but don't really know which APIs should I use. I have been digging the source, doxygen documentation, mailing list, issues, etc. and don't have a clear vision of direction the development efforts are leaning to... Should I start using the Peripheral drivers APIs? I think the APIs are some what clean and clear, but I can't seem to find any consumers of those APIs in the main tree. If those APIs are going to be the HAL for RIOT I could start using them and contribute some feedback and testing of hardware independent drivers with those APIs. Implementing a good HAL is fundamental to a portable OS, like *BSDs ( I specially like the NetBSD APIs), and for making RIOT a big player in the IoT. Could someone orient me in the right direction. Thanks. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Hi, On 11/05/14 18:15, Martine Lenders wrote: * Transport layer - port to netapi and pktbuf (Cenk?) Maybe we should think on how to use messaging with large buffers and adapt netapi accordingly? IMHO it would simplify a lot. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Hi Martine! > I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I > still need some kind of way to communicate with the transceiver module for > older boards (alternative would be to remove it, but for this we need #1772 > and #1733 merged and all boards moved to the low-level driver model). I > hope I have this done at the end of next week. I guess deprecating the old transceiver API completely would be the better approach. Probably the MSB-A2 (+AVSExtrem) and maybe the WSN430-v1_3b are the only somewhat relevant boards where a new driver is missing. But it's probably not too difficult to adapt it to #1772. > - optional: Next header compression (Oleg?) Sure, I can do this. > * Transport layer > - port to netapi and pktbuf (Cenk?) I'm also willing to provide support here, but won't have to much time to work on it directly. > * optional tasks for full deprecation of `transceiver`: > - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) and > CCNlite to netapi or netdev Sounds doable to me from what I know about both stacks. > - port boards that use cc110x to periph API or port cc110x_legacy and > cc110x_legacy_csma to netdev See above. > - either removal or port to netdev of redbee-econotag The infamous econotag... Porting it to the new periph interface could be nice, but I would consider it as optional for the release. Cheers, Oleg -- I'm working on a bittorrent joke, but I only have about 30% and nobody's seeding! pgp41yDBg1cHY.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
