Hi Baptiste,
On 17 May 2017, at 1:14 PDT(-0700), Baptiste Clenet wrote:
According to their example:
Example:
A frame transmission of length five with TX_AUTO_CRC_ON set, is
started with a Frame Buffer write access of five bytes (the last two
bytes can be omitted). The first three bytes are used for FCS
generation; the last two bytes are replaced by the internally
calculated FCS.
Even a five bytes frame would have its last two bytes overwritten. Is
my understanding correct?
So I don't understand why the driver limits the frame length to 127-2?
The at86rf2xx driver doesn't limit the *frame length* to 127-2 octets
because the
FCS is part of the frame sent out. The driver just makes sure that no
payload
data is overwritten by the FCS.
Every 802.15.4 frame has two bytes of FCS. So if we didn't use
TX_AUTO_CRC_ON
we would have to calculate the checksum in software and write it into
the
frame buffer, appended to the header, sequence number, addresses and
payload we
want to send. All together (FCF + seq_num + addrs + payload + FCS) this
can
be 127 bytes max.
Now RIOT's at86rf2xx driver uses TX_AUTO_CRC_ON thus we don't have to
calculate
the FCS, it's appended to the rest of the frame.
Personally, I never tried what happens if you remove this check for
127-2 and
fully fill the frame buffer but I would imagine that exactly that
happens, the
last two bytes are overwritten by the FCS and thus lost, unless it
already was
the exact same checksum.
Best, Thomas
2017-05-16 16:42 GMT+02:00 Thomas Eichinger <[email protected]>:
Hi Baptiste,
If you take a look at figures 37-1 and 37-2 in the data sheet you
linked you can see that IEEE 802.15.4 allows up to 127 bytes for the
MPDU and this includes the FCS.
So if the driver would allow writing 127 bytes into the frame buffer
the last two bytes would indeed be overwritten which is undesired I
guess.
I hope I understood you correctly and this helps.
Best, Thomas
On May 16, 2017, at 6:09 AM, Baptiste Clenet <[email protected]>
wrote:
Thomas, Hauke, Martine, Kaspar what do you think about it?
My last question: how do I send a packet with length 127 octets with
at86rf2xx transceiver?
2017-05-15 14:59 GMT+02:00 Baptiste Clenet <[email protected]>:
Hi,
When I want to send a pkt which is 126 Octet long, I get a message
from [at86rf2xx]:
[at86rf2xx] error: packet too large (2 byte) to be send
IEE802.15.4 MAX length is 127 so it should be sent.
#define IEEE802154_FRAME_LEN_MAX (127U) /**< maximum frame
length */
I checked source code of at86rf2xx driver and I think I understand
the
magic number +2 in the if condition but I don't know why this is
checked.
at86rf2xx_netdev.c:110:
/* current packet data + FCS too long */
if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
DEBUG("[at86rf2xx] error: packet too large (%u byte) to
be
send (iov_len %d, i %d, count %d)\n",
(unsigned)len + 2, ptr->iov_len, i, count);
return -EOVERFLOW;
}
+2 mean two FCS octets?
In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:
For a frame with a frame length specified as N (3 ≤ N ≤ 127),
the FCS
is calculated on the first N-2 octets in the Frame Buffer, and the
resulting FCS field is transmitted in place of the last two octets
from the Frame Buffer.
Example:
A frame transmission of length five with TX_AUTO_CRC_ON set, is
started with a Frame Buffer write access of five bytes (the last
two
bytes can be omitted). The first three bytes are used for FCS
generation; the last two bytes are replaced by the internally
calculated FCS.
So while I think we should remove the +2 test and let the
possibility
to send packet up to 127 octets and I don't understand the part in
datasheet: "the last two bytes are replaced by the internally
calculated FCS". This mean that a part of data is erased? (for 5
octets or 127)
Cheers,
[1]
http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf
--
Baptiste
--
Baptiste
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
--
Baptiste
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
