Godzil: L'I2C utilise deux fils

.
Quel beau résumé! C'est exactement ça. Sauf que ça nécessite une participation constante des deux périphériques concernés. C'est bien pour gérer les time-out, mais ça fait chier pour les expérimentations. En plus ça ne respecte aucun standard électronique connu.
Par contre question débit, je vais mettre tout le monde d'accord.
J'ai fait un programme de test de vitesse en TIGCC qui utilise la lib I2C de Hiddenfiles.
Sans rien toucher au code, l'émission se fait à 37 kbps et la réception à 48 kbps. Après des optimisations sévères dans la routine d'envoi, j'atteins 64 kbps. Je n'ai pas réussi à optimiser l'envoi. Quand j'aurai accès au lecteur zip de la salle internet

, je vous mettrai mon code. Donc nous voila fixés. En débit "efficace" ça fait du 8 kilo-octets par seconde.
Par contre par souci d'exactitude, sachez que ces calculs se basent sur l'auto-int 5 à 20 ms de période, donc j'aimerais savoir comment être certain du résultat. Sachez que j'ai fait les tests avec des piles neuves, juste après un reset, kernel unios 1.30 (même si mon prog est nostub) sur une 92+ HW2.
Electrocut: A force de commander, vous avez du épuiser leur stock d'échantillons! Attends un peu qu'ils en récupèrent!
Edit:
Le ZIP est libre!
Voila mon code modifié:
i2cdrv.h version 2
Et le dessin ASCII art de la plaquette à trous pour la connexion:
