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
