Handling of more than 15 EXTI lines

[patrickschneider9]

Hi there,

I just wondered if any of you would have an idea about my current problem, or faced similar challenges:

For a new project I would need about 20 configurable EXTI lines, which exceeds the number of any STM32 MCU as far as we know. How could we still achieve that with additional hardware circuitry or any "tricks" on the MCU? I thought about having DMA configured to read GPIO registers to a memory buffer, but don't know if that will really work.

Any ideas are appreciated!

[waclawek.jan · Accepted solution]

Which STM32?

Have a look at TIM input capture.

>  I thought about having DMA configured to read GPIO registers

How is that equivalent to EXTI?

JW​

[AScha.3]

16 exti int are possible;

[S.Ma]

Which STM32? Wakup/Tamper, Timer input capture, adc watchdog can detect edge, if low power scheme is not involved. Otherwise LPTIM. Otherwise, externally, open drain enable and wired combination to trigger one interrupt, in case this is doable. Are all the inputs are active at the same time, or timeultiplex is possible?

[patrickschneider9]

Hi,

thanks for the quick reply.

> Which STM32?

We are still in the process of choosing the right controller to fit all requirements for the project, so pretty open to all derivates.

So TIM input capture basically means we can trigger interrupts on both edges, just like EXTI, is that correct? That would be exactly what we need.

[patrickschneider9]

Analog Watchdog sounds also promising, we have Frequency Capture on all pins - and as I read in the datasheet Analog Watchdog can be enabled for all channels, but that means that all channels are routed through one interrupt right? How do you know which channel caused the interrupt, and can more than one cause the ISR during the same scan?

You would then need an extra timer to calculate the frequency.

I just wonder if that would cause too much software overhead inside the interrupts.

[S.Ma]

Analog watchdog comparator is based on adc converted values which are in a dmanram buffer, so you can read all scanned pins voltages. If you keep track of previous trigger, you should be able to deduct which ones changes. Said that, have a look at the voltage comparators, they should be even easier analog animals to use for your needs.

[MM..1]

Primary how latency you need? With some latency you can use pool timer int on all pins...

[Tesla DeLorean]

>>I just wonder if that would cause too much software overhead inside the interrupts.

No frequencies or interrelationship of pins has been disclosed.

Each TIM has a single counting element, but paired channels can provide period/duty type counts. Most TIM being 16-bit can be significantly unhelpful.

If there is a lot of high speed and concurrent operation, perhaps an FPGA holding a CM0, or other core, might be a better a path. A unified solutions could have as many counting and interrupting instances as would fit the available gate count.

General Purpose MCU get to be less ideal in specialized/niche applications.

[AScha.3]

if needed speed is not very high, i would use a port expander, ie:

• 3 of them make 24 lines with an active-low INT Output Alerts Change on Inputs