January 24, 2009
I got TOSSIM running by repeating instructions like a trained monkey. Since I run Fedora on the laptop, the installation was a piece of cake. Builing of a sample application Blink was simple too.
About the only trick I had to learn was that an empty line ends an indented block in Python when entering interactively into the interpterer. Result looks like this:
1
1
DEBUG (32): LEDS: Led0 off.
1
DEBUG (32): LEDS: Led1 off.
1
DEBUG (32): LEDS: Led2 on.
1
1
TOSSIM itself is a funny animal, which took a few moments to grok. It's an event-driven sim, so the Levis' "Nido" paper scared me with this:
• Time: While TOSSIM precisely times interrupts (allowing things like bit-level radio simulation), it does not model execution time. From TOSSIM’s perspective, a piece of code runs instantaneously. Time is kept at a 4MHz granularity (the CPU clock rate of the rene and mica platforms). This also means that spin locks or task spin locks will never exit: as the code runs instantaneously, the event that would allow the spin to stop will not occur until the code completes (never).
My first reaction was, honestly, "what is this crap?!". Only after reading the older Levis/Culler's paper, I understood what this is about. The thing is, TOSSIM is not intended to emulate hardware. It just does some of that because they want the applications unmodified. But mainly, TOSSIM emulates the network. All the talk about getting gdb attached got me confused. Also, I wrote a share of CPU emulators in my life (with circuit, cicle, and instruction resolutions), and that experience provides a wrong framework to think about TOSSIM. It's not qemu at all.
Anyway, I'm going to turn to that energy grid paper now.
Tags: cs-591-005
Posted by: Pete Zaitcev at
03:29 PM
| No Comments
| Add Comment
Post contains 299 words, total size 2 kb.
22 queries taking 0.0095 seconds, 18 records returned.
Powered by Minx 1.1.6c-pink.