I'm wondering why command HPLCC2420M.readRXFIFO is written with a
signaled callback after completion. The command does all its work
before returning, so the callback is not needed. The callback adds
complexity and time on both the called and calling sides.
I suppose one explanation might be that there are other implementations
of the HPLCC2420FIFO interface where the implementation isn't blocked,
and where callback is needed. So, this HPLCC2420M implementation
adheres to the interface so that a caller can potentially substitute
other implementations without affecting the calling code.
But, the problem is that this transparency (if that's in fact the design
motivation) comes at a large cost in complexity and performance. In my
application I must call readRXFIFO several times in succession.
Treating readRXFIFO as a blocked service, I just make a simple sequence
of calls. But, treating it as non-blocked (i.e. asynchronous), I must
use a series of callbacks to track the application state and take the
next action. That's *way* more complex, and somewhat slower, and is too
big a price to pay, especially in an embedded application where
transparency may have minimal value.
If that's the tradeoff here - transparency vs simplicity - then I'll
just make my choice and move on. But, I want to be sure I'm not missing
some other point that drove the readRXFIFO design, and that may burn me
downstream.
Thanks,
Ron Olson
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
