Go Down

Topic: Interrupciones (Read 321 times) previous topic - next topic

el_pedriyo

Buenas,

He estado mirando un poco sobre las interrupciones con arduino, y la verdad es que son interesantes, pero he visto que no funcionan bien cuando por ejemplo hay delays.
El tema es el siguiente, he estado investigando y algunas personas de por aqui ya me lo dijeron en su tiempo que algunos sensores de temperatura tardan un tiempo en responder a arduino, por que lo que arduino se queda un rato esperando a que el sensor le devuelva un valor para seguir procesando su codigo.
El tema esta en lo siguiente: Si en el momento que esta consultando el sensor de temperatura, entra una interrupcion, va a ejecutar directamente la interrupcion sin problemas o habria que esperar a que el sensor devolviera el valor?

Un saludo,

Pedro

surbyte

No hay modo de que el arduino espere algo a menos que se lo expreses inhabilitando las interrupciones.
Pero para quitarte la duda, debo decirte que las interrupciones deben siempre ser rápidas, o sea, una rutina corta  o que no insuma tiempos largos.
Puedes hacer de todo pero no usar delays dentro de una interrupción. Tampoco puedes dejar que la interrupción se quede esperando una tecla o un estado de un sensor.
La idea es que tu código fluye y algo externo (por ejemplo) genera una interrupción, la atienda y devuelve el control en pocos microsegundos.
Tu programa ni se entera. Es como si tuvieras un delay(1) pero aún menos.

Lucario448

Si en el momento que esta consultando el sensor de temperatura, entra una interrupcion, va a ejecutar directamente la interrupcion sin problemas o habria que esperar a que el sensor devolviera el valor?
En resumen: sí; a menos que se deshabilite la atención de interrupciones durante ese proceso (se ejecutan todas las pendientes apenas se rehabiliten).

el_pedriyo

No hay modo de que el arduino espere algo a menos que se lo expreses inhabilitando las interrupciones.
En resumen: sí; a menos que se deshabilite la atención de interrupciones durante ese proceso (se ejecutan todas las pendientes apenas se rehabiliten).
No me ha quedado del todo claro, que si tendria que esperar a que el sensor devolviera lo que se le estaba preguntando, o que si ejecutaria la interrupcion sin esperar a que el sensor devolviera el resultado?

Pero para quitarte la duda, debo decirte que las interrupciones deben siempre ser rápidas, o sea, una rutina corta  o que no insuma tiempos largos.
Puedes hacer de todo pero no usar delays dentro de una interrupción. Tampoco puedes dejar que la interrupción se quede esperando una tecla o un estado de un sensor.
La idea es que tu código fluye y algo externo (por ejemplo) genera una interrupción, la atienda y devuelve el control en pocos microsegundos.
Tu programa ni se entera. Es como si tuvieras un delay(1) pero aún menos.
A ver, yo se que no se deben de usar delays, lo que no sabia es por que no puede ser muy extenso el codigo de la interrupcion, es decir, yo basicamente la quiero para cuando se activen ciertos sensores que los pueda leer. Ya sea el sensor de una alarma, de movimiento o de lo que sea. Es decir, no quiero que por culpa de estar el arduino ejecutando otro codigo, se le pase el estado de un sensor "critico".


Un saludo,

Pedro

surbyte

Lo que ocurre es que pretendes usar algo sin leer al respecto, porque no buscas arduino interrupciones y te informas al respecto.
Te va a quedar muy claro luego de tener una base.

Carlos007

No me ha quedado del todo claro, que si tendria que esperar a que el sensor devolviera lo que se le estaba preguntando, o que si ejecutaria la interrupcion sin esperar a que el sensor devolviera el resultado?

A ver, yo se que no se deben de usar delays, lo que no sabia es por que no puede ser muy extenso el codigo de la interrupcion, es decir, yo basicamente la quiero para cuando se activen ciertos sensores que los pueda leer. Ya sea el sensor de una alarma, de movimiento o de lo que sea. Es decir, no quiero que por culpa de estar el arduino ejecutando otro codigo, se le pase el estado de un sensor "critico".


Un saludo,

Pedro
Las interrupciones se atienden al instante. Cuando entra una interrupción, arduino deja todo lo que está haciendo y atiende a la interrupción. Si la rutina de la interrupción es corta, no influye en el normal recorrido o ejecución del programa principal, con respecto a los tiempos (cuestión de microsegundos). Pero si la rutina de la interrupcion es larga (por ejemplo, un delay()), o tiene  mucho código con bucles FOR -NEXT, etc, si que puede influir en la normal ejecución del código principal.

Si justo cuando el programa principal está en un bucle esperando recibir señales externas, se produce una interrucpion, cabría la posibilidad de que coincidieran exactamente las 2 cosas, y se podría perder el valor o la señal que estaba esperando, porque las interruciones tienen preferencia con respecto al programa principal. Por eso son interrupciones....pero es una posibilidad bastante remota, ya que estamos hablando de microsegundos.

Cuando hay una parte del código principal, digamos "sensible", que no puede ser interrumpido bajo ningún concepto, se pueden deshabilitar las interrupciones en ese tramo de código, y volver a habilitar después.

En los casos excepcionales en los que arduino está atendiendo la interrupción (A), y en ese momento salta la interrupción (B), arduino no deja de atender la (A). Espera a que se termine el código de (A), y después atiende la (B).
Aunque también es posible dejar de atender una interrupción para atender otra más "importante". Pero eso requiere estar muy seguro de que las interrupciones no entren en un bucle sin salida.




surbyte

Qué cosas haces en una interrupción y qué cosas no?

Qué haces:
1. modificas variables, p.ej contadores. Muy usado para medir RPM, velocidad, contar eventos.
2. inicias la cuenta de una cuenta de tiempo.
3. cambias estados de pines.
4. detectas que una señal AC pasó por 0 y sincronizas el disparo de un triac.
5. actualizas un display multiplexado sea de 7 o de matriz de puntos.
6. puedes leer un sensor o variable analógica
y mucho mucho mas.

Qué no debes hacer :
1. usar delay() no importa el valor.
2. Usar Serial.print
3. Refrezcar una pantalla TFT, LCD OLED lo que fuere.
4. Llamar a rutinas que insuman un tiempo largo.
5. por ciclos que insuman tiempos largos.
6. leer un sensor I2C, SPI que demore mucho. Cuanto depende de su hoja de datos. Ejemplo: un ds18b20, un DHT22/11, un RTC, y 10mil mas

basicamente resguardar que todo lo que este en esa rutina insuma microsegundos. Todas las advertencias que señalé y otras que no me vienen ahora a la mente, superan mseg.

Go Up