i2c twi Fehlererkennung

Wie kann man eigentlich überprüfen ob eine datenübertragung (lesen/schreiben) geklappt hat?
Man kann ja nicht grundsätzlich davon ausgehen daß alles funktioniert, oder doch?
Ich hab das err byte abgefragt aber das gibt öfters 1 zurück:

Code:

---


Lesebyte:
  Err = 0
  Waitus 5
  I2cstart
      If Err <> 0 Then
  Locate 1 , 1
  Lcd "111EEEEELERstar1"
  Wait 1
  End If

  I2cwbyte Ees
  If Err <> 0 Then
  Locate 1 , 1
  Lcd "FEEEEEEELERees"
  Wait 1
  End If

  I2cwbyte Epromoffset
  If Err <> 0 Then
  Locate 1 , 1
  Lcd "FEEEEEEELERoff"
  Wait 1
  End If

  I2cwbyte Epromadresse
  If Err <> 0 Then
  Locate 1 , 1
  Lcd "FEEEEEEELEReadr"
  Wait 1
  End If

  Waitus 5
  I2cstart

      If Err <> 0 Then
  Locate 1 , 1
  Lcd "FEEEEEEELERstar"
  Wait 1
  End If


  Waitus 4
  I2cwbyte Eel
  If Err <> 0 Then
  Locate 1 , 1
  Lcd "FEEEEEEELEReel"
  Wait 1
  End If


  I2crbyte Eprombytea , Ack
  If Err <> 0 Then
  Locate 1 , 1
  Lcd "FEEEEEEELERebytea"
  Wait 1
  End If
 
  I2crbyte Eprombyteb , Nack
  If Err <> 0 Then
  Locate 1 , 1
  Lcd "FEEEEEEELERebyteb"
  Wait 1
  End If

  I2cstop
      If Err <> 0 Then
  Locate 1 , 1
  Lcd "FEEEEEEELERstop"
  Wait 1
  End If

---

gruß Werner...

Hi, im Datasheet stehen Romane über die TWI Zustände. Ich weiß nicht, wie der Bascom zu seinem "Err" kommt. Eins ist klar: bei Read mit und ohne Ack gibt's keine sinnvollen Fehler, denn ACK und NACK kommt ja von dir. Beim Stop haut er wahrscheinlich den Bus weg und pfeift sich nix.
Eigentlich nur bei Write gibt's ev. Antworten.
Wie das bei start ist, mußt man mit einem niedergehalten Bus mal probieren. mfg robert

Hallo Werner,

also BASCOM nutzt meines Wissens nach (es sei denn es wurde in den neuesten Versionen geändert) für die I2C-Funktionen eine Software-Library und nicht das TWI-Hardware-Objekt des Controllers.
Damit hängt der Inhalt der Err-Variable nur von der Implementierung ab, die TWI-Register haben nichts damit zu tun.

Viele Grüße
Jörg

Ja, aber wenn der Bascom die Hardware verwendet (?) muß er sich ja wohl irgendwie mit diesen Flags auseinandersetzen, sonst weiß er ja auch nix ??? mfg robert

*grnft* manchmal heiß' ich auch Gast.
Wolltest du damit sagen, daß der Bascom die TWI Hardware NICHT verwendet, auch wenn sie da ist ?
Und wenn ja, wie is'n das mit der UART ?
*abgrundschau* mfg robert

Hi Robert,

Zitat:

---

Wolltest du damit sagen, daß der Bascom die TWI Hardware NICHT verwendet, auch wenn sie da ist ?

---

Ganz genau.

Irgendwo habe ich mal gelesen, dass daran gearbeitet wird oder worden ist, aber ich mache nichts mit BASCOM und weiß deswegen auch nichts genaueres.

Zitat:

---

Und wenn ja, wie is'n das mit der UART ?
*abgrundschau*

---

Also der Print-Befehl arbeitet wohl auf jeden Fall hardwareunterstützt. Bei SerIn und SerOut sieht das nicht so aus. Im RoWalt Buch wird zumindest in den Beispielen direkt mit den UART-Registern gearbeitet.

Viele Grüße
Jörg

Ich bin zwar nicht sicher, ob ich sowas Grausliches hören wollte, aber trotzdem, die Gemeinde dankt für die Information. mfg robert

Also in der Hilfe steht: "When an error occurs, the internal ERR variable will return 1. Otherwise it will be set to 0."

Das steht bei jedem befehl : I2CSEND , I2CSTART , I2CSTOP , I2CRBYTE , I2CWBYTE

- Heißt das dann ich muß nach jedem Befehl abfragen ob err=1 ?
- Was muß ich dann tun - nur den letzten Befehl neu senden oder alles komplett.
- Was kann ich an den Einstellungen verbessern weil die err Variable wird bei jeder 2ten oder 3ten i2c Aktion (z.b. bei jedem 2ten oder 3ten lesezyklus) entweder in
"I2cwbyte Epromoffset" oder bei
"I2cwbyte Epromadresse" auf 1 gesetzt.

gruß werner...

Hi, scheint, als erkenne er nicht immer das ACK. Wenn es der EEprom immer schickt, was wir hoffen wollen, dann solltest du mal testweise gaaanz langsam (config i2cdelay = 10 ' 100khz) probieren, ob sich was ändert
Man müßte überprüfen, ob der insgesamt gelesene Wert vom PROM nun stimmt oder nicht, mit und ohne Err.
d.h. schreib 1 - 100 rein, lies es aus und zähl wieder mit, und schau, ob der Err <> 0 überhaupt was zu sagen hat.
mfg robert

ich hab das mal mit dem oszi gemessen bei mir ist Config
I2cdelay = 4 '==>95 kHz
ja er macht fehler drum bin ich ja draufgekommen ich hab mich 2 wochen mit meinem programm rumgeärgert weil ich nicht gefunden hab wo er einen fehler macht...

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

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

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?

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

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

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

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

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