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.71k stars 2.58k forks source link

Priorities for issues and current show stoppers #680

Open mkovatsc opened 10 years ago

mkovatsc commented 10 years ago

There are a bunch of show stoppers that make it hard to use Contiki in projects that are supposed to work and evolve for a long time. Many people have a rather old fork of Contiki that contains all the fixes required for their project, but it is usually impossible to merge with the official repository again because they diverged too far. Yet many of the "custom" fixes are actually common must-haves for productive deployments that should go into the Contiki master. Thus, I think we should find a way to prioritize issues and merge the related pull requests faster.

For my projects, I see the following show stoppers---but I am really happy to see that some of them were recently fixed!

Solved:

Open:

I guess it is no surprise that there is a large overlap with the Contiki 3.x Roadmap (#422). The issue I see is that it is not clear how we can get there, how to coordinate the contributors, and how to improve the merging process. I believe that priorities and maybe responsible mergers for the top x issues could be a starting point.

Can we use this thread to identify our top x show stoppers?

dak664 commented 10 years ago

I think people should be encouraged to back up the git head to whatever is appropriate for their platforms. Given the wide application of contiki it would be easier to make core changes it they didn't have to be checked and debugged for every platform.

g-oikonomou commented 10 years ago

Windows support (Cygwin): minimal-net is not working anymore (might be an ND/DAAD problem)

Is this a bug we're talking about here? If so, perhaps what we need is a new issue / bug report for this.

dynamic RF channels and PAN IDs: this has been a long discussion and ultimately we are all waiting for the new radio API. I would also contribute network configuration via tunslip/nbr.

I didn't quite get this last statement about network configuration

RDC support: sky was the only platform on which ContikiMAC was working properly, but does not have enough memory for actual applications. With sky now at the end of its life, there is currently no platform with good RDC support (that is documented or runs out-of-the-box).

From my tests and from what I've heard from others, the CC2538DK plays very nicely with ContikiMAC. I suspect that other future CC2538-based platforms will also work (e.g. OpenMote)

homogeneous platforms and configuration parameters: in particular AVR platforms are still completely different from the rest and require special configuration.

I hear you, but how much of a showstopper is this?

mkovatsc commented 10 years ago

Windows support (Cygwin): minimal-net is not working anymore (might be an ND/DAAD problem)

Is this a bug we're talking about here? If so, perhaps what we need is a new issue / bug report for this.

I do not know yet. I checked the parts that caused the problem last time, but the fixes are in there. So the cause must be somewhere else...

dynamic RF channels and PAN IDs: this has been a long discussion and ultimately we are all waiting for the new radio API. I would also contribute network configuration via tunslip/nbr.

I didn't quite get this last statement about network configuration

When deploying several LoWPANs, it is nice when you can configure the channel or PAN ID without flashing anything. For that, I simply added flags to tunslip6 and configure the border router remotely (and some kind of docking networking to configure new motes via CoAP, but that still needs more work). It is something for the "easier connectivity" bullet. I really would like to improve on that. Joakim, for instance, also has an active scan for motes, which could be added, so that they automatically find the right channel/network.

RDC support: sky was the only platform on which ContikiMAC was working properly, but does not have enough memory for actual applications. With sky now at the end of its life, there is currently no platform with good RDC support (that is documented or runs out-of-the-box).

From my tests and from what I've heard from others, the CC2538DK plays very nicely with ContikiMAC. I suspect that other future CC2538-based platforms will also work (e.g. OpenMote)

Okay, great. It is disabled in the examples, though, so it is really hard to figure out the current status. I guess code coverage and someone keeping a Wiki entry up to date is again the solution :)

homogeneous platforms and configuration parameters: in particular AVR platforms are still completely different from the rest and require special configuration.

I hear you, but how much of a showstopper is this?

For me, it was the cause of endless merge conflicts, so that I had to start over and over again applying my changes to a newer version of Contiki from scratch. I guess, this is not a problem when working in a lab setting with a single platform, but I want to prototype actual IoT scenarios where we have several different platforms due to their different strengths. I agree with David that a better separation of core and platforms might be helpful. Then everyone can keep their own modifications (e.g., pin assignments, baud rates, or custom code in the main), while benefiting from the updates and fixes in core. For that, we would need a clean interface, that is fixed parameter names, homogeneous configuration, and of course this improved radio API...

mkovatsc commented 10 years ago

Okay, I must apologize for the minimal-net on Windows issue! The culprit is Cygwin64+wpcap. The init_pcap function reads out corrupted IPv6 addresses, so that no frame even reaches Contiki. I am not sure if we can fix the problem in wpcap.c or if it lies deeper...

So, only the tunslip6/nbr socket issue for Cooja remains :)