Interrupts with joystick libs etc

Thanks to this forum, I’m almost finished with a complicated flight-sim button box utilising a Due, three 4067 muxes, nine encoders, three rotary switches…

…but I’m struggling with the interrupt-driven aspects.

All of the encoder actions are associated with interrupts - and using Serial.print, these are clearly working well (as in the physical action is immediately recognised).

However, whereas all my toggle and rotary switches are happily executing joystick (button) outputs over serial, the interrupt-driven actions aren’t working (well) at all…

I understand that when an interrupt is triggered, basically everything else is suspended - but does this mean I can’t use joystick libraries etc. effectively? Testing has already shown that any attempt to use the delay function (e.g. to help debounce) in interrupt functions basically hangs the Arduino…

Am I missing something? Can I execute joystick library button presses from an interrupt function?

TIA as always.

Are you meaning you are using serial.Print() inside an interrupt function?
Serial.Print() in an interrupt function just puts the data into the buffer, it DOES NOT get sent until sometime after the interrupt function returns.

1 Like

That is very unlikely to work correctly.

1 Like

Hello foxflier

To do so is deeply not recommended.

Design and code a very simple button manager including debouncing and processing via member functions.

Have a nice day and enjoy coding in C++.

1 Like

So yes, I have tested my interrupt functions with Serial.prints inside them - purely to check they are triggering. Thanks for the reminder that we are in a form of suspended animation until the interrupt function returns - the more I think about it (and the other responses overnight), the more I can see that my approach has been well-meaning but flawed…

So… As I understood it, interrupts are effective for encoders etc. where you don’t want to miss a pulse - but I see any actions will need to take place after the interrupt call returns…

At best, I can update some global variables inside the interrupt calls and then have to deal with them when the main loop gets around to them….? …which might not be any easier/better than treating all switched inputs the same…

I guess my project doesn’t have a critical timing need though - and debouncing is probably more important to the quality of experience in a flight sim than worrying about whether I’ve missed a pulse or two…

Thanks once again, everyone -

Now you are on the right track! Use interrupts to count the interrupts or to set a Boolean to true showing the interrupt has occurred. For a program to react to an interrupt occurred, do not use delays, but use millis to decide WHEN to do something, not wait after something has been done.

I’ve removed the unnecessary interrupts and used one of the debounce libraries where possible. It all seems to be working fine (box on the left of the photo - 16 two-way momentary toggles multiplied by 4-way mode (rotary) switches, 9 encoders etc. etc.!

Once I’ve tested it more thoroughly in my sims for missed/phantom pulses etc., I’ll revisit the interrupts if necessary.

Thanks for all the help!

2 Likes

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.