at86rf2xx: do not try to send when device is busy

[miri64]

Contribution description

Otherwise, a race condition might be triggered where data that was just
received (which is the reason the device might be busy) is overridden
by the sent data (see #11256).

Testing procedure

Run the tests in #11256 together with #11263 [the test doesn't include gnrc_netif so merging #11263 would be pointless] (I did not do this myself yet, this is why I marked it as WIP).

Issues/PRs references

This prevents the race condition show-cased in #11256.
Together with #11263 the sent packets are tried to be sent later instead of just being dropped.

Depends on #11263

Basis for #11068

[miri64]

Rebased and added #11263 as a dependency when gnrc_netif is also included.

[miri64]

Rebased to current master and dependencies.

[miri64]

Maybe this will be fixed less hacky with #12069. Until this is confirmed, I keep this open.

[miri64]

Rebased to current #11263

[miri64]

Rebased to current master and dependencies

[miri64]

Rebased to current master and dependencies to resolve #11263's conflict with #13065.

[benpicco]

Can this be closed now that #12728 is merged?

[miri64]

If #11068 is able to perform without this PR, yes. Let me check this in the coming days.

[fjmolinas]

If #11068 is able to perform without this PR, yes. Let me check this in the coming days.

ping :)

[miri64]

Sorry, still did not find the time to test this :(. Will see if I manage today.

[miri64]

I tested with #11068 rebased to master and without gnrc_netif_pktq and also tested as it is now. I used ping6 -s 120 -i 750 -c 4800 beef::1 over static routes with a single hop.

Rebased to master:

2020-04-14 12:02:40,266 # --- beef::1 PING statistics ---
2020-04-14 12:02:40,272 # 4800 packets transmitted, 423 packets received, 91% packet loss
2020-04-14 12:02:40,276 # round-trip min/avg/max = 84.702/111.848/142.180 ms

In the current version:

2020-04-14 13:10:52,562 # --- beef::1 PING statistics ---
2020-04-14 13:10:52,567 # 4800 packets transmitted, 1265 packets received, 73% packet loss
2020-04-14 13:10:52,572 # round-trip min/avg/max = 75.163/111.254/153.087 ms

So yes, in some form or another, this PR is still needed. However, as I said multiple times before: this should be made configurable and based on a MAC protocol on top. As it is now it basically just requires a minimal MAC queue on top, which might not work for all devices.

[miri64]

Rebased to current master, mainly to reflect the current state. We should discuss in #14954 how to proceed with this in netdev. I will adapt this PR then accordingly.

[jia200x]

I think there's still a case of race condition: If the user calls the send function while receiving and at the same moment RX_BUSY goes to RX, the send function will pass through and we will see the same issue :/

I think the proper way to do it would be to either save the IRQ request somewhere or use features like the Frame Buffer Empty Indicator (section 11.7 of datasheet) or the SPI_CMD_MODE to read the IRQ_STATUS register (section 6.3.1)

[miri64]

IMHO with the radio HAL now merged, it doesn't make much sense to keep this PR. Shout if you disagree.