Gioie e dolori degli interrupt

Ho trovato la risposta dopo qualche impazzimento: manuale PIC18F2550 e company sotto il paragrafo dedicato al PORTB Interrupt onchange che recita così:
L'utente nella ISR puo cancellare il flag RBIF in questo modo-->Qualsiasi lettura o scrittura del PORTB ad eccezione dell'istruzione MOVFF (ANY); questo rende la condizione del PORTB sconosciuta e quindi sarà impossibile pulire detto flag.
Una condizione sconosciuta mantiene detto flag attivo e la lettura del PORTB consente di settarlo a 0.
Detto ciò mi rispondo da solo anche se non concordo con sta roba:
per poter utilizzare la funzione Interrupt on change del PORTB occorre prestare attenzione al modo in cui vengono scritte le istruzioni in modo particolare occorre, per poter pulire il flag RBIF, effettuare un'operazione R o W sul PORTB tipo:
int ValPB;
ValPB = PORTB;
INTCONbits.RBIF=0;
ed il gioco è fatto!
Del resto essendo un Interrupt on change quindi H>L o L>H, credo che casa microchip abbia ben pensato la cosa in modo che l'utente sia sicuro di aver letto in PORTB prima della cancellazione del flag.

Effettivamente quello che hai trovato è la soluzione.

Molti non vedono il problema quando fai uso di più pin, visto che sei obbligato a leggere la PORTB per vedere chi ha generato l'interrupt.

La ragione sta nel fatto che l'interrupt on change fa uso di un registro per confrontare il suo valore con PORTB.
Questo registro viene aggiornato solo con la lettura della PORTB.
Per cui se non lo aggiorni trova sempre la differenza...
Quindi viene generato un nuovo interrupt.

Questa problematica è vera anche per altri microcontrollori che hanno interrupt on change sui pin e un interrupt vector unico per eventi multipli (più pins).

Saluti,

Mauro