Re: [riot-devel] Netdev2 State changes
Hi Alex, sorry for the big delay. NETOPT_ACK_REQ, NETOPT_AUTOACK as well as NETOPT_RETRANS, NETOPT_CSMA or NETOPT_CSMA_RETRIES are not meant to be called each time before a frame-transmission but just to set the option on the device/driver. That means -if set- the driver will set the ACK REQ bit automatically for each frame it sends. Best Peter Am 14.09.2016 um 10:25 schrieb Alexander Aring: Hi, On 09/13/2016 11:31 PM, Peter Kietzmann wrote: Hi Alex, It confuses me a little bit here, does such netdev2 option exists to disable auto-acknowledgement or not? For me it should always depends on the acknowledgement-request bit in fc field. have a look at this PR: https://github.com/RIOT-OS/RIOT/pull/5297 . I agree with you that (except in promiscuous sniffer mode) the ACK of a receiver should depend on the ACK request field of the received frame which will be handled by the hardware (in case AACK is not disabled). IIRC "NETOPT_AUTOACK" once was meant to handle the ACK request of a transmitter but the name was a bit misleading. okay, but why does this setting reach the driver layer, or does it not? The driver(or in case of at86rf2xx the hardware) should check if the acknowledgement-request bit is set or not and this _per_ _frame_ and prepare transceiver to do ARET handling if it's set (maybe inside the transmit callback of driver layer). Or will the NETOPT_ACK_REQ option called each time before transmit to signal the fc acknowledgement-request bit? This confuse me then with the at86rf2xx hardware which will do ARET handling or not at hardware side by checking fc acknowledgement-request bit setting in fc. Such setting should only reach the mac layer, which controls then the frame control field generation of 802.15.4 dataframes, in my opinion. The transceiver should has some per frame decision if doing ARET or not ARET handling before transmit, or do nothing e.g. at86rf2xx because the hardware does that check. (sniffer) I think our handling in Linux is to let ARET enabled but disable AACK handling. AACK handling without address filtering will occur that you ack mostly every frame which will arrived. :-) - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Netdev2 State changes
Hi, On 09/13/2016 11:31 PM, Peter Kietzmann wrote: > Hi Alex, > >> It confuses me a little bit here, does such netdev2 option exists to >> disable auto-acknowledgement or not? For me it should always depends >> on the acknowledgement-request bit in fc field. > > have a look at this PR: > > https://github.com/RIOT-OS/RIOT/pull/5297 . > > I agree with you that (except in promiscuous sniffer mode) the ACK of a > receiver should depend on the ACK request field of the received frame which > will be handled by the hardware (in case AACK is not disabled). IIRC > "NETOPT_AUTOACK" once was meant to handle the ACK request of a transmitter > but the name was a bit misleading. > okay, but why does this setting reach the driver layer, or does it not? The driver(or in case of at86rf2xx the hardware) should check if the acknowledgement-request bit is set or not and this _per_ _frame_ and prepare transceiver to do ARET handling if it's set (maybe inside the transmit callback of driver layer). Or will the NETOPT_ACK_REQ option called each time before transmit to signal the fc acknowledgement-request bit? This confuse me then with the at86rf2xx hardware which will do ARET handling or not at hardware side by checking fc acknowledgement-request bit setting in fc. Such setting should only reach the mac layer, which controls then the frame control field generation of 802.15.4 dataframes, in my opinion. The transceiver should has some per frame decision if doing ARET or not ARET handling before transmit, or do nothing e.g. at86rf2xx because the hardware does that check. (sniffer) I think our handling in Linux is to let ARET enabled but disable AACK handling. AACK handling without address filtering will occur that you ack mostly every frame which will arrived. :-) - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Netdev2 State changes
Hi Alex, It confuses me a little bit here, does such netdev2 option exists to disable auto-acknowledgement or not? For me it should always depends on the acknowledgement-request bit in fc field. have a look at this PR: https://github.com/RIOT-OS/RIOT/pull/5297 . I agree with you that (except in promiscuous sniffer mode) the ACK of a receiver should depend on the ACK request field of the received frame which will be handled by the hardware (in case AACK is not disabled). IIRC "NETOPT_AUTOACK" once was meant to handle the ACK request of a transmitter but the name was a bit misleading. Best Peter Am 13.09.2016 um 22:50 schrieb Alexander Aring: Hi, On 09/13/2016 10:15 PM, Neo wrote: Hello Peter, shure - in the datasheet you find this RFSTATE, but it is not really helpful. RTSEL1 and RTSEL2 are not described at all. The CALVCO and CALFIL show Calibration States, so the only useful states seems to be RX, TX, SLEEP and RESET. But every code I have seen up to know uses the RX State during receive and transmit. I tried to monitor this register to see if the TX state is visible during transmitting packets, but no success. The state field shows only RX. I tried to force the chip to show TX state by setting bit-1 of RFCTL register (RFTXMODE). No success - the chip stucks. So for me it looks like the RFSTATE register is useless, except the detection of reset and sleep. The driver is able to transmit packet without auto-retransmission. I have at the moment the problem to distinguish the phases of transmission or reception inside the interrupt service routine (_isr) and to set the correct netdev2 states if I configure the system to use auto-retries and auto-acknowledgement. I hope I understand this correctly and will try to answer your question: -- - I have at the moment the problem to distinguish the phases of transmission or reception inside the interrupt service routine -> This is indicated by BIT_TXNIF or BIT_RXIF of REG_INTSTAT (using linux defines here) But these indicates tx _completion_ rx _completion_. --- - and to set the correct netdev2 states -> I would suggest here if after setting the "transmit my frame on the air command", means BIT_TXNTRIG in REG_TXNCON you need to set the netdev2 state to TX, if you get a tx completion interrupt then you set back to RX state. --- - system to use auto-retries and auto-acknowledgement. -> auto-retransmit should be done when the acknowledge-request bit in the 802.15.4 frame control field is set. The at86rf2xx do this automatically by check on this bit at _hardware_ level. The mrf24j40 needs to set the BIT_TXNACKREQ in REG_TXNCON, before TXNTRIG. The complete retransmission algorithmn will be done by hardware then. It confuses me a little bit here, does such netdev2 option exists to disable auto-acknowledgement or not? For me it should always depends on the acknowledgement-request bit in fc field. :-/ Of course, when hardware exists where you can't control another handling if this bit is set e.g. at86rf2xx. It would be possible to make sending frames out in at86rf2xx without retransmission and acknowledgement-request bit is set, but this needs a complete different state machine there to go into TX_ON instead TX_ARET_ON, but the use-case is not there. Note: This handling may depends if the transceiver is in some kind of "RIOT sniffer mode" - I don't know RIOT's policy here. -> auto-acknowledgement, should be never turned off (in my opinion), except you run RIOT as sniffer. I think for "auto-acknowledgement" you can't _exactly_ track the states which the hardware does. E.g. transmit a frame and wait for a received ack. True, this would be a state change from "TX to RX", but you can't track it because it's done by hardware. The at86rf2xx will handle that also as TX_ARET_BUSY only, there is no change to get the "very small" receiving state after transmission. Also see my other related question, if the tx state is "including" filling tx buffer, or "excluding". This could differs on mrf24j40 with at86rf2xx because separate tx and rx framebuffers. I hope I could help here. - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Netdev2 State changes
Hi, On 09/13/2016 10:50 PM, Alexander Aring wrote: ... > > I think for "auto-acknowledgement" you can't _exactly_ track the states > which the hardware does. E.g. transmit a frame and wait for a received ack. > True, this would be a state change from "TX to RX", but you can't track > it because it's done by hardware. The at86rf2xx will handle that also as > TX_ARET_BUSY only, there is no change to get the "very small" receiving > state after transmission. > s/change/chance/ And the same is for "RX to TX", when receiving a frame and sends an ACK frame back. This will also occur no netdev2 statechange in at86rf2xx. It's not possible to detect this statechange on hardware (so far I know). It will handled as RX state completely. - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Netdev2 State changes
Hi, thanks for the informations. I wasn't aware of 'em all and I still didn't read the whole manual. To find a solution, let me ask you some questions: - So the "TX" bit in the "RFSTATE" does not function? - In sec. 3.12.2 point 4 is written > Transmit the packet by setting the TXNTRIG > (TXNCON 0x1B<0>) bit = 1. The bit will be > automatically cleared by hardware. Do you know *when* exactly the hardware will clear this bit? After the actual transmission or directly after setting the bit to transmit the frame? - Do you see any reason *not* to handle this state in "pure" software? (@Neo I wrote that before reading your latest mail. Still I wanted to let this point in) - Do I understand it correctly that potential (e.g.) retransmissions might take longer than you can determine by pure software? - I assume you looked at lines around this in the Atmel driver, right? https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L638 Were do you see the biggest issue in simply not implementing it? (This is not a proposal but just to get a deeper understanding of the problem :-)) - @Alex I agree with you that the general term "TX state" might have different meanings on different devices. However, IMO the driver should handle it's states internally correct and the interface to the upper layer are given by these potential event types: https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/net/netdev2.h Where do you see the room for improvement in this thing? Best Peter Am 13.09.2016 um 22:15 schrieb Neo: Hello Peter, shure - in the datasheet you find this RFSTATE, but it is not really helpful. RTSEL1 and RTSEL2 are not described at all. The CALVCO and CALFIL show Calibration States, so the only useful states seems to be RX, TX, SLEEP and RESET. But every code I have seen up to know uses the RX State during receive and transmit. I tried to monitor this register to see if the TX state is visible during transmitting packets, but no success. The state field shows only RX. I tried to force the chip to show TX state by setting bit-1 of RFCTL register (RFTXMODE). No success - the chip stucks. So for me it looks like the RFSTATE register is useless, except the detection of reset and sleep. The driver is able to transmit packet without auto-retransmission. I have at the moment the problem to distinguish the phases of transmission or reception inside the interrupt service routine (_isr) and to set the correct netdev2 states if I configure the system to use auto-retries and auto-acknowledgement. Regards, Neo Am 13.09.2016 um 09:23 schrieb Peter Kietzmann: Hi Neo, there might be code snippets that actively wait for a state transition, but AFAIK not in the netdev part any more. Then there is interrupt handling which signals tx/rx start/end points to the upper layer. Of course you can't implement anything once it's not available on the device. The great thing about netdev is that it's pretty generic and you don't *need* to implement every function/message/interrupt/state change/whatsoever to get the device running. But looking at the data sheet I stumbled upon the RFSTATE register which signals the following (useful) sates: 111 = RTSEL2 110 = RTSEL1 101 = RX 100 = TX 011 = CALVCO 010 = SLEEP 001 = CALFIL 000 = RESET In addition there is the INTSTAT register which seems somehow similar to the Atmel radio. Where exactly did you stuck? Could you be a more precise? Best Peter Am 11.09.2016 um 17:38 schrieb Neo: Dear radio module driver developers, as far as I have seen, the netdev2 architecture reads several time the state of the radio chip to synchronize with the hardware dependent part of the driver (state changes). This is wonderful if the radio chip has a register which shows the actual state of the radio-modul - like the TRX_STATUS register inside of the Atmel chips. What could be done, if the radio chip doesn't have such a register or shows only rudiment state informations to synchronize/trigger the netdev2 part of the driver. The MRF24J40 from Microchip for example shows only the following useful state information: RX SLEEP RESET Transmission is done in the RX state without any changes, just trigger the transission (TXNCON-Reg./TXNTRIG-Bit). Thanks a lot! Regards, Neo ___ 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 -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Netdev2 State changes
Hi, On 09/13/2016 10:15 PM, Neo wrote: > Hello Peter, > shure - in the datasheet you find this RFSTATE, but it is not really helpful. > RTSEL1 and RTSEL2 are not described at all. The CALVCO and CALFIL show > Calibration States, so the only useful states seems to be RX, TX, SLEEP and > RESET. But every code I have seen up to know uses the RX State during receive > and transmit. I tried to monitor this register to see if the TX state is > visible during transmitting packets, but no success. The state field shows > only RX. > I tried to force the chip to show TX state by setting bit-1 of RFCTL register > (RFTXMODE). No success - the chip stucks. > So for me it looks like the RFSTATE register is useless, except the detection > of reset and sleep. > The driver is able to transmit packet without auto-retransmission. > I have at the moment the problem to distinguish the phases of transmission or > reception inside the interrupt service routine (_isr) and to set the correct > netdev2 states if I configure the system to use auto-retries and > auto-acknowledgement. > I hope I understand this correctly and will try to answer your question: -- - I have at the moment the problem to distinguish the phases of transmission or reception inside the interrupt service routine -> This is indicated by BIT_TXNIF or BIT_RXIF of REG_INTSTAT (using linux defines here) But these indicates tx _completion_ rx _completion_. --- - and to set the correct netdev2 states -> I would suggest here if after setting the "transmit my frame on the air command", means BIT_TXNTRIG in REG_TXNCON you need to set the netdev2 state to TX, if you get a tx completion interrupt then you set back to RX state. --- - system to use auto-retries and auto-acknowledgement. -> auto-retransmit should be done when the acknowledge-request bit in the 802.15.4 frame control field is set. The at86rf2xx do this automatically by check on this bit at _hardware_ level. The mrf24j40 needs to set the BIT_TXNACKREQ in REG_TXNCON, before TXNTRIG. The complete retransmission algorithmn will be done by hardware then. It confuses me a little bit here, does such netdev2 option exists to disable auto-acknowledgement or not? For me it should always depends on the acknowledgement-request bit in fc field. :-/ Of course, when hardware exists where you can't control another handling if this bit is set e.g. at86rf2xx. It would be possible to make sending frames out in at86rf2xx without retransmission and acknowledgement-request bit is set, but this needs a complete different state machine there to go into TX_ON instead TX_ARET_ON, but the use-case is not there. Note: This handling may depends if the transceiver is in some kind of "RIOT sniffer mode" - I don't know RIOT's policy here. -> auto-acknowledgement, should be never turned off (in my opinion), except you run RIOT as sniffer. I think for "auto-acknowledgement" you can't _exactly_ track the states which the hardware does. E.g. transmit a frame and wait for a received ack. True, this would be a state change from "TX to RX", but you can't track it because it's done by hardware. The at86rf2xx will handle that also as TX_ARET_BUSY only, there is no change to get the "very small" receiving state after transmission. Also see my other related question, if the tx state is "including" filling tx buffer, or "excluding". This could differs on mrf24j40 with at86rf2xx because separate tx and rx framebuffers. I hope I could help here. - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Netdev2 State changes
Hello Peter, shure - in the datasheet you find this RFSTATE, but it is not really helpful. RTSEL1 and RTSEL2 are not described at all. The CALVCO and CALFIL show Calibration States, so the only useful states seems to be RX, TX, SLEEP and RESET. But every code I have seen up to know uses the RX State during receive and transmit. I tried to monitor this register to see if the TX state is visible during transmitting packets, but no success. The state field shows only RX. I tried to force the chip to show TX state by setting bit-1 of RFCTL register (RFTXMODE). No success - the chip stucks. So for me it looks like the RFSTATE register is useless, except the detection of reset and sleep. The driver is able to transmit packet without auto-retransmission. I have at the moment the problem to distinguish the phases of transmission or reception inside the interrupt service routine (_isr) and to set the correct netdev2 states if I configure the system to use auto-retries and auto-acknowledgement. Regards, Neo Am 13.09.2016 um 09:23 schrieb Peter Kietzmann: Hi Neo, there might be code snippets that actively wait for a state transition, but AFAIK not in the netdev part any more. Then there is interrupt handling which signals tx/rx start/end points to the upper layer. Of course you can't implement anything once it's not available on the device. The great thing about netdev is that it's pretty generic and you don't *need* to implement every function/message/interrupt/state change/whatsoever to get the device running. But looking at the data sheet I stumbled upon the RFSTATE register which signals the following (useful) sates: 111 = RTSEL2 110 = RTSEL1 101 = RX 100 = TX 011 = CALVCO 010 = SLEEP 001 = CALFIL 000 = RESET In addition there is the INTSTAT register which seems somehow similar to the Atmel radio. Where exactly did you stuck? Could you be a more precise? Best Peter Am 11.09.2016 um 17:38 schrieb Neo: Dear radio module driver developers, as far as I have seen, the netdev2 architecture reads several time the state of the radio chip to synchronize with the hardware dependent part of the driver (state changes). This is wonderful if the radio chip has a register which shows the actual state of the radio-modul - like the TRX_STATUS register inside of the Atmel chips. What could be done, if the radio chip doesn't have such a register or shows only rudiment state informations to synchronize/trigger the netdev2 part of the driver. The MRF24J40 from Microchip for example shows only the following useful state information: RX SLEEP RESET Transmission is done in the RX state without any changes, just trigger the transission (TXNCON-Reg./TXNTRIG-Bit). Thanks a lot! Regards, Neo ___ 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] Netdev2 State changes
Hi, On 09/13/2016 09:23 AM, Peter Kietzmann wrote: > Hi Neo, > > there might be code snippets that actively wait for a state transition, but > AFAIK not in the netdev part any more. Then there is interrupt handling which > signals tx/rx start/end points to the upper layer. Of course you can't > implement anything once it's not available on the device. The great thing > about netdev is that it's pretty generic and you don't *need* to implement > every function/message/interrupt/state change/whatsoever to get the device > running. > > But looking at the data sheet I stumbled upon the RFSTATE register which > signals the following (useful) sates: > > 111 = RTSEL2 > 110 = RTSEL1 > 101 = RX > 100 = TX > 011 = CALVCO > 010 = SLEEP > 001 = CALFIL > 000 = RESET > > In addition there is the INTSTAT register which seems somehow similar to the > Atmel radio. Where exactly did you stuck? Could you be a more precise? > as the linux maintainer of 802.15.4 and I worked with at86rf2xx and mrf24j40 transceiver I think I know what Neo means. The main difference between both transceiver is that: - at86rf2xx has ONE framebuffer for transmit and receive - mrf24j40 has two (also even more for GTS, etc) framebuffers one for transmit and one for receive. The main "performance?" advantage is that the mrf24j40 can _fill_ the tx framebuffer while it's _actual_ receiving a frame. That doesn't mean that it can transmit and receive at the same time. It's about filling framebuffer over SPI connection. For me it's important to know what does the state parameter exactly means. Does a TX state means including "filling tx framebuffer" or excluding "filling tx framebuffer". :-/ In at86rf2xx I think it would be including, because you acutally stop receiving of frames to going into TX state. This would be end in some different meaning depends on transceiver what acutally the TX state means. - Alex ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Netdev2 State changes
Hi Neo, there might be code snippets that actively wait for a state transition, but AFAIK not in the netdev part any more. Then there is interrupt handling which signals tx/rx start/end points to the upper layer. Of course you can't implement anything once it's not available on the device. The great thing about netdev is that it's pretty generic and you don't *need* to implement every function/message/interrupt/state change/whatsoever to get the device running. But looking at the data sheet I stumbled upon the RFSTATE register which signals the following (useful) sates: 111 = RTSEL2 110 = RTSEL1 101 = RX 100 = TX 011 = CALVCO 010 = SLEEP 001 = CALFIL 000 = RESET In addition there is the INTSTAT register which seems somehow similar to the Atmel radio. Where exactly did you stuck? Could you be a more precise? Best Peter Am 11.09.2016 um 17:38 schrieb Neo: Dear radio module driver developers, as far as I have seen, the netdev2 architecture reads several time the state of the radio chip to synchronize with the hardware dependent part of the driver (state changes). This is wonderful if the radio chip has a register which shows the actual state of the radio-modul - like the TRX_STATUS register inside of the Atmel chips. What could be done, if the radio chip doesn't have such a register or shows only rudiment state informations to synchronize/trigger the netdev2 part of the driver. The MRF24J40 from Microchip for example shows only the following useful state information: RX SLEEP RESET Transmission is done in the RX state without any changes, just trigger the transission (TXNCON-Reg./TXNTRIG-Bit). Thanks a lot! Regards, Neo ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Netdev2 State changes
Dear radio module driver developers, as far as I have seen, the netdev2 architecture reads several time the state of the radio chip to synchronize with the hardware dependent part of the driver (state changes). This is wonderful if the radio chip has a register which shows the actual state of the radio-modul - like the TRX_STATUS register inside of the Atmel chips. What could be done, if the radio chip doesn't have such a register or shows only rudiment state informations to synchronize/trigger the netdev2 part of the driver. The MRF24J40 from Microchip for example shows only the following useful state information: RX SLEEP RESET Transmission is done in the RX state without any changes, just trigger the transission (TXNCON-Reg./TXNTRIG-Bit). Thanks a lot! Regards, Neo ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
