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?
2017-05-16 16:42 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>:
> 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 <bapcle...@gmail.com> 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 <bapcle...@gmail.com>:
>>> 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
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
--
Baptiste
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
