RISCV: remove the direct-vectoring & interrupt-preemption features and enable them by default

[MabezDev]

This is an attempt to try and solve #1246

• Enables the feature by default, removing the cfgs
• Removes old redundant code
• renames the old direct_vectoring enable function enable_direct

TODO

• Can interrupt-preemption also be enabled by default/removed?
• enable_direct a good name? Maybe we just remove this method completely, it's possible to "build" this function using the other methods available
  • I think we want to keep it for now, which we reserve some interrupts for the vectored feature, we still have some CPU interrupts free which users can use directly if they wish.
• Test chips other than esp32c3 & esp32c6
• Test exceptions also work on all chips, they work on esp32c3 at least
• Test it doesn't regress interrupt latency (I would hope that this is a net benefit)
  • main, first trigger: 25us, after that 13us
  • This RP: consistent 10-11us latency
• Test the fix-sp feature still works
• Documentation updates

[MabezDev]

@bjoernQ I know we're not really looking P4 support right now, but do you know if this is going to be viable for the P4?

[bjoernQ]

@bjoernQ I know we're not really looking P4 support right now, but do you know if this is going to be viable for the P4?

Vectored interrupts are definitely supported. t.b.h. I don't recall why I omitted dirtect-vectoring support for P4 initially but shouldn't be a huge problem to implement it

[MabezDev]

I like removing features, so I've made an executive to cut out interrupt-preemption for riscv and enable it by default.

This matches the same behaviour as Xtensa by default, so I think it's a good change all around. You can test the behaviour of both arches with the interrupt preemption example.

[MabezDev]

I ended up doing a couple of changes to Xtensa too, just to being the APIs in line with each other (they're still different and can't be shared, but they have the same capabilities).

Overall I'm quite happy with how this ended up. I just need to test the latency effects and @bjoernQ if you could show me or test yourself the fix-sp feature.

This is now read for review.

[bjoernQ]

I tested this with esp-wifi and after the necessary adjustments it seems to still work on C3, C6 and S3.

To test the fix-sp functionality I just use some code to overflow the stack and the flip-link feature. I can test that

[bjoernQ]

Ok seems fix-sp is broken here.

There is also a problem enabling "flip-link" in build.rs - but that was already broken before this PR. We need a ".to_string()" there.

To reproduce I changed hello_world.rs into

//! This shows how to write text to UART0.
//!
//! You can see the output with `espflash` if you provide the `--monitor`
//! option.

//% CHIPS: esp32 esp32c2 esp32c3 esp32c6 esp32h2 esp32s2 esp32s3
//% FEATURES: embedded-hal-02

#![no_std]
#![no_main]

use core::fmt::Write;

use embedded_hal_02::timer::CountDown;
use esp_backtrace as _;
use esp_hal::{
    clock::ClockControl,
    peripherals::Peripherals,
    prelude::*,
    timer::TimerGroup,
    uart::Uart,
};
use nb::block;
use esp_println::println;

#[entry]
fn main() -> ! {
    let peripherals = Peripherals::take();
    let system = peripherals.SYSTEM.split();
    let clocks = ClockControl::boot_defaults(system.clock_control).freeze();

    let timg0 = TimerGroup::new(peripherals.TIMG0, &clocks);
    let mut timer0 = timg0.timer0;
    timer0.start(1u64.secs());

    let mut uart0 = Uart::new(peripherals.UART0, &clocks);

    boom();

    loop {
        writeln!(uart0, "Hello world!").unwrap();
        block!(timer0.wait()).unwrap();
    }
}

#[inline(never)]
fn boom() {
    deadly_recursion([0u8; 2048]);
}

#[ram]
#[allow(unconditional_recursion)]
fn deadly_recursion(data: [u8; 2048]) {
    static mut COUNTER: u32 = 0;

    println!(
        "Iteration {}, data {:02x?}...",
        unsafe { COUNTER },
        &data[0..10]
    );

    unsafe {
        COUNTER = COUNTER.wrapping_add(1);
    };

    deadly_recursion([0u8; 2048]);
}

And enabled flip-link for esp-hal. Works on main but doesn't here. (i.e. it prints "Stack overflow detected at 0x42004124 called by 0x42003e0a" on main but nothing here)

[MabezDev]

Thanks to @bjoernQ's test configuration, I measured the interrupt latency on main and this PR:

• main, first trigger: 25us, after that 13us
• This PR: consistent 10-11us latency

I'm pleased about that!

[MabezDev]

Thanks for testing fix-sp, I'll look into fixing that tomorrow.

[MabezDev]

Fix-sp/flip-link feature should be working now! I had the code in the wrong place, it should be before we modify the sp :D.

[bjoernQ]

LGTM - nice improvement!

[JurajSadel]

LGTM! Thanks for doing this!

[jessebraham]

Looks like there are some missing imports still

[jessebraham]

LGTM! Thank you once again for tackling this! 😁

[jessebraham]

GHA why are you like this ;_;

[MabezDev]