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).
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:
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:
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.
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.
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
> (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:
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.
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.
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.
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.
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.
okay, but why does this setting reach the driver layer, or does it not?
The driver(or in case of at86rf2xx the hardware) should check if the
acknowledgement-request bit is set or not and this _per_ _frame_ and
prepare transceiver to do ARET handling if it's set (maybe inside the
transmit callback of driver layer).
Or will the NETOPT_ACK_REQ option called each time before transmit to
signal the fc acknowledgement-request bit? This confuse me then with the
at86rf2xx hardware which will do ARET handling or not at hardware side
by checking fc acknowledgement-request bit setting in fc.
Such setting should only reach the mac layer, which controls then the
frame control field generation of 802.15.4 dataframes, in my opinion.
The transceiver should has some per frame decision if doing ARET or not
ARET handling before transmit, or do nothing e.g. at86rf2xx because the
hardware does that check.
(sniffer) I think our handling in Linux is to let ARET enabled but
disable AACK handling. AACK handling without address filtering will
occur that you ack mostly every frame which will arrived.
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 bit automatically for each frame it sends.
