New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contiki 3.x Roadmap #422

Open
g-oikonomou opened this Issue Nov 15, 2013 · 56 comments

Comments

Projects
None yet
@g-oikonomou
Contributor

g-oikonomou commented Nov 15, 2013

Discussion thread for features / fixes / goals / changes to be made in Contiki v3.x

  • Easier Connectivity [#524]
  • Focus on IPv6
  • Focus on ARMs
  • Multi RF Channel Support [#525]
  • Crypto / Security support [#526]
  • Improved TCP and UDP API [#527]
  • General Cleanup
  • Larger Group of Mergers
  • Configuration System Sanity [#528]
  • Improve the Debug System [#529]
  • update standard protocols to ensure RFC-compliance
  • implement missing standard of the low-power IP stack (e.g. 6lowpan-nd) [#523]
  • implement 802.15.4e MAC layers (at least CSL (ContikiMAC/Drowsy-style), TSCH and possibly solutions from the IETF 6TiSCH working group)
  • get rid of dependencies between IPv6 and Rime [#499] [#547] [#864] [#890]
  • Multicast support [#364]
  • Multiple Interface Support [#530]
@g-oikonomou

This comment has been minimized.

Show comment
Hide comment
@g-oikonomou

g-oikonomou Nov 15, 2013

Contributor

Initial list populated based on this post:
http://sourceforge.net/mailarchive/message.php?msg_id=31642373

and on the discussion under #403

Contributor

g-oikonomou commented Nov 15, 2013

Initial list populated based on this post:
http://sourceforge.net/mailarchive/message.php?msg_id=31642373

and on the discussion under #403

@g-oikonomou

This comment has been minimized.

Show comment
Hide comment
@g-oikonomou

g-oikonomou Nov 15, 2013

Contributor

I'm gonna sneak multicast support in the OP ;)

Contributor

g-oikonomou commented Nov 15, 2013

I'm gonna sneak multicast support in the OP ;)

@laurentderu

This comment has been minimized.

Show comment
Hide comment
@laurentderu

laurentderu Nov 15, 2013

Member

I would also add a rework/redesign of the slip-radio and slip-radio protocol. Right now it still has many bugs (for example !R messages are sometimes confused with debug traces and dropped, verbosity above 1 corrupts some packets, lost slip packets hangs CSMA, …) Also it does not scale well when you increase the bitrate.

A standardization of the radio api is also needed as right now each platform needs its own piece of code inside slip-radio in order to manage channel, pan-id, mac address, ...

Member

laurentderu commented Nov 15, 2013

I would also add a rework/redesign of the slip-radio and slip-radio protocol. Right now it still has many bugs (for example !R messages are sometimes confused with debug traces and dropped, verbosity above 1 corrupts some packets, lost slip packets hangs CSMA, …) Also it does not scale well when you increase the bitrate.

A standardization of the radio api is also needed as right now each platform needs its own piece of code inside slip-radio in order to manage channel, pan-id, mac address, ...

@g-oikonomou

This comment has been minimized.

Show comment
Hide comment
@g-oikonomou

g-oikonomou Nov 15, 2013

Contributor

@laurentderu If you've discovered bugs with SLIP radio, can I ask you to open an issue with more details and put a bug label on it?

Contributor

g-oikonomou commented Nov 15, 2013

@laurentderu If you've discovered bugs with SLIP radio, can I ask you to open an issue with more details and put a bug label on it?

@adamdunkels

This comment has been minimized.

Show comment
Hide comment
@adamdunkels

adamdunkels Nov 15, 2013

Member

Regarding SLIP: it is really horrible and certainly not the way of the future.

When we at Thingsquare moved to Ethernet for connectivity instead of relying on those old wonky serial-over-USB ports and that dreaded SLIP and that border router stuff, our lives improved significantly 👍

Devices like this one definitely is the way forward: http://www.redwirellc.com/store/node/13

We might need to have SLIP around for those few cases where we can't use regular Ethernet, but I think we should just keep the SLIP stuff out of the way as much as possible.

Member

adamdunkels commented Nov 15, 2013

Regarding SLIP: it is really horrible and certainly not the way of the future.

When we at Thingsquare moved to Ethernet for connectivity instead of relying on those old wonky serial-over-USB ports and that dreaded SLIP and that border router stuff, our lives improved significantly 👍

Devices like this one definitely is the way forward: http://www.redwirellc.com/store/node/13

We might need to have SLIP around for those few cases where we can't use regular Ethernet, but I think we should just keep the SLIP stuff out of the way as much as possible.

@laurentderu

This comment has been minimized.

Show comment
Hide comment
@laurentderu

laurentderu Nov 15, 2013

Member

@g-oikonomou Will do it (maybe with PR if the code has not diverged too much)

The problem boils down to the fact that there is no immediate way to identify packets from commands or requests and so slip-dev relies on heuristics to guess what it has received. One way to move forward would be to switch to a more well defined protocol, like serial-radio.

Member

laurentderu commented Nov 15, 2013

@g-oikonomou Will do it (maybe with PR if the code has not diverged too much)

The problem boils down to the fact that there is no immediate way to identify packets from commands or requests and so slip-dev relies on heuristics to guess what it has received. One way to move forward would be to switch to a more well defined protocol, like serial-radio.

@malvira

This comment has been minimized.

Show comment
Hide comment
@malvira

malvira Nov 15, 2013

Member

On Fri, Nov 15, 2013 at 10:30 AM, Adam Dunkels notifications@github.comwrote:

Regarding SLIP: it is really horrible and certainly not the way of the
future.

When we at Thingsquare moved to Ethernet for connectivity instead of
relying on those old wonky serial-over-USB ports and that dreaded SLIP and
that border router stuff, our lived improved significantly [image: 👍]

Devices like this one definitely is the way forward:
http://www.redwirellc.com/store/node/13

We might need to have SLIP around for those few cases where we can't use
regular Ethernet, but I think we should just keep the SLIP stuff out of the
way as much as possible.


Reply to this email directly or view it on GitHubhttps://github.com/contiki-os/contiki/issues/422#issuecomment-28577033
.

+1 on to the Redwire gear :)

BTW: also http://www.redwirellc.com/store/node/9

Both are pretty fun albeit different. BR12 tunnels out and provides full
global ipv6 addresses to everything (and runs linux). Re: no more SLIP ---
that's happening on the kernel dev too. Linux 6lowpan dev has been
progressing very steadily.

But the real note is I am designing a new batch of hardware which will be
released in Q4 2014. I'm not sure what SoC I'm going to use yet ---
thoughts on that are appreciated.

Feel free to send me wishlists, requests, use cases, features, complaints
etc. I try to make hardware that will stand-alone by itself as something
useful in an application but is also great for development when you open it
up.

-Mar.

Member

malvira commented Nov 15, 2013

On Fri, Nov 15, 2013 at 10:30 AM, Adam Dunkels notifications@github.comwrote:

Regarding SLIP: it is really horrible and certainly not the way of the
future.

When we at Thingsquare moved to Ethernet for connectivity instead of
relying on those old wonky serial-over-USB ports and that dreaded SLIP and
that border router stuff, our lived improved significantly [image: 👍]

Devices like this one definitely is the way forward:
http://www.redwirellc.com/store/node/13

We might need to have SLIP around for those few cases where we can't use
regular Ethernet, but I think we should just keep the SLIP stuff out of the
way as much as possible.


Reply to this email directly or view it on GitHubhttps://github.com/contiki-os/contiki/issues/422#issuecomment-28577033
.

+1 on to the Redwire gear :)

BTW: also http://www.redwirellc.com/store/node/9

Both are pretty fun albeit different. BR12 tunnels out and provides full
global ipv6 addresses to everything (and runs linux). Re: no more SLIP ---
that's happening on the kernel dev too. Linux 6lowpan dev has been
progressing very steadily.

But the real note is I am designing a new batch of hardware which will be
released in Q4 2014. I'm not sure what SoC I'm going to use yet ---
thoughts on that are appreciated.

Feel free to send me wishlists, requests, use cases, features, complaints
etc. I try to make hardware that will stand-alone by itself as something
useful in an application but is also great for development when you open it
up.

-Mar.

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Nov 15, 2013

Contributor

Really nice with this roadmap! Perfect way to get the Contiki development more focused! I'll avoid saying anything on the SLIP topic just to avoid making this a SLIP thread....

  • Regarding focus on ARM and simulation of ARM-based devices in Cooja (or in general). We are working with Cortex-M3 emulation in Cooja - via AntMicro and Realtime Embedded that have been working on an emulator that is called Emul8. We have already made some first succesful experiments with running STM32W with Contiki in Cooja. What is the approach that you have considered so far? Is it integrating QEMU or something else?
  • We are working along the lines of complete autoconfiguration of 802.15.4 with active scan, etc. to get all PANID and channel configuration out of the way. Is that somethings that would be of general interest?!
Contributor

joakimeriksson commented Nov 15, 2013

Really nice with this roadmap! Perfect way to get the Contiki development more focused! I'll avoid saying anything on the SLIP topic just to avoid making this a SLIP thread....

  • Regarding focus on ARM and simulation of ARM-based devices in Cooja (or in general). We are working with Cortex-M3 emulation in Cooja - via AntMicro and Realtime Embedded that have been working on an emulator that is called Emul8. We have already made some first succesful experiments with running STM32W with Contiki in Cooja. What is the approach that you have considered so far? Is it integrating QEMU or something else?
  • We are working along the lines of complete autoconfiguration of 802.15.4 with active scan, etc. to get all PANID and channel configuration out of the way. Is that somethings that would be of general interest?!
@simonduq

This comment has been minimized.

Show comment
Hide comment
@simonduq

simonduq Nov 15, 2013

Member

This thread is soon going to be hard to follow I'm afraid :)
How should we proceed to actually enable discussions on the various topics of the roadmap? Perhaps simply having one distinct github issue for every single item, and having this thread point to each of them? The topics would need a discussion and perhaps even a voting system to agree on a practical solution (a stackoverflow-style system could be an option).

Member

simonduq commented Nov 15, 2013

This thread is soon going to be hard to follow I'm afraid :)
How should we proceed to actually enable discussions on the various topics of the roadmap? Perhaps simply having one distinct github issue for every single item, and having this thread point to each of them? The topics would need a discussion and perhaps even a voting system to agree on a practical solution (a stackoverflow-style system could be an option).

@mcr

This comment has been minimized.

Show comment
Hide comment
@mcr

mcr Nov 15, 2013

Contributor

I've been investigating a minimal PPP implementation.

Contributor

mcr commented Nov 15, 2013

I've been investigating a minimal PPP implementation.

@sdawans

This comment has been minimized.

Show comment
Hide comment
@sdawans

sdawans Nov 15, 2013

Contributor

to build on @simonduq's comment, we ought to use the milestone feature github provides to sort out the different features into short/medium/long term.

6lowpan-nd isn't a one-nighter I'm afraid ;)

Contributor

sdawans commented Nov 15, 2013

to build on @simonduq's comment, we ought to use the milestone feature github provides to sort out the different features into short/medium/long term.

6lowpan-nd isn't a one-nighter I'm afraid ;)

@jarun

This comment has been minimized.

Show comment
Hide comment
@jarun

jarun Nov 17, 2013

Any guidelines on how to proceed for item 10. Debug System? Anyone up for it yet? I am interested but need some light on the 'how' and 'what' part of it.

jarun commented Nov 17, 2013

Any guidelines on how to proceed for item 10. Debug System? Anyone up for it yet? I am interested but need some light on the 'how' and 'what' part of it.

@ivan-lapitski

This comment has been minimized.

Show comment
Hide comment
@ivan-lapitski

ivan-lapitski Nov 18, 2013

Hello! Any thoughts on Zigbee IP & sleepy nodes (described in the Zigbee IP spec) ?

Why?

  1. Interoperability.
  2. Power consumption. (Altough contikimac is great, i'ts not good enough for sensors that only report their data once a day and need to be alive for 10+ years)

ivan-lapitski commented Nov 18, 2013

Hello! Any thoughts on Zigbee IP & sleepy nodes (described in the Zigbee IP spec) ?

Why?

  1. Interoperability.
  2. Power consumption. (Altough contikimac is great, i'ts not good enough for sensors that only report their data once a day and need to be alive for 10+ years)
@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Nov 18, 2013

Contributor

We are testing some sleepy nodes mechanisms right now (on STM32W), but not yet any Zigbee IP. Are there any good Zigbee IP devices to do interop with?

Contributor

joakimeriksson commented Nov 18, 2013

We are testing some sleepy nodes mechanisms right now (on STM32W), but not yet any Zigbee IP. Are there any good Zigbee IP devices to do interop with?

@adamdunkels

This comment has been minimized.

Show comment
Hide comment
@adamdunkels

adamdunkels Nov 20, 2013

Member

@mcr: there is a small ppp here that might be interesting to look at: https://github.com/adamdunkels/contiki-1.x/tree/master/contiki/ppp

@sdawans: github's milestone and issues feature is a great idea!

In general, it is good to have both open ended ideas (e.g. full RFC compliance) and those that are much more closer to actually being merged (e.g. IP multicast) so that we both can make meaningful progress in the short term and have a bigger target to aim for.

I'd like to see the first Contiki 3.0 version out really soon, perhaps already in January if possible.

Member

adamdunkels commented Nov 20, 2013

@mcr: there is a small ppp here that might be interesting to look at: https://github.com/adamdunkels/contiki-1.x/tree/master/contiki/ppp

@sdawans: github's milestone and issues feature is a great idea!

In general, it is good to have both open ended ideas (e.g. full RFC compliance) and those that are much more closer to actually being merged (e.g. IP multicast) so that we both can make meaningful progress in the short term and have a bigger target to aim for.

I'd like to see the first Contiki 3.0 version out really soon, perhaps already in January if possible.

@aguirrem

This comment has been minimized.

Show comment
Hide comment
@aguirrem

aguirrem Nov 21, 2013

Any desire for multiple interface support? It's been mentioned in the mailing list before

aguirrem commented Nov 21, 2013

Any desire for multiple interface support? It's been mentioned in the mailing list before

@laurentderu

This comment has been minimized.

Show comment
Hide comment
@laurentderu

laurentderu Nov 21, 2013

Member

@aguirrem: 👍

Current Contiki UIP stack with its fallback interface provides only limited IPv6 connectivity that works only in the trivial deployment. For Border Router with Ethernet interface multiple interfaces support is mandatory; or you have to emulate one like we did in 6LBR with packet filtering.

Member

laurentderu commented Nov 21, 2013

@aguirrem: 👍

Current Contiki UIP stack with its fallback interface provides only limited IPv6 connectivity that works only in the trivial deployment. For Border Router with Ethernet interface multiple interfaces support is mandatory; or you have to emulate one like we did in 6LBR with packet filtering.

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Nov 21, 2013

Contributor

Yes, multiple interfaces would be a nice feature! 👍

Contributor

joakimeriksson commented Nov 21, 2013

Yes, multiple interfaces would be a nice feature! 👍

@ivan-lapitski

This comment has been minimized.

Show comment
Hide comment
@ivan-lapitski

ivan-lapitski Nov 25, 2013

@joakimeriksson: Cool! I know of no Zigbee IP devices yet (maybe someone else knows?), I guess as a first step it would be wise to analyze the Zigbee IP specification and see if it's worth implementing.

ivan-lapitski commented Nov 25, 2013

@joakimeriksson: Cool! I know of no Zigbee IP devices yet (maybe someone else knows?), I guess as a first step it would be wise to analyze the Zigbee IP specification and see if it's worth implementing.

@laurentderu

This comment has been minimized.

Show comment
Hide comment
Member

laurentderu commented Nov 25, 2013

@AriZuu

This comment has been minimized.

Show comment
Hide comment
@AriZuu

AriZuu Dec 10, 2013

Contributor

I have been using Contiki uIP stack (both IPv4 and IPv6) in another rtos. Generally this has been quite easy, although I had to do some head-scratching when starting to use 2.7 code as there were some dependencies
in IPv6 neighbour code to rime stack. So planning to clean up dependencies sounds great to me.
It would be great if 3.x uIP stack would still be usable (with some porting required, of course) in other environments too as there might be other "old" uIP users like me (for other rtos or bare metal).

Contributor

AriZuu commented Dec 10, 2013

I have been using Contiki uIP stack (both IPv4 and IPv6) in another rtos. Generally this has been quite easy, although I had to do some head-scratching when starting to use 2.7 code as there were some dependencies
in IPv6 neighbour code to rime stack. So planning to clean up dependencies sounds great to me.
It would be great if 3.x uIP stack would still be usable (with some porting required, of course) in other environments too as there might be other "old" uIP users like me (for other rtos or bare metal).

@cdealti

This comment has been minimized.

Show comment
Hide comment
@cdealti

cdealti Dec 28, 2013

@g-oikonomou
6lowpan-nd: as far as I understand this would be mainly useful in a mesh-under lowpan but no such implementation has been defined either by IEEE or IETF. In a route-over lowpan there is significant overlapping between 6lowpan-nd and RPL, making the former unnecessary. There had been flames in the ROLL/6LoWPAN mailing lists in 2010 about this overlapping and the winner seems to be RPL which has been adopted by Zigbee IP (and Contiki of course). As far as I know (can anyone confirm?) 6lowpan-nd has been adopted by ISA100 which should implement a proprietary mesh-under lowpan.
As you know there were/are IPv6/6LoWPAN proprietary stacks running on top of a mesh-under lowpan: Atmel's RUM and Jennic's JenNet-IP but they do not seem to have a large adoption.

About the 802.15.4 MAC: I started working with WSNs on TinyOS. Later on I moved to Zigbee (non IP on a Freescale SoC) and then I discovered Contiki: they all implement their own MAC.
TinyOS and Contiki have a non-standard (and I guess non interoperable) low power MAC. They do not use 802.15.4 MLME primitives such as scans, associations or polls, all stuff used by Zigbee.
They allow for sleeping routers which are not supported by Zigbee 2007. Anyway, how long such sleeping routers will last running off batteries? Years? Zigbee Alliance probably ackowledged that a router could be implemented in a mains powered application such as a light and it was not worthwhile to define a low power MAC for routers (noticeably they could have leveraged the 802.15.4 beacon-enabled functionality but they did not and for a good reason). I think I agree we need to support scans at least.

+1 for the serial-radio, all SoC manufacturers provide such an interface to interact with their stack.
Alternatively to the SLIP framing, Exegin once pointed me out to COBS http://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing.
I think the actual interface really depends on how 6LoWPAN will be eventually supported in the border router.
On Linux I thought this would have happened at the linux-zigbee project. Having kernel support for a true 6LoWPAN interface in the kernel
is the right thing to do I think. They seem to have started porting Contiki's 6LoWPAN implementation but I don't think the code is ready for production and development seems a little slower than in the past. This should be complemented by an RPL daemon using a raw socket (like radvd).

@malvira
is BRamble based on the linux-zigbee project?

@aguirrem
The alternative is the user space implementation at a 6lbr project. I really admire your project but I think it's a short term solution (no flames here).
Contiki aims at providing a stack for constained devices and clearly a border router running Linux has not such limitations.

cdealti commented Dec 28, 2013

@g-oikonomou
6lowpan-nd: as far as I understand this would be mainly useful in a mesh-under lowpan but no such implementation has been defined either by IEEE or IETF. In a route-over lowpan there is significant overlapping between 6lowpan-nd and RPL, making the former unnecessary. There had been flames in the ROLL/6LoWPAN mailing lists in 2010 about this overlapping and the winner seems to be RPL which has been adopted by Zigbee IP (and Contiki of course). As far as I know (can anyone confirm?) 6lowpan-nd has been adopted by ISA100 which should implement a proprietary mesh-under lowpan.
As you know there were/are IPv6/6LoWPAN proprietary stacks running on top of a mesh-under lowpan: Atmel's RUM and Jennic's JenNet-IP but they do not seem to have a large adoption.

About the 802.15.4 MAC: I started working with WSNs on TinyOS. Later on I moved to Zigbee (non IP on a Freescale SoC) and then I discovered Contiki: they all implement their own MAC.
TinyOS and Contiki have a non-standard (and I guess non interoperable) low power MAC. They do not use 802.15.4 MLME primitives such as scans, associations or polls, all stuff used by Zigbee.
They allow for sleeping routers which are not supported by Zigbee 2007. Anyway, how long such sleeping routers will last running off batteries? Years? Zigbee Alliance probably ackowledged that a router could be implemented in a mains powered application such as a light and it was not worthwhile to define a low power MAC for routers (noticeably they could have leveraged the 802.15.4 beacon-enabled functionality but they did not and for a good reason). I think I agree we need to support scans at least.

+1 for the serial-radio, all SoC manufacturers provide such an interface to interact with their stack.
Alternatively to the SLIP framing, Exegin once pointed me out to COBS http://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing.
I think the actual interface really depends on how 6LoWPAN will be eventually supported in the border router.
On Linux I thought this would have happened at the linux-zigbee project. Having kernel support for a true 6LoWPAN interface in the kernel
is the right thing to do I think. They seem to have started porting Contiki's 6LoWPAN implementation but I don't think the code is ready for production and development seems a little slower than in the past. This should be complemented by an RPL daemon using a raw socket (like radvd).

@malvira
is BRamble based on the linux-zigbee project?

@aguirrem
The alternative is the user space implementation at a 6lbr project. I really admire your project but I think it's a short term solution (no flames here).
Contiki aims at providing a stack for constained devices and clearly a border router running Linux has not such limitations.

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Dec 28, 2013

Contributor

Regarding 6lowpan-nd - if you have mesh-under I guess regular IPv6-nd works well, but for route-over there are a few problems (detailed in the 6lowpan-nd spec). And if you read the Zigbee IP specification - this is what at least my copy says:

"5.3.3 Neighbor Discovery
The neighbor discovery protocol MUST be implemented as defined in 6LoWPAN neighbor discovery
specification [RFC 6775].
A ZigBee IP node MUST support the optional mechanisms defined in [RFC 6775] for multihop
distribution of prefix and context information.
A ZigBee IP node MUST support the optional mechanisms defined in [RFC 6775] for multihop
duplicate address detection."

So some elements from it is needed - hopefully not a full implementation, but at least prefix and context information and some of the ND-optimizations are probably useful.

Contributor

joakimeriksson commented Dec 28, 2013

Regarding 6lowpan-nd - if you have mesh-under I guess regular IPv6-nd works well, but for route-over there are a few problems (detailed in the 6lowpan-nd spec). And if you read the Zigbee IP specification - this is what at least my copy says:

"5.3.3 Neighbor Discovery
The neighbor discovery protocol MUST be implemented as defined in 6LoWPAN neighbor discovery
specification [RFC 6775].
A ZigBee IP node MUST support the optional mechanisms defined in [RFC 6775] for multihop
distribution of prefix and context information.
A ZigBee IP node MUST support the optional mechanisms defined in [RFC 6775] for multihop
duplicate address detection."

So some elements from it is needed - hopefully not a full implementation, but at least prefix and context information and some of the ND-optimizations are probably useful.

@cdealti

This comment has been minimized.

Show comment
Hide comment
@cdealti

cdealti Dec 30, 2013

@joakimeriksson
Cool! Thanks for the info. I'm reading the Zigbee IP spec. There's an interesting section on how to join a Zigbee IP network by means of MAC scans and the Mesh Link Establishment protocol. Should Contiki target Zigbee IP compliance (the spec seems fairly complete)? Anyway I think the usual concerns about intellectual property exist...

cdealti commented Dec 30, 2013

@joakimeriksson
Cool! Thanks for the info. I'm reading the Zigbee IP spec. There's an interesting section on how to join a Zigbee IP network by means of MAC scans and the Mesh Link Establishment protocol. Should Contiki target Zigbee IP compliance (the spec seems fairly complete)? Anyway I think the usual concerns about intellectual property exist...

bygreencn pushed a commit to bygreencn/contiki that referenced this issue Jan 3, 2014

gdisirio
Fixed bug #422.
git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@6061 35acf78f-673a-0410-8e92-d51de3d6d3f4
@malvira

This comment has been minimized.

Show comment
Hide comment
@malvira

malvira Jan 4, 2014

Member

@cdealti
currently BRamble does not use the linux 6lowpan implementation, but it certainly could. BRamble is a set of code that provides a UI on border-routers (similar to the webpages WiFi routers serve) to help administer RPL networks. It's all user space code that calls the various admin functions to do setup, maintenance, and reporting.

Member

malvira commented Jan 4, 2014

@cdealti
currently BRamble does not use the linux 6lowpan implementation, but it certainly could. BRamble is a set of code that provides a UI on border-routers (similar to the webpages WiFi routers serve) to help administer RPL networks. It's all user space code that calls the various admin functions to do setup, maintenance, and reporting.

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Jan 21, 2014

Contributor

What about grabbing each of the bullets in the bullet-list and create a separate issue? I'll start with one right now.

Contributor

joakimeriksson commented Jan 21, 2014

What about grabbing each of the bullets in the bullet-list and create a separate issue? I'll start with one right now.

@g-oikonomou

This comment has been minimized.

Show comment
Hide comment
@g-oikonomou

g-oikonomou Jan 21, 2014

Contributor

I've created two milestones 'Contiki 3.0' and 'Contiki-3.x' for short-term and longer-term goals respectively. I've tried to include everything discussed in this thread here, except some bullets which mainly express a 'vision', rather than a specific goal with a clear-cut finishing line.

For .15.4e and Zigbee IP, can I ask someone else to open an issue with more information and invite a conversation?

The 3.0 vs 3.x assignment is a bit arbitrary for the time being, until discussions have made it clear what we want to do now and what we'd rather defer.

Contributor

g-oikonomou commented Jan 21, 2014

I've created two milestones 'Contiki 3.0' and 'Contiki-3.x' for short-term and longer-term goals respectively. I've tried to include everything discussed in this thread here, except some bullets which mainly express a 'vision', rather than a specific goal with a clear-cut finishing line.

For .15.4e and Zigbee IP, can I ask someone else to open an issue with more information and invite a conversation?

The 3.0 vs 3.x assignment is a bit arbitrary for the time being, until discussions have made it clear what we want to do now and what we'd rather defer.

@klh

This comment has been minimized.

Show comment
Hide comment
@klh

klh Feb 12, 2014

Adding better hooks for Real Time/or Laggy/Estimated/onDemand Location Services - based on Time of Flight (TOF) or Received Signal Strength? (RSSI)?

klh commented Feb 12, 2014

Adding better hooks for Real Time/or Laggy/Estimated/onDemand Location Services - based on Time of Flight (TOF) or Received Signal Strength? (RSSI)?

@poppe34

This comment has been minimized.

Show comment
Hide comment
@poppe34

poppe34 Mar 18, 2014

Is there any interest in making a generic Arm CM3/CM4/CM0+ startup that is build from the ground up so it wouldn't be dependent on any licenses. I would like to make one to aid in the addition of multiple manufactures with having a constant startup/clock, and maybe also a bootloader. Or is it a better Idea to keep the manufactures separate and just use CMSIS? I planed on starting this soon but I am kinda holding off for the Atmel code for the new R21s to see what direction those take.

poppe34 commented Mar 18, 2014

Is there any interest in making a generic Arm CM3/CM4/CM0+ startup that is build from the ground up so it wouldn't be dependent on any licenses. I would like to make one to aid in the addition of multiple manufactures with having a constant startup/clock, and maybe also a bootloader. Or is it a better Idea to keep the manufactures separate and just use CMSIS? I planed on starting this soon but I am kinda holding off for the Atmel code for the new R21s to see what direction those take.

@pfalcon

This comment has been minimized.

Show comment
Hide comment
@pfalcon

pfalcon commented Mar 18, 2014

@poppe34: See https://github.com/pfalcon/cortex-uni-startup for such a project (startup part). See also https://github.com/pfalcon/libperipha ("CMSIS" part).

@poppe34

This comment has been minimized.

Show comment
Hide comment
@poppe34

poppe34 Mar 18, 2014

That is pretty much how I would want this implemented. I don't think I would automate the vendor dependent IRQs. I am more asking the community if this is something that Contiki would want done for the RTOS. My version would be more complete and have clock/context_switching and anything else I could think of that is common between arm-m cores.

poppe34 commented Mar 18, 2014

That is pretty much how I would want this implemented. I don't think I would automate the vendor dependent IRQs. I am more asking the community if this is something that Contiki would want done for the RTOS. My version would be more complete and have clock/context_switching and anything else I could think of that is common between arm-m cores.

@nooona

This comment has been minimized.

Show comment
Hide comment
@nooona

nooona Aug 3, 2014

hi a have question please theie is a version of contiki3.x in the nternet?

nooona commented Aug 3, 2014

hi a have question please theie is a version of contiki3.x in the nternet?

@barryzxy

This comment has been minimized.

Show comment
Hide comment
@barryzxy

barryzxy Sep 15, 2014

when Contiki 3.x will be release?

barryzxy commented Sep 15, 2014

when Contiki 3.x will be release?

@adamdunkels

This comment has been minimized.

Show comment
Hide comment
@adamdunkels

adamdunkels Dec 7, 2014

Member

I've been going through everything needed for Contiki 3.0. There have been a lot of good cleanup pull requests recently, as well as a bunch of other good stuff.

Looking back at this list and what we have achieved since we put it together, I think we are very close to the Contiki 3.0 release.

With the llsec patch, we now have link-layer security. With the ip64 patch, we have easier connectivity. We have done a lot of cleanup and the transition to IPv6 is pretty much done.

With the incoming openmote platform, we also have a hardware platform that provides easy connectivity over Ethernet. We have a platform with IP64 connectivity over Ethernet that is ready to be merged once the openmote port is in.

If we move quickly, I expect that we could have Contiki 3.0 out before Christmas.

Member

adamdunkels commented Dec 7, 2014

I've been going through everything needed for Contiki 3.0. There have been a lot of good cleanup pull requests recently, as well as a bunch of other good stuff.

Looking back at this list and what we have achieved since we put it together, I think we are very close to the Contiki 3.0 release.

With the llsec patch, we now have link-layer security. With the ip64 patch, we have easier connectivity. We have done a lot of cleanup and the transition to IPv6 is pretty much done.

With the incoming openmote platform, we also have a hardware platform that provides easy connectivity over Ethernet. We have a platform with IP64 connectivity over Ethernet that is ready to be merged once the openmote port is in.

If we move quickly, I expect that we could have Contiki 3.0 out before Christmas.

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Dec 7, 2014

Contributor

OK - that is a short deadline. We have some RPL bug-fixes and improvements that we would like to share! I'll try to speed up our pull-requests as much as possible and get some of them in as soon as possible.

Contributor

joakimeriksson commented Dec 7, 2014

OK - that is a short deadline. We have some RPL bug-fixes and improvements that we would like to share! I'll try to speed up our pull-requests as much as possible and get some of them in as soon as possible.

@nvt

This comment has been minimized.

Show comment
Hide comment
@nvt

nvt Dec 8, 2014

Member

Sounds like a good plan. We have enough major changes merged in to start making the final preparations for the release of 3.0 now.

Member

nvt commented Dec 8, 2014

Sounds like a good plan. We have enough major changes merged in to start making the final preparations for the release of 3.0 now.

@simonduq

This comment has been minimized.

Show comment
Hide comment
@simonduq

simonduq Dec 9, 2014

Member

One more cleanup I'd like to see is on the net/mac folder, which I find very confusing at the moment. I'll be happy to submit a PR if we agree on something.
I see the following problems:

  • mac, rdc, framer layers all co-located. I'd vote for adding two directories, net/rdc and net/framer
  • for clarity and consistency
    • rename framer-nullmac to nullframer?
    • rename nullrdc-noframer to nordc?
    • move slip-radio's no_framer to net/framer (or, alternatively, move nullrdc-noframer inside the slip-radio example)
    • move phase inside the contikimac module
Member

simonduq commented Dec 9, 2014

One more cleanup I'd like to see is on the net/mac folder, which I find very confusing at the moment. I'll be happy to submit a PR if we agree on something.
I see the following problems:

  • mac, rdc, framer layers all co-located. I'd vote for adding two directories, net/rdc and net/framer
  • for clarity and consistency
    • rename framer-nullmac to nullframer?
    • rename nullrdc-noframer to nordc?
    • move slip-radio's no_framer to net/framer (or, alternatively, move nullrdc-noframer inside the slip-radio example)
    • move phase inside the contikimac module
@simonduq

This comment has been minimized.

Show comment
Hide comment
@simonduq

simonduq Dec 9, 2014

Member

Yes another cleanup that would be more than welcome before 3.0 IMO is that of the examples directory. I would trash most of the examples, and re-arrange what remains, e.g. improve the current situation where some ipv6 examples are under examples/ipv6, others directly under examples, and also avoid duplicate, per-platform examples.

Additionally, some of the "examples" are actually much more examples of how to use Contiki, but rather very generic and readily-usable Contiki firmwares. For instance, the border router and slip-radio. Not sure where these could move though.

Member

simonduq commented Dec 9, 2014

Yes another cleanup that would be more than welcome before 3.0 IMO is that of the examples directory. I would trash most of the examples, and re-arrange what remains, e.g. improve the current situation where some ipv6 examples are under examples/ipv6, others directly under examples, and also avoid duplicate, per-platform examples.

Additionally, some of the "examples" are actually much more examples of how to use Contiki, but rather very generic and readily-usable Contiki firmwares. For instance, the border router and slip-radio. Not sure where these could move though.

@cmorty

This comment has been minimized.

Show comment
Hide comment
@cmorty

cmorty Dec 9, 2014

Contributor

Maybe a bit off topic, but maybe it would be worth also checking all the old PRs - some of them are > 2 years. I think some are trivial (to rebase) and just got lost in the backlog. The other should probably be closed.

Contributor

cmorty commented Dec 9, 2014

Maybe a bit off topic, but maybe it would be worth also checking all the old PRs - some of them are > 2 years. I think some are trivial (to rebase) and just got lost in the backlog. The other should probably be closed.

@laurentderu

This comment has been minimized.

Show comment
Hide comment
@laurentderu

laurentderu Dec 9, 2014

Member

We have some important fixes related to RPL long term stability and multi-dodags support, I hope to make the pull requests this week.
Also, it would be really great if we could converge on #833, when you have large networks it becomes impossible to modify RPL parameters even with a synchronous reset. I have a working proof of concept handling two parameters, but before going further into the implementation we should agree on the actual solution.

Member

laurentderu commented Dec 9, 2014

We have some important fixes related to RPL long term stability and multi-dodags support, I hope to make the pull requests this week.
Also, it would be really great if we could converge on #833, when you have large networks it becomes impossible to modify RPL parameters even with a synchronous reset. I have a working proof of concept handling two parameters, but before going further into the implementation we should agree on the actual solution.

@sieben

This comment has been minimized.

Show comment
Hide comment
@sieben

sieben Dec 10, 2014

Contributor

@simonduq I would also add a csc file in the remaining examples to quickly get started with a precise configuration. I think it's confusing to have some folders with a csc and some without it.

Contributor

sieben commented Dec 10, 2014

@simonduq I would also add a csc file in the remaining examples to quickly get started with a precise configuration. I think it's confusing to have some folders with a csc and some without it.

@klh

This comment has been minimized.

Show comment
Hide comment
@klh

klh Dec 17, 2014

Add better examples please.... and remove the ones that are outdated or rely on legacy interfaces.
This has tripped alot of people up when going into 2.x and 1.x for that matter...

klh commented Dec 17, 2014

Add better examples please.... and remove the ones that are outdated or rely on legacy interfaces.
This has tripped alot of people up when going into 2.x and 1.x for that matter...

@adamdunkels

This comment has been minimized.

Show comment
Hide comment
@adamdunkels

adamdunkels Dec 18, 2014

Member

We did get a whole bunch of interesting RPL patches in the last few days, travis currently fails, and I just didn't get the time I had hoped to get to work on this, so let's postpone the 3.x release until early 2015.

A few things needed before 3.x:

  • review and potentially merge the pull requests from @laurentderu
  • get the openmote platform into the tree, along with its Ethernet base module and the accompanying ip64 code so that we have one platform with full Internet capabilities
  • we have a DNS64 mechanism for the ip64 module that is needed to get things like HTTP working nicely
  • and a number of other smaller things here and there.

@simonduq, @klh, @sieben: cleaning up the examples is definitely needed - would love to see a pull request!

Member

adamdunkels commented Dec 18, 2014

We did get a whole bunch of interesting RPL patches in the last few days, travis currently fails, and I just didn't get the time I had hoped to get to work on this, so let's postpone the 3.x release until early 2015.

A few things needed before 3.x:

  • review and potentially merge the pull requests from @laurentderu
  • get the openmote platform into the tree, along with its Ethernet base module and the accompanying ip64 code so that we have one platform with full Internet capabilities
  • we have a DNS64 mechanism for the ip64 module that is needed to get things like HTTP working nicely
  • and a number of other smaller things here and there.

@simonduq, @klh, @sieben: cleaning up the examples is definitely needed - would love to see a pull request!

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Dec 18, 2014

Contributor

We will try to do a few more PRs on ContikiRPL from our work with Yanzi too - before 3.0. Merry Christmas all!

Contributor

joakimeriksson commented Dec 18, 2014

We will try to do a few more PRs on ContikiRPL from our work with Yanzi too - before 3.0. Merry Christmas all!

@arpit-ag

This comment has been minimized.

Show comment
Hide comment
@arpit-ag

arpit-ag Mar 6, 2015

Hi,
Any updates on Contiki 3.0 release?

arpit-ag commented Mar 6, 2015

Hi,
Any updates on Contiki 3.0 release?

@Tamarinen

This comment has been minimized.

Show comment
Hide comment
@Tamarinen

Tamarinen May 26, 2015

Are there any plans for Contiki to support being built with TI/RH's new MSP430 toolchain? http://www.ti.com/tool/msp430-gcc-opensource

My apologies if this already has been discussed, and just couldn't find.

Tamarinen commented May 26, 2015

Are there any plans for Contiki to support being built with TI/RH's new MSP430 toolchain? http://www.ti.com/tool/msp430-gcc-opensource

My apologies if this already has been discussed, and just couldn't find.

@laurentderu

This comment has been minimized.

Show comment
Hide comment
@laurentderu

laurentderu May 26, 2015

Member

I tried sometime ago to use the new toolchain, apart from a few modifications here and there it was working fine. However at that time there was no platform library like the one provided by mspgcc; you had to copy it from the mspgcc or use CCS to generate it, which was cumbersome.

I should have a look at it again as it seems they claim they have now the platform header files.

Member

laurentderu commented May 26, 2015

I tried sometime ago to use the new toolchain, apart from a few modifications here and there it was working fine. However at that time there was no platform library like the one provided by mspgcc; you had to copy it from the mspgcc or use CCS to generate it, which was cumbersome.

I should have a look at it again as it seems they claim they have now the platform header files.

@Tamarinen

This comment has been minimized.

Show comment
Hide comment
@Tamarinen

Tamarinen May 26, 2015

@laurentderu That sounds awesome. I tried the setup at http://thedestitutedeveloper.blogspot.se/2015/02/msp430-and-fedora-21-same-but-different.html - I'm trying to give myself a crash course in Contiki and MSP430.

Tamarinen commented May 26, 2015

@laurentderu That sounds awesome. I tried the setup at http://thedestitutedeveloper.blogspot.se/2015/02/msp430-and-fedora-21-same-but-different.html - I'm trying to give myself a crash course in Contiki and MSP430.

@jonnteolsson

This comment has been minimized.

Show comment
Hide comment
@jonnteolsson

jonnteolsson May 31, 2015

Contributor

@joakimeriksson any updates on the enhancements/PR to ContikiRPL? Can you give some more details?

Contributor

jonnteolsson commented May 31, 2015

@joakimeriksson any updates on the enhancements/PR to ContikiRPL? Can you give some more details?

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Jun 1, 2015

Contributor

Some are minor bug fixes (some of the are up already) but other like node-to-RPL-ROOT DAO ACK and full implementation of DAO_NACK/ACK mechanism (significantly more "full" that the specification so there will be need to produce a short add-on RFC in the long run - RPL RFC is too thin on DAO handling). Then there are quite a bunch of changes in neighbour management and routing table management to make Contiki-RPL scalable to more than the tables can hold (we have scaled well above 100 nodes with 10 neighbours and 20 routes in the tables).

These fixes made the whole Yanzi >1000 nodes deployment in less than four hours possible. I can send a link to anyone who would like to see the video from the deployment (joakime@sics.se - can not share the link here yet I think - it is still under "production").

Contributor

joakimeriksson commented Jun 1, 2015

Some are minor bug fixes (some of the are up already) but other like node-to-RPL-ROOT DAO ACK and full implementation of DAO_NACK/ACK mechanism (significantly more "full" that the specification so there will be need to produce a short add-on RFC in the long run - RPL RFC is too thin on DAO handling). Then there are quite a bunch of changes in neighbour management and routing table management to make Contiki-RPL scalable to more than the tables can hold (we have scaled well above 100 nodes with 10 neighbours and 20 routes in the tables).

These fixes made the whole Yanzi >1000 nodes deployment in less than four hours possible. I can send a link to anyone who would like to see the video from the deployment (joakime@sics.se - can not share the link here yet I think - it is still under "production").

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Jun 29, 2015

Contributor

Finally the deployment video is open for sharing: http://yanzi.se/video.jsp?id=7 - I am hoping to upstream some of the needed fixes soon!

Contributor

joakimeriksson commented Jun 29, 2015

Finally the deployment video is open for sharing: http://yanzi.se/video.jsp?id=7 - I am hoping to upstream some of the needed fixes soon!

@sieben

This comment has been minimized.

Show comment
Hide comment
@sieben

sieben Oct 19, 2015

Contributor

@simonduq Is it worth closing now that contiki 3.X is out ? :)

Contributor

sieben commented Oct 19, 2015

@simonduq Is it worth closing now that contiki 3.X is out ? :)

@simonduq

This comment has been minimized.

Show comment
Hide comment
@simonduq

simonduq Oct 19, 2015

Member

I would not, this roadmap was not only for 3.0, it is for the ongoing 3.x

Member

simonduq commented Oct 19, 2015

I would not, this roadmap was not only for 3.0, it is for the ongoing 3.x

@janeksz

This comment has been minimized.

Show comment
Hide comment
@janeksz

janeksz Nov 11, 2015

There is a number of small and low power WiFi modules available now (ESP8266, TI sensortag WiFi, ...)
It would be nice to have them as an edge router options. I would like to see as well Raspberry Pi as native edge router and websocket examples for both server and client.

janeksz commented Nov 11, 2015

There is a number of small and low power WiFi modules available now (ESP8266, TI sensortag WiFi, ...)
It would be nice to have them as an edge router options. I would like to see as well Raspberry Pi as native edge router and websocket examples for both server and client.

@joakimeriksson

This comment has been minimized.

Show comment
Hide comment
@joakimeriksson

joakimeriksson Apr 20, 2016

Contributor

I do think it is time for an update of the Contiki OS Roadmap! There are lots of things done, and new things to do that are not on this roadmap. Or should this be kept until it is 100% done? Maybe put up a Contiki 3.1 Roadmap and keep 3.X items for long term?

Contributor

joakimeriksson commented Apr 20, 2016

I do think it is time for an update of the Contiki OS Roadmap! There are lots of things done, and new things to do that are not on this roadmap. Or should this be kept until it is 100% done? Maybe put up a Contiki 3.1 Roadmap and keep 3.X items for long term?

@janeksz

This comment has been minimized.

Show comment
Hide comment
@janeksz

janeksz Apr 30, 2016

can you add websockets to the list?

janeksz commented Apr 30, 2016

can you add websockets to the list?

mcr pushed a commit to mcr/contiki that referenced this issue May 7, 2018

Merge pull request #422 from g-oikonomou/contrib/trailing-ws
Remove trailing whitespaces and other code style fixes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment