External interrupts with multiplexed IRQs

LeafLabs Garden » Support » Maple Hardware Support

External interrupts with multiplexed IRQs

(12 posts) (6 voices)

Started 4 years ago by ridgebackred
Latest reply from rogerclark

ridgebackred
Member

I hesitate to call this a bug, but I am seeing repeatable results when staying in the userspace code area...

My setup is a six channel RC receiver with the outputs connected to the MapleMini.

All inputs to the MapleMini are used as external interrupts. Care has been taken not to violate the multiplexed interrupt pin assignment rules.

AFIO_EXTI_0 through AFIO_EXTI_4 work fine.
Inputs AFIO_EXTI_5 and above all seem to drop to a lower interrupt priority. Interrupt servicing for the multiplexed handlers is not consistent.

Ideas?

Posted 4 years ago #
robodude666
Member

There may be two explanations for this:

1) All interrupts are configured for the lowest possible priority. If you adjust the priority of 0 - 4, they will operate at a higher priority level.

2) EXTI 0 through 4 have their own irq line. 5-9 and 10-15 respectively share the same IRQ line and interrupt handlers.

If an interrupt for 5 through 9 is received, it goes through more code to determine which of the five interrupts could have been triggered. This takes more time and creates a delay.

You can view the libmaple/exti.c file yourself to see how the implementation actually works to understand where these delays come from. This implementation is based on STM's design, and not some weird setup LeafLabs decided on.

-robodude666

Posted 4 years ago #

ridgebackred
Member

Thanks robodude666,

This is the code snip. It's repeated for each handler. Unless the micros() function is taking much longer than I realize, I should be in-n-out of the handlers plenty fast enough not to miss any.

void handler_CH1(void) {               // Measure RX Pitch duration
    if(Chan1begin == 0){               // Rising edge interrupt signal
     Chan1begin = micros();
     Chan1prev = RxInPitch;
    }
    else{                              // Falling edge interrupt signal
     Chan1end = micros();
     RxInPitch = Chan1end - Chan1begin;
     if((RxInPitch < 1000) || (RxInPitch > 2000)) //Glitch suppression
     {RxInPitch = Chan1prev; Chan1end = 0;}
     RxInPitchSmooth =(RxInPitchSmooth + RxInPitch) / 2;
     Chan1begin = 0;
    }
}

Posted 4 years ago #

mbolivar
LeafLabs

ridgebackred,

can we see your entire program, or get some more details on what you mean by the following:

Inputs AFIO_EXTI_5 and above all seem to drop to a lower interrupt priority. Interrupt servicing for the multiplexed handlers is not consistent.

Posted 4 years ago #
ridgebackred
Member

mbolivar,

I have 2 MapleMini's flying in my tricopter and quadcopter since the MapleMini's went on sale. Lots of fun! The MapleMini's are great controllers. I had my doubts about using high clock speed controllers in an environment as electrically noisy as RC models. The MapleMini's are holding up very well in a demanding application.

Four RC channels are all that is required for basic flying.
Additional channels are for mode selection and trying out new control schemes in flight.

My "real-time" debug method is limited to blinking the led from different parts of the code, and looking at the led output with an o-scope.

It seems like a AFIO_EXTI_5 handler and higher is being blocked by something.
I have eliminated the RX signal itself as the cause by switching RX channels 4 and 5 of the receiver to the MapleMini inputs. The 'missed/late interrupt' stays with EXTI 5 (and higher) pin(s).

Interrupt capture is rock solid for EXTI 0 through 4.

A functional program is at: http://snipt.net/ridgebackred/mapleminiquad0002apde

A photo about half way down the page of the MapleMini.
http://aeroquad.com/showthread.php?3614-3D-printed-motor-mounts-for-aluminum-airfoil-arms/page3

Posted 4 years ago #
mbolivar
LeafLabs

I have reproduced the issue. IRQs that are shared between several EXTI lines do appear to get dropped on the floor if a non-multiplexed EXTI IRQ is triggered at the same time.

Since I don't have access to your sensors, I've added a new (non-portable and Maple Mini specific, ATM) test of external interrupts which only requires wires:

https://github.com/leaflabs/libmaple/blob/master/examples/mini-exti-test.cpp

See the file header for a way to wire it up.

Bugtracker reference, with expected and actual output:

http://code.google.com/p/leaflabs/issues/detail?id=77

I'll try to sort out what's going on.

Posted 4 years ago #
mbolivar
LeafLabs

OK, I've pushed what should be a fix; see this bugtracker comment for more details:

http://code.google.com/p/leaflabs/issues/detail?id=77#c2

Let me know if it resolves the issue on your tricopter/quadcopter.

The fix went in as part of the following series of commits (now merged into master), which should also bring some other bugfixes and performance improvements to exti.c:

c0750411002ce61a0df96aefd385106c2fc2b509 exti.c: Optimize multiplexed IRQ handlers.
487a60946d89f340982e4435d7ededaea1a09468 exti.c: Cleanups.
aee5bceb0f773826627543199de4332b2e36ba4a exti.c: Remove enable_irq() and maybe_disable_irq().
5a7ad93ab24cac998cc498aadb7e32cc29b836de exti.c: Clean up some bit-banding usages.
f5935ef4778aa081c7a22e1d3bfd0aadc7a213e2 exti.c: Cleanups.

If you notice any other improvements or regressions, we'd love some feedback.

Edit: Here's the compare view on those commits:

https://github.com/leaflabs/libmaple/compare/dab7dd44...c075041

Posted 4 years ago #
ridgebackred
Member

Thanks mbolivar!

The Maple Mini: $34.99

Having LeafLabs expertise brought to bear on an issue: Priceless

Posted 4 years ago #
ridgebackred
Member

mbolivar,

Yes, that update of exti.c fixed the multiplexed EXTI IRQ issue for me!

The pulse duration of all six channels of the RC receiver are now captured correctly using the external interrupt capability of the Maple Mini.

Thanks!

Posted 4 years ago #
anton
Member

Happy to hear. I had the same problem.

Posted 4 years ago #
josemaes
Member

Hi mbolivar,

do I need to recompile the bootloader to apply the patch?

Posted 8 months ago #
rogerclark
Member

It seems unlikely that you need to change the bootloader, as it is unloaded when the sketch runs.

As the last posting to this thread was 3 years ago, I'd suggest you post to http://www.stm32duino.com as its more active than this forum, and uses a derivative of libmaple

Posted 6 months ago #

RSS feed for this topic

Reply

You must log in to post.