I²C EEPROM

Die billigste: 2 LEDs. Eine an SDA, eine an SCL.
Dann den Prozessor per Soft- oder Hardware so weit bremsen, daß man die
Bits "sehen" kann. Die Atmels haben eine statische Struktur, man kann
den Oszillator fast auf 0 runter fahren. Oder eben
Verzögerungsschleifen rein.
Etwas teurer, aber wesentlich komfortabler ist ein Speicheroszilloskop.

Oder such mal nach BootICE.
Gruß Bernhard

oder lasse die beiden pin´s von noch einem avr protokolieren und per
uart an den pc senden. hab ich eigentlich auch erst machen wollen, hab
meine i2c bauteile aber dann doch noch so angesprochen bekommen.

mit dem eeprom hab ich auch große probleme gehabt. hab mir dann mehrere
routinen aus dem netz geholt und verglichen, bis es dann geklappt hat.

Hi,
Die Idee mit LED's für SCL&SDA hatte ich auch schon. Hatte gedacht es
gibt vielleicht noch einen besonderes Tool welches Gute dienste
leistet. Es ist halt so wie es aus dem Thread von Henning hervor ging:
FUMMELARBEIT.
Ganz verstanden habe ich Henning trotzdem nicht. Wofür einen zweiten
AVR zum protokolieren. Wenn man den Traffic über den UART mit
protokollieren will kann man doch den AVR verwenden der die Signale
sendet/empfängt.
Egal ich werde wohl noch ein wenig im trüben fischen.
Trotzdem danke für die Vorschläge

man könnte natrürlich auch den code schritweise mit dem simulator
durchgehen und sich dabei einen Signalplan zeichnen. aber soviel mühen
habe ich bis jetz gescheut :)

mit dme zusätzlichen avr habe ich gedacht könnte man die signale
mitlauschen, du hast aber recht, man könnte natürlich auch das ganze an
die uart senden. die is ja fix genug. werd ich nachher mal probieren...
meine i2c-routinen scheinen noch nicht ganz ast-rein zu sein. :(
obwohl sie ja funktionieren... (wenigstens DIE routinen; ich dachte
währe mit meinem projekt fast fertig, tritt der unlogischte fehler auf,
den ich mir vorstellen kann. und das bei 2104 Befehlswörtern...)

Hallo Peter,
erstmal bleibt mir bei meinem Controller keine andere Möglichkeit als
mit den Ports zu klappern (SW I²C). Die Vorgänge auf dem Bus sind mir
also bekannt. OK vielleicht wäre Steuerbyte besser gewesen. Keine
Ahnung wie das Byte in der Phillipsspec genannt wird welches sich aus
Adresse des Slave und R/W Bit zusammen setzt. Denke aber das es logisch
ist was ich damit meinte wenn ich darauf warte das mein EEPROM die SDA
Leitung auf logisch Low zieht(ACK).
Gruß BR

Danke Peter,

ich werde mich erst noch mal selber rein hängen. Wenn ich nicht klar
komme melde ich mich noch mal mit ein paar Codeschnipseln