While implementing the at86rfr2 transceiver for the jiminy board I thought of also implement the hwrng.
What I did is implementing in cpu/atmega256rfr2/periph/hwnrg.c
Added feature and module to makefiles.
Now I have some questions:
when the RNG component of the at86rf2xx driver was provided in  we decided to not implement the
periph/hwnrg with it.
Main reasons are that it is
- Not a
periph (i.e. a CPU feature)
- Hard to integrate when e.g. the CPU already provides a
Hope this helps,
But as the atmegarfr2 is a soc this is the hwrng for this device.
So what would be the best place to put it if not as cpu/periph in this special case?
I would then implement it as CPU feature and remove the depency to the at86rf2xx driver.
Still the remaining question is it made sure that random32 calls or any calls to random are directed to hwrng_read
Is this already done by just enabling the module when building with FEATURES_REQUIRED = periph_hwrng ?
IMO: cpu/periph is right if its part of the SOC (as you already said, there should be no dependency to the at86rf2xx driver -if possible- ).
Regarding your other question: I think the answer is no, at the moment its not guaranteed that calls to random32 are directed to hwrng, see .
random should IMHO also stay strictly an API for pseudo random number generators, I agree however with Michel’s issue, that hwnrg should be used for seed generation if available.