USART interrupt names

[pdgilbert]

The USART interrupts in stm23f3xx_hal have unusual names. For example, USART1_EXTI25 is used in place of USART1 used in most other hals. I am trying to construct examples that build with many different hals and this is causing trouble in rtic examples, see https://github.com/rtic-rs/cortex-m-rtic/issues/540. I expect there is a good reason for the choice of name but I am wondering if it is possible to give also an alternate name that corresponds with the convention used by other hals?

[Sh3Rm4n]

First of all, USART1_EXTI25 and others are names originate from the pac generated by svd2rust on bases of the .svd files STM provides.

But there are ways to make the names nicer, though these would hide the fact, that one interrupt flag corresponds to multiple interrupt sources: EXTI25 and USART1 in this example.

Partially, the naming problem is already tackled by the InterruptNumber trait, which has some implementors.

The mapping / implementations for these traits are mainly done with macros, like here:

https://github.com/stm32-rs/stm32f3xx-hal/blob/c99fd56062af13a3cb33bed2c1faca2b80363379/src/serial.rs#L1382-L1385

and here:

https://github.com/stm32-rs/stm32f3xx-hal/blob/c99fd56062af13a3cb33bed2c1faca2b80363379/src/timer/interrupts.rs#L20

But it does need some time to implement, because of naming conventions and inconsistencies between device sub-families and other issues.

[pdgilbert]

(I apologize if I am asking things that should be obvious. I'm new to many aspects of Rust and embedded programming.)

I'm curious to understand what can reasonably be expected from the hardware abstraction in the hals and if there is a way hals can provide a common API for this.

When the interrupt is shared by EXTI25 and USART1 is it possible an application could use that one interrupt for two different purposes? I think there can only be one handler, but is there any way the handler can distinguish EXTI25 from USART1? Or does the interrupt need to be used either for EXTI25 or for USART1?

When you say

Partially, the naming problem is already tackled by the InterruptNumber trait, which has some implementors.

does that mean the InterruptNumber's are an abstraction on top of the interrupt names? ( I was thinking of the numbers as being closer to the hardware.) Are those numbers expected to be the same across different hals? If so, pointers to examples of how those can be used in place of names would be much appreciated.

My specific problem (https://github.com/rtic-rs/cortex-m-rtic/issues/540) might be solved within rtic by improved #[cfg] expansion support and proc-macros, but I think that would just give application programmers the ability to program around hardware differences, not give them a common API.