___ método qstnhdr ___ para manejar fuentes de interrupción GPIO concurrentes? ______ qstntxt ___

Tengo dos fuentes de interrupción GPIO que se ejecutan en dos subprocesos separados:

1. Pulsos GPIO siguiendo la línea de frecuencia (60 Hz)
botón
2. presionar

¿Cómo puedo usar estas dos interrupciones simultáneamente, considerando que mi controlador (ESP32) multiplexa todas las interrupciones del periférico GPI0 en una interrupción de la CPU?

Actualmente, el programa permite que solo uno de ellos funcione a la vez.

Gracias

    

______ answer370267 ___

Estoy escribiendo esto sin utilizar nunca un ESP32 (o cualquier otro núcleo dual) o FreeRTOS. Desde mi conocimiento de FreeRTOS (búsqueda muy rápida), implementas los controladores de interrupción por tu cuenta, pero tienes que llamar a algunas funciones del sistema operativo desde dentro.

Por lo tanto, independientemente de la GPIO en la que ocurra la interrupción, terminará en la misma función de interrupción, porque solo hay un vector de interrupción para GPIO.

Pero el ESP32 tiene algunos registros para decirle qué interrupciones están pendientes. Y tienes registros que te dicen qué interrupción está habilitada. La combinación de esos registros le permite decidir qué pines están causando una interrupción.

Por lo tanto, en función de esto, puede hacer diferentes cosas según el GPIO que haya provocado la interrupción.

Te voy a dar una idea, no una implementación, así que lo siguiente es pseudocódigo:

%pre%

De esta manera puede dividir la interrupción en múltiples funciones de ejecución. Prefiero la manera de usar las funciones, pero estoy programando en C ++ e intento evitar las variables globales.

    

______ answer370257 ___

Primero verifique si el firmware / SDK le permite dividir las interrupciones. Es posible que tengas que saltar algunos aros adicionales para poder hacerlo. Muchas veces, el SDK basado en arduino silenciará las opciones disponibles para que sea más fácil para los principiantes y unificar la experiencia en diferentes tableros. Y revise la especificación del microcontrolador para ver exactamente qué sucederá cuando entren las interrupciones mientras ya está manejando otra.

De lo contrario, puede comprobar qué provocó la interrupción dentro de la rutina de interrupción y luego establecer un indicador volátil para manejarlo en su bucle principal.

    

______ answer370293 ___

A menos que un dispositivo tenga un enganche por pin de eventos de interrupción, su mejor opción es probablemente rastrear el último estado reconocido de cada registro de puertos de E / S [en %code% , abajo], y luego hacer algo como:

%pre%

Si cualquier bit de interés se establece en %code% o %code% , el código debe borrar atómicamente el bit (tal vez al deshabilitar las interrupciones, usar la carga vinculada / almacenamiento condicional u otros medios) y manejar la condición apropiada. Tenga en cuenta que si el estado de un pin cambia y luego vuelve a cambiar antes de ser observado por el código anterior, la transición debería perderse.

Cada vez que el sistema vaya a estar inactivo en función de una interrupción de cambio de pin, debería borrar el indicador de interrupción de cambio de pin, luego verificar si el estado del puerto coincide con %code% , y solo irse a dormir si lo hace partido. De esa manera, si el pin del puerto cambia antes de leerlo, el código lo notará y, si cambia después de leerlo, el hardware lo notará. Algunas plataformas hacen que sea imposible evitar por completo las condiciones de carrera, pero las buenas plataformas garantizarán que los eventos que se producen entre el borrado de la bandera y la lectura del estado del puerto se activen por el hardware además de que se informen en el software. En consecuencia, incluso si un evento que ocurre precisamente cuando el puerto se está leyendo no aparece en la lectura, aún se registrará como una activación de hardware.

    

___

Estoy escribiendo esto sin utilizar nunca un ESP32 (o cualquier otro núcleo dual) o FreeRTOS. Desde mi conocimiento de FreeRTOS (búsqueda muy rápida), implementas los controladores de interrupción por tu cuenta, pero tienes que llamar a algunas funciones del sistema operativo desde dentro.

Por lo tanto, independientemente de la GPIO en la que ocurra la interrupción, terminará en la misma función de interrupción, porque solo hay un vector de interrupción para GPIO.

Pero el ESP32 tiene algunos registros para decirle qué interrupciones están pendientes. Y tienes registros que te dicen qué interrupción está habilitada. La combinación de esos registros le permite decidir qué pines están causando una interrupción.

Por lo tanto, en función de esto, puede hacer diferentes cosas según el GPIO que haya provocado la interrupción.

Te voy a dar una idea, no una implementación, así que lo siguiente es pseudocódigo:

if ((GPIO_InterruptPendingRegister & GPIO_InterruptEnabledRegister) == GPIO_0_Interrupt)
{
    executeGPIO_0_Function();
    // or
    volatile GPIO_0_Flag = true;
    // depends on how the peripheral handles this, usually needed
    Reset_GPIO_0_PendingFlag();
}
if ((GPIO_InterruptPendingRegister & GPIO_InterruptEnabledRegister) == GPIO_1_Interrupt)
{
    executeGPIO_1_Function();
    // or
    volatile GPIO_1_Flag = true;
    // depends on how the peripheral handles this, usually needed
    Reset_GPIO_1_PendingFlag();
}
etc.

De esta manera puede dividir la interrupción en múltiples funciones de ejecución. Prefiero la manera de usar las funciones, pero estoy programando en C ++ e intento evitar las variables globales.

Primero verifique si el firmware / SDK le permite dividir las interrupciones. Es posible que tengas que saltar algunos aros adicionales para poder hacerlo. Muchas veces, el SDK basado en arduino silenciará las opciones disponibles para que sea más fácil para los principiantes y unificar la experiencia en diferentes tableros. Y revise la especificación del microcontrolador para ver exactamente qué sucederá cuando entren las interrupciones mientras ya está manejando otra.

De lo contrario, puede comprobar qué provocó la interrupción dentro de la rutina de interrupción y luego establecer un indicador volátil para manejarlo en su bucle principal.

A menos que un dispositivo tenga un enganche por pin de eventos de interrupción, su mejor opción es probablemente rastrear el último estado reconocido de cada registro de puertos de E / S [en latched_port , abajo], y luego hacer algo como:

// Assume interrupts are disabled in this section
uint32_t port_now = GPIOREG->inputs;
uint32_t port_prev = latched_port;
latched_rising_edges |= port_now & ~port_prev;
latched_falling_edges |= ~port_now & port_prev;
latched_port = port_prev;

Si cualquier bit de interés se establece en latched_rising_edges o latched_falling_edges , el código debe borrar atómicamente el bit (tal vez al deshabilitar las interrupciones, usar la carga vinculada / almacenamiento condicional u otros medios) y manejar la condición apropiada. Tenga en cuenta que si el estado de un pin cambia y luego vuelve a cambiar antes de ser observado por el código anterior, la transición debería perderse.

Cada vez que el sistema vaya a estar inactivo en función de una interrupción de cambio de pin, debería borrar el indicador de interrupción de cambio de pin, luego verificar si el estado del puerto coincide con latched_port , y solo irse a dormir si lo hace partido. De esa manera, si el pin del puerto cambia antes de leerlo, el código lo notará y, si cambia después de leerlo, el hardware lo notará. Algunas plataformas hacen que sea imposible evitar por completo las condiciones de carrera, pero las buenas plataformas garantizarán que los eventos que se producen entre el borrado de la bandera y la lectura del estado del puerto se activen por el hardware además de que se informen en el software. En consecuencia, incluso si un evento que ocurre precisamente cuando el puerto se está leyendo no aparece en la lectura, aún se registrará como una activación de hardware.