Reprise du message précédent :
J'ai tout retracé, je me suis acheté des yeux et un cerveau et cela va mieux

C'est un pointeur de fonction. Doit falloir a un endroit lui affecter l'adresse du callback.

Ah oui, j'avais zappé l'étoile. A voir, doit bien y avoir une doc pour tout ce bazar?

oui, je me suis farci la doc, c'est pas ouf les anciens pic16

Je pensais à la doc de ton IDE / générateur de code; pas à celle des PIC16. Mais oui, paraît que c'est "pas ouf" ces trucs...

C'est MPLAB, c'est pas ouf non plus

Ensuite, comme dit avant, au vu du prix, cela reste mieux qu'un paquet d'autre uC pour bien moins cher, pour des applications alacon.

Par exemple, un truc que je capte pas, il y a un registre pour la lecture des pins et un registre pour l'écriture. Mais :

En gros PORTC c'est pour lire l'état des pins et LATC c'est pour écrire l'état des pins. Si je change via PORTC, cela change sur LATC, mais l'inverse n'est pas vrai. Ce qui induit que tu peux avoir un état différent d'écriture et de lecture entre les 2 registres.

C'est quoi l'idée ?

Si t'es en collecteur ouvert style I2C ca te permet de lire si quelqu'un force un état different sur la broche.

J'ai pas bien compris

Tu connais le système collecteur ouvert?
 
Dans ce cas tu peux NE PAS tirer la broche vers la masse mais un autre composant branché sur la broche peut le faire. Tu auras donc une différence entre ce que tu as "programmé" dans ton registre PIC et la réalité.
 
Avec une sortie push-pull ce n'est pas possible ce genre de chose; ça donnerait un court-circuit.
 
mot clé: "wired-or"

Je vois l'idée, mais je vois pas le rapport avec leur système.

J'ai pas mis au dessus :

De ce que je comprends, c'est lors des changements input/output, il y a conservation des états jusqu'à modification d'un des deux.