Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TRNG driver #1499

Open
MabezDev opened this issue Apr 22, 2024 · 1 comment
Open

TRNG driver #1499

MabezDev opened this issue Apr 22, 2024 · 1 comment

Comments

@MabezDev
Copy link
Member

Copying from #1296 (comment)

Possible solutions:

  1. have two separate constructors for RNG (normal) and TRNG (will also take ADC peripheral so user won't be able to use them together)
  2. Just provide a revert_trng for user, which is not a good solution from the point of "user-friendliness" (and many other points I guess)
  3. somehow ensure that revert_trng was called where and when needed after TRNG initialization (is it possible?)

First one sounds a bit "hacky", third one sounds impossible/difficult.

IDF seems to be using the second approach, which means that random_disable function is being provided to user "on his own risk" : https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/random.html

I like the IDF way in this case: We'll make "RNG" be "TRNG" by default, then provide function (revert_trng) to revert the "True" part and make it be just RNG again. However, it's not the most user-friendly approach, I'll think a bit more about other options.

On the other hand, having an explicit interface AND constructor for the TRNG is better then giving the "unsafe sword" to the user.

Feel free to post your thoughts here

@playfulFence
Copy link
Contributor

Most of the progress is already done in my branch, I'll do a PR as soon as I can.
https://github.com/playfulFence/esp-hal/tree/feature/trng_revert

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

3 participants