È davvero necessario cancellare manualmente il flag di interruzione di overflow del timer XMEGA?

Come alcuni di voi sanno, Atmel fornisce un framework software (principalmente come parte di Atmel Studio) che fornisce driver ed esempi e viene aggiornato su una base più o meno regolare.

In un recente aggiornamento sottolineano esplicitamente che è importante cancellare manualmente il flag di interrupt di overflow nella funzione di callback di interrupt.

 // * \subsection xmega_tc_qs_ovf_setup_code Example code
 // *
 // * Add a callback function that will be executed when the overflow interrupt
 // * trigger.
 // * \code
 static void my_callback(void)
 {
    // User code to execute when the overflow occurs here

    // THIS WAS ADDED IN LAST UPDATE
    // Important to clear Interrupt Flag
    tc_clear_overflow(&TCC0);
    // THIS WAS ADDED IN LAST UPDATE

 }
 //\endcode

Secondo la scheda tecnica XMEGAA:

OVFIF viene automaticamente cancellato quando viene eseguito il vettore di interrupt corrispondente. La bandiera può anche essere cancellata scrivendone una nella sua posizione di bit.

Esiste uno scenario / motivo in cui potrebbe essere necessario cancellare manualmente il flag?

c atmel-studio xmega

— Rev1.0
fonte

sembra che la risposta sia se non si interrompe quindi è necessario cancellarlo manualmente. essenzialmente se / durante il polling invece di usare gli interrupt. puoi semplicemente leggere il registro nell'interrupt e in qualche modo visualizzarlo per vedere se era davvero impostato. allo stesso modo prova il polling senza l'interrupt abilitato e vedi se viene impostato e se riesci a cancellarlo. convalidare la documentazione è o non è corretta.

— old_timer,

Non sarebbe il primo caso che ho visto nei prodotti Atmel in cui un interrupt "cancellato automaticamente" sembra non essere effettivamente cancellato quando il gestore spara.

— Connor Wolf,

@ConnorWolf: Davvero? Ricordi quale controller e interrompi? Lavoriamo molto silenziosamente con i controller Atmel e questo potrebbe essere un potenziale trabocchetto.

— Rev.1.0

@ Rev1.0 - Un esempio con cui sto lavorando in questo momento: SAM4SD32C- Gli interrupt del timer ( TC0_Handler, ecc ...) non vengono cancellati quando si entra nell'ISR se non ho letto esplicitamente TC0->TC_SR. Scavando più a fondo, in questo caso, è perché l'interrupt viene attivato dal RCbit di corrispondenza del registro di confronto e ciò non viene cancellato fino a quando non si legge esplicitamente TC_SR. IOW, non sono corretto sulla causa reale (non era direttamente il bit ISR), ma il risultato finale è lo stesso: devi cancellare manualmente la causa ISR , se non il flag ISR .

— Connor Wolf,

Forse c'è un'errata?

— Vicatcu,

Esiste uno scenario / motivo in cui potrebbe essere necessario cancellare manualmente il flag?

Non sono sicuro dell'ASF, ma ci sono casi in cui è necessario annullare qualsiasi interruzione in sospeso. Ad esempio, quando (ri) configura un timer, potresti voler disabilitare gli interrupt, modificare il timer e annullare qualsiasi interruzione del timer che potrebbe essersi verificata nel frattempo, prima di riattivare gli interrupt.

Se non si dispone nemmeno di un ISR di overflow, è comunque possibile eseguire il polling di OVIF per rilevare l'overflow e reimpostare il flag per armarlo per l'overflow successivo.

— JimmyB
fonte

In generale, deseleziono sempre i flag di interrupt appena prima di abilitare un determinato interrupt, nel caso in cui qualcosa abbia impostato il flag in passato. Sembra un'assicurazione economica.

Non sono a conoscenza di alcuno scenario in cui è necessario cancellare manualmente la bandiera a meno che non si utilizzino gli interrupt e si sta osservando la bandiera con una routine che viene eseguita periodicamente per verificare la bandiera impostata.

— user103218
fonte