[Tinyos-devel] ctp vs other radio clients
Philip Levis
pal at cs.stanford.edu
Mon Oct 27 18:28:57 PDT 2008
On Oct 27, 2008, at 5:36 PM, Branislav Kusy wrote:
> guys,
>
> is it allowed to use the radio (ie ActiveMessageC) while using Ctp? if
> not, should it be allowed? most of my applications require it...
>
> i couldn't find anything about this in tep123, but i found this
> comment
> in CtpForwardingEngineP.nc,v1.17:
>
> line 487:
> subsendResult = call SubSend.send(dest, qe->msg, payloadLen);
> ....
> lines 509-519:
> else if (subsendResult == EBUSY) {
> // This shouldn't happen, as we sit on top of a client and
> // control our own output; it means we're trying to
> // double-send (bug). This means we expect a sendDone, so just
> // wait for that: when the sendDone comes in, we'll try
> // sending this packet again.
> dbg("Forwarder", "%s: subsend failed from EBUSY.\n", __FUNCTION__);
> // send a debug message to the uart
> call CollectionDebug.logEvent(NET_C_FE_SUBSEND_BUSY);
> }
>
> if there are other radio clients, subsendResult may be EBUSY even if
> we
> don't double send. therefore, we should just call
> startRetxmitTimer();
>
> if we don't do this, ctp basically hangs forever.
>
> i've had this problem for a long time - ctp hanging on me for no good
> reason. my test application can reproduce it in a few seconds. i
> tested
> calling startRetxmitTimer() from the EBUSY case and it fixed the
> problem. i'm not sure if it didn't introduce any other problems,
> though.
Hrm. That's weird. Please read TEP 116: send should return EBUSY iff
it has returned SUCCESS to a prior call and has not yet signaled
sendDone.
This suggests that it's a bug in CTP where it calls send multiple times.
Phil
More information about the Tinyos-devel
mailing list