Dear riot-users and developers,
we are glad to announce that it is now possible to have a first look at RIOT without the need to access to supported hardware!
Let's start the RIOT! Oleg
Dear riot-users and developers,
we are glad to announce that it is now possible to have a first look at RIOT without the need to access to supported hardware!
Let's start the RIOT! Oleg
Great! Emmanuel
Congratulations for this great achievement!
BTW do you think this could be a first step towards a simulation of RIOT? Because, Monday I will meet ns3 guys, our collegues in Sophia, they will present how they are integrating ns3 and Contiki - so if you are interested, would some specific information be useful for you ?
Best regards, -- Cedric
Hi,
I have no experience whatsoever with ns3, but as far as I understand it: yes and yes.
Off the top of my head: The biggest difference between RIOT and Contiki with regard to interfacing with a simulator is that RIOT has preemptive context switches. This will probably lead to a higher overhead when synchronizing with an external (from the OSs view) clock.
Interesting questions: - are they running the whole Contiki system or just parts? - how does ns3 communicate time / how are they handling time? - at what level (driver/hardware/syscall) do they intercept io?
Most interesting of course would be their diff and/or pointers to helpful sources of information.
Thank you for your offer!
Cheers, Ludwig
Cedric Adjih schrieb:
Hello Ludwig, hello Rioters,
For this possible ns3 integration topic, thank to Daniel Camara [in copy], I understood the following:
- for the Contiki <-> ns3 integration, the architecture of Contiki itself will be used. ns3 will appear as a new architecture for Contiki, and low-level parts (drivers, timers) will be rewritten like any Contiki port. So, to answer the question it will be "just parts" of the Contiki system, except that the parts could be pretty big, and more importantly, Contiki is itself naturally divided in parts. I think that the missing point prior actual implementation is how to handle Contiki global variables in such an architecture.
- For a possible RIOT port to ns3, Daniel advice is that such a method of integration would be more elegant and more straightforward.
- Also another possibility that was pointed is the DCE module in ns3: the intent of DCE (Direct Code Execution http://www.nsnam.org/~thehajime/ns-3-dce-next-doc/doc/build/html/index.html) is exactly to integrate external programs in ns3 without modifying the source. From what I gathered, it works with clever tricks in the dynamic library loader, etc. Several instances of the same program are run from ns3, by having their memory mapped at different absolute addresses. Moreover normal (e.g. POSIX) system/library calls are mapped to ns3 operations by hijacking the library function calls (normally defined in dynamic libraries, external to the program). This uses Position Independent Executables http://en.wikipedia.org/wiki/Position-independent_code Daniel opinion is that using DCE with Riot-Linux-port, could either work directly, or could fail with a difficult-to-solve (conceptual) problem.
Best Regards, -- Cedric