[riot-devel] at86rf2xx radio driver -- potential severe performance issues for multi-hop communication
alex.aring at gmail.com
Thu Oct 15 14:48:06 CEST 2015
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
> 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.
More information about the devel