I²C EEPROM

[Bernd Reichelt (Gast)]

Hallo,

ich bin gerade dabei ein EEPROM über I2C anzusteuern. Leider bekomme
ich noch kein Ack. wenn ich mein Steuerwort sende. Mein Problem liegt
nicht in der Programmierung sondern eher in der Auswahl der Tools. Ich
bin es gewohnt mit komplexen Emulatoren zu arbeiten was das BUG finden
einfacher macht, aber leider für mich privat unerschwinglich ist.
Hier also mein Anliegen: Gibt es billige Möglichkeiten für das STK200
den Code auf dem Board zu Debuggen?
Danke
BR

[thkaiser (Gast)]

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.

[BernhardT (Gast)]

Oder such mal nach BootICE.
Gruß Bernhard

[Henning (Gast)]

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.

[Bernd Reichelt (Gast)]

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

[Peter D. (peda)]

@Bernd,

"Leider bekomme ich noch kein Ack. wenn ich mein Steuerwort sende."


bist Du sicher, daß Du das I2C richtig verstanden hast ?
Von Steuerwort steht da ja nirgends was.

Ohne Deinen Code kann man auch nichts weiteres dazu sagen.


Aber ich würde empfehlen, es erstmal mit Software-I2C (SBI, CBI) zu
machen. Damit schließt man schon mal Probleme im Verständnis des
Hardware-I2C als eine Fehlerquelle aus



Peter

[Henning (Gast)]

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...)

[Bernd Reichelt (Gast)]

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

[Peter D. (peda)]

Ohne Deinen Code kann man auch nichts weiteres dazu sagen.


Peter

[Bernd Reichelt (Gast)]

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