Interrupts

Buongiorno!! Limitatamente alla routine di interrupt, penso che usi la porta RB4 per contare gli impulsi. A cosa serve RC4? Con il codice così com'è, siccome la porta sente i passaggi di livello, ma sia sul fronte di salita che di discesa, rischi che quando premi incrementa e quando rilasci decrementa. Perché non controlli solo quando RB4 è a 1? Più in generale, perché non fai uso delle nuove librerie che si semplificano la vita?

Ricontrollato datasheet, ok, INTCON2bits.INTEDG0 = 1 Abilita gli interrupts su rising edge, ma comunque, a che serve
if (INTCONbits.RBIF == 1)
if (PORTBbits.RB4 == 1 & PORTCbits.RC4 == 1) {
pulses--;

non avendo ancora riportato a 0 INTCONbits.RBIF, questa parte viene comunque eseguita ogni volta che si preme il pulsante

Nel caso RC4 serva a determinare se devo incrementare o decrementare, farei così:
__interrupt (high_priority) void ISR_alta (void) {
if (INTCONbits.RBIF == 1) {
if (PORTBbits.RB4 == 1 && PORTCbits.RC4 == 0) {
pulses++ ; }
else if (PORTBbits.RB4 == 1 && PORTCbits.RC4 == 1) {
pulses--;}
INTCONbits.RBIF = 0;
}
}

Buonasera Claudio,

grazie per l'intervento.

Si, il controllo di RC4 serve a determinare il senso di incremento.

Riguardavo il codice che ho postato e mi pare che l'azzeramento del flag l'ho fatto alla fine di entrambi gli if in moda da azzerarlo in entrambi i casi, il tuo codice è probabilmente più pulito.

Tuttavia il problema è un altro. Non funziona

Quando carico questo prog nel pic , il LCD non funziona correttamente. Pulsa come se venisse aggiornato frequentemente
e compaiono simboli "sconosciuti". Talvolta si cancella anche.

Non sembra essere un problema di connessioni del display perchè con altri prog funziona (anche se credo di aver fatto fuori qualche pixel ultimamente ..... ma questa è un'altra storia....

Direi che devo trovare , spero con il vostro aiuto, la soluzione al problema (mi riferisco al funzionamento degli interrupt) anche se , e forse dico castronerie, anche con l'uso degli interrupts non credo di poter contare in real-time.

Il concetto è che se (senza interrupts) l'implementazione del display produce , come ho misurato, un ritardo sul ciclo di 25ms ossia, se durante questi 25ms non posso acquisire gli impulsi , ovviamente li perdo. Dovrei fermare il processo di acquisizione (fermare il dispositivo) e permettere al display di aggiornarsi al valore della variabile ma la cosa mi sembra assai brutta.

Anche con gli interrupt però , probabilmente, avrei lo stesso problema. Mi spiego.

Se devo acquisire impulsi alla frequenza di 1Khz per 10 minuti per, ad esempio, controllare una posizione senza perderne neanche uno allora , non vedo dove il pic possa trovare il tempo per aggiornare il display.

1Khz = 1 impulso ogni ms , con il display che ne impegna 25......

Mi viene , dal fondo della mia inesperienza, solo in mente l'utilizzo di 2 pic comunicanti, del tipo che il primo conta e aggiorna una variabile x ed il secondo che gestisce il display. Il primo invia "continuamente" info al secondo che ad ogni ciclo si aggiorna.

Ho detto una fesseria ?

Mi stavo leggendo il protocollo I2C ma al momento non saprei come usarlo per questa specifica esigenza.

Guido