2017-05-17 17:47 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>:
> 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.
I don't think it is appended to the frame but it really replace the
last two bytes of the frame
Example:
at86rf2xx_tx_load(dev, ptr->iov_base, 5, 0);
FCS is calculated on bytes 1, 2 and 3 and bytes 4 and 5 are replaced by FCS
at86rf2xx_tx_load(dev, ptr->iov_base, 126, 0);
FCS is calculated on bytes 1, to 124 and bytes 125 and 126 are replaced by FCS
So the stack which give the frame should give a frame 2bytes longer
to let the transceiver calculate the FCS.
This is why IMO this check is useless.
After reading more the datasheet, it's not clear because it is written:
On transmission the radio transceiver generates and appends the FCS
bytes during the frame transmission. This
behavior can be disabled by setting register bit TX_AUTO_CRC_ON = 0
(register 0x04, TRX_CTRL_1).
>
> 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 <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
>
> _______________________________________________
> 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
