[riot-devel] Netdev2 State changes

Peter Kietzmann peter.kietzmann at haw-hamburg.de
Tue Sep 13 23:31:02 CEST 2016


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