Objetivos

 

  • Presentar el concepto de Interrupcion en Arduino.
  • Conocer los tipos de interrupciones.
  • Mostrar los Flags de disparo.
  • Consideraciones generales.
  •  

    Material requerido.

     

    Kit Arduino Uno  Kit inicio UNO
    Kit Arduino MEGA Kit Inicio Mega

     

    Las Interrupciones

     

    Nunca he sabido muy bien que tiene esto de las interrupciones, que hacer temblar a programadores curtidos como si fueran unos novatos.

    Recuerdo que en una época en que nos dedicábamos a los microprocesadores (cuando los dinosaurios dominaban la tierra) y comenzábamos a jugar con las interrupciones, había un porcentaje de técnicos, ingenieros electrónicos o informáticos, que aun  comprendiendo la idea de las interrupciones, parecía que su cerebro no podía abarcarlas y sencillamente las ignoraban elegantemente.

    Mentarle las interrupciones a muchos Arduineros ya fogueados, en muchos casos supone que recordarán inmediatamente la necesidad de salir urgentemente a hacer algo. Nunca he sabido porque pasa esto, pero vamos a intentar ponerlo remedio inmediatamente.

    ¿Qué es una interrupción hardware?

    A un nivel básico, una interrupción es una señal que interrumpe la actividad normal de nuestro microprocesador y salta a atenderla. Hay tres eventos que pueden disparar una interrupción:

  • Un evento hardware, previamente definido.
  • Un evento programado, o Timer
  • Una llamada por software.
  •  

    Cuando un evento dispara una interrupción, la ejecución normal del micro se suspende (ordenadamente para poder volver) y salta a ejecutar una función especial que llamamos Interrupt Service Handler o ISH (Servicio de gestión de interrupción).

    Cuando el ISH finaliza, el procesador vuelve tranquilamente al punto donde lo dejó y sigue con lo que estaba como si no hubiese pasado nada.

  •  El concepto de interrupción nace de la necesidad imperiosa de reaccionar de forma inmediata en respuesta a un acontecimiento electrónico fulgurante, que no admite demora. Bien sea por la urgencia del suceso o porque algo se podría perder de forma irrecuperable sino reaccionamos con suficiente presteza.
  •  

    Pero ¿Qué hay tan urgente que no pueda esperar? ¿Es que nuestros Duinos no son lo suficientemente rápidos para ver cada poco si hay una señal de alarma? ¿Por qué complicarnos la vida con una cosa tan extravagante?

    La respuesta como siempre es… depende. Nuestro Arduino puede estar liado y solo leerá la señal de un pin de tanto en tanto. Y si la señal que aparece se desvanece antes de que hayamos ido a ver, ni siquiera lo sabremos, porque aunque los Duinos son rápidos una señal electrónica lo es varios millones de veces más. Este es otro motivo por el que usar delays tiene mucho peligro.

  •  En la jerga técnica, a pasar de vez en cuando a ver como está el asunto, se le llama Polling.
  •  

    Por otro lado las interrupciones nos ofrecen una ventaja enorme a la hora de organizar nuestro programa. Se define la función que se ejecutará al recibir una interrupción dada y se ejecuta limpiamente cuando ocurre, no hay que comprobar si se da o no una situación.

    Simplemente te olvidas y se ejecutará única y exclusivamente cuando se alce la interrupción. No me digáis que no es elegante (SI, es una obsesión).

    En realidad, nosotros funcionamos por interrupciones habitualmente, en respuesta a sucesos no previstos que nos sacan de la rutina habitual.

    Imagínate que estás viendo tu serie favorita en la tele y estas esperando a tu colega, amigo o novia.

    Hay dos maneras de abrirle la puerta. Una es pasar a ver si ha llegada cada, digamos dos minutos, para ver si esta con cara de pánfilo/pánfila en la puerta esperando a que le abramos.

    La otra es establecer una interrupción, para eso están los timbres. Cuando tu compi llega, pulsa el timbre. Tu paras tu capitulo tranquilamente, dejas el refresco en la mesa y vas a abrirle.

    Cuando vuelves con él, reanudas tu peli y recoges el refresco. ¿Qué tienen de raro las interrupciones? ¿Qué me decís del teléfono o de los Whatsapp? Es la misma idea. Y lo mismo pasa con tu Arduino.

    ¿Por qué voy a renunciar a las interrupciones y dedicarme a pasar por la puerta cada poco? Es absurdo. Las interrupciones no tienen nada de extraño ni de incognoscible. Dedícale un poco de tiempo y te encontrarás una herramienta magnifica que te resolverá limpiamente más de un problema.

     

    Tipos de interrupciones

     

    De los tres  sucesos que pueden disparar una interrupción

  • Un evento hardware,
  • Un evento programado, o Timer
  • Una llamada por software.
  •  

    Nos encontramos con que Arduino no soporta las interrupciones por software y punto.

    ¿Y entonces porque hemos hablado de ellas? Pues, porque otros entornos de programación las aceptan y no será raro que en el futuro Arduino también.

    Los eventos programados o Timers, son muy interesantes y tendrán una sesión monográfica propia en un futuro próximo. Pero por ahora vamos a meternos con las interrupciones disparadas por hardware.

     

    Las interrupciones por hardware

     

    Estas interrupciones hardware, se diseñaron por la necesidad de reaccionar a suficiente velocidad en tiempos inimaginablemente cortos a los que la electrónica trabaja habitualmente y a los que ni siquiera el software era capaz de reaccionar.

    La idea que debéis  que tener en mente es que vamos a definir una función que se ejecutará de forma asíncrona, sin planificación, cuando se ocurra un cierto suceso electrónico.

    Para definir una interrupción necesitamos tres cosas:

  • Un pin de Arduino que recibirá la señal de disparo
  • Una condición de disparo
  • Una función que se ejecutará, cuando se dispare la interrupción (Llamada call back function).
  •  

    Lo primero es un pin de Arduino donde conectaremos el “timbre” de llamada. Dependiendo del modelo Arduino que tengamos, tendremos varias posibilidades:

    Modelo Arduino Int 0 Int 1 Int 2 Int 3 Int 4 Int 5
    UNO Pin 2 Pin 3
    MEGA 2 3 21 20 19 18
    DUE Todos los pines del DUE pueden usarse para interrupciones.
    Leonardo 3 2 0 1 7

     

    Esto quiere decir que el Arduino UNO puede definir dos interrupciones hardware llamadas 0 y 1, conectadas a los pines 2 y 3 (Para que no sea fácil).

    El Mega como es habitual en él, acepta nada menos que 6 interrupciones diferentes. Y el DUE, muy sobrado, exhibe su poderío.

    En cuanto a la condición de disparo puede ser:

  • LOW, La interrupción se dispara cuando el pin es LOW.
  • CHANGE, Se dispara cuando pase de HIGH a LOW o viceversa.
  • RISING, Dispara en el flanco de subida (Cuando pasa de LOW a HIGH).
  • FALLING, Dispara en el flanco de bajada (Cuando pasa de HIGH a LOW).
  • Y una solo para el DUE: HIGH se dispara cuando el pin esta HIGH.
  •  

    Si nuestra call back function se llama Funcion1 (),  para activar la interrupción usaremos:

    attachInterrupt(interrupt, ISR, mode)

    Donde Interrupt es el número de la interrupción, ISR será Funcion1 y mode es una de las condiciones que hemos visto arriba. Así en un Arduino UNO podría ser:

    attachInterrupt(0, Funcion1, RISING) ;

    Suponiendo que hemos enchufado la señal de interrupción al pin 2 de Arduino. Vamos a ver algún ejemplo de interrupciones.

     

    Esquema de conexiones

     

    Es una especie de costumbre en Arduino, usar un pulsador para ilustrar el concepto de Interrupción, así que nos plegáramos a ello. Vamos a utilizar un típico circuito para leer un pulsador con un pullup.

    Esquema de conexión

     

    Hasta ahora habríamos escrito el programa para leerlo así,

    void setup()
       {   pinMode(2, INPUT);
           Serial.begin(9600);
       }
    
    void loop()
       {   bool p = digitalRead(2);
           Serial.println(p);
       }

    El resultado seria normalmente 1, por el pull up y la lectura bajaría a 0, al pulsar el botón. Nada nuevo en esto.

    Pero vamos a reescribir el programa para  establecer una interrupción en el pin 2 (Interrupción 0) .El programa quedara más o menos así:

    int contador = 0;
    int n = contador ;
    
    void setup()
       {   Serial.begin(9600);
           attachInterrupt( 0, ServicioBoton, FALLING);
       }
    void loop()
       {   if (n != contador)
              {     Serial.println(contador);
                    n = contador ;
              }
       }
    
    void ServicioBoton() 
       {    contador++ ;
       }

    En primer lugar fijaros que hemos eliminado la definición de entrada del pin 2, porque no vamos a usarlo como input estrictamente. Con definir la interrupción es suficiente.

    En segundo lugar usamos attachInterrupt() pasándole como parámetros la interrupción 0, que es el pin2 de Arduino UNO. SI fuese la Interrupción 1, la conectaríamos al pin 3 (Anda que…)

    Le pasamos el nombre de la función CallBack ServicioBoton, que es de lo más sencilla. Un variable global contador, guarda el número de pulsaciones. Lo único que hace la función de servicio es aumentar contador en uno cada vez que se pulsa y volver.

    Y por último el trigger es FALLING porque el estado es normalmente HIGH y baja a LOW al pulsar el botón,  utilizaremos el disparo con el flanco de bajada, o sea FALLING o LOW.

  • Un disparador en inglés es trigger y es el nombre que encontrareis en la jerga técnica.
  •  

    El loop comprueba si el número de pulsaciones ha cambiado y si es así lo imprime, pero puede dedicarse a hacer cualquier cosa, porque no vamos a perder ninguna pulsación.

    Os puede parecer una manera extravagante de hacer las cosas pero no me digáis que no es elegante. De hecho todos los lenguajes modernos de alto nivel para Windows, Mac o Linux utilizan la programación por eventos que es algo básicamente igual a esto (Salvando las distancias claro).

    Cuando veamos la salida en la consola tendremos una sorpresa esperada:

    Botón por interrupción

    Cuando pulsamos el botón, el número que aparece no aumenta de uno en uno si no a golpes. ¿Por qué?

    Pues como ya vimos en su día, se debe a los rebotes del pulsador. Decíamos en la sesión “Condicionales y botones”, que para eliminar el rebote de los botones, tenemos que hacer el debouncing y allí lo hacíamos con un delay de 250 ms.

    Pero vamos a tener un problema. No podemos usar un delay dentro de una interrupción. No funciona. ¿Cómo dice?

    Hay varias consideraciones a tener en cuenta con las interrupciones:

  • Haz lo que quieras pero no te demores. Acaba cuanto antes y lárgate.
  • Hay cosas que no funcionan, como las funciones delay (), millis () y cualquier cosa que dependa de interrupciones o timers.
  • Ni se te ocurra meter un Serial.Nada en una interrupción, son muy lentos (Y además tampoco funcionan porque también dependen de interrupciones).
  • Debes entender que una interrupción es como un estado de excepción, que se puede usar sin reparos, pero entendiendo que hay que hacer el trabajo y salir cuanto antes.
  • De hecho, una ISR o función CallBack, no puede devolver parámetros ni tampoco recibirlos
  •  

    Además cuando definimos una variable global como contador, de la que depende una función ISR, se recomienda definirla como volatile y no como una global normal.

  • Estrictamente hablando, volatile no es un tipo de variable, sino una directiva para el compilador.
  • Eso significa que la variable en cuestión, debe ser almacenado de un cierto modo que evite algunos problemas raros que pueden surgir cuando una variable puede ser cambiada por el ISR o por el programa (algo que no ocurre en nuestro ejemplo).
  • Bajo ciertas circunstancias puede surgir un conflicto y volatile lo evita y por eso se recomineda hacerlo así siempre.
  •  

    Si necesitas un retraso para algo, o sea , un delay, siempre es mejor, comprobar el tiempo transcurrido y decidir si se toma la acción o no. Veamos otro ejemplo

    volatile int contador = 0;   // Somos de lo mas obedientes
    int n = contador ;
    long T0 = 0 ;  // Variable global para tiempo
    
    void setup()
       {    pinMode(2, INPUT);
            Serial.begin(9600); 
            attachInterrupt( 0, ServicioBoton, LOW);
       } 
    void loop()
       {   if (n != contador)
               {   Serial.println(contador);
                   n = contador ;
               }
       }
    void ServicioBoton()
       {
           if ( millis() > T0  + 250)
              {   contador++ ;
                  T0 = millis();
              }
        }

    En primer lugar definimos contador como volátil, por prescripción médica, y definimos otra variable global T0 para almacenar el tiempo a partir del cual contaremos.

    En la ISR la diferencia es que comprobamos si el valor actúan de millis es mayor en 250 ms a la última vez que paso por la interrupción. Si no es así, lo consideramos un rebote y lo ignoramos olímpicamente. Por el contrario si ha pasado un tiempo prudencial incrementamos contador.

    La ventaja d este sistema es que no congelamos el procesador con un delay, si no que le dejamos seguir con su trabajo, atendiendo otras interrupciones, por ejemplo.

    Pero….Un momento… No habíamos dicho que millis() no funciona en las interrupciones.

    Así es. Mientras una interrupción esta activa millis está congelada y su valor no cambiará, pero sigue pudiéndose leer.

  • Mientras estas dentro de una interrupción, todas las demás interrupciones, son ignoradas, por eso, nada que dependa de otras interrupciones funciona.
  • Por eso es importante salir pronto, para garantizar que no nos perdemos nada de interés.
  • Mientras una interrupción está activa, millis() y micros()se congelan. Eso quiere decir que si tienes unos cuantos miles de interrupciones por segundo (Como si estas midiendo la frecuencia de una onda de audio) tu medida de tiempo con millis o micros se puede ver distorsionada.
  •  

    Por ultimo os conviene saber que existen algunas otras instrucciones relativas a las interrupciones:

  • noInterrupts(), Desactiva la ejecución de interrupciones hasta nueva orden.
  • Interrupts(), Reinicia las interrupciones definidas con attachInterrupt().
  • detachInterrupt( num Interrupt), Anula la interrupción indicada.
  •  

    Resumen de la sesión

     

    En este curso de arduino hemos aprendido lo siguiente:

  • Hemos conocido el motivo y el concepto de las interrupciones.
  • Hemos empezado por estudiar las interrupciones hardware, dejando los Timers para futuras sesiones.
  • Vimos que en Arduino UNO solo disponemos de 2 interrupciones llamadas 0 y 1 en los pines 2 y 3 respectivamente.
  • Vimos los posibles disparos de una interrupción por flanco de subida, bajado o LOW.
  •  

    Deja una respuesta