RISCV vectored interrupts #118
Conversation
- Adds support for vectoring peripheral interrupts to PAC handlers - Currently supports level interrupts with priorities from 1-15 - Updated the gpio interrupt example to reflect the new changes
This is as simple as making sure we clear the CPU interrupt whenever we receive one. This also documents further what APIs are safe to call when the `vectored` feature is enabled.
MabezDev
force-pushed
the
feature/riscv-vectored-interrupts
branch
from
8c56b6b
to
7c1dfe5
Compare
MabezDev
force-pushed
the
feature/riscv-vectored-interrupts
branch
from
7c1dfe5
to
8375677
Compare
|
I got esp-wifi (BTLE and WIFI) working on top of commit 8375677 but not on the latest commit 🤔 However I still don't get what causes the WIFI example to fail with the last commit |
Ouch, is this in debug or release? I think I might make an enhancement issue to try profile the vectoring code (I haven't put any effort into this apart from sprinkling
That's quite odd, Haven't really changed much apart from the handler names! Maybe try a clean build? Perhaps cargo is doing some weird stuff with caching because they are unmangled symbols? |
|
Also even on 8375677 it now fails to connect to my mobile hotspot with |
|
Could you push your branch on esp-wifi? I'll try and track it down on my end too. |
Sure - here it is: https://github.com/esp-rs/esp-wifi/tree/adapt-to-esp32c3-interrupt-changes/src |
* RISCV interrupt vectoring - Adds support for vectoring peripheral interrupts to PAC handlers - Currently supports level interrupts with priorities from 1-15 - Updated the gpio interrupt example to reflect the new changes * remove .vscode files * Support vectored edge interrupts This is as simple as making sure we clear the CPU interrupt whenever we receive one. This also documents further what APIs are safe to call when the `vectored` feature is enabled. * fix all examples to use vectoring * doc & cleanup * run handlers from ram * make xtensa::interrupt::vectored private, we rexport public items * fix default handlers * pass interrupt into EspDefaultHandler
Specifically for the esp32c3 interrupt controller/matrix right now - we'll need to modify this later on for sure.
This PR reserves interrupts 1 through 15 for interrupt vectoring. One interrupt per possible priority. I've tried to document where possible which APIs are safe to use with vectoring and which are not. Most that APIs which can break vectoring have been made unsafe to match what we did with Xtensa interrupt vectoring.