Der I2C Bus ist Open Collektor, er wird also aktiv nur nach Low getrieben. Damit man den Bus nicht stört, müssten die LEDs an Vcc liegen und nach GND geschaltet werden. SDA und SCL müssen, nach Spec, mindestens 3mA treiben können. Wenn der Bus kapazitiv belastet ist, schöpft man mit den Pullups gerne die vollen 3mA aus (z.B. 1k an 3,3V). Da bleibt dann, wieder nach Spec, nichts mehr für die LED. Nun können heutzutage CMOS Ausgänge mehr als 3mA, es könnte also gehen.

Ich würde einen Buffer dazwischen schalten, HC04 oder HC14, dann wird der Bus nur mit den wenigen pF Eingangskapazität des Buffers belastet.

Die Frage ist, was man gewinnt. Bei 100kHz dauert ein Byte ca. 100 µs, bei SCL ist die Diode auch nur die Hälfte der Zeit an. Da sieht man nicht wirklich viel. Und Probleme resultieren eigentlich selten daraus, daß der Master nicht sendet. Das macht er typisch blind auf den Bus. Sondern sie kommen daher, daß der Slave nichts oder etwas falsches versteht. Das kann man mit LEDs eigentlich nicht erkennen. Um wirklich die Signale beurteilen zu können, braucht man ein Scope, bei einem DSO könnte man dann noch die Bits von Hand auszählen.

Ich debugge I2C mit einem saleae Mini Logic analyzer. Der decodiert gleich das Protokol. Im Netz findet man aber preiswertere Alternativen. Wenn man direkten Zugriff auf die I2C Hardware Register hat und sich unterstützende Funktionen schreibt, könnte man auch mit Breakpoint und Single-Step auskommen. Es ist eine Frage der Zeit und der Mühe, die man aufwenden will.

MfG Klebwax