[riot-devel] Netdev2 State changes

Peter Kietzmann peter.kietzmann at haw-hamburg.de
Tue Sep 13 22:51:55 CEST 2016


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


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:


Where do you see the room for improvement in this thing?


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
>>> 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 at riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at 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

More information about the devel mailing list