interrupt on change su fotocellule che non cancella RBIF e TEMPO DI RIPRESA

in definitiva:
una volta nell'interrupt di RBIF:

1) leggo RB6 ed RB7 e li metto in due variabili
2) cancello RBIF
3)...eseguo le varie parti della funzione da me scritta
4) leggo nuovamente RB6 ed RB7 e li rimetto nelle variabili

attualmente invece

1) leggo RB6 ed RB7 e li metto in due variabili
2)...eseguo le varie parti della funzione da me scritta
3) leggo nuovamente RB6 ed RB7 e li rimetto nelle variabili
4) cancello RBIF

Il problema che maggiornmente mi preoccupa è che se blocco le fotocellule al valore alto e le lascio così, RBIF resta sempre alto a prescindere di quante volte io legga RB6 ed RB7 e li trovi uguali

PRIMO PROBLEMA RISOLTO, in realtà la procedura di leggere prima i due ingressi, creare un delay e poi cancellare RBIF funzionava, ma dato che il fotoaccoppiatore che stava tra le fotocellule e gli ingressi al pic si era compromesso, non riusciva a mantenere stabile la chiusura verso massa e per questo entrava e usciva dall'interrupt.

SECONDO PROBLEMA (LATENZA POST INTERRUPT) sto notando che, se si attiva l'interrupt di RBIF, pur cancellando il bit e uscendo dalla routine di interrupt (ho messo due led sia per vedere quando entra ed esce dalla parte relativa all'interrupt sugli ingressi RBx sia quando entra ed esce in generale dalla funzione ISR) il sistema impiega circa 3 secondi prima di riprendersi e continuare quanto stava facendo.

Ho cercato ovunque nel firmware ma non ci sono nè while(..) nè timer che si attivano quando c'è questo interrupt. Sembra proprio che quando avviene questo tipo di interrupt il pic impiega semplicemente molti cicli per riprendersi....certo che 3 secondi sono tanti!

Secondo voi è una cosa possibile?

SOLUZIONE AL PROBLEMA DELLA LATENZA POST INTERRUPT:

il problema della eccessiva latenza dopo un interrupt sui pin RB era dovuta al fatto che si verificavano durante un delay_ms .
E' bastato inserire un timer per creare quei ritardi ed il problema si è risolto

Grazie della soluzione.

Vorrei tirare fuori anche una "morale" dall'esperienza di Debug.

Quando un sistema complesso non funziona, non bisogna cercare il problema solo in un punto ma a livello di sistema.
In particolare in un sistema embedded con hardware esterno bisogna cercare problemi anche li. La compatibilità tra i livelli logici tra I/O possono essere un problema tipico.

Nel caso in cui l'ISR è lenta, bisogna sospettare funzioni bloccanti. La funzione delay è tipicamente bloccante e deve essere evitata all'interno di ISR. Funzioni grafiche o aggiornamenti di dispay LCD devono essere in generale evitati.

...ottimo,

Saluti,

Mauro