nrf52840: implement Radio HAL

[jia200x]

Contribution description

Following #14791 , this PR implements the Radio HAL API for nrf52840. As documented in #14792, this PR also expands the ieee802154_hal test to make it compatible with this radio.

Testing procedure

Please follow the test procedure described in #14791.

Issues/PRs references

#14792
#13943

[jia200x]

rebased to current master

[jia200x]

I think I addressed all comments

[benpicco]

Looking good.
Travis spotted a white space issue and the case should not be indented as per Linux coding style mandated by coding conventions (and IMHO less deep indentations are more readable anyway)

If @bergzand doesn't have any objections, let's move forward with this as well!

[jia200x]

everything was addressed in 8358bb6

[benpicco]

Looking good!
Only some style nits, including those from Travis.

[benpicco]

Murdock is not happy.

[jia200x]

since #14997 is imminent, I implemented the off function here :)

[jia200x]

I think I addressed all comments, plus some stuff found by Vera++.
I added the IFS definitions to common ieee802154.h header

[benpicco]

Murdock is still unhappy.

[benpicco]

Should this generate a notification to the submac that the next frame can now be transmitted?

[jia200x]

Hmmm this is the only radio that doesn't handle IFS (I think it's quite rare...).
All the other radios might report "BUSY" when trying to send within the IFS. This is what we have here.

So maybe I would keep it as it is, otherwise we would need to implement a generic IFS handler for only one radio

[benpicco]

Do I get it right that the IFS period starts after the TX done event?
Or do you say other radios will only report TX done after the IFS period is over?

(I'm almost certain at86rf215 won't do any internal calculations w.r.t. timings as I already had do the calculations for all the other timings manually. They'll probably differ between modulations too.)

[benpicco]

No delay between the end of RF signal and TXFE on at86rf215

[jia200x]

Do I get it right that the IFS period starts after the TX done event?
Or do you say other radios will only report TX done after the IFS period is over?

I'm not sure when this event is generated, but I'm sure most radios already handle the IFS (maybe @PeterKietzmann can confirm this). The actually, the nrf802154 supports hardware IFS but it's disabled in order to use the fast mode (this means, switching between TRX_OFF to TX_ON in 40 us). I think the trade off is totally worth it for this radio.

They'll probably differ between modulations too.

Yes, it depends on the modulation (it's expressed in symbol times).

[benpicco]

We could just introduce another radio capability for this

[benpicco]

Is 5 channel spacing?

[jia200x]

I don't know, I simply copied this line from the original netdev driver.

[jia200x]

From what I read from the datasheet, yes. It seems to be the channel spacing.

Basically, the center frequency is 2400 + FREQUENCY (in MHz). I will maybe take the opportunity to add a comment here

[benpicco]

Yea 5 MHz channels make sense for O-QPSK.

[benpicco]

If it turns out that most radios will allow to set the frequency directly, there would be even more reason to move the channel calculations to the submac 😉
That would also ease supporting multiple regions in the sub-GHz band (868 MHz vs 902 MHz, etc)

[jia200x]

yes, we can do that. Actually, most O-QPSK radios already have a frequency register (even the at86rf2xx)

[benpicco]

I checked again. On at86rf2xx and at86rf215 you set the base frequency (and channel spacing), then you can write the channel register and the radio will calculate frequency + chan * spacing internally.

[benpicco]

Please squash!

[benpicco]

Looks like auto_init_nrf802154.c still needs an update.