search

contiki-os / contiki

The official git repository for Contiki, the open source OS for the Internet of Things
http://www.contiki-os.org/
Other
3.72k stars 2.58k forks source link

Contiki 3.x Roadmap #422

Open g-oikonomou opened 11 years ago

g-oikonomou commented 11 years ago

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

g-oikonomou commented 11 years ago

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

and on the discussion under #403

g-oikonomou commented 11 years ago

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

laurentderu commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 :+1:

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 commented 11 years ago

@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 commented 11 years ago

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: :+1:]

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 commented 11 years ago

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....

simonduq commented 11 years ago

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 commented 11 years ago

I've been investigating a minimal PPP implementation.

sdawans commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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

laurentderu commented 11 years ago

@aguirrem: :+1:

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 commented 11 years ago

Yes, multiple interfaces would be a nice feature! :+1:

ivan-lapitski commented 11 years ago

@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 commented 11 years ago

There are a few already available : http://www.zigbee.org/Products/CompliantPlatforms/ZigBeeIP.aspx

AriZuu commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

@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...

malvira commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

poppe34 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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

barryzxy commented 10 years ago

when Contiki 3.x will be release?

adamdunkels commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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:

simonduq commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.

remyleone commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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:

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

joakimeriksson commented 9 years ago

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 commented 9 years ago

Hi, Any updates on Contiki 3.0 release?

Tamarinen commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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

joakimeriksson commented 9 years ago

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").