AttachInterrupt and LEDs

Using Arduino Project Guidance
1

hi all,

I'm wondering if you all can help me with a coding issue as I'm quite new to arduino. I'm working with a 32bit arduino nano and trying to figure out an LED program.

I am trying to design is an LED power up sequence and shut off, basically when you click a physical limit switch the 4 LEDs light up in sequence and shut off immediately when you let go, whether they all lit up or not, rinse and repeat.

From my experience I would have guessed that I should use one or two attach interrupt functions, one that receives the interrupt signal and one starts the sequence, and one that receives the change in signal when the switch is released.

So far I have used the slightly modified code from some one else to make this this very simple code to test the LED reaction time.

const byte ledPin = 6;
const byte interruptPin = 2;
volatile byte state = LOW;

void setup() {
  pinMode(ledPin, OUTPUT);
  pinMode(interruptPin, INPUT);
  attachInterrupt(digitalPinToInterrupt(interruptPin), blink, CHANGE);
}

void loop() {
  digitalWrite(ledPin, state);
}

void blink() {
  state = !state;
}

However there are delays in between sending the interrupt signal and the LED changing. I'm wondering is this a hardware issue? I understand the arduino should be able to receive many interrupts without delays of multiple seconds, or is this code just too simple to expect the LED state to change quickly. thanks.

2

That is not what interrupts are for!

As a beginner, it is incredibly unlikely that interrupts will be useful to you.

A common "newbie" misunderstanding is that an interrupt is a mechanism for altering the flow of a program - to execute an alternate function. Nothing could be further from the truth! :astonished:

An interrupt is a mechanism for performing an action which can be executed in "no time at all" with an urgency that it must be performed immediately or else data - information - will be lost or some harm will occur. It then returns to the main task without disturbing that task in any way though the main task may well check at the appropriate point for a "flag" set by the interrupt.

Now these criteria are in a microprocessor time scale - microseconds. This must not be confused with a human time scale of tens or hundreds of milliseconds or indeed, a couple of seconds. A switch operation is in this latter category and a mechanical operation perhaps several milliseconds; the period of a 6000 RPM shaft rotation is ten milliseconds.

Unless it is a very complex procedure, you would expect the loop() to cycle many times per millisecond. If it does not, there is most likely an error in code planning; while the delay() function is provided for testing purposes, its action goes strictly against effective programming methods. The loop() will be successively testing a number of contingencies as to whether each requires action, only one of which may be whether a particular timing criteria has expired. Unless an action must be executed in the order of microseconds, it will be handled in the loop().

So what sort of actions do require such immediate attention? Well, generally those which result from the computer hardware itself, such as high speed transfer of data in UARTs(, USARTs) or disk controllers.

An alternate use of interrupts, for context switching in RTOSs, is rarely relevant to this category of microprocessors as it is more efficient to write cooperative code as described above.

3

For your simple example code, are you using a pull-down resistor on the switch?

Have you taken into account that switches can bounce?

How do you know that it does not react immediately?

I totally agree that interrupts are not suitable. Have a look at e.g.
Using millis() for timing. A beginners guide and
Demonstration code for several things at the same time

4

Should the leds remain cycling if the switch is not released? Or is it a "one-shot" that happens when the switch becomes pressed? (ie would require a release and new press to go again?)