Re: [riot-devel] RIOT Package
Hi Baptiste, On Wed, May 17, 2017 at 08:24:50AM +0200, Baptiste Clenet wrote: > Concerning external package, I suggest that RIOT download and store > the archive in pkg folder then extract here in the right location to > be compiled. This is helpful when you work on a package so you don't > need to download it again every time after a `make clean` or when you > compile another example, you need to download it again. > What do you think? for Git-based packages you can use git-cache for exactly this purpose [1]. Cheers, Oleg [1] https://github.com/kaspar030/git-cache -- RAID joke are always redundant ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Package
So you mean that git-cache is already used and allow to download an archive of a .git repo? Could you give me an example of a package that is download as an archive and store so you don't need to git clone again? 2017-05-17 9:28 GMT+02:00 Oleg Hahm : > Hi Baptiste, > > On Wed, May 17, 2017 at 08:24:50AM +0200, Baptiste Clenet wrote: >> Concerning external package, I suggest that RIOT download and store >> the archive in pkg folder then extract here in the right location to >> be compiled. This is helpful when you work on a package so you don't >> need to download it again every time after a `make clean` or when you >> compile another example, you need to download it again. >> What do you think? > > for Git-based packages you can use git-cache for exactly this purpose [1]. > > Cheers, > Oleg > > [1] https://github.com/kaspar030/git-cache > -- > RAID joke are always redundant > ___ > 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
Re: [riot-devel] RIOT Package
Hi Baptiste! On Wed, May 17, 2017 at 10:08:50AM +0200, Baptiste Clenet wrote: > So you mean that git-cache is already used and allow to download an > archive of a .git repo? Yes, but you have to "install" git-cache first (see dist/tools/git/README.md). > Could you give me an example of a package that is download as an > archive and store so you don't need to git clone again? Every git-based package uses git-cache, e.g. nanocoap or ccn-lite. Cheers, Oleg -- Yo mamma is so fat that she sat on a binary tree and made it a linked list in constant time. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] at86rf2xx: packet too large -> FCS check
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 : > 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 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 : >>> 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
Re: [riot-devel] RIOT Package
Thank you for your answers. I see! Very interesting feature and I really think it should be enabled by default! What's your opinion? 2017-05-17 10:12 GMT+02:00 Oleg Hahm : > Hi Baptiste! > > On Wed, May 17, 2017 at 10:08:50AM +0200, Baptiste Clenet wrote: >> So you mean that git-cache is already used and allow to download an >> archive of a .git repo? > > Yes, but you have to "install" git-cache first (see dist/tools/git/README.md). > >> Could you give me an example of a package that is download as an >> archive and store so you don't need to git clone again? > > Every git-based package uses git-cache, e.g. nanocoap or ccn-lite. > > Cheers, > Oleg > -- > Yo mamma is so fat that she sat on a binary tree and made it a linked list in > constant time. > ___ > 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
Re: [riot-devel] RIOT Package
Hi! On Wed, May 17, 2017 at 10:21:45AM +0200, Baptiste Clenet wrote: > I see! Very interesting feature and I really think it should be > enabled by default! What's your opinion? Not sure what you mean. The feature is enabled by default, the only thing you need to do is to add git-cache to your $PATH. Cheers, Oleg -- /* Fuck me gently with a chainsaw... */ linux-2.0.38/arch/sparc/kernel/ptrace.c ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Package
Hi Baptiste, Oleg, On 17-05-17 11:07:25, Oleg Hahm wrote: > Hi! > > On Wed, May 17, 2017 at 10:21:45AM +0200, Baptiste Clenet wrote: > > I see! Very interesting feature and I really think it should be > > enabled by default! What's your opinion? > > Not sure what you mean. The feature is enabled by default, the only thing you > need to do is to add git-cache to your $PATH. That's not necessary. RIOT's build system looks explicitly in `dist/tools/git` for `git-cache`. However, it is necessary to initialize `git-cache` once with `$RIOT/dist/tools/git/git-cache init`. This will create an empty bare git reposiroty in $HOME that is used to cache the necessary git objects. Cheers, Cenk > > Cheers, > Oleg > -- > /* Fuck me gently with a chainsaw... */ > linux-2.0.38/arch/sparc/kernel/ptrace.c > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] devel Digest, Vol 51, Issue 10
1. Re: RIOT Package (Baptiste Clenet) On Wed, May 17, 2017 at 6:00 PM, wrote: > Send devel mailing list submissions to > devel@riot-os.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.riot-os.org/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to > devel-requ...@riot-os.org > > You can reach the person managing the list at > devel-ow...@riot-os.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > > Today's Topics: > >1. Re: RIOT Package (Baptiste Clenet) >2. Re: RIOT Package (Oleg Hahm) >3. Re: RIOT Package (Cenk Gündoğan) > > > -- > > Message: 1 > Date: Wed, 17 May 2017 10:21:45 +0200 > From: Baptiste Clenet > To: RIOT OS kernel developers > Subject: Re: [riot-devel] RIOT Package > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Thank you for your answers. > > I see! Very interesting feature and I really think it should be > enabled by default! What's your opinion? > > 2017-05-17 10:12 GMT+02:00 Oleg Hahm : > > Hi Baptiste! > > > > On Wed, May 17, 2017 at 10:08:50AM +0200, Baptiste Clenet wrote: > >> So you mean that git-cache is already used and allow to download an > >> archive of a .git repo? > > > > Yes, but you have to "install" git-cache first (see > dist/tools/git/README.md). > > > >> Could you give me an example of a package that is download as an > >> archive and store so you don't need to git clone again? > > > > Every git-based package uses git-cache, e.g. nanocoap or ccn-lite. > > > > Cheers, > > Oleg > > -- > > Yo mamma is so fat that she sat on a binary tree and made it a linked > list in > > constant time. > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > > > > -- > Baptiste > > > -- > > Message: 2 > Date: Wed, 17 May 2017 11:07:25 +0200 > From: Oleg Hahm > To: RIOT OS kernel developers > Subject: Re: [riot-devel] RIOT Package > Message-ID: <20170517090725.forwgqab5ecok...@hobbykeller.org> > Content-Type: text/plain; charset=us-ascii > > Hi! > > On Wed, May 17, 2017 at 10:21:45AM +0200, Baptiste Clenet wrote: > > I see! Very interesting feature and I really think it should be > > enabled by default! What's your opinion? > > Not sure what you mean. The feature is enabled by default, the only thing > you > need to do is to add git-cache to your $PATH. > > Cheers, > Oleg > -- > /* Fuck me gently with a chainsaw... */ > linux-2.0.38/arch/sparc/kernel/ptrace.c > > > -- > > Message: 3 > Date: Wed, 17 May 2017 11:20:57 +0200 > From: Cenk Gündoğan > To: devel@riot-os.org > Subject: Re: [riot-devel] RIOT Package > Message-ID: <20170517092057.GA5165@cgundogan.localdomain> > Content-Type: text/plain; charset="utf-8" > > Hi Baptiste, Oleg, > > On 17-05-17 11:07:25, Oleg Hahm wrote: > > Hi! > > > > On Wed, May 17, 2017 at 10:21:45AM +0200, Baptiste Clenet wrote: > > > I see! Very interesting feature and I really think it should be > > > enabled by default! What's your opinion? > > > > Not sure what you mean. The feature is enabled by default, the only > thing you > > need to do is to add git-cache to your $PATH. > > That's not necessary. RIOT's build system looks explicitly in > `dist/tools/git` for `git-cache`. However, it is necessary to initialize > `git-cache` once with `$RIOT/dist/tools/git/git-cache init`. This will > create an empty bare git reposiroty in $HOME that is used to cache > the necessary git objects. > > Cheers, > Cenk > > > > > Cheers, > > Oleg > > -- > > /* Fuck me gently with a chainsaw... */ > > linux-2.0.38/arch/sparc/kernel/ptrace.c > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > -- next part -- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: <http://lists.riot-os.org/pipermail/devel/attachments/ > 20170517/f3b8a540/attachment-0001.sig> > > -- > > Subject: Digest Footer > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > > -- > > End of devel Digest, Vol 51, Issue 10 > * > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Package
2017-05-17 11:20 GMT+02:00 Cenk Gündoğan : > Hi Baptiste, Oleg, > > On 17-05-17 11:07:25, Oleg Hahm wrote: >> Hi! >> >> On Wed, May 17, 2017 at 10:21:45AM +0200, Baptiste Clenet wrote: >> > I see! Very interesting feature and I really think it should be >> > enabled by default! What's your opinion? >> >> Not sure what you mean. The feature is enabled by default, the only thing you >> need to do is to add git-cache to your $PATH. > > That's not necessary. RIOT's build system looks explicitly in > `dist/tools/git` for `git-cache`. However, it is necessary to initialize > `git-cache` once with `$RIOT/dist/tools/git/git-cache init`. This will > create an empty bare git reposiroty in $HOME that is used to cache > the necessary git objects. Yes it is what I mean, `git-cache` should be initialized automatically at the first compilation. I do think it is possible and will avoid people to forget to initialize it. > > Cheers, > Cenk > >> >> Cheers, >> Oleg >> -- >> /* Fuck me gently with a chainsaw... */ >> linux-2.0.38/arch/sparc/kernel/ptrace.c >> ___ >> 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
Re: [riot-devel] at86rf2xx: packet too large -> FCS check
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 : 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 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 : 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
Re: [riot-devel] at86rf2xx: packet too large -> FCS check
2017-05-17 17:47 GMT+02:00 Thomas Eichinger : > 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 : >>> >>> 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 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 : > > 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 intern
Re: [riot-devel] at86rf2xx: packet too large -> FCS check
Hi, On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote: > 2017-05-17 17:47 GMT+02:00 Thomas Eichinger : > > 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 > starting here at 0 or 1? :S Replaced by FCS? I suppose this function loads frame into framebuffer, the FCS isn't calculated there. See below. > 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). > I think when the transmitter starts sending the FRAME -> going into BUSY. The transceiver will make some: init_fcs(); for (b:each_bytes_to_tx) { <--- 127 - 2 send(b); calc_fcs(b); } send_fcs(); <--- 2 bytes then you need to be sure you send 127 - 2 bytes out. If you disable --- now if you disable AUTO_CRC then you can load 127 bytes into framebuffer and hopefully last 2 bytes are FCS (or doesn't need to be, but then you running out-of-spec). - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT Package
Cool! Let's do a PR? Or is there any other problem? Le 17 mai 2017 21:10, "Kaspar Schleiser" a écrit : > Hey, > > On 05/17/2017 07:25 PM, Baptiste Clenet wrote: > > I see. > > Is there another way to initialize it inside RIOT repo instead of home > > directory? > > Sure, just set the "GIT_CACHE_DIR" environment variable to the desired > directory, then run "dist/tools/git/git-cache init". > > Kaspar > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] at86rf2xx: packet too large -> FCS check
I re-do my example again started at 0: Example: at86rf2xx_tx_load(dev, ptr->iov_base, length=5, 0); FCS is calculated on bytes 0, 1 and 2 and bytes 3 and 4 are replaced by FCS at86rf2xx_tx_load(dev, ptr->iov_base, length=126, 0); FCS is calculated on bytes 0, to 123 and bytes 124 and 125 are replaced by FCS In your example Alexandre: > I think when the transmitter starts sending the FRAME -> going into > BUSY. The transceiver will make some: > > init_fcs(); > for (b:each_bytes_to_tx) { <--- 127 - 2 >send(b); >calc_fcs(b); > } > send_fcs(); <--- 2 bytes > > then you need to be sure you send 127 - 2 bytes out You send to the radio driver N bytes, then the transceiver calculates FCS on this N bytes and after sending these N bytes, send the calculated FCS. So you say that transmitter appends FCS to the given frame. Now, I'm helping to port OpenThread on RIOT and OpenThread stack gives sometimes to the radio driver a frame of 126 bytes. My team asks them how is it possible: Their answer: > The IEEE 802.15.4 frame length includes the FCS bytes at the end of the > frame. The radio driver should simply update the last two bytes of the frame > rather than extending it. If I understand well, RIOT stack does not include FCS in its ieee802154 layer and OpenThread stack includes it? Am I right? 2017-05-17 21:26 GMT+02:00 Alexander Aring : > Hi, > > On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote: >> 2017-05-17 17:47 GMT+02:00 Thomas Eichinger : >> > 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 >> > > starting here at 0 or 1? :S > > Replaced by FCS? I suppose this function loads frame into framebuffer, > the FCS isn't calculated there. See below. > >> 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). >> > > I think when the transmitter starts sending the FRAME -> going into > BUSY. The transceiver will make some: > > init_fcs(); > for (b:each_bytes_to_tx) { <--- 127 - 2 > send(b); > calc_fcs(b); > } > send_fcs(); <--- 2 bytes > > then you need to be sure you send 127 - 2 bytes out. If you disable > > --- > > now if you disable AUTO_CRC then you can load 127 bytes into framebuffer > and hopefully last 2 bytes are FCS (or doesn't need to be, but then you > running out-of-spec). > > - Alex > ___ > 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