Problema grave in interrupt

[posta10100]

Hai verificato che la procedura dell'interrupt sia conclusa prima che arrivi l'interrupt successivo?
Prova a disattivare l'interrupt all'inizio e a riattivarlo alla fine della <>_ISR, in questo modo sei sicuro di non avere interrupt sovrapposti con i relativi problemi.

[ivanpascolo]

Adesso ho fatto così e sbaglia ancora, all'ingresso ho disabilitato tutti gli interrupt, incremento la mia variabile e prima di uscire ricarica le variabili dell'interrupt e riabilito gli interrupt.

Codice: Seleziona tutto

void TMR0_ISR(void)
{
    INTCONbits.GIE = 0;
    sys_tick++;
    static volatile unsigned int CountCallBack = 0;

    // clear the TMR0 interrupt flag
    INTCONbits.TMR0IF = 0;

    TMR0 += timer0ReloadVal;

    // callback function - called every 1000th pass
    if (++CountCallBack >= TMR0_INTERRUPT_TICKER_FACTOR)
    {
        // ticker function call
        TMR0_CallBack();

        // reset ticker counter
        CountCallBack = 0;
    }

    // add your TMR0 interrupt custom code

    INTCONbits.GIE = 1;
    //LATAbits.LATA5 = ~ LATAbits.LATA5 ;                            // toggle FOUT = 500Hz
}

[ivanpascolo]

Se qualcuno vuole, potrei inviargli l'intero progetto (l'ho ridotto all'osso per comprenderlo meglio) dato che sbaglia anche in simulazione.Magari dopo continuiamo la discussione nel forum.

Ho anche verificato il listato in assembler e i RETURN li mette in automatico.

[WALTERmwp]

Prova a disattivare l'interrupt all'inizio e a riattivarlo alla fine della <>_ISR, in questo modo sei sicuro di non avere interrupt sovrapposti

... il GIE viene cancellato automaticamente quando insorge un interrupt, quindi credo non sia questo che in un modo o nell'altro falsi i risultati.

Forse potrei essermi perso qualcosa ma se l'anomalia che riscontri consiste "solo" nei valori incongruenti che ti restituisce il debug, escludendo altri comportamenti strani, continuando sulla falsa riga della mia precedente ipotesi, per quanto strana, ti suggerirei, piuttosto, di inserire l'istruzione per disabilitare il GIE e di riabilitare il GIE, rispettivamente, prima e dopo il punto (la istruzione) in corrispondenza del quale vuoi controllare i valori delle variabili.
E' solo una prova in più.

Saluti

[ivanpascolo]

Intendi così:

Codice: Seleziona tutto

#define _XTAL_FREQ 32000000                               //Used by the XC8 delay_ms(x) macro
#include "mcc_generated_files/mcc.h"
unsigned long sys_tick = 0, t0 = 0, t1 = 0;

void main(void)
{   
    SYSTEM_Initialize();   
    INTERRUPT_GlobalInterruptEnable();               
    INTERRUPT_PeripheralInterruptEnable();     
/**********************************************************
*               PROGRAMMA PRINCIPALE                     *
*********************************************************/   
    while (1){               
        t1 = sys_tick - t0;
        INTCONbits.GIE = 0;
        if ((t1) > 100) {
            if ((t1<100)||(t1>101)){               
                LATAbits.LATA5 = ~ LATAbits.LATA5 ;
            }
            else t0=sys_tick;
        }
        INTCONbits.GIE = 1;
    }
}

Ma non funziona, si ferma con questi valori:
sys_tick = 2816
t0 = 2727
t1 = 344

sys_tick è sempre multiplo di 256, in qualunque punto si fermi.

[WALTERmwp]

Da "qui" non è proprio semplice trovare una soluzione però se mi limito a considerare i valori che hai riportato noto che la differenza (sys_tick - t0) dovrebbe essere pari a:
Post [1] -> 20
Post [2] -> 59
Post [35] -> 89
... al contrario rispetto a quanto hai visualizzato.
Questa differenza è sempre inferiore a 101 e sys_tick è sempre maggiore di t0; quindi in coerenza con quanto ci si dovrebbe attendere.
Curioso il riscontro quale multiplo di [256], cosa che però nel Post [1] non vale.

Non sono per la "caccia" agli ectoplasmi ma io non so ancora dirti cosa non va.
Ho immaginato, per esempio, che la variabile t1, da te visualizzata nel debug, non sia quella utilizzata nella esecuzione della sottrazione; scriverai che non è possibile ma, è una delle cose che posso pensare.

Le variabili coinvolte sono generali, non sono sullo stack e sono tutte dello stesso tipo; non è che da qualche parte c'è un'altra t1 ?
Quando fai il debug, l'output come lo ottieni ?
Potresti inserire in un Post lo screenshot ?
Hai fatto una verifica dei valori delle tre variabili posizionando il breakpoint sulla istruzione che esegue la sottrazione ?
Le domande potrebbero apparire fuori luogo però vale quanto scritto nella prima riga.

Saluti

[ivanpascolo]

Ha ragione, al post1 sys_tick non è multiplo di 256 (su una ventina di numeri che mi sono trascritto è l'unico), spero di non aver sbagliato a trascriverlo.
Ho verificato (anche utilizzando la funzione find del MPLAB), t0 e t1 sono dichiarate solo nel main.c mentre sys_tick è dichiarato come "extern" anche nel timer0.c.
Per il debug ho messo un breakpoint sull'istruzione LATAbits.LATA5 = ~ LATAbits.LATA5.

Si seguito uno screenshot fatto e lo sto al breakèpoint, il tutto fatto con il simulatore.

[img]screenshot[/img]

[WALTERmwp]

Ha ragione, al post1 sys_tick non è multiplo di 256 (su una ventina di numeri che mi sono trascritto è l'unico), spero di non aver sbagliato a trascriverlo.

... a questo punto mi viene il dubbio che potesse essere 23040 e non 23048 ( ... forse hai ripetuto l'otto che invece è presente nell'altro valore).
Quindi, se anche gli altri osservati e non riportati nei Post(s) erano multipli è, con buona probabilità, fatto indicativo di qualche cosa che ancora "sfugge" all'intenzione.

Come ti avevo scritto, posiziona il breakpoint sulla linea [14], dove esegui la sottrazione.

il tutto fatto con il simulatore.

... ma non stavi provando sull'hardware ?

Saluti

[ivanpascolo]

Si, stavo provando con l' hardware ma poi Paolino mi ha consigliato di provare con il simulatore.
Se metto il breakpoint alla linea 14 il programma in pratica rimane sempre piantato ma proverò anche questo. Sulla scheda ho anche una seriale, proverò a leggere i valori di sys_tick, t0 e t1 mentre il programma gira.

[ivanpascolo]

In rete ho trovato questo, cercherò di capire se è l'origine dei miei problemi.