Hi Mike.

On Dec 21, 2007 5:38 PM, Chieh-Jan (Mike) Liang <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> On Dec 21, 2007, at 4:39 AM, David wrote:
> >
> > * I can't build the GoldenImage or other Deluge apps with the "sim"
> > option to test under TOSSIM. Is this currently unsupported?
> >
>
> I get the feeling that you want to simulate the entire Deluge as it
> is. I don't think it will work because TOSSIM doesn't simulate low-
> level microprocessor, flash, and serial (at least not officially).

I would like to be able to simulate our wireless network, which will
include Deluge (as the software update mechanism) and multiple
applications. It will also include some lower level details (eg: using
chip-specific code to get voltage levels so we can tell when batteries
need to be replaced). Does this mean that we won't be able to simulate
using TOSSIM? Or should we use conditional compilation syntax to strip
out the TOSSIM-incompatible logic (deluge, lower level stuff, etc)
when we want to run simulations?

>
> Changing the number of slots involves changing couple files. We are
> thinking about ways to make it simpler. However, for the time being,
> if you really want to change it, I can give you the list of files. I
> wouldn't recommend changing the slot configuration after motes are
> already configured for a certain setup. This is because changing slot
> configuration means changing the flash volumes, but I could be too
> paranoid about the side-effect.
>

Thanks for your input. We don't need more slots immediately, but in
the future we will want to add more applications to our tinyos
network, preferably distributed over Deluge. The 2 main ways I see to
do this:

1) One Deluge slot per (simple) application (number of required slots
can grow quickly). Each application "knows" which deluge slot it
should use to update itself. The other slots are for other (unrelated)
applications being distributed via Deluge.

2) One Deluge slot per [major application type]. Needs fewer slots..
Each application checks the mote "application type" in flash, then
starts a sub-program based on that. Needs fewer deluge slots, but it
will grow over time (also needs to "reserve" slots, so it can update
to the correct image each time). Also, each program is larger and more
complicated.

In both of the above, we would eventually need to expand the number of
slots. Either that, or have larger applications with more sub-programs
which get triggered based on configuration stored in flash.

Do you have any other ideas/suggestions?

Thanks,

David.
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to