Interrupción de software vs función

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 hecho varios trabajos con STM32 y nunca he usado las interrupciones del software. De hecho, esta es una gran pregunta para mí:

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

Cada vez que quieras, puedes llamar a una función (que hayas escrito para tu 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 prioridad más alta a la interrupción de software para evitar que la interrupción de hardware interrumpa su tarea.

Creo que el propósito principal de usar interrupciones es que puedes seguir haciendo otras tareas importantes mientras esperas que suceda algo más, y cuando los tiempos no siempre van a ser constantes. También creo que es un poco más rápido que sondear en la mayoría de los casos.
@MrPhooky Esas son las interrupciones de hardware de las que estás hablando. El OP está hablando de interrupciones de software.

Respuestas (3)

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.
  • Una interrupción se ejecuta dentro del contexto del controlador de interrupciones.

En un sistema simple, esto puede no ser una diferencia real, y las interrupciones de software pueden usarse simplemente 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 el 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 contexto del kernel . 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 kernel 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 kernel, y para eso se usa una interrupción.

Además, las interrupciones pueden detener arbitrariamente el progreso de un programa para que el sistema pueda hacer otra cosa (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 que ocurrió la interrupción. En los sistemas más antiguos, así es como los programas TSR (Terminate/Stay Resident) simulaban la multitarea, conectando la interrupción del temporizador/reloj. Incluso sin los niveles de IOPL, había un beneficio en, por ejemplo, mantener actualizado el reloj del sistema.
Tal vez también tenga en cuenta que esas "interrupciones de software" también se denominan "interrupciones síncronas", porque el código de la aplicación sabe exactamente cuándo y por qué ocurre tal interrupción, a diferencia de las "interrupciones asíncronas" que pueden, desde el punto de vista de la aplicación, básicamente suceden en cualquier momento de manera no solicitada.
@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 todas las interrupciones de mayor prioridad hayan terminado.

Las interrupciones de software se pueden usar para finalizar una tarea de interrupción con una prioridad más baja. El código crítico de sincronización a menudo recibe una alta prioridad de interrupción para evitar demasiada latencia. Una vez que finaliza la parte crítica del tiempo, puede haber tareas adicionales que pueden ser demasiado críticas para el ciclo principal, pero que no son tan críticas como para retrasar 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 una prioridad alta para minimizar la fluctuación de pasos. La tarea más crítica de temporización 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 de sensores, etc. Dado que esto debe procesarse en cada paso, puede que no sea apropiado procesarlo desde main() ya que la sincronización del bucle principal puede ser demasiado larga. Estas tareas adicionales pueden ser procesadas por 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 llama 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 su 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 prioridad alta. 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 con la nueva prioridad (inferior).

Otro patrón común puede ser tener una interrupción de 100 KHz para manejar cosas de tiempo crítico, y también necesitar un tic del temporizador de 1 kHz, pero no tener dos temporizadores separados disponibles. No se necesita mucho tiempo para que una rutina de interrupción de 100 kHz diga que if ((timer_count--) & 0x80000000) SET_TICK_INTERRUPT_FLAG(); else timer_count = temp-1;la otra interrupción puede hacer lo suyo y con las interrupciones deshabilitadas brevemente agregue 100 a timer_count; incluso si la rutina de 1kHz tarda más de 10us en ejecutarse, no interferirá con la de 100kHz.
De manera similar, he usado interrupciones de software en sistemas simples (sin un RTOS completo) como un pseudoprogramador, donde los ISR manejan los requisitos de hardware, 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.
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"? Tiene 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 No estoy seguro de qué tipo de referencia necesita. Se denomina "interrupción de software" porque eso es lo que se usa 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 básico de ARM. La única "interrupción de software" cubierta en RM0008 es EXTI_SWIER (registro de eventos de interrupción de software) que se puede usar para generar interrupciones de software, ya sea que los pines de hardware reales se usen o no para las interrupciones. Personalmente no he usado la instrucción SWI (SWC).
¡Gracias! Podría ser bueno incluir parte de esta información en la respuesta, para dejar en claro qué "interrupción de software" es.

Para ampliar un poco la respuesta de Majenko, las interrupciones de software se utilizan para implementar sistemas operativos, particularmente la interfaz de llamada al 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á usando 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 al sistema Linux y MS-DOS en x86 usan interrupciones de software, por lo que las vincularé como ejemplo.

Y en muchos casos en los que el sistema operativo usa interrupciones suaves, están envueltas en funciones para simplificar la vida.
Todavía programo cosas (nuevas también) para DOS, y estoy muy familiarizado con los controladores int 21. Casi todo lo que necesito en cuanto a E/S se maneja con DOS ISR.
Tenga en cuenta que la página citada para Linux es de 1993-1996.
Reemplacé el enlace con uno más actualizado.
Interrupción de software vs función
RespuestasAquíPolítica de privacidad1y, 0v