[riot-devel] at86rf2xx radio driver -- potential severe performance issues for multi-hop communication

Alexander Aring alex.aring at gmail.com
Thu Oct 15 14:48:06 CEST 2015


Hi,

On Thu, Oct 15, 2015 at 02:38:29PM +0200, Andreas Weigel wrote:
> Hi again,
> 
> indeed this should solve the issue -- I have to admit, that I hadn't
> considered this possibility for our driver, because I adapted the TinyOS MAC
> layer (using the basic operating mode) and had everything there already,
> including a handling of the ACKs in software, which works reasonably well.
> 

Sorry, this sounds awful. Ack handling in software is a mess because you
have very timing ciritcal things there. That's why at86rf2xx supports
the RX_AACK states which do AACK handling -> ACK handling on the
transceiver side.

> You will obviously still have to implement the CSMA-CA mechanism then if you
> need it. Is there already usable (for the at86rf2xx) code available for a
> CSMA-CA in Riot? Then probably combining it with the existing driver (with
> deactivated CSMA-CA) would be a good solution.
> 

CSMA-CA handling is the same like above, in my opinion you can not do
this in software. Okay you working in a little mcu world and yes you
maybe can do this by calculate all factors, spi-bus speed, max interrupt
latency, etc. inside the mcu world. If you don't do that and see if it's
fit, then don't do that.

CSMA-CA handling is also done by on transceiver side (no software mac
implementation required) in TX_ARET mode (except you disable it by
change csma retries to 7).

I need to admit, I don't know how RIOT handle timing critical 802.15.4
mac things. On linux, we don't support it in the MAC implementation and
we never will do that, because we can't.

- Alex


More information about the devel mailing list