It sounds like the OP is trying to implement some sort of application
level message acknowledge mechanism. I'll assume that the protocol
and/or hardware level ACKs are just not sufficient (if that's not the
case, search for ACK on this list and in my oft-posted code bolus).
Using the 'standard' GenericComm messaging mechanism you would probably
want to have a user task that deals with the retransmission and use
send(), sendDone() and the reply message receive function to (re)set
a timer that fires off the retry task. This is a type of software
watchdog function:
send() or sendDone() starts a timer with 1ms period
reply-receive() sets a flag
timer-fired() posts a task to do a new send or resend
based on the timer flag
Doing a busy-wait of more than a few micro-sec is a BadIdea(TM) in TOS.
It blocks execution of other code, and in many cases interrupts, that you
need to get messages, run timers, and do data acquisition. Doing a busy-
wait in sendDone() or any other event might even be worse as it could
already be executing in an interrupt context.
Also in my experience a full message send-reply cycle can take anywhere
from 5ms on the micaz to 20ms on the mica2, so a 1ms watchdog may not
be sufficient.
MS
Ittipong Khemapech wrote:
> No worries. From what I understand, you have (at least) 2 nodes (A and
> B) communicating together. After A has sent a packet to B, A waits for
> 1,000 microseconds to see if B successfully receives the packet. I guess
> that A and B have the same piece of code.
>
> In this case, A and B have the same message structure. A increments the
> number of sent packets after being signaled SUCCESS by sendDone(). B
> increments the number of received packets after its successful data
> reception somehow.
>
> A can then look at the field in message structure indicating the number
> of received packets. (This can be implemented in the sendDone() event)
> If it's *not* incremented, when the timer already hits 1,000
> microseconds. A re-transmits the packet.
>
> The above is just *preliminary* idea. Not sure if it's what you want.
>
> Ittipong
>
> 2008/8/10 ram kishore <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>
>
> Hi,
> Sorry for misleading.I am transmitting as well as receiving on
> the same mote.After I transmit,I need to wait for 1000 micro
> seconds.If I get a packet with this duration,I transmit next packet
> else re-transmit.
>
> My worry is I am not able to detect packet reception(even erroneous)
> from senddone() event.
>
> Regards,
> Kishore
>
> On Sun, Aug 10, 2008 at 3:56 PM, Ittipong Khemapech
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hi,
>
> I think that sendDone() is at the sending side *not* receiving
> side. If sendDone() returns SUCCESS, you may increment the
> number of sent packets. The other thing is modifying the code at
> the receiving side to increment the number of received packets.
>
> Hope this helps.
> Ittipong
>
> 2008/8/10 ram kishore <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>
>
> Hi all,
> Sorry for re-posting but desperate.After
> transmission, senddone() is signaled.Being in senddone()
> event,How can I be notified that packet has come?
> Any interrupts?macros for detecting that packet has
> come(need not be correct packet,just arrival)?
>
> Kindly Help,
>
> Regards,
> Kishore
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> <mailto:[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
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
