Skip to content
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

pkg: contiki/cooja integration #1921

Closed
wants to merge 1 commit into from

Conversation

phiros
Copy link
Member

@phiros phiros commented Oct 31, 2014

This will add Contiki OS and the network simulator Cooja [1] to pkg.
Cooja in conjunction with mspsim is able to simulate whole networks consisting of
MSP-430 compatible platforms (various ATmega128* platforms are also supported through avrora[2]).
The simulator does not only support cycle accurate simulation of nodes but also a range of
different models for wireless networks (ranging from simple unit disk graphs to ray
tracing based interference models).

TODO:

  • add contiki and cooja to pkg.
  • integrate cooja into pytermcontroller (and testbed abstraction)
  • ...

@phiros phiros added State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Area: pkg Area: External package ports labels Oct 31, 2014
@OlegHahm
Copy link
Member

OlegHahm commented Nov 5, 2014

Do we necessarily need Contiki as a package to work with Cooja?

@phiros
Copy link
Member Author

phiros commented Nov 5, 2014

No not necessarily. For cooja itself we only need certain parts of the contiki tree.
My rationale for including the whole tree into this pkg is mainly that It might be useful to have the tree available in case we implement some kind of contiki integration for RIOT (e.g.: contiki running as a thread on top of RIOT).

However, we can always add the rest of the tree in another pkg later on.
-> I will alter this PR so that it only downloads the parts from the contiki repo which are necessary for cooja.

@N8Fear
Copy link

N8Fear commented Nov 5, 2014

Contiki in a thread in RIOT? Sounds like unnecessary overhead. What's the usecase? Reminds me strangely of some meme...

@phiros
Copy link
Member Author

phiros commented Nov 5, 2014

@N8Fear Honestly: I have no idea what the use case might be. I did however notice that someone from our team floated this idea around, so I guess there might be at least one valid use case.
I can only speculate that it might be useful if you want to be able to run unmodified contiki application layer code on top of a platform which is not supported by contiki but is supported by RIOT or something of that sort.

@OlegHahm
Copy link
Member

OlegHahm commented Nov 5, 2014

Heiko once told me that in the old days of FeuerWare they used a kind of Contiki compatibility layer to run Contiki applications as a thread to ease porting. But, honestly, I think the most valid motivation for doing this now would be the why-do-dogs-lick-their-balls argumentation.

EDIT: fixed typo

@kaspar030
Copy link
Contributor

Agreed. We can do that, contiki can't the other way. So let's do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: pkg Area: External package ports State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants