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
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
