body, html {font-family: 'Open Sans', sans-serif;} #nav a, #nav{font-family: 'Open Sans', sans-serif;} #title #tagline {font-family: 'Open Sans', sans-serif;} #main .gridItem h3 {font-family: 'Open Sans', sans-serif;}

About Interrupts


Tuesday, 3.5.2016

I got from my son as birthday gift a book regarding Ardunios - Thanks again for that, Nils. I jumped through the different chapters and started reading one about interrupts. I should have known earlier!

What is an interrupt? You can understand it as a second tiny program (sketch), which is running in parallel to the main one. To be quite honest, to work integrate interrupts to a program isn’t difficult. Difficult is the logic behind coming that from now on you have to think about 2 programs running in parallel and interacting.

What’s the advantage?

I just wrote this in an eMail and I’m just copying the lines here:

Do you want to know an interrupt, you’re all the time aware but maybe not knowing it is an interrupt? Your operating system of your PC and the program (e.g. Word) are all programs running and doing something. But when moving your mouse, that’s creating an interrupt and regardless what your program or your operating system is just doing, this interrupt forces your cursor to move immediately...

In the past I wrote a lot of programs, where something is looping, text is displayed etc. and the status of a sensor or a button is read. I was already quite disappointed that sometimes it took some time (shit wording! sorry!), up the status was read. Example: The text was still displayed on the LCD and after that the sensor was read. Ok, you can make the time waiting to read the display quite short, but that’s not every time a solution. With one of the latest programs (Questions) there’s a loop where

  1. The question is shown
  2. Time for reading the question
  3. Possible answers are shown
  4. (Shorter) time to read the possible answers
  5. Reading the button
  6. start over with 1 if no button was pressed

The program is only recognizing that a button is pressed, when it’s pressed during step 5.

Now the „interrupt alternative“:

An interrupt you can understand as a second (tiny) program running in parallel (!!!) to the main sketch. So whenever the button is pressed (even quite short) regardless where the sketch is at this moment, this will be recognized. That’s making the sketch much better…

For you, Tim, the sketch is in our DropBox, for all the others it’s here:

Thursday, 5.5.2016

After I’ve understood the principle with one interrupt, I did the next step to finally integrate it into an existing cache. I added 3 more buttons and programmed 4 interrupts, each triggered by one specific button. Without any problem it worked… 

But again I’ve learned something: I wrote, the interrupts would tun in parallel to the main program. The feeling is like that, but it’s not the truth. The Arduino is checking the interrupts sequentially. It’s more like that:

  1. Running a small part of the main program
  2. Checking interrupt 0
  3. Checking interrupt 1
  4. Checking interrupt 2
  5. Checking interrupt 3
  6. Running the next small part of the main program
  7. Checking interrupts again
  8. Running the next small part of the main program .

Is there any consequence, you’ll become aware, because all this is happening within microseconds? Yes, it is! Assume you pressed button 1 (interrupt 0). The interrupt will immediately do something and the Arduino will no longer check the interrupts of the other buttons. Consequence: You can’t check for two buttons being pressed at the same time.

The sketch for your cache „Test Time“ has a setup part at it’s beginning. You can e.g. reset the visitors counter to Zero when entering the setup part. To enter this setup mode, you had to press two buttons at the certain time. This didn’t worked any longer. So I had to change the logic to one dedicated button must be pressed (I did it with the 4th one).

Now the updated version of the sketch is in your DropBox and I’m quite nosy to hear, what you’re thinking about….

Monday, 1.7.2016

Meanwhile I worked on another sketch and it took hours to discover two mistakes I did:

  1. Only some few pins can be used as interrupts (see below). So you must carefully only use that pins.
  2. The part of the program executed by the interrupt must be as short as possible. I wrote something onto the LCD screen. That lasted much too long. Best is, only to set one or a few flags and than return to the main program.

Schnappschuss (2016-08-01 07.06.02)

©  Olaf Goette 2008 - 2022