You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
Configure a clock for the EIC (external interrupt controller)
Enable the EIC interrupt vector in the NVIC
Enable the EIC peripheral
Setup trigger and enable interrupts for the correct ExtIntX pin
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.
The text was updated successfully, but these errors were encountered:
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… 😭
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:
If we group these per unit we get:
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.
The text was updated successfully, but these errors were encountered: