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)
Sorry for the many errors in grammar and spelling (and the missing complimentary close). Accidentaly hit the send button before reading through the mail again…
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.
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).
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
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.
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
Will this refactoring effort allow for multiple interfaces on a single RIOT device?
What about bringing the border router support back into a state where a real, well designed RIOT based border router? Or, is the role of a border router better filled by Linux and the associated 15.4 driver work that’s being done.
I'm just adding my 2c worth. I'm not really directly answering the question.
Recently I've been using the ESP2866 wifi modules. They're pretty interesting.
I really think at some point, a 'Cloud' approach needs to be considered/discussed.
Yes, there are lots of people that want their own device-space but since a 'Linux Router' is extra hardware+software (that somebody might not want), some sort of cloud notion is worthwhile considering. It's also 'funding-friendly'.
