Hello!
I fine this is cased by the component LowPowerListeningLayerP, and this
has been fixed by mmaroti on Nov 13, 2010, Revision: r5220. And when I
update the LowPowerListeningLayerP, it is OK!
Thanks for you attention! Best regards!
2010/11/16 Philip Levis <[email protected]>
>
> On Nov 1, 2010, at 6:46 PM, Dongyu Yang wrote:
>
> > Hello!
> >
> > The return value is EBUSY. The AM layer do not promise signal
> AMSend.sendDone
> > event, if the return value is not SUCCESS when call AMSend.send().
> > Because in the component AMQueueImplP, when call Send.send() it may
> return
> > EBUSY in two place, as show below:
> >
> > generic module AMQueueImplP(int numClients) @safe() {
> > provides interface Send[uint8_t client];
> > uses{
> > interface AMSend[am_id_t id];
> > interface AMPacket;
> > interface Packet;
> > }
> > }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; //
> .................................................................................(1)
> > }
> > dbg("AMQueue", "AMQueue: request to send from %hhu (%p):
> passed checks\n", clientId, msg);
> >
> > queue[clientId].msg = msg;
> > call Packet.setPayloadLength(msg, len);
> >
> > if (current >= numClients) { // queue empty
> > error_t err;
> > am_id_t amId = call AMPacket.type(msg);
> > am_addr_t dest = call AMPacket.destination(msg);
> >
> > dbg("AMQueue", "%s: request to send from %hhu (%p):
> queue empty\n", __FUNCTION__, clientId, msg);
> > current = clientId;
> >
> > err = call AMSend.send[amId](dest, msg,
> len);//.....................................(2)
> > if (err != SUCCESS) {
> > dbg("AMQueue", "%s: underlying send failed.\n",
> __FUNCTION__);
> > current = numClients;
> > queue[clientId].msg = NULL;
> >
> > }
> > return err;
> > }
> > else {
> > dbg("AMQueue", "AMQueue: request to send from %hhu
> (%p): queue not empty\n", clientId, msg);
> > }
> > return SUCCESS;
> > }
> > ......
> > }
> >
> > If the EBUSY is returned from (1), it is OK, and the Send.sendDone
> event will be
> > signaled for the client who call it later; but if the EBUSY is returned
> from (2), the
> > problem arise, it do not signal the Send.sendDone event for the client
> who call it, but
> > it will only signal the Send.sendDone event for another client whose AM
> ID is different
> > from the current client later.
> > I find this phenomenon arises when the EBUSY value return from (2).
> So it may be
> > the component AMQueueImplP have some problem, it can not guarantee the
> same
> > semantic for the EBUSY.
> >
> >
> > Best regards!
>
> Except that EBUSY should never be returned in this case. EBUSY is only for
> when the AM layer is already sending a packet. If you're getting an EBUSY in
> (2), this implies a component is *not* going through the AM queue and
> instead directly accessing the active message layer: this breaks the queue's
> semantics and implementation.
>
> Can you determine why the active message layer is returning EBUSY?
>
> Phil
>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
