Re: [riot-devel] Netdev2 State changes

2016-09-22 Thread Peter Kietzmann
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

Re: [riot-devel] Netdev2 State changes

2016-09-14 Thread 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: > > htt

Re: [riot-devel] Netdev2 State changes

2016-09-13 Thread Peter Kietzmann
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

Re: [riot-devel] Netdev2 State changes

2016-09-13 Thread Alexander Aring
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 i

Re: [riot-devel] Netdev2 State changes

2016-09-13 Thread Peter Kietzmann
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 > (TXN

Re: [riot-devel] Netdev2 State changes

2016-09-13 Thread 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.

Re: [riot-devel] Netdev2 State changes

2016-09-13 Thread 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

Re: [riot-devel] Netdev2 State changes

2016-09-13 Thread Alexander Aring
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

Re: [riot-devel] Netdev2 State changes

2016-09-13 Thread 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. Th

[riot-devel] Netdev2 State changes

2016-09-11 Thread 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