Arduino Interrupts

Что такое прерывания Arduino? Как их использовать? Что вам следует знать о них? В этом уроке по прерываниям Arduino я покажу вам пример того, когда вы можете использовать прерывания и как с ними обращаться. Я также дам вам список важных моментов, на которые вам следует обратить внимание, потому что, как вы увидите, с прерываниями следует обращаться осторожно. Оглавление

Пример 1 Давайте воспользуемся аналогией из реальной жизни. Представьте, что вы ждете важного письма. Вы не знаете, когда оно придет, но хотите убедиться, что прочитали его, как только оно попадет в ваш почтовый ящик. Самое простое решение — часто проверять свой почтовый ящик — скажем, каждые 5 минут — чтобы быть уверенным, что максимальная задержка между получением электронного письма и его чтением составляет 5 минут. Но это действительно не идеальное решение. Во-первых, вы потратите все свое время на обновление почтового ящика и при этом не будете заниматься ничем продуктивным. Во-вторых, это относительно неэффективно. Когда письмо придет, у вас будет задержка до 5 минут, прежде чем вы его прочтете. Эта техника называется «

опрос“. С заданной частотой вы опрашиваете состояние чего-либо, чтобы узнать, поступила ли новая информация. В человеческом масштабе вы видите, что оно того не стоит.

Другой возможный способ сделать это — использовать прерывания. Для нас, людей, это означает включение уведомлений. Как только письмо придет, на вашем телефоне/компьютере появится всплывающее окно с сообщением о том, что письмо здесь. Теперь вы можете проверить свою электронную почту, и задержка между получением и чтением электронной почты практически равна нулю. Вы учитесь использовать Arduino для создания собственных проектов? *Ознакомьтесь с * Arduino для начинающих и учитесь шаг за шагом. Давайте добавим больше деталей к этой аналогии: электронное письмо, которое вы собираетесь получить, содержит специальное предложение на получение скидки на определенном веб-сайте — и это предложение доступно только в течение 2 минут.

Если вы используете метод «опроса», есть вероятность, что вы пропустите некоторые данные(в данном примере вы пропустите скидку). ** Благодаря прерываниям вы можете быть уверены, что не пропустите событие.**

Пример 2

Другой пример: вы ждете, чтобы о чем-то поговорить с почтальоном. Теперь он приедет с 9 до 11 утра. Первый вариант — опрос — вы можете продолжать подходить к своей двери, чтобы проверить, пришел ли он. Но, возможно, ты будешь скучать по нему, потому что ты не можешь все время сидеть у окна и смотреть на улицу. Второй вариант — прерывание — вы вешаете на дверь записку с надписью «Уважаемый господин почтальон, пожалуйста, позвоните в колокольчик, когда увидите это». Как только придет почтальон, он позвонит в колокольчик, и вы его не пропустите.

В обоих сценариях вы прекращаете текущее действие. Вот почему это называется прерыванием. Вам придется прекратить то, что вы делаете, чтобы справиться с прерыванием, и только после того, как вы закончите, вы сможете возобновить свои действия.

Прерывания Arduino работают аналогичным образом. Например, если вы ждете, пока пользователь нажмет кнопку, вы можете либо контролировать кнопку с высокой частотой, либо использовать прерывания. Используя прерывания, вы уверены, что не пропустите триггер. Мониторинг прерываний Arduino осуществляется аппаратно, а не программно. Как только кнопка нажата, аппаратный сигнал на выводе запускает функцию внутри кода Arduino. Это останавливает выполнение вашей программы. После завершения запущенной функции основное выполнение возобновляется. Обратите внимание, что в приведенных выше аналогиях из реальной жизни прерывания имеют гораздо больше смысла, чем метод опроса. Однако я хочу отметить, что иногда опрос может быть лучшим выбором. В человеческом масштабе прерывания имеют гораздо больше смысла. В масштабе микроконтроллера, где частота выполнения намного выше, иногда все усложняется и выбор не всегда очевиден. Мы обсудим это подробнее позже в этом посте.

В выводах прерываний Arduino используются цифровые выводы. Однако обычно вы не можете использовать все доступные цифровые контакты. Только у некоторых из них эта функция включена. Вот контакты, которые вы можете использовать для прерываний на основных платах Arduino: |Arduino Board |Digital Pins for Interrupts |Arduino Uno, Nano, Mini |2, 3 |Arduino Mega |2, 3, 18, 19, 20, 21 |Arduino Micro, Leonardo |0, 1, 2, 3, 7 |Arduino Zero |All digital pins except 4 |Arduino Due |All digital pins On this tutorial we’ll be using an Arduino Uno board, so we only have two choices! We can either use pin 2 or pin 3. If you want to use more interrupts in your programs, you can switch to the Arduino Mega. This board is really pretty close from the Arduino Uno, with more pins. And if you need even more interrupts, choose something like the Arduino Due – pay attention though, the Due works with 3.3V, not 5V.

For this tutorial we’ll use a basic example. The goal of the program is to change the state of a LED when the user presses a push button.

Note that we are using the pin 3 for the button. As previously stated, on Arduino Uno you can only use pin 2 and 3 for interrupts. Pay attention when you have to choose a pin for an interrupt. If the pin is not compatible with interrupts your program won’t work (but still compile), and you’ll spend quite some time scratching your head while trying to find a solution.

Arduino interrupts are triggered when there is a change in the digital signal you want to monitor. But you can choose exactly what you want to monitor. For that you’ll have to modify the 3rd parameter of the attachInterrupt() function:

RISING: Interrupt will be triggered when the signal goes from LOW to HIGH FALLING: Interrupt will be triggered when the signal goes from HIGH to LOW CHANGE: Interrupt will be triggered when the signal changes (LOW to HIGH or HIGH to LOW) LOW: Interrupt will be triggered whenever the signal is LOW Practically speaking, you could monitor when the user presses the buttons, or when he/she releases the button, or both. If you’ve added a pull-down resistor to the button – meaning its normal state is LOW – then monitoring when it’s pressed means you have to use RISING. If you’ve added a pull-up resistor, the button state is already HIGH, and you have to use FALLING to monitor when it’s pressed (linked to the ground).

#define LED_PIN 9 
#define BUTTON_PIN 3 
byte ledState = LOW; 

void setup()                                
    {                                           
        pinMode(LED_PIN, OUTPUT);               
        pinMode(BUTTON_PIN, INPUT);             
    }                                           
    void loop()                                 
    {                                           
        if (digitalRead(BUTTON_PIN), HIGH)      
        {                                       
            ledState = !ledState;               
        }                                       
        digitalWrite(LED_PIN, ledState);        
    }

Nothing really new here. We initialize the pin of the LED as OUTPUT and the pin of the button as INPUT. In the loop() we monitor the button state and modify the LED state accordingly. Note that for simplicity I haven’t use a debounce on the button.

#define LED_PIN 9
#define BUTTON_PIN 3
volatile byte ledState = LOW;
void setup()
{
    pinMode(LED_PIN, OUTPUT);
    pinMode(BUTTON_PIN, INPUT);
    attachInterrupt(digitalPinToInterrupt(BUTTON_PIN), blinkLed, RISING);
}
void loop()
{ 
    // nothing here!
}
void blinkLed()
{
    ledState = !ledState;
    digitalWrite(LED_PIN, ledState);
}

Here we changed the way we are monitoring the push button. Instead of polling its state, there is now an interrupt function attached to the pin. When the signal on the button pin is rising – which means it’s going from LOW to HIGH, the current program execution – loop() function – will be stopped and the blinkLed() function will be called. Once blinkLed() has finished, the loop() can continue. Here, the main advantage you get is that there is no more polling for the button in the loop() function. As soon as the button is pressed, blinkLed() will be called, and you don’t need to worry about it in the loop(). As you might have noticed, we use the keyword “volatile” in front of the ledState variable. I’ll explain you later in this post why we need that. You have to use the attachInterrupt() function to attach a function to an interrupt pin. This function takes 3 parameters: the interrupt pin, the function to call, and the type of interrupt.

As you can guess, you should make the interrupt function as fast as possible, because it stops the main execution of your program. You can’t do heavy computation. Also, only one interrupt can be handled at a time. What I recommend you to do is to only change state variables inside interrupt functions. In the main loop(), you check for those state variables and do any required computation or action. Let’s say you want to move a motor, and this action is triggered by an interrupt. In this case, you could have a variable named “shouldMoveMotor” that you set to “true” in the interrupt function. In your main program, you check for the state of the “shouldMoveMotor”. When it’s true, you start moving the motor.

#define BUTTON_PIN3
volatile bool shouldMoveMotor = false;

void setup()
{
    pinMode(BUTTON_PIN, INPUT);
    attachInterrupt(digitalPinToInterrupt(BUTTON_PIN), triggerMoveMotor, RISING);
}
void loop()
{
    if (shouldMoveMotor)
    {
        shouldMoveMotor = false;
        moveMotor();
    }
}
void triggerMoveMotor() { shouldMoveMotor = true; }
void moveMotor()
{
    // this function may contains code that
    // requires heavy computation, or takes
    // a long time to execute
}

And you can do exactly the same for a heavy computation, for example if the computation takes more than a few microseconds to complete. If you don’t keep the interrupts fast, you might miss important deadlines in your code. For a mobile robot with 2 wheels, that may make the motor movement jerky. For communication between devices, you might miss some data, etc. When you need to deal with real-time constraints, this rule becomes even more important.

A basic rule of thumb: don’t use time functionalities in your interrupts. Here’s more details about the 4 main time functions: [:

this will return the time spent since the Arduino program has started, in milliseconds. This function relies on some other interrupts to count, and as you are inside an interrupt, other interrupts are not running. Thus, if you use millis(), you’ll get the last stored value, which will be correct, but when inside the interrupt function, the millis() value will never increase.](/arduino-millis-vs-micros/) millis() : this one will simply not work, as it also relies on interrupts. Plus, even if it was possible, you should not use it because you now know that you have to keep the interrupts very fast. delay() micros(): this function is the same as millis(), but returns the time in microseconds. However, contrary to millis(), micros() will work at the beginning of an interrupt. But after 1 or 2 milliseconds, the behavior won’t be accurate and you may have a permanent drift every time you use micros() afterwards. Again, the advice is the same: make your interrupts short and fast! delayMicroseconds(): this one will work as usual, but… Don’t use it. As you saw before, there are too many things that can go wrong if you stay too long in an interrupt.

All in all, you should avoid using those functions. Maybe using millis() or micros() can sometimes be useful, if you want to make a comparison of duration (for example to debounce a button). But you can also do that in your code, using the interrupt only to notify of a change in the state of the monitored signal.

The Serial library is very useful to debug and communicate between your Arduino board and another board or device. But it’s not a great fit for interrupt functions. When you are inside an interrupt, the received Serial data may be lost. Thus it’s not a good idea to use the reading functionalities of Serial. Also if you make the interrupt too long, and read from Serial after that in your main code, you may still have lost some parts of the data. You can use Serial.print() inside an interrupt for debugging, for example if you’re not sure when the interrupt is triggered. But it also has its own source of problems. The best way to print something from an interrupt, is simply to set a flag inside the interrupt, and poll this flag inside the main loop() program. When the flag is turned on, you print something, and turn off the flag. Doing that will save you from potential headaches.

If you modify a variable inside an interrupt, then you should declare this variable as volatile. The compiler does many things to optimize the code and the speed of the program. This is a good thing, but here we need to tell it to “slow down” on optimization. For example, if the compiler sees a variable declaration, but the variable is not used anywhere in the code (except from interrupts), it may remove that variable. With a volatile variable you’re sure that it won’t happen, the variable will be stored anyway. Also, when you use volatile it tells the controller to reload the variable whenever it’s referenced. Sometimes the compiler will use copies of variables to go faster. Here you want to make sure that every time you access/modify the variable, either in the main program or inside an interrupt, you get the real variable and not a copy. Note that only variables that are used inside and outside an interrupt should be declared as volatile. You don’t want to unnecessarily slow down your code.

An interrupt function can’t take any parameter, and it doesn’t return any value. Basically if you had to write a prototype for an interrupt this would be something like void interruptFunction();. Thus, the only way to share data with the main program is through global volatile variables. In an interrupt you can also get and set data from hardware pins, as long as you keep the program short. For example, using digitalRead() or digitalWrite() may be OK if you don’t abuse it.

Arduino interrupts are very useful when you want to make sure you don’t miss any change in a signal you monitor (on a digital pin mostly). However, during this post you saw that there are many rules and limitations when using interrupts. This is something you should handle with care, and not use too much. Sometimes, using simple polling may be more appropriate, if for example you manage to write an efficient and deterministic multitasking Arduino program. Interrupts can also be used just to trigger a flag, and you keep using the polling technique inside your main loop() – but this time, instead of monitoring the hardware pin, you monitor the software flag. The main takeaway for you, if you want to use interrupts in your code: keep your interrupts short. Thus you will avoid many unnecessary and hard-to-debug problems.