¿Cómo detectar qué temporizador se interconecta llamado callback cuando se usa ASF?

Navega tus respuestas
1

Tengo una función general, que se pasa, entre otros, un temporizador. Inicializa el temporizador utilizando la función de devolución de llamada común: 

void setup(config_t* config) {
    ...
    tc_enable(config.timer);
    tc_set_overflow_interrupt_callback(config.timer, common_callback);
    ...
}

Esa función se puede llamar varias veces con diferentes configuraciones, incluidos los temporizadores. En la devolución de llamada de interrupción, me gustaría identificar de alguna manera qué temporizador causó la devolución de llamada. 

void common_callback() {
    // Which timer called?
}

No encontré una función asf tc_ que me diera algún tipo de identificación.

  • Intenté ver TCXX.INTFLAGS , pero las marcas de desbordamiento parecen restablecerse con el código asf.
  • Un enfoque intrépido que podría encontrar es comparar el registro de conteo

¿Existe una forma sencilla de hacerlo utilizando el marco de software Atmel? Asumo que asf tiene un controlador de interrupción interno que hace algo como restablecer los indicadores de interrupción antes de llamar al callback definido por el usuario. Otro enfoque sería escribir tc_set_overflow_interrupt_callback -function que mantendría parte de esa información.

    
pregunta varesa

1 respuesta

1

Atmel Studio Framework no borra ninguna de las banderas y el código subyacente es bastante sencillo en esa área. Las rutinas de devolución de llamada se configuran de la siguiente manera: 

void tc_set_overflow_interrupt_callback(volatile void *tc,
        tc_callback_t callback)
{
#ifdef TCC0
    if ((uintptr_t) tc == (uintptr_t) & TCC0) {
        tc_tcc0_ovf_callback = callback;
    } else
#endif
#ifdef TCC1
    if ((uintptr_t) tc == (uintptr_t) & TCC1) {
        tc_tcc1_ovf_callback = callback;
    } else
#endif
... etc for other timers

Y el código de interrupción real es: 

ISR(TCC0_OVF_vect)
{
    if (tc_tcc0_ovf_callback) {
        tc_tcc0_ovf_callback();
    }
}
... etc for other timers

El XMEGA es un poco diferente a algunos procesadores en que algunos de los indicadores se borran antes de que se llame al código de interrupción en lugar de regresar. Por ejemplo, la siguiente es la descripción de la bandera OVFIF :

  

Este indicador se establece en una condición TOP (desbordamiento) o BOTTOM (subdesbordamiento), dependiendo de la configuración de WGMODE. OVFIF se borra automáticamente cuando se ejecuta el vector de interrupción correspondiente. La bandera también se puede borrar escribiendo un uno en su ubicación de bit.

Una implicación de usar ASF es que las directivas #ifdef anteriores causan que todos los vectores de interrupción aplicables a un dispositivo se incluyan una vez que incluya el controlador de temporizador / contador en el proyecto.

Pero volviendo a su pregunta original, ya que ha encontrado que esas banderas se borran antes de llamar a la rutina de interrupción. Después de volver a revisar la documentación y echar un vistazo a los distintos indicadores de temporizador / interrupción antes y después de una interrupción en un depurador, no veo ninguna manera de lograr exactamente lo que está buscando. Es posible que deba atenerse a una devolución de llamada separada para cada temporizador que llame al controlador principal con un parámetro. Al menos, la sobrecarga de código no debería ser demasiado grande porque todos los vectores ya están incluidos.

    
respondido por el PeterJ

Lea otras preguntas en las etiquetas

Viendo la lista de redes en ltspice nativo para mac Problema de cálculo del circuito eléctrico simple