On Dec 30, 2007, at 7:51 AM, KURT PETERS wrote:
Phil,
I went over tos/lib/tossim/HilTimerMilliC as you suggested, but
really am not too sure of what's actually required to create a new
sim interface. I agree that a component on top of the I2C would be
best.
Are there some "key" steps that need to be taken, like:
1) Create sim/ directory in chips/atm128/i2c directory
2) modify .platform in platforms/micaz/sim/ with something
3) what do you recommend including in terms includes(like
headers,etc.?),
4) should I modify platform.h with 50kHz (the speed of the I2C bus
as default),
5) If I'm using Atm128I2CMasterC.nc, what should the file be called
in the sim/ directory (or am I looking at making multiple files?)-
Atm128I2CMasterP , Atm128I2CMasterPacketP, HplAtm128I2CBus.nc? I'm
not sure which level to start at and what will actually work (ie,
"good enough" to at least be recognized as valid by the compiler)?
6) (Not really expecting an answer on this one) how much of it do I
need to implement as simulating I2C functionality, vs can just
hardcode a dbg message? I'm less worried about response of i2C
device on other end than I am with timing and that the Atm128L
stays active.
Answering these will help me start a new wiki entry to on this
topic as I muddle along.
TOSSIM is a discrete event simulator. This allows you to easily tell
a simulation that something will happen in the future by putting an
event on the event queue. The event queue is a simple priority queue,
where events with earlier times come off first. So when that future
event is at the head of the queue, TOSSIM has reached that time,
pulls the event off the queue, and executes it.
This discrete event framework can be used to simulate any split-phase
call. In real hardware, interrupts form the basis of events that
occur in the future. For example, your program tells the radio to
send a packet by sending a command over a bus; when the transmission
completes, the radio raises an I/O line, causing an interrupt. In
TOSSIM, there isn't any such hardware. So instead, you can write a
simulator replacement for the radio. When this simulator determines
that it sends a packet (e.g., the channel is clear), it puts an event
on the queue denoting that the transmission has completed. The time
of this event is the current time *plus* the time it takes to
transmit the packet. When TOSSIM executes that event, the simulated
radio component can act like it handled an interrupt.
So how do you write a simulated version of a component? Where do you
put it?
I'll start with the second question. Compiling for TOSSIM (add the
'sim' option to make) adds the -tossim flag to ncc. When ncc sees
this flag, it modifies the include path that an application passes.
If compiling has the include paths
-Ia -Ib -Ic
then compiling for TOSSIM changes this to
-Ia/sim -Ib/sim -Ic/sim -I%T/lib/tossim -Ia -Ib -Ic
So compiling TOSSIM will cause ncc to first look in all sim/
subdirectories, then lib/tossim, and finally, the standard
directories. This allows you to put simulated re-implementations of
any component in a sub-directory sim, and TOSSIM can also have
default simulated implementations in lib/tossim. Note that this
rewrite is not only the application's directories, but also all of
the standard TinyOS directories.
Now, as for the first question: how do you write a simulated version
of a component? The general rule here is that it needs to behave like
the normal one, especially with respect to its interfaces. For
example, if there are split phase calls in the standard
implementation, they need to be split-phase calls in the simulated one.
So let's say you want to simulate a sensor, which provides the Read
interface. One simple way to simulate it is to write a version that,
when Read.read is called, posts a task that signals Read.readDone.
This might not give you a reasonable sensor reading, but it will
behave like a normal sensor.
Another way would be to go through the TOSSIM event loop. Let's say
this sensor normally takes one second to get a reading. So posting a
task would be unrealistic. Instead, when a component calls Read.read,
you test to see if a read is pending. If not, then the simulated
version puts an event into the TOSSIM event queue that will fire in
one second. The event handler function posts a task, and the task
signals Read.readDone.
-------------------
To answer your specific questions:
1) Yes.
2) No: compiling for -tossim will take care of this.
3) The simulated component signature and includes should be the same
as the standard one.
4) I don't understand.
5) I would write a simulated version of Atm128MasterPacketP.nc
6) It's important that you obey the interface semantics and timing.
So a call to read should get a readDone around the right time. If you
are worried about the atm128L staying in active mode, then you will
need to be sure to twiddle the simulated control registers in the
AsyncStdControl. But by default TOSSIM does not simulate atm128 power
states, so I am not 100% sure what you are asking here.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
