He usado la interrupción del temporizador en mi aplicación, principalmente por razones de tiempo como detección de tiempo de espera para procesos, generación de pulsos, etc., cada 1 ms. Ahora tengo una duda.
Supongamos que en main(), si estoy haciendo otra operación, tal vez escribiendo en un SPI Flash una gran cantidad de datos, y se produce la interrupción del temporizador, ¿se detendrá el proceso de escritura de datos debido a la interrupción del temporizador ISR o los datos se corromperán debido a la interrupción? por temporizador ISR? Me pregunto si el tiempo de interrupción del temporizador se decide teniendo en cuenta las operaciones que componen el código de aplicación completo.
Si es así, si una escritura SPI flash tarda aproximadamente 5 ms y la interrupción del temporizador ocurre cada 1 ms, ¿cómo puedo realizar un seguimiento de los tiempos de espera, las generaciones de pulsos, etc. sin comprometer los escenarios de corrupción de datos, porque ahora tendré que cambiar la interrupción del temporizador a más de 5 ms? , y luego no puedo mantener una referencia de tiempos de espera para procesos donde pueden ser necesarios pequeños tiempos de espera como 1 ms.
Actualizar
Estoy usando un temporizador de hardware, y cuando ocurre la interrupción, usaré un contador de temporizador de software (variable) en el ISR, para realizar un seguimiento del tiempo.
Si escribe el código de la línea principal donde se realizan las escrituras SPI Flash de la manera adecuada, la ocurrencia de la interrupción del temporizador no debería dañar la operación en curso. Si la operación de flujo principal tiene ciertas dependencias de tiempo que deben mantenerse, entonces es necesario deshabilitar las interrupciones por períodos cortos de tiempo cuando ocurren las ventanas de tiempo críticas.
Otra cosa es mantener el código en la interrupción del temporizador muy simple y conciso. No coloque ningún código de decisión real en la rutina del temporizador. En su lugar, hágase una colección de variables de temporizador administradas por software. La interrupción del temporizador simplemente verifica cada una de estas variables y, si no es cero, simplemente disminuiría el valor en uno. El código principal establecería una o más de estas variables en valores adecuados distintos de cero cuando se necesita un período de tiempo. Luego, en el curso normal de sus operaciones de línea principal, la variable del temporizador se puede verificar para ver si se ha ido a cero. Por lo tanto, esto puede indicar que se ha producido un tiempo de espera o un retraso de tiempo.
escribiendo en una SPI Flash una gran cantidad de datos y se produce la interrupción del temporizador, ¿se detendrá el proceso de escritura de datos debido a la interrupción del temporizador ISR o los datos se corromperán debido a la interrupción del temporizador ISR?
De ninguna manera (pero verifique la hoja de datos de su flash para estar seguro). SPI flash no tiene tiempos de espera, solo límites inferiores en los tiempos. Tienes todo el tiempo del mundo para terminar una escritura o cualquier otra operación. No debería ocurrir ninguna corrupción de datos mientras no toque los registros SPI desde dentro de su ISR (para principiantes, más tarde haría algunos bloqueos).
si el tiempo de interrupción del temporizador se decide teniendo en cuenta las operaciones que componen el código de aplicación completo?
Por supuesto, siempre debe tener en cuenta el tiempo posiblemente invertido en algún controlador de interrupción. Si tiene que hacer alguna tarea realmente crítica en cuanto al tiempo, puede deshabilitar las interrupciones por un corto tiempo, simplemente haga lo siguiente
La suma del tiempo máximo invertido en los controladores de interrupciones y en cualquier sección crítica (donde las interrupciones están deshabilitadas) no debe exceder el tiempo entre interrupciones consecutivas del mismo tipo.
De esa manera, aún tendrá un cronometraje preciso y no perderá ninguna interrupción. La mayoría (si no todos) los controladores de interrupción son lo suficientemente inteligentes como para retener una solicitud de interrupción hasta que la CPU pueda procesarla, pero no realizarán un seguimiento de cuántas solicitudes del mismo tipo han ocurrido sin servicio.
Además de lo que dijo @berendi, puedes hacer dos cosas.
1) Deshabilite las interrupciones, justo antes de realizar la transferencia de datos críticos. Y use el sondeo en su lugar. Suponiendo que está transfiriendo datos desde un búfer, envíe unos 10 (use cualquier número arbitrario aquí) marcos de datos y sondee el pin de interrupción. Incluso si la interrupción está deshabilitada, el indicador se establecerá, por lo que puede aproximar* el evento sin tener que pausar la transferencia de datos.
2) Mantener la interrupción habilitada. Tiene muy pocas instrucciones dentro del ISR. Un controlador de alta velocidad podrá acomodar procesos muy pequeños entre la transferencia de datos**. Dado que el periférico SPI tomará la carga una vez que descargue los datos en el búfer, el procesador tendrá poco tiempo en el medio. Puede acomodar eventos bien calculados. Considere la latencia de entrada y salida de la interrupción y el tiempo de procesamiento de las instrucciones.
Alternativamente , SI el controlador es compatible con DMA, su inquietud puede abordarse fácilmente.
*suponiendo que lo haga con la frecuencia suficiente para detectar dos eventos.
** durante las transferencias de datos críticos, se recomienda deshabilitar y habilitar las interrupciones.
AlfaGoku
miguel karas
AlfaGoku