I guess if I took the time to read and understand all the NESCC design/doc, rather than wasting it on trying to make my own projects work, I wouldn't be asking so many seemingly redundant questions. I expect the whole thing has to do with using "async" as a flag to force race-condition evaluation, which then blossomed into a chain of fix-the-boundary-cases keywords.
thanks for the answer MS Michiel Konstapel wrote:
OK, good. Then another stupid question: "signal" == noop?Not a stupid question at all, because yes, that's basically true. If you look at the generated C code in build/$PLATFORM/app.c you'll see both "call Foo.bar()" and "signal Foo.bar()" get turned into an ordinary C function call. Here's an example taken from Blink: nesC: event void Timer0.fired() { call Leds.led0Toggle(); } C: static inline void BlinkC$Timer0$fired(void) { ; BlinkC$Leds$led0Toggle(); } The code that fires the timer event from VirtualizeTimerC is a bit messy because of the generic components involved, but eventually firing the event just turns into a regular call to BlinkC$Timer0$fired(). HTH, Michiel
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
