Comportamiento de la función del controlador de dispositivo en la interrupción

Supongamos que un sistema integrado ejecuta FreeRTOS y un programa de aplicación realiza llamadas a una interfaz de controlador de dispositivo (supongamos que es I2C). ¿Qué sucede exactamente cuando esto es interrumpido por una interrupción externa? Además, ¿qué sentido tiene implementar las funciones del conductor como tareas?

Respuestas (2)

¿Qué sucede exactamente cuando esto es interrumpido por una interrupción externa?

La forma en que se manejan las interrupciones depende del sistema. Pero un controlador es como cualquier otro código, detendrá la ejecución temporalmente a favor de la interrupción.

Además, ¿qué sentido tiene implementar las funciones del conductor como tareas?

Un controlador correctamente escrito consta de dos módulos: una capa de abstracción de hardware, que es lo que llama su aplicación, y el controlador real, que es específico del sistema y no portátil.

Idealmente, el controlador debería estar completamente libre de cosas específicas de la aplicación, por lo que no tiene sentido colocar un controlador en una tarea del sistema operativo. Un controlador es/debería ser de un nivel mucho más bajo que cosas como los sistemas operativos. Sin embargo, podría poner todo el código de la aplicación que se comunica con un determinado controlador en una tarea propia. Por ejemplo, un codificador/descodificador de protocolo.

Un controlador de dispositivo (para dispositivos como I2C) generalmente se divide en una interfaz de aplicación y una interfaz de hardware.

La interfaz de la aplicación generalmente solo coloca los datos que desea enviar al dispositivo en un búfer y notifica a la parte de la interfaz de hardware del controlador que hay datos para enviar y luego regresa a la persona que llama. Solicitar datos implicaría verificar si ya hay suficientes datos disponibles y esperar a que los datos estén disponibles o devolverlos de inmediato.

La sección de hardware de la interfaz tomaría datos en el búfer de escritura y los pasaría al hardware tan rápido como el hardware pueda aceptarlos; el hardware generalmente notifica al controlador mediante una interrupción para decir que ha recibido datos para procesar o puede aceptar más datos para transmitir.

Existe el requisito de que las secciones de hardware y aplicación no intenten modificar los búferes de almacenamiento compartido al mismo tiempo, y hay varias formas de lograrlo.

El uso de interrupciones es óptimo, porque el procesador solo tiene que trabajar en el mantenimiento del hardware cuando el hardware indica que está listo. Hacer lo mismo en las tareas implica un proceso conocido como 'sondeo' que básicamente pregunta al hardware si está listo. Puede pensar que esto es análogo a apagar el timbre de su teléfono y levantar el teléfono periódicamente para ver si alguien está llamando.

"Usar interrupciones es óptimo" Bueno, eso es una simplificación excesiva. Depende de su especificación y de cómo debe comportarse el programa. Si tiene un cirujano que aborta en un momento crítico en medio de la operación solo para levantar el teléfono celular que suena, está haciendo un trabajo mucho peor que el cirujano que apaga su teléfono y solo lo revisa después de que finaliza la operación. Las interrupciones asíncronas son, de hecho, muy problemáticas por muchas razones diferentes y, por lo tanto, generalmente se evitan en aplicaciones de misión crítica.