Hi David,
Thanks for the explanation.
The treatment of packets already in the RXFIFO queue is definitely
reasonable to the receiver. But if we use SACK to issue acknowledgements
like in CC2420ReceiveP.nc, the 3rd packet may wait quite some time before
the ack for it is sent, and hence the deadline at sender side may have been
missed. The delay before ack timer fires is CC2420_ACK_WAIT_DELAY = 256, so
does it take the delay in reading RXFIFO into consideration? What is the SPI
speed in TelosB or TmoteSky?
Thanks,
Sha
--------------------------------------------------
From: "David Moss" <[EMAIL PROTECTED]>
Sent: Monday, March 17, 2008 10:21 AM
To: "'Liusand'" <[EMAIL PROTECTED]>; <tinyos-help@millennium.berkeley.edu>
Subject: RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS
2.0.2?
Hi Sha -
You're right, we are missing a check for RXFIFO overflow. Right now the
maximum default CC2420 packet size in TinyOS is 41 bytes (including CRC).
The RXFIFO is 128 bytes, which means you'd be able to fit 3 full packets
in
the RXFIFO before an overflow occurs. Although I think it may be unlikely
that you'd spontaneously receive 3+ full packets in the RXFIFO due to CSMA
backoffs and transmit delays, it can still happen.
But imagine this scenario: you receive 3 maxed-out packets that are valid,
and get a fourth packet that causes an RXFIFO overflow, and is therefore
corrupted. Do you flush the RXFIFO at that point and lose the 3 valid
packets that are already in there? Or do you wait until you're reading
out
the fourth packet that is corrupted before flushing it? In the current
scenario, you read out the amount of data as specified by the fourth
packet
and see that the CRC doesn't check out. Upon reading the next packet, the
length is found to be invalid and the RXFIFO is flushed.
Putting in an explicit check for RXFIFO overflow may be more desirable,
but
the question is, when is the best time to flush the RXFIFO? Right when
the
error occurs? Or after you get any remaining valid packets out?
-David
-----Original Message-----
From: Liusand [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 10:33 PM
To: David Moss; tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS
2.0.2?
Thanks, David.
I have some questions concerning RXFIFO overflow. In CC2420ReceiveP.nc,
RXFIFO is flushed only when the length byte is invalid. So where is RXFIFO
overflow taken care of? Can reading bytes from RXFIFO automatically clear
the overflow status?
Also, in CC2420TransmitP, RXFIFO overflow status is not checked before
issuing the STXONCCA or STXON strobe. So if RXFIFO has already overflowed,
there will be no more space for ack frame. TinyOS 1.1.15 does do this
check
before sending and flush RXFIFO accordingly even though I'm not sure if it
is for this purpose.
Thanks,
-Sha
--------------------------------------------------
From: "David Moss" <[EMAIL PROTECTED]>
Sent: Friday, March 14, 2008 5:26 PM
To: "'Liusand'" <[EMAIL PROTECTED]>;
<tinyos-help@millennium.berkeley.edu>
Subject: RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS
2.0.2?
The TX FIFO is preloaded with data. The data is not being transmitted to
the CC2420 as the transmission is taking place, unlike other chips.
Because
of the preload, it is impossible for the CC2420 to produce a TXFIFO
UNDERFLOW. All the data to send is available on the chip when transmit
occurs.
Due to the rules of the CSMA and Transmit modules, a new packet cannot be
uploaded to the TX FIFO until the previous packet in the TX FIFO was
transmitted. This should guarantee that the TX FIFO be empty when the
next
transmit occurs. If a cancel occurs, a quick SFLUSHTX empties the
contents
of the TX FIFO.
-David
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Liusand
Sent: Friday, March 14, 2008 12:45 PM
To: tinyos-help@millennium.berkeley.edu
Subject: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS
2.0.2?
Hi,
When I was studying CC2420TransmitP.nc, I noticed that TXFIFO is never
flushed and underflow status is never checked. In CC2420RadioM.nc from
TinyOS 1.1.15, TXFIFO is flushed in startSend() every time before it is
written data to.
It might be too conservative in TinyOS 1.1.15, but why overflow is never
taken care of in TinyOS 2.0.2?
Another related question is, in which situations TXFIFO underflow may
happen?
Thanks,
Sha
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
