Excellent, great news. Best, Miklos On Tue, Nov 16, 2010 at 5:56 PM, Dongyu Yang <[email protected]> wrote: > 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 >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
