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

More constfn! #137

Open
hargoniX opened this issue Sep 23, 2020 · 0 comments
Open

More constfn! #137

hargoniX opened this issue Sep 23, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@hargoniX
Copy link
Member

It has finally happened! As per rust-lang/rust#72437 the following things are now allowed in const functions:

  • if, if let, and match
  • while, while let, and loop
  • the && and || operators

This should allows us to basically move all of our clock calculation optionally to compile time since for most of the peripherals we provide it's very unlikely someone will want to dynamically change the clock speed at runtime, if they instead opt in to const-fn calculation of their clock speeds we can:

  • reduce initialization time since we don't have to calculate the config while starting up anymore
  • reduce binary size since the code wanders from runtime to compile time

I'm not quite sure whether this is doable as a const fn without breaking the current API though? I'd imagine we would need to add an additional parameter clock_configuration that gets passed the result of such a config calculator function? For example an I2C init might end up looking like:

dp.I2C1.i2c((scl, sda), i2c_configuration(100.khz()), ccdr.peripheral.I2C1, &ccdr.clocks);

Because otherwise the constant functions aren't called in a constant context so the rust compiler would treat them just like normal functions, or am I mistaken about that? If the compiler was feeling really clever it could of course allow us to call the const fn inside the i2c function, see that the parameter is a constant and evaluate the const fn at compile time, but I dont think it can perform such magic? Again not quite sure, this definitely requires some further investigation but definitely provides some big benefits for the HAL once adopted.

@hargoniX hargoniX added the enhancement New feature or request label Sep 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant