[Tinyos-devel] ctp vs other radio clients

[Philip Levis]

On Dec 6, 2008, at 8:06 AM, Geoffrey Werner-Allen wrote:

> Couldn't this happen if, as Brany suggests, another component is  
> using the radio stack?  I've also used CTP with other protocols  
> (including FTSP) and recall seeing it hit this corner. We were  
> implementing reliability at a higher level so it wasn't fatal, but I  
> believe I tracked it down to CTP trying to forward a packet while  
> FTSP broadcast messages were being sent. With LPL these occupy the  
> stack for a potentially long period of time (half a second at our  
> duty cycle), and so the chances of DefaultLPLP.nc returning BUSY  
> from Send.send() was pretty high. (I believe the default FTSP  
> traffic rate is one global message / 10 seconds, so using a sleep  
> interval of 1/2 second this means that you have a 1/20 chance of  
> colliding with a FTSP broadcast message.)
>
> Best,

No. Please read TEP 116. Each AMSenderC has a reserved slot in the AM  
transmit queue. AMSend.send returns EBUSY iff there is an outstanding  
AMSend.send. The text reads:

The ``Send`` and ``AMSend`` interfaces have an explicit queue of
depth one.

The implementation:

     command error_t Send.send[uint8_t clientId](message_t* msg,
                                                 uint8_t len) {
         if (clientId >= numClients) {
             return FAIL;
         }
         if (queue[clientId].msg != NULL) {
             return EBUSY;
         }

Of course, a very busy link layer causes longer delays between send  
and sendDone, such that it's more likely the higher layer will issue a  
second send before the sendDone comes in. But if it hasn't called  
send(), then it should not get EBUSY.

Phil