Meeting 2024-09-17

[adamgreig]

This is the agenda for the next meeting. Please add anything you'd like to discuss below!

• Meetings: Tuesday 8pm Europe/Berlin time
• Join the Matrix chat
• Nominated issues
• IRC/Matrix logs

Announcements

• None yet

[romancardenas]

I want to share with all of you the new macros for RISC-V interrupts and exceptions I am proposing as part of this PR.

The idea is to have macros that expect the path to a valid interrupt/exception variant. For example, you would do something like this:

// let us assume our target is an E310x chip (PAC crate is e310x)

// import the enums that define interrupts and exceptions in our chip
use e310x::interrupt::{CoreInterrupt, ExternalInterrupt, Exception} 

#[riscv_rt::core_interrupt(CoreInterrupt::MachineTimer)]
fn my_core_interrupt_handler() {
    ...
}

#[riscv_rt::external_interrupt(ExternalInterrupt::GPIO1)]
fn my_external_interrupt_handler() {
    ...
}

#[riscv_rt::exception(Exception::MachineEnvCall)]
fn my_exception_handler(trap: &riscv_rt:: TrapFrame) {
    ...
}

The macro not only checks that the function signature is valid. It also checks at compile time that the provided variant is an interrupt or an exception. For example, the first macro would expand to:

const _: fn() = || {
    fn assert_impl<T: riscv_rt::CoreInterruptNumber>(_arg: T) {}

    assert_impl(CoreInterrupt::MachineTimer);
};
#[export_name = "MachineTimer"]
fn my_core_interrupt_handler() {
    ...
}

I would like to know what you think about this approach. Maybe we can use it in cortex-m-rt too.

[hdoordt]

Announcement: next book sprint for the Discovery MB2 book will be on October 26, 17:00-21:00 CEST, 15:00-19:00 UTC, 8:00AM-12:00PM PST. Join if you're interested in helping to write the new discovery book!

[jannic]

Weekly tickets collection:

• Add @rmsyn to RISC-V team #795 could be merged
• Prepare for cortex-m-rt 0.7.5 cortex-m#533 looks stalled. What's left to do?
• Linker section alignment isn't suitable for MPU cortex-m#524 could be closed I guess