i2c twi Fehlererkennung

[edgar]

ich habs auch mit Config I2cdelay = 10 probiert das ändert nix.
man muß doch nur beim abspeichern eines bytes 5bzw10ms warten nicht beim schreiben der offset und adressen , oder kanns an dem auch liegen?
is ein atmel 24c64 aa.
gruß werner..

[PicNick]

Da der Master den Takt gibt, muss der Takt nicht genau sein.
Ist deine Platine selbst gebaut ? Irgendwie klingt dein Problem eher nach Hardware. Leitungsüberspruch, ungenügend Pull up auf dem I2C oder sowas. Hast du da ein reines Gewissen ? mfg

[Joerg]

Hallo,

es gibt noch eine weitere Fehlermöglichkeit und zwar hat der I2C-Slave, in diesem Fall der EEPROM, die Möglichkeit bei längeren Operationen den I2C-Master auszubremsen indem er den Takt (SCL) einfach länger auf Low zieht. Der Master bekommt das mit und wartet bis der Slave den Bus wieder freigibt. Viele Softwareimplementationen jedoch, bekommen das einfach nicht mit, weil dieser Fall gar nicht in Betracht gezogen wird.

Im Zusammenhang mit den I2C-Sensormodulen (beim EEPROM ists aber genauso) haben manche Kunden insbesondere mit Software-I2C-Implementationen (C-Control, aber auch AVR) Probleme, dass die Kommunikation mitunter nicht einwandfrei arbeitet. Durch Einfügen einer künstlichen Pause (dirty, aber geht) nach dem Write lässt sich dies dann aber zumeist beheben.

Ich würde dir empfehlen, unbedingt mit der Hardware-I2C-Objekt zu arbeiten. Wie das mit Bascom geht steht in dem Buch von Roland Walter "AVR Mikrocontroller Lehrbuch".

HTH und Viele Grüße
Jörg

also ich hatte schon mal 10k dann 5k und jetzt hab ich 2k auf beiden leitungen ich finde die kurven haben schon bei 5k ganz ok ausgeschaut aber zur sicherheit hab ich halt mal 2k als pullup genommen.

die leitungslänge ist zwischen 8 und 9 cm , die leitungen verlaufen halt genau nebeneinander. wie schaut denn ein "Leitungsüberspruch" aus im oszi?

[PicNick]

Leitungsüberspruch: Signale auf einer anderen Leitung versauen die Signale auf einer anderen.
@Joerg: is ja hochinteressant, darüberhinaus will ich mich nicht wiederholen.

Das mit pausen könnt der Werner ja probieren, dann hätt er zwar nix vom err, aber keine (weniger) Fehler mfg

[edgar]

ok wie kann ich dann so nen Leitungsüberspruch, falls es wirklich einer sein sollte, im Oszi erkennen?
das mit den Pausen werd ich mal probieren, hat nicht jemand schon mal Routinen gemacht die funktionieren oder die auch den Hardware TWI verwenden?
jetzt hab ich mir gerade freitag früh ein Buch von Claus Kühnel(genau das Falsche weil es ja eigentlich nur 2 bekannte gibt) bestellt ich hoffe mal da steht auch was drin über Hardware TWI
gruß Werner...

[PicNick]

Du mußt vom Programm her permanent senden und die Clock und Daten oszillieren. Man erkennt, wenn die Signale nicht sauber sind (müssen immer schön 0-5V haben, keine Treppen etc.)
Ich hab dzt. leider nur beim PIC16f877 Assemblermäßig den Bus direkt bedient, beim Atmel faulerweise mit Bascom, da hat ich andere Sorgen.
schauen wor, ob ein wissender im Thread auftaucht mfg robert

[edgar]

also ich hab jetzt getestet ohne ende so wie es aussieht macht er doch keine fehler beim schreiben/lesen (liegt wohl irgendwo anders im programm.
so ganz zufrieden bin ich dann aber noch nicht daß er dann ein err zurückgibt find ich komisch. so kann ich nicht testen obs dann auch wirklich geklappt hat oder nicht. (vertrauen is gut - kontrolle is besser!)
gruß werner...

[PicNick]

Gut, zurück ins Labor.
Du mußt gezielt Zustände hervorrufen und sehen, was ERR macht.
Interessant sind nur I2CStart u. I2Cwbyte
1. schließ' einmal garnix an
2 I2CStart ---> Err ? muß ok. sein
3 Leg die Datenleitung auf GND
2 I2CStart ---> Err ? darf nicht ok. sein, oder der ganze Kobel bleibt stecken. beides is im Prinzip ok, wenn auch Steckenbleiben unerwünscht ist. Bleibt er stecken, laß ihn hängen und gibt die Datenleitung wieder frei, er müßte wieder weiterlaufen mit Err = 0 (ok)
Wichtigster TEST
I2Cstart
I2Cwbyte addr (write-addr)
ohne Gerät kriegt er kein ACK err sollte also was anzeigen.
mit Gerät sollte das ACK kriegen und err sollte 0 (ok) zeigen

I2Cstart
I2Cwbyte addr +1 (read-addr)
ohne Gerät kriegt er kein ACK err sollte also was anzeigen.
mit Gerät sollte das ACK kriegen und err sollte 0 (ok) zeigen

Versuch mal und berichte mfg robert