Interrupción de software vs función


10

Después de aproximadamente 3 años de trabajar con MCU, todavía no sé cuál es el uso de las interrupciones de software. He realizado varios trabajos con STM32 y nunca he usado las interrupciones de software. De hecho, esta es una gran pregunta para mí:

¿Por qué cuando podemos usar una función simple para hacer una tarea, debemos usar una interrupción de software? ¿Cuáles son las diferencias entre una interrupción de software y una función?

Cada vez que lo desee, puede llamar a una función (que ha escrito para su trabajo). Debería haber algunos beneficios al usar una interrupción de software en lugar de una función simple. No estoy seguro, pero creo que hay un beneficio para las interrupciones de software: puede asignar una prioridad para una interrupción de software, luego puede darle una mayor prioridad a la interrupción de software para evitar que la interrupción de hardware interrumpa su tarea.


1
Creo que el propósito principal para usar las interrupciones es que puedes seguir haciendo otras tareas importantes mientras esperas a que suceda algo más, y cuando los tiempos no siempre serán constantes. También creo que es un poco más rápido que el sondeo en la mayoría de los casos.
MrPhooky

1
@MrPhooky De eso estás hablando de interrupciones de hardware. El OP está hablando de interrupciones de software.
Brhans

Respuestas:


19

La principal diferencia entre una función y una interrupción de software es lo que se conoce como contexto .

  • Una función se ejecuta dentro del contexto de su programa principal.
  • Se ejecuta una interrupción dentro del contexto del manejador de interrupciones.

En un sistema simple, esto puede no ser una diferencia real, y las interrupciones de software simplemente se pueden usar como una forma conveniente de proporcionar rutinas de biblioteca codificadas en ROM: no necesita saber la dirección de cada rutina, solo el código de identificación y Punto de entrada principal. Esto hace que su código sea más portátil.

Sin embargo, en sistemas más complejos, la interrupción del software puede ejecutarse en un entorno completamente diferente, conocido como el contexto del núcleo . Normalmente, su aplicación se ejecutaría en un contexto de usuario protegido que tiene acceso limitado a los recursos. Solo cuando se ejecuta en el contexto del núcleo puede realizar las tareas más complicadas; de hecho, algunos sistemas incluso limitan las instrucciones que se pueden ejecutar, por lo que necesita un mecanismo para activar el código en el contexto del núcleo, y para eso se utiliza una interrupción.


1
Además, las interrupciones pueden detener arbitrariamente el progreso de un programa para que el sistema pueda hacer algo más (por ejemplo, interrupciones de hardware). Sus programas no necesitan tener esto en cuenta porque, desde el punto de vista de su programa, el estado de la función no cambia desde el momento en que ocurrió la interrupción. En sistemas más antiguos, así es como los programas TSR (Terminar / Permanecer Residente) simulan la multitarea, desconectando la interrupción del temporizador / reloj. Incluso sin los niveles de IOPL, hubo un beneficio para, por ejemplo, mantener actualizado el reloj del sistema.
phyrfox

44
Quizás también tenga en cuenta que esas "interrupciones de software" también se conocen como "interrupciones síncronas", porque el código de la aplicación sabe exactamente cuándo y por qué ocurre dicha interrupción, en oposición a las "interrupciones asincrónicas" que pueden, desde el punto de vista del aplicación, básicamente sucede en cualquier momento de una manera no solicitada.
JimmyB

@HannoBinder: Creo que el OP está hablando de publicar solicitudes de interrupción en el controlador de interrupción vectorial Cortex-M3; si el código para una interrupción de alta prioridad publica una de menor prioridad, la solicitud se aplazará hasta un momento posterior cuando finalicen todas las interrupciones de mayor prioridad.
supercat

12

Las interrupciones de software se pueden utilizar para finalizar una tarea de interrupción con una prioridad inferior. El código crítico de temporización a menudo recibe una alta prioridad de interrupción para evitar demasiada latencia. Una vez que finaliza la parte crítica de temporización, puede haber tareas adicionales que pueden ser demasiado críticas para el bucle principal, pero que no son tan críticas como para detener otras interrupciones de alta prioridad. Activar una interrupción de software de menor prioridad puede lograr esto.

Por ejemplo, suponga que tiene varios motores paso a paso, cada uno con su propio temporizador. Las interrupciones del temporizador tienen alta prioridad para minimizar la fluctuación de fase. La tarea más crítica de tiempo puede ser tan simple como configurar o borrar un pulso de paso o avanzar las salidas de fase. Es posible que se requiera una funcionalidad adicional, como el cálculo de las rampas de aceleración, el procesamiento del sensor, etc. Dado que esto debe procesarse en cada paso, puede que no sea apropiado procesar esto desde main () ya que la sincronización del bucle principal puede ser demasiado larga. Estas tareas adicionales pueden procesarse mediante una interrupción de software de menor prioridad para no aumentar la latencia de los otros canales paso a paso de alta prioridad.

¿Cuál es la diferencia entre una interrupción de software y una función?

Una función se llama inmediatamente desde donde se llame y no cambia el nivel de prioridad de interrupción actual si se llama desde una interrupción. Una interrupción de software es un disparador de interrupción que hará que se llame a esa interrupción cuando surja la prioridad. Si se insertara una llamada de función al final de una interrupción de alta prioridad, la función estaría contenida dentro de esa alta prioridad. Al activar la interrupción de software de menor prioridad y luego regresar de la interrupción de alta prioridad, se llama a la funcionalidad a la nueva prioridad (menor).


2
Otro patrón común puede ser tener una interrupción de 100KHz para manejar cosas críticas de tiempo, y también necesita un tic de temporizador de 1kHz, pero no tener dos temporizadores separados disponibles. Para que una rutina de interrupción de if ((timer_count--) & 0x80000000) SET_TICK_INTERRUPT_FLAG(); else timer_count = temp-1; 100 kHz tome mucho tiempo, la otra interrupción puede hacer lo suyo y con las interrupciones brevemente desactivadas, agregue 100 a timer_count; incluso si la rutina de 1kHz toma más de 10us para ejecutarse, no interferirá con la de 100kHz.
supercat

De manera similar, he usado interrupciones de software en sistemas simples (sin un RTOS completo) como pseudo-planificador, donde los requisitos de hardware son manejados por los ISR, pero las funciones de devolución de llamada y otras tareas largas que se realizan en respuesta a cambios en El estado del hardware se delega a la interrupción del software.
Evil Dog Pie

Básicamente has descrito una variación de la "mitad inferior". ¿Tiene alguna referencia para que esto también se denomine "interrupción de software"? Es un significado bastante diferente de la respuesta de Majenko, y la pregunta está etiquetada como ARM: la arquitectura en realidad tiene la instrucción SWI (interrupción de software).
domen

3
@domen No estoy seguro de qué tipo de referencia necesitas. Se denomina "interrupción de software" porque eso es lo que se utiliza para lograrlo. En el contexto de ARM, el OP hizo referencia específica al STM32 y proporcionó un enlace al manual de referencia RM0008. Este no es un manual de referencia central de ARM. La única "interrupción de software" cubierta en RM0008 es el EXTI_SWIER (registro de eventos de interrupción de software) que puede usarse para generar interrupciones de software, ya sea que los pines de hardware reales se usen o no para las interrupciones. No he usado personalmente la instrucción SWI (SWC).
Tut

¡Gracias! Puede ser bueno incluir parte de esta información en la respuesta, para dejar en claro qué "interrupción de software" es.
domen

7

Para ampliar un poco la respuesta de Majenko, las interrupciones de software se utilizan para implementar sistemas operativos, particularmente la interfaz de llamada del sistema. Esto significa que las aplicaciones no necesitan estar vinculadas con el sistema operativo para realizar llamadas a funciones, y el cambio de contexto permite que el sistema operativo limite el acceso al hardware y aproveche cosas como la memoria protegida.

Si no está utilizando un sistema operativo y controla todo el código en la MCU, probablemente no necesite usar interrupciones de software. (Aunque, como mencionó Tut, pueden tener otros usos).

Las interfaces de llamada del sistema Linux y MS-DOS en x86 usan interrupciones de software, por lo que los enlazaré como ejemplo.


1
Y en muchos casos donde el sistema operativo usa interrupciones suaves, se envuelven en funciones para simplificar la vida.
hildred

1
Todavía programo cosas (también nuevas) para DOS, y estoy muy familiarizado con los controladores int 21. Casi todo lo que necesito en cuanto a E / S se maneja con el ISR de DOS.
R Drast

Tenga en cuenta que la página citada para Linux es de 1993-1996.
un CVn

Reemplacé el enlace por uno más actualizado.
Adam Haun
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.