[sim-wg] TOSSIM and the 2.1 Release

[Chad Metcalf]

Integration wise it will be fairly simple. My specific files will go
into a sf and sf/sim directory in the TOSSIM directory. And I'll add a
sim-sf.extra to support/make. That's it.

Since we have some time between the 2.1 release and now do you want to
wait to integrate until after your NDSI deadlines, Phil? I imagine
someone besides me should take a look at what I'm doing.

Cheers
Chad



On 9/20/07, Philip Levis <pal at cs.stanford.edu> wrote:
> On Sep 20, 2007, at 10:55 AM, Chad Metcalf wrote:
>
> > Resending to the group...
> >
> > On 9/20/07, Philip Levis <pal at cs.stanford.edu> wrote:
> >> That is, whether the SF code is *in* TOSSIM, or is just Python code
> >> included in the Python driver script. Don't forget, there's a TOSSIM
> >> command that lets you inject packets to nodes. It currently only
> >> works for radio packets, but adding the serial one would be trivial.
> >> So you could just write Python code that processes SF packets and
> >> calls inject() on TOSSIM. Or is that what you're doing?
> >
> > I've added the serial packet injection.
> >
> >  34 serialpkt = t.newSerialPacket();
> >  35 serialpkt.setData(msg.data)
> >  36 serialpkt.setType(msg.get_amType())
> >  37 serialpkt.setDestination(0)
> >  38 serialpkt.deliver(0, t.time() + 3)
> >
> > The SerialForwarder is a stand alone object written in C++ as a
> > wrapper around C functions which link into the simulation itself. I
> > also used SWIG to generate a Python wrapper so that it can be used in
> > Python. But its only integrated into TOSSIM as much as regular packet
> > injection is. I looked at how you did packet injection and basically
> > mirrored it. And yes my C/C++ processes packets which then are
> > injected.  Its in the TOSSIM module in Python because thats the way I
> > had to do it to overcome build issues.
> >
> > Currently the way the extension is I have my own sim-sf.extra which
> > builds sf support into TOSSIM. If you don't want it you run sim.extra
> > and you don't get the overhead. My thought was to do something
> > similar.
> >
> >>>> The one downside of pushing this into the scripting world is it
> >>>> makes
> >>>> transitioning between C++ and Python harder.
> >>>
> >>> So is the thought going forward then that TOSSIM won't be supporting
> >>> C++ based simulation drivers?
> >>
> >> No -- just that moving back and forth between Python and C++ might be
> >> a bit trickier.
> >
> > This was the basis for my decision to write it in C/C++ with a Python
> > wrapper. That way everyone gets access to the functionality.
>
>
> Awesome. It sounds like a near-perfect design.
>
> Phil
>


-- 
Chad @ Home