Re: [riot-devel] At86rf2xx ACK frame
Hi Alex! On Fri, Jun 16, 2017 at 10:43:05PM +0200, Alexander Aring wrote: > On Fri, Jun 16, 2017 at 09:45:25PM +0200, Oleg Hahm wrote: > > Using at86rf2xx's extended operating mode allows you to figure out if an ACK > > was received or not, but not all models allows you to read if and how many > > retransmissions were necessary. > > Question here is: > > Is "how many retransmissions were necessary" is a required information > for IEEE 802.15.4 MLME-ops? If so, then the transceiver hardware has a > lack of support to implement IEEE 802.15.4, if not then this is some > "extra" feature. Not sure if this information is required. Required > information for some MLME-ops is if finally there was an ACK or NOT, no > matter how many retransmissions was involved. Hm, you can still use the base operation mode and implement "everything" (i.e., ACK handling, retransmissions etc.) yourself. Hence, the transceiver hardware is capable - it's just a matter of implementation comfort. > Such "extra" feature could only be useful to check how reliable a peer > is, maybe?. True. Cheers, Oleg -- printk(KERN_WARNING "%s: Thanks, I feel much better now!\n", dev->name); linux-2.6.6/drivers/net/de620.c ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
Hi, On Fri, Jun 16, 2017 at 09:45:25PM +0200, Oleg Hahm wrote: > Hi Alex! > > On Fri, Jun 16, 2017 at 09:21:18PM +0200, Alexander Aring wrote: > > On Fri, Jun 16, 2017 at 11:57:01AM +0200, Oleg wrote: > > > On 2017-06-16 11:27, Baptiste Clenet wrote: > > > > Yes Thomas I haven't tried yet but I don't think transceiver stores it. > > > > Joakim, OpenThread requires it as explained here: > > > > https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978 > > > > > > Sorry, I don't get the explanation. Why does OpenThread needs the pointer > > > to > > > the ACK frame? > > > > > > > Some IEEE 802.15.4 MLME-ops requires if the ack was received or not. > > This need be handled by upper layers e.g. a SoftMAC layer of IEEE > > 802.15.4. So actually if ARET is supported by hardware and it's an > > SoftMAC transceiver it should have the possibility to read out some > > status register of handled ARET algorithm on hardware side if ACK was > > there or not (because MLME-ops requires this information). If hardware > > can't report and is a SoftMAC transceiver with ARET support and can't > > handle MLME-ops on hardware side: you have a problem. > > Using at86rf2xx's extended operating mode allows you to figure out if an ACK > was received or not, but not all models allows you to read if and how many > retransmissions were necessary. > Question here is: Is "how many retransmissions were necessary" is a required information for IEEE 802.15.4 MLME-ops? If so, then the transceiver hardware has a lack of support to implement IEEE 802.15.4, if not then this is some "extra" feature. Not sure if this information is required. Required information for some MLME-ops is if finally there was an ACK or NOT, no matter how many retransmissions was involved. Such "extra" feature could only be useful to check how reliable a peer is, maybe?. - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
Hi Alex! On Fri, Jun 16, 2017 at 09:21:18PM +0200, Alexander Aring wrote: > On Fri, Jun 16, 2017 at 11:57:01AM +0200, Oleg wrote: > > On 2017-06-16 11:27, Baptiste Clenet wrote: > > > Yes Thomas I haven't tried yet but I don't think transceiver stores it. > > > Joakim, OpenThread requires it as explained here: > > > https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978 > > > > Sorry, I don't get the explanation. Why does OpenThread needs the pointer to > > the ACK frame? > > > > Some IEEE 802.15.4 MLME-ops requires if the ack was received or not. > This need be handled by upper layers e.g. a SoftMAC layer of IEEE > 802.15.4. So actually if ARET is supported by hardware and it's an > SoftMAC transceiver it should have the possibility to read out some > status register of handled ARET algorithm on hardware side if ACK was > there or not (because MLME-ops requires this information). If hardware > can't report and is a SoftMAC transceiver with ARET support and can't > handle MLME-ops on hardware side: you have a problem. Using at86rf2xx's extended operating mode allows you to figure out if an ACK was received or not, but not all models allows you to read if and how many retransmissions were necessary. Cheers, Oleg -- printk (KERN_ERR "%s: Oops - your private data area is hosed!\n", ...) linux-2.6.6/drivers/net/ewrk3.c ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
Hi Baptiste! On Fri, Jun 16, 2017 at 07:07:17PM +0200, Baptiste Clenet wrote: > If you get deeper, I think they use it to get the power of the > transmission and may be something else that I missed: > https://github.com/openthread/openthread/blob/master/src/core/mac/mac.cpp#L993 Thanks for the pointer. So, OpenThread is basically not interested in the ACK itself, but the accompanying information like RSSI and/or LQI. Well, in that case, I guess there's no way around using the base mode of the at86rf2xx. Thomas once started a branch for that which seemed to work fine at a first glance: https://github.com/thomaseichinger/RIOT/tree/feat/rf2xx_basic_netdev2 Not sure how much work would be required to rebase it on current master. One would also need to check if OpenThread also takes care about sending ACKs and retransmissions itself. Cheers, Oleg -- "The idea is to keep the green alien landing craft from taking up humans from the ground and changing them into mutants. A mutant is very dangerous to you, because it flies faster than you do and shoots at you." Beastie Boys, Time To Build ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
Hi, On Fri, Jun 16, 2017 at 07:07:17PM +0200, Baptiste Clenet wrote: > OpenThread asks all new platform to use new function: > otPlatRadioTxDone that requires ACK frame. > > If you get deeper, I think they use it to get the power of the > transmission and may be something else that I missed: > https://github.com/openthread/openthread/blob/master/src/core/mac/mac.cpp#L993 > yes, but the power is not part of ack frame payload. It's just the receive power measured when ARET was done "or something like that", or? And they do it to collect some per peer statistics about how reliable/link quality a neighbor is (I suppose). E.g. doing routing decisions afterwards. - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
Hi, On Fri, Jun 16, 2017 at 09:21:18PM +0200, Alexander Aring wrote: > Hi Oleg, > > On Fri, Jun 16, 2017 at 11:57:01AM +0200, Oleg wrote: > > Hi Baptiste! > > > > On 2017-06-16 11:27, Baptiste Clenet wrote: > > > Yes Thomas I haven't tried yet but I don't think transceiver stores it. > > > Joakim, OpenThread requires it as explained here: > > > https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978 > > > > Sorry, I don't get the explanation. Why does OpenThread needs the pointer to > > the ACK frame? > > > doh! Thought about why they need ackframe there or not, but it's about payload... sorry. - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
Hi Oleg, On Fri, Jun 16, 2017 at 11:57:01AM +0200, Oleg wrote: > Hi Baptiste! > > On 2017-06-16 11:27, Baptiste Clenet wrote: > > Yes Thomas I haven't tried yet but I don't think transceiver stores it. > > Joakim, OpenThread requires it as explained here: > > https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978 > > Sorry, I don't get the explanation. Why does OpenThread needs the pointer to > the ACK frame? > Some IEEE 802.15.4 MLME-ops requires if the ack was received or not. This need be handled by upper layers e.g. a SoftMAC layer of IEEE 802.15.4. So actually if ARET is supported by hardware and it's an SoftMAC transceiver it should have the possibility to read out some status register of handled ARET algorithm on hardware side if ACK was there or not (because MLME-ops requires this information). If hardware can't report and is a SoftMAC transceiver with ARET support and can't handle MLME-ops on hardware side: you have a problem. For my Linux experiments I tried to implement to make an upper layer report if ACK was there or not, see [0]. I didn't implement MLME-ops it was to keep per peer stats about link quality. Further this information for upper layer (mac802154) it's necessary for some IEEE 802.15.4 MLME-ops handled by this layer. I think OpenThread needs also this information for some of "future or already?" handled MLME-ops. --- What I have also in plans is... I need that also on an user space POSIX socket on linux. This requires obviously a synced transmit handling in user space for e.g. IEEE 802.15.4 sockets or even IPv6 Sockets. I want to handle such information over the "socket error queue" [1] which allows a synced xmit on user space level and even request if the transmitted frame/ipv6 packet got an acked frame back. Okay for IPv6 lot of more stuff need to be handled e.g. ACK handling report with fragmentation. But for IEEE 802.15.4 sockets I need this handling for running user space stacks e.g. RIOT in user space on a registered Linux 802.15.4 PHY. Which is actually a necessary use-case which I found, same can be adapted for IPv6/6LoWPAN (maybe somebody will specified protocols to check on L2 ack handling, I don't know if such thing exists). Note: the above idea was stolen from wireless (802.11) Linux subsystem, see [3]. - Alex [0] https://github.com/linux-wpan/linux-wpan-next/blob/for-mcr/drivers/net/ieee802154/at86rf230.c#L658 [1] https://linux.die.net/man/2/recv - MSG_ERRQUEUE [3] http://www.spinics.net/lists/netdev/msg176415.html ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
OpenThread asks all new platform to use new function: otPlatRadioTxDone that requires ACK frame. If you get deeper, I think they use it to get the power of the transmission and may be something else that I missed: https://github.com/openthread/openthread/blob/master/src/core/mac/mac.cpp#L993 2017-06-16 11:57 GMT+02:00 Oleg : > Hi Baptiste! > > On 2017-06-16 11:27, Baptiste Clenet wrote: >> >> Yes Thomas I haven't tried yet but I don't think transceiver stores it. >> Joakim, OpenThread requires it as explained here: >> https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978 > > > Sorry, I don't get the explanation. Why does OpenThread needs the pointer to > the ACK frame? > > Cheers, > Oleg -- Baptiste ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] devel Digest, Vol 52, Issue 14
Hi Craig, This would be welcome also from the RISC-V Foundation's side (and some other people who I know might be interested). I am on the marketing committee and we're always happy to see new activity, the more choice of OS, the better. Also in my role in Antmicro, we are building workshop badges based on SiFive E310 for the next RISC-V workshop in the Bay Area so it'd be cool to have the RIOT port running there too (currently we're using Zephyr). If you do manage to launch that effort, be sure to remind us to put you in the software status list: https://github.com/riscv/riscv-wiki/wiki/RISC-V-Software-Status Best regards, Michael > Date: Thu, 15 Jun 2017 08:53:03 -0700 > From: "Thomas Eichinger" > To: "RIOT OS kernel developers" > Subject: Re: [riot-devel] RIOT port to RISC-V? > Message-ID: <7ce74894-6066-4f2f-b5a8-5b718061a...@riot-os.org> > Content-Type: text/plain; format=flowed > > Hi Craig, > > That's great news and I am stoked to see support for RISC-V in RIOT. > > To my knowledge nobody put real effort into that yet. (I'm happy to be > corrected!) > If you need help or guidance on porting please don't hesitate to ask on > this list. > > Thanks and good luck for your funding proposal, > > Thomas > > On 15 Jun 2017, at 2:53 PDT(-0700), Craig S. Steele wrote: > > > I am preparing a funding proposal in the U.S., and am contemplating a > > port of RIOT to the 32-bit RISC-V architecture. We have HiFive > > development boards from SiFive.com, as well as FPGA platforms, to work > > on a project trying to provide hardware security support for 32-bit > > RISC-V MCU variants. > > > > It is helpful for the proposal process to know if anyone else is > > working on such a port to RISC-V. I have seen a question about that > > last year on the developers' email list, but have seen no indication > > that anyone is actually working on this port. If anyone is aware of > > any such effort at present, I'd appreciate that information. > > > > Thanks in advance, > > > > Craig Steele > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > > -- Michael Gielda mobile: +48 504 631 956 Antmicro Ltd | www.antmicro.com Zwierzyniecka 3, 60-813 Poznan, Poland ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
Hi Baptiste! On 2017-06-16 11:27, Baptiste Clenet wrote: Yes Thomas I haven't tried yet but I don't think transceiver stores it. Joakim, OpenThread requires it as explained here: https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978 Sorry, I don't get the explanation. Why does OpenThread needs the pointer to the ACK frame? Cheers, Oleg ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] At86rf2xx ACK frame
Yes Thomas I haven't tried yet but I don't think transceiver stores it. Joakim, OpenThread requires it as explained here: https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978 Shuguo, this a hack solution. There is a way to use old function which does not required the ACK frame so we're going to use as long as it is possible. 2017-06-16 9:47 GMT+02:00 Shuguo Zhuo : > I guess if you only want to use the ACK frame as an input of the function, > given that it is hard to get from the extended mode, then, maybe one > solution is that you can manually build one yourself (you can get the > sequence number from the hardware) and pass it to the function. > > Cheers, > Shuguo > > > > 发件人: "Joakim Nohlgård" > 收件人: "RIOT OS kernel developers" > 发送时间: 星期四, 2017年 6 月 15日 下午 10:55:03 > 主题: Re: [riot-devel] At86rf2xx ACK frame > > > Why do you need the actual ACK frame? It's only like 3 bytes + FCS and > doesn't really contain anything interesting. The only interesting > information is that the frame with the given sequence id was received > properly, which is exactly the same information you get from the transceiver > hardware. > > Regards, > Joakim > > On Jun 15, 2017 8:18 AM, "Baptiste Clenet" wrote: > > Which mean that automated ACK by the transceiver is fine. > 1 - RIOT sends a frame > 2 - Transceiver receives an ACK and transmit a > AT86RF2XX_TRX_STATE__TRAC_SUCCESS > 3 - Here I want to get the ACK frame content > 4 - Use it with openthread (Have a look here [1] to understand why we need > it) > > [1] > https://github.com/openthread/openthread/blob/master/include/openthread/platform/radio.h#L404 > > Cheers, > > 2017-06-13 15:46 GMT+02:00 Baptiste Clenet : >> 2017-06-13 14:45 GMT+02:00 Oleg : >>> Hi Baptiste! >>> >>> On 2017-06-13 12:30, Baptiste Clenet wrote: On netdev event: NETDEV_EVENT_TX_COMPLETE (after AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame received by at86rf2xx? >>> >>> >>> The ACK frame is processed automatically by the transceiver. There is no >>> way >>> to access it using the extended mode. If you use the base mode, you will >>> have to send and process the ACK yourself. >>> >> >> Ok I don't want to process the ACK myself, I only want to get the >> frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame >> store in a register/frame buffer? Or do we must use base mode to get >> the ACK frame. >> >>> >>> Cheers, >>> Oleg >>> ___ >>> devel mailing list >>> devel@riot-os.org >>> https://lists.riot-os.org/mailman/listinfo/devel >> >> >> >> -- >> 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 > > > > ___ > 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 ACK frame
I guess if you only want to use the ACK frame as an input of the function, given that it is hard to get from the extended mode, then, maybe one solution is that you can manually build one yourself (you can get the sequence number from the hardware) and pass it to the function. Cheers, Shuguo - 原始邮件 - > 发件人: "Joakim Nohlgård" > 收件人: "RIOT OS kernel developers" > 发送时间: 星期四, 2017年 6 月 15日 下午 10:55:03 > 主题: Re: [riot-devel] At86rf2xx ACK frame > Why do you need the actual ACK frame? It's only like 3 bytes + FCS and > doesn't really contain anything interesting. The only interesting > information is that the frame with the given sequence id was received > properly, which is exactly the same information you get from the transceiver > hardware. > Regards, > Joakim > On Jun 15, 2017 8:18 AM, "Baptiste Clenet" < bapcle...@gmail.com > wrote: > > Which mean that automated ACK by the transceiver is fine. > > > 1 - RIOT sends a frame > > > 2 - Transceiver receives an ACK and transmit a > > AT86RF2XX_TRX_STATE__TRAC_SUCCESS > > > 3 - Here I want to get the ACK frame content > > > 4 - Use it with openthread (Have a look here [1] to understand why we need > > it) > > > [1] > > https://github.com/openthread/openthread/blob/master/include/openthread/platform/radio.h#L404 > > > Cheers, > > > 2017-06-13 15:46 GMT+02:00 Baptiste Clenet < bapcle...@gmail.com >: > > > > 2017-06-13 14:45 GMT+02:00 Oleg < o...@riot-os.org >: > > > >> Hi Baptiste! > > > >> > > > >> On 2017-06-13 12:30, Baptiste Clenet wrote: > > > >>> > > > >>> On netdev event: NETDEV_EVENT_TX_COMPLETE (after > > > >>> AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame > > > >>> received by at86rf2xx? > > > >> > > > >> > > > >> The ACK frame is processed automatically by the transceiver. There is no > > >> way > > > >> to access it using the extended mode. If you use the base mode, you will > > > >> have to send and process the ACK yourself. > > > >> > > > > > > > > Ok I don't want to process the ACK myself, I only want to get the > > > > frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame > > > > store in a register/frame buffer? Or do we must use base mode to get > > > > the ACK frame. > > > > > > > >> > > > >> Cheers, > > > >> Oleg > > > >> ___ > > > >> devel mailing list > > > >> devel@riot-os.org > > > >> https://lists.riot-os.org/mailman/listinfo/devel > > > > > > > > > > > > > > > > -- > > > > 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
