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

Interrupts for SAM #435

Closed
henrikssn opened this issue Jul 14, 2020 · 2 comments
Closed

Interrupts for SAM #435

henrikssn opened this issue Jul 14, 2020 · 2 comments

Comments

@henrikssn
Copy link
Contributor

So I started looking into this and got stuck on how to fit the CMSIS model of SAM into the interrupt pattern as it is for stm32/xmega platforms.

It looks like those define a unit as GPIO pin and all methods on those. This works sometimes but not always, for example on stm32 then there is a N->M mapping between pins and interrupt handlers, so that some pins "overwrite" the handler of others.

On SAM, there is a N->1 mapping between pin interrupts and IRQ handlers (yes, there is only one). I think this is a forcing function for a rethink, as otherwise it would not be possible to have more than one interrupt enabled at the same time.

The steps to enable interrupts on SAM are:

  1. Set PMUX for the pin (already implemented in Implement GPIO inputs for SAM #433). This takes the ExtIntX (X in 0..15) pin as template argument.
  2. Configure a clock for the EIC (external interrupt controller)
  3. Enable the EIC interrupt vector in the NVIC
  4. Enable the EIC peripheral
  5. Setup trigger and enable interrupts for the correct ExtIntX pin
  6. Implement the IRQ handler using MODM_ISR(EIC) macro, here you need to implement some sort of switch statement to see which ExtIntX pin triggered the interrupt. You (similarly to stm32) also need to clear the interrupt flag in the ISR.

If we group these per unit we get:

  • "GPIO pin"-level: 1
  • "ExtInt pin"-level: 5, 6
  • Global: 2, 3, 4

From this, it seems that it would be useful to have a global "interrupt controller" and a generated / templated ExtInt class in addition to the GPIO level config. There should be a mapping from each GPIO to its ExtInt and bonus points if this makes it clear to the programmer which pins conflict.

Where I am not so sure is if this would also be useful for stm32 (+other platforms) and how we best can make this platform independent, so that I can write portable code.

@salkinium
Copy link
Member

salkinium commented Jul 14, 2020

I agree, and the STM32 ExtInt implementation is not the right approach, it should be its own peripheral (since it actually is its own peripheral). So don't feel constrained by the existing implementations, you can greenfield this as much as you like.
There isn't a common modm API for interrupts anyways (except perhaps the CMSIS NVIC_* functions and MODM_ISR, but they only cover the CPU/Linker part, not the peripheral part.).

In general, I'd be interested in a more general approach to attach any number of handlers to a hardware event, with the respective interrupt handler, flag checking and dispatching code being auto generated. There are a couple of different approaches to demuxing the mappings: #303, and two experimental PRs: #307 and #308. In short, it's not that easy… 😭

@henrikssn
Copy link
Contributor Author

This is fixed, see examples/samd/interrupt/main.cpp for an example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants