On Mar 22, 2006, at 6:31 AM, Ron Olson wrote:
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.
This is the reason. readRXFIFO is supposed to be split-phase, but its
implementation in 1.x is not. In 2.x, the implementation is split-phase.
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.
The problem is that doing a whole bunch of readRXFIFOs in a blocking
fashion could (theoretically) take a long time.
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.
Basically, the issue is that for a short read, doing it single-phase
is OK. The problem is when you want to do a long read: then, you need
to do it split-phase so you don't block the system. The 1.x
implementation sort of cheats, in that it makes things look split-
phase, but in reality just is a single-phase call.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
