[Tinyos-devel] problem of using FTSP and CTP

[Miklos Maroti]

Phil,

> 1) Any transient failure code from Send should have a corresponding event
> that denotes the condition has cleared. For example:
>        EOFF: SplitControl.startDone
>        EBUSY: Send.sendDone
>
> 2) An implementation that allows multiple sending components must preclude
> starvation by providing some kind of fairness between the senders.
>
> If we need to rework the queue implementations to deal with new send
> interfaces, 6lowpan, etc., that's fine; replacing some of these internal
> implementations in order to deal with changing needs is much better than
> violating one of the above invariants.

We might want to do resource arbitration like for any other resource.
So any user of the radio for example could use a RoundRobinArbiterC,
this would include all direct users of ActiveMessageC, 6LowPan
implementation and the AMSenderC. Most of the users would be protected
by the AMSenderC, so they can use the usual paradigm.

There is a separate issue: do we want to allow the EBUSY return code
from the MAC layer? I always assumed that we should because there
could be several conditions where sending is not possible temporarily
(see my previous post). If we decide that it is NOT possible, then we
need to audit/rework the radio drivers (at least the RF230 I guess).

Miklos