You must be logged in to reply.

Page 1 of 2 out of 17 messages.

Multiple Threads Interfering With Interrupts. How to Diagnose and Fix?

Posted 2yr ago
by Gismofx | Senior | 1,322 exp
Posted 2yr ago
by Gismofx | Senior | 1,322 exp
I'm running a few threads on my device per this thread:
https://www.ghielectronics.com/community/forum/topic?id=23551

When I rotate the encoder to drive a menu, It should scroll one menu item at a time. On occasion, the menu will jump several items. Here's a video of the behavior(starting around the 9 second mark you see the jump):

https://www.youtube.com/watch?v=z_Ew_MWtQvY


When I eliminate the sensor threads, this behavior goes away.
How can I diagnose this? Any ideas on what is happening?
Reply #1 — Posted 2yr ago
by Mike | Superhuman | 82,265 exp
Reply #1 — Posted 2yr ago
by Mike | Superhuman | 82,265 exp
@Gismofx - Could it be garbage collection occurring?
Reply #2 — Posted 2yr ago
by mcalsyn | Legend | 48,189 exp
Reply #2 — Posted 2yr ago
by mcalsyn | Legend | 48,189 exp
Multiple responses to a single interrupt could be a number of things - you;re going to need to debug it either in the debugger or with Debug.Print, but unfortunately both of those can change the execution profile (timing) of your program.

There's actually so many ways this could go wrong, it's hard to give much guidance. The two hardest classes of bugs to diagnose are memory corruption and concurrency bugs (and this is probably a concurrency bug). That's why threads, for reasons of both runtime cost and maintenance complexity, are best left to those situations where you REALLY need them - not just as a mechanism for simplifying code structure.
Reply #3 — Posted 2yr ago
by ianlee74 | Superhuman | 127,688 exp
Reply #3 — Posted 2yr ago
by ianlee74 | Superhuman | 127,688 exp
You could add a limit so that no more than one move can occur in say 500ms. Then if you get extra events you just toss them out.
Reply #4 — Posted 2yr ago
by Dave McLaughlin | Legend | 58,471 exp
Reply #4 — Posted 2yr ago
by Dave McLaughlin | Legend | 58,471 exp
I recall your hardware design for this project and you had a capacitor/resistor to act as a sort of debounce. The fact you are seeing the occasional extra click could be down to the fact you are still seeing some bounces. How does the pulses look like on a scope (if you have on that is)
Reply #5 — Posted 2yr ago
by Gismofx | Senior | 1,322 exp
Reply #5 — Posted 2yr ago
by Gismofx | Senior | 1,322 exp
@Dave McLaughlin -
Signal is clean: Here's a shot where I spin Clockwise and then Count-Clockwise. The signal looks no different when enable or disable the sensor threads(see atttached image)
Reply #6 — Posted 2yr ago
by godefroi | Legend | 43,071 exp
Reply #6 — Posted 2yr ago
by godefroi | Legend | 43,071 exp
Is it possible you're just not reading interrupts fast enough?
Reply #7 — Posted 2yr ago
by Gismofx | Senior | 1,322 exp
Reply #7 — Posted 2yr ago
by Gismofx | Senior | 1,322 exp
@mcalsyn -
That's my fear.. I won't be able to do much with normal debug statements without interfering with the actual timing of the system. I'm still trying find a way to figure out what's going on.
Reply #8 — Posted 2yr ago
by Mike | Superhuman | 82,265 exp
Reply #8 — Posted 2yr ago
by Mike | Superhuman | 82,265 exp
assuming it is not GC, as I mentioned earlier, can you increase the sleep times in your threads, one at a time, to see if you can isolate the thread causing the delay?
Reply #9 — Posted 2yr ago (modified)
by Gismofx | Senior | 1,322 exp
Reply #9 — Posted 2yr ago (modified)
by Gismofx | Senior | 1,322 exp
godefroi says:
Is it possible you're just not reading interrupts fast enough?

I would think that I should be capturing all the interrupts, but I suppose stranger things could occur. How could that happen?

Here's a link to a post I made about the encoder with the code:
https://www.ghielectronics.com/community/forum/topic?id=20019&page=2#msg218355

Page 1 of 2 out of 17 messages.

You must be logged in to reply.