Björn Quentin

> Is is possible that one of the critical code path is not in IRAM for the ESP32-S3? I pretty much discovered the same thing, interrupt (and thus embassy) is...

I decided to look at this more in general and less in the direction of `esp-wifi` again. My test setup is as this: have an GPIO interrupt trigger at falling...

So, I looked a bit into the DROM access. One easy thing is `CPU_INTERRUPT_LEVELS` - the `const array` is placed in DROM and seems nothing can be done about it...

Here is the code for what I used to benchmark: https://gist.github.com/bjoernQ/4bc8236b926803e6aa22960880af70cd it's good to use a logic-analyzer which supports a reasonable high sample rate (I used DSLogic Pro at 400MHz)

For not emitting jump-tables there is `"-Z", "no-jump-tables",` - RFC: https://doc.rust-lang.org/beta/unstable-book/compiler-flags/no-jump-tables.html Currently it seems there is no support for doing that on a function level: https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/middle/codegen_fn_attrs.rs

Had another look at this. "Replace consts with static's if they're referenced in interrupt handling code" doesn't have a huge impact but increases the RAM usage - we probably don't...

I will definitely get back to this once we have a sane way to do fine grained configuration by the user (i.e. not hundreds of Cargo features 😄)

Such functionality wouldn't be too hard to do via the linker script. It's just that we currently try to avoid introducing new features but want that build-time config system

Going to close this in favor of #1747

> ... rewriting the whole driver ... Yes - this driver is known to be the ugly duckling