If I make an interrupt and use a goto statement to go from the interrupt function to the main function will I start running into problems: with the flow of my program and with bugs. Will I start getting overflow errors or am I not even able to jump like that? (I have yet to use the goto statement)

Essentially I'm using the interrupt to for rotary encoders that each time they turn I change a value and run a draw function but if I interrupt in the middle of a draw I will mess up the draw block, and the screen will stay messed up until more input. Any suggestions?


GOTO, in C, only allows jumps to labels in the same function. So you will not be able to do that. Even if you could it would be a bad idea, Interrupt Handlers must return from their function to end the interrupt, a GOTO is not a function call

You can in principle call the redraw method directly, however this will have the side-effect that you describe - multiple interrupts may "clobber" each other or some other system thrashing.

Interrupt handler should be as small as possible, In this case a simple handler would

  • increment the counter
  • set a flag (boolean variable) to indicate a redraw is needed
  • Alternatively, you can only increment a counter and store the previous value elsewhere for comparison

The main thread would run in a standard while-true-redraw-sleep loop, you would check this flag every cycle. This way, when multiple interrupts are issued, the counter is incremented multiple times, but the redraw is only triggered when the main thread is ready, in other words the redraw is synchronous with the main thread refresh timer.

A more clever way would be to use events/signals for the refresh. The main thread "sleeps" on an event and is woken by the interrupt handler. This way if there are many events the refresh is triggered as often as it can be, but if there no events it is idle. This makes the refresh synchronous with the interrupt.


The key is that no drawing code is done in the interrupt context. You need to think of a way to indicate that a redraw is needed. The redraw happens in the GUI thread.

  • I love the handler idea. Infect I think i will use that idea for all my drawing needs. I can keep drawing on demand that way. and use the interrupt for all my GPIO inputs witch will free up tonnes of CPU room for more activities. - I know this isn't allowed but its really deserved. Thanks! That was an amazing answer and not only that I learned a great deal from it. I appreciate the effort. – qwerty asdfgh Sep 12 '17 at 1:23
  • Its not always ideal, interrupt forces context switches to kernel and then back to user space, which adds latency and additional CPU load per pin change. Interrupt Handlers (a.k.a. Interrupt Service Routine or ISR in some worlds) are a standard design piece. However, You may still find that performance is insufficient if there are many interrupts. There are design alternatives, but it would require a lot more to understand why one approach is better than the other. If you have many slow changing GPIO pins, a single polling thread may be more effective (e.g. check all pins every 10ms. – crasic Sep 12 '17 at 1:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.