On Dec 7, 2006, at 12:51 PM, R. Steve McKown wrote:
I think in general the need/desire for a spin lock or other similar
continue-to-test strategies suggest that some of the best benefits
of TinyOS
aren't being fully exploited. Granted, it can mean the
organization of your
code is trickier, not unlike that of a state machine. The "TinyOS
way",
however, yields wins in lower energy consumption. For most TinyOS
apps, this
is a big deal.
This is generally true. There are situations, though, when small spin
loops can improve performance. This happens when the spinning time is
shorter than the time to execute the prelude for the corresponding
interrupt handler. E.g., if you expect the operation to complete in
10 cycles but pushing registers on the stack would take 20 cycles,
then it's better to spin. But spinning arbitrarily long is
problematic. So something you sometimes see in low-level TinyOS
abstractions is a situation where you spin for X consecutive
operations then handle an interrupt on the X+1th. This enables
concurrency but reduces overhead. E.g., the SpiPacket interface on
the atmega128 writes 10 (SPI_ATOMIC_SIZE) bytes using a spin loop and
handles an interrupt on the 10th byte. So the interrupt handling
overhead is amortized over 10 operations.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
