Interrupt map

[davidkern]

Draft attempt at an interrupt map, with a few issues.
Interrupt map with issues sorted.

[MabezDev]

Thanks for submitting this! Just a nits to sort out. Will happily merge after.

[MabezDev]

In cortex-m land, they put the processor interrupts (or exceptions as they called them) in side the runtime crate: https://github.com/rust-embedded/cortex-m-rt/blob/b265e3ec1fbdde531cdbefff82fcc6e9fec16166/src/lib.rs#L698, I think so that it was generic across vendors, maybe we should implement those inside xtensa-rt?

[MabezDev]

In the IDF source?

[MabezDev]

TIMER1 & TIMER2 are the xtensa built in peripherals right? So probably xtensa crate (currently empty in esp-rs)

[igrr]

No, they aren't. These are two timers outside of the CPU (i.e., peripherals).

[MabezDev]

This whole project is WIP 😂 , may as well remove this As I'm sure we'll make changes in the future

[MabezDev]

s/Invalied /Invalid

[jessebraham]

s/calibartion/calibration

[davidkern]

I've grouped the CPU exceptions and the two CPU timers (TIMER0/TIMER1) under an XTENSA peripheral - perhaps these will be removed entirely when xtensa-rt crate is ready.

Also corrected the typos and adjusted comments.

Fixes #12

[MabezDev]

I've grouped the CPU exceptions and the two CPU timers (TIMER0/TIMER1) under an XTENSA peripheral - perhaps these will be removed entirely when xtensa-rt crate is ready.

Sounds like a good idea for now.

Thanks again for taking the time on this!

(and thanks for the sponsor :))

[igrr]

Sorry, have not reviewed when this PR was submitted. One correction: none of the interrupts listed in the table are from the Xtensa CPU, all are peripheral interrupts.

Each interrupt signal listed here goes into the interrupt matrix, which allows mapping interrupt signals to the external interrupt inputs of the Xtensa CPU. I.e. every CPU interrupt of type "external" in this table can receive one or more peripheral interrupt signals. This connection is done using the interrupt matrix peripheral.

[davidkern]

@igrr thanks for that clarification. Would it be better to use the original strategy of taking the prefix of the interrupt name as the name of the originating peripheral? As an example, ETS_UART0_INTR_SOURCE clearly maps to the UART0 peripheral and most others follow the same pattern. Therefore we could presume the names of peripherals for which we lack documentation, like BT_BB and MMU.

If just keeping the same prefixes as the ETS_* definitions is the correct way forward, then it would be straightforward to do this with a regex in idf2svd against those names, along with a patch for a few renames such as TG0 -> TIMG0.

[igrr]

Yes, I think aside from a few inconsistencies between interrupt signal names and peripheral register names, this should work.

Notable exceptions:

• FROM_CPU_INTRx — these are 4 software interrupts, implemented outside of the CPU. The registers which allow setting/clearing these interrupts are in DPORT_. Not sure which peripheral they should be mapped to, possibly DPORT.
• TIMER1_INTR, TIMER2_INTR — these are the interrupts of "FRC timer", or "legacy timer" peripheral inherited from the ESP8266. As mentioned in Fix detection of some registers MabezDev/idf2svd#6 (comment), i would suggest skipping these older timer peripherals and using Timer Group peripherals instead.
• MMU, MPU, CACHE — most of the related registers are in DPORT_, however it may be reasonable to split these registers into a separate "peripheral" from Rust perspective. Note that most of the respective registers (at least the useful ones) should be documented in the TRM.

Also one other observation about the changes in this PR. It seems that unlike other repeating peripherals, I2S interrupts didn't get split into two peripheral instances (there is I2C0, I2C1, but only one I2S with 2 interrupts inside).