driver/at86rf215: add functions to configure trim & clock output at run-time

[benpicco]

Contribution description

To calibrate the at86rf215 radio, trim value has to be set at run-time during board production.
Add two helper functions to control the trim value and clock output register.

This also adds a gnrc_netif_get_netdev() netdev function to get a pointer to a previously registered netdev from netif.

Testing procedure

tests/driver_at86rf215 has gained three new functions:

• set_trim set the trim value
• set_clko enable clock output
• get_random get numbers from the radio's random number generator (previously untested)

If you connect a frequency counter to the clock output pin, you should be able to measure the set frequency and see it change when adjusting the trim value.

Issues/PRs references

[benpicco]

rebased to solve the merge conflict

[maribu]

And again, I forget to submit a review. Let's see if the comments are still valid

[maribu]

Some comments for the test

[maribu]

@benpicco: Code looks good to me. I cannot test this with my hardware, as

1. I cannot access the clock output due to missing testing point (will be fixed by next revision)
2. I'm using a TCXO instead of a crystal as clock source, but trimming only makes sense for crystals.

Maybe you could give the test another spin after squashing and document your result here?

[benpicco]

2020-12-02 12:44:51,311 #  set_clko 26
2020-12-02 12:44:51,314 # Clock output set to 26 MHz

2020-12-02 12:46:09,985 #  set_trim 15
2020-12-02 12:46:09,986 # setting trim to 4500 fF

2020-12-02 12:46:38,560 # set_clko 32
2020-12-02 12:46:38,563 # Clock output set to 32 MHz

2020-12-02 12:47:16,320 #  set_clko 8
2020-12-02 12:47:16,322 # Clock output set to 8 MHz

[maribu]

ACK. @jia200x, any objections to merging?

[maribu]

my ACK remains valid

[jia200x]

I'm fine with it!

My only comment is that I think we should resolve in the mid term how to access device specific stuff + how to represent a device within the OS. Accessing the device descriptor directly when there are network interfaces on top seems to be sensible, since changing any internal state might affect what the network interface/stack expects from the radio.

IMO this should be done through a generic netif_t (not gnrc_netif_t). But this is completely independent of this PR :)