EXTI interrupts

[gbip]

Is there any way to setup EXTI interrupts at the moment ?
I need to have an interrupt handler when a rising front occurs on a GPIO pin, how could I do that ?

[TheZoq2]

There is, but I don't remember the exact way to do it. In one of the crates, probably cortex-m, there is a macro to define an interrupt, it takes a function along with this enum https://docs.rs/stm32f1/0.6.0/stm32f1/stm32f103/enum.Interrupt.html that specifies which interrupt to listen for.

Using interrupts without cortex-m-rtfm is a bit annoying because passing ownership of peripherals into interrupt handlers is impossible, but it is useable with some unsafe code

[gbip]

Thank you !
I don't see anything to set up the gpio side of things. Is it not yet implemented ? I might take a look.

[therealprof]

I've used EXTI on STM32 before here: https://github.com/stm32-rs/stm32f0xx-hal/blob/master/examples/led_hal_button_irq.rs

Just no one has made it into something HAL-worthy.

NB: It is possible to pass ownership of peripherals safely but yeah, it's annoying.

[gbip]

I will try to come up with a proposition, otherwise I will just use your code as inspiration, thanks !

[TeXitoi]

I reopen this issue because I think that's an important feature request.

[gbip]

I was thinking about the following API to attach handlers to certain events.

Pros :

• easy to use
• use the type system to enforce safe concurrency

Cons :

• I have no idea how to setup the interrupt handler in a transparent way for the crate user

[TeXitoi]

@gbip you can't do that at zero cost. You'll have to stock the closure somewhere, and you don't know it's size ahead of time.

Better to first provide an interface close to the hardware but safe as a first version.

[therealprof]

We do have a (non-exhaustive) implementation to setup EXTI on pins in stm32f4xx-hal: https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/gpio.rs

[tib888]

I believe this will be the ultimate solution for interrupts and safety is already under development by @japaric: https://github.com/japaric/cortex-m-rtfm

However it would be nice to see an example made for STM32F103 EXTI...

[TeXitoi]

You'll have to do the same thing as in @therealprof example, just that the interrupt handler will be managed by RTFM, with shared resources handled safely.

[therealprof]

@tib888 RTFM is just a different way of handling resources by creatively using interrupt priorities and statically checking that the resources are properly used within the boundaries of the defined rules. It neither addresses the setup of peripherals nor is it applicable in every scenario.

[Windfisch]

I've ported the stm32f4xx-hal way of doing this over to stmf1xx-hal. Not tested yet, however: https://github.com/Windfisch/stm32f1xx-hal/tree/gpio_exti
I'm open to comments and suggestions :)

[Windfisch]

I've fixed and tested my patch, it seems to work for "normal" (i.e., non-erased) pins.

However, I feel like I should add something to macro_rules! impl_pxx's implementation; unfortunately, I do not understand what this macro is used for, and thus what to add there. @TheZoq2 or @therealprof, can you help me there :)? (I'll file a PR once ready)

[TheZoq2]

Sure!

The point of impl_pxx is to implement a generic pin which is independent of the GPIO port. This is implemented using an enum

enum Pxx {
    PAx(PAx),
    PBx(PBx),
    ...
}

Where PAx, PBx and so on are what used to be the semi erased pins. The impl_pxx macro simply defers the execution of all the gpio functions to the corresponding (private) PXx structs.

If you want to add more functions to it, you basically want to add an impl block like this

fn function_to_implement(&self) -> Result<bool, Void> {
    match self {
        $(Pxx::$pin(pin) => pin.function_to_implement()),*
    }
}

Hope that answers the question, for more dicussion about that macro, see #114 and #115

[Windfisch]

thanks @TheZoq2 for the explanation; I've added the ExtiPin trait to the fully erased pins in the branch linked above.
Could you kindly have a look over my PR #125 :)?

[Windfisch]

@TheZoq2 or anyone else can likely close this now #125 is merged

[TheZoq2]

Ah yes, thanks for the reminder!