Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USART interrupt names #290

Open
pdgilbert opened this issue Oct 10, 2021 · 2 comments
Open

USART interrupt names #290

pdgilbert opened this issue Oct 10, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@pdgilbert
Copy link

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 rtic-rs/rtic#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 Sh3Rm4n added the enhancement New feature or request label Oct 26, 2021
@Sh3Rm4n
Copy link
Member

Sh3Rm4n commented Oct 26, 2021

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:

stm32f3xx-hal/src/serial.rs

Lines 1382 to 1385 in c99fd56

usart!([
(1, 2, Interrupt::USART1_EXTI25),
(2, 1, Interrupt::USART2_EXTI26),
(3, 1, Interrupt::USART3_EXTI28)

and here:

pub(crate) const TIM2: Interrupt = Interrupt::TIM2;

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

@pdgilbert
Copy link
Author

(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 (rtic-rs/rtic#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants