[riot-devel] Netdev2 State changes

Alexander Aring aar at pengutronix.de
Tue Sep 13 17:37:59 CEST 2016


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

More information about the devel mailing list