-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 19

Thema: i2c twi Fehlererkennung

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    21.09.2004
    Ort
    Augsburg
    Beiträge
    49

    i2c twi Fehlererkennung

    Anzeige

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

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.11.2003
    Ort
    Dresden
    Alter
    53
    Beiträge
    409
    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

  4. #4
    Gast
    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

  5. #5
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    *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

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.11.2003
    Ort
    Dresden
    Alter
    53
    Beiträge
    409
    Hi Robert,

    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.

    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

  7. #7
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Ich bin zwar nicht sicher, ob ich sowas Grausliches hören wollte, aber trotzdem, die Gemeinde dankt für die Information. mfg robert

  8. #8
    Benutzer Stammmitglied
    Registriert seit
    21.09.2004
    Ort
    Augsburg
    Beiträge
    49
    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...

  9. #9
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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

  10. #10
    Gast
    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...

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •