GPIO: Refactor AnyPin to contain a u8
#2854
Conversation
bugadani
force-pushed
the
gpio-opt
branch
2 times, most recently
from
009ddbb to
5e80ef0
Compare
bugadani
changed the title
Flex::set_levelu8
| @@ -3231,7 +3231,7 @@ impl Driver { | |||
| // wait | |||
| } | |||
| } else if #[cfg(esp32)] { | |||
| xtensa_lx::timer::delay(1); | |||
| xtensa_lx::timer::delay(2); // ☠️ | |||
There was a problem hiding this comment.
any idea why we need this now?
|
I can reproduce the 1.60 MHz for the erased case 🚀 |
The slight problem with that is, that we're not actually testing the performance of the erased GPIO, but the compilers ability to const-propagate the pin number. We need a better benchmark going forward |
We are relying a lot on the toolchains' optimization and here we try to please the compiler to produce better optimizations - maybe it would be good to have benchmarks in CI to avoid regressions in future (as good as it gets since optimizations are hard to predict - we already tried something like that for direct-vectored interrupts in hil-tests but suffered from flakiness) But I don't see a situation where this might make things worse |
It seems like the compiler is WAY better at propagating a single
u8than an enum of different types. My silly little benchmark is now completely const-propagated and toggles at 1.6MHz.As a neat bonus, we can now provide
AnyPin::steal