-         

Ergebnis 1 bis 5 von 5

Thema: möglicher fehler in RN-Wissen ? Bascom I2C Master

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    08.11.2006
    Ort
    olargues
    Beiträge
    776

    möglicher fehler in RN-Wissen ? Bascom I2C Master

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    hallo,

    ich da gerade auf einen eintrag gestossen, der mir zunächst fehlerhaft vorkommt.
    vielleicht kann das mal jemand überprüfen.

    es geht um folgende seite:
    http://rn-wissen.de/index.php/Bascom...r#Hardware_TWI

    wenn man dort auf punkt2 klickt (Hardware TWI ) findet man einen programmcode unterhalb des textes "Unter Zuhilfenahme des Datenblattes könnte eine Highend-Version so aussehen: "

    Code:
    $regfile = "M32def.dat"                           ' the used chip 
    $crystal = 16000000                               ' frequency used 
    $baud = 9600
    
    $lib "i2c_twi.lbx"                                ' Für Hardware TWI 
    
    Config Twi = 400000                               ' Init TWBR und TWSR 
    
    ' TWI gleich einschalten, das macht Bascom ansonsten erst beim I2CStart ! 
    TWCR = &B00000100                                 ' nur TWEN setzen 
    
    Const Pcf_write = &H40                            ' Slaveadresse 
    Const Pcf_read = &H41
    
    ' Startausgabe 
    Print
    Print "I2C-TWI High-Demo mit PCF 8574"
    Print
    
    Do
        I2cstart
        If TWSR = &H08 Then                           ' Start wurde abgesetzt 
            I2cwbyte Pcf_write                        ' Slaveadresse ausgeben 
    
            If TWSR = &H18 Then                       ' Slave hat sich gemeldet 
                I2cwbyte &HAA                         ' Datenbyte ausgeben 
    
    ?FEHLER?            If TWSR <> &H28 Then                  ' Byte erfolgreich übertragen 
                    Print "Byte mit NACK quittiert !"
                End If
            Else
                Print "kein Slave !"
            End If
        Else
            Print "Fehler bei Start"
        End If
    
        ' Immer Stop, damit die Buspegel wieder stimmen 
        I2cstop
    
        Print "E " ; Err                              ' Err = 0 -> kein Fehler ! 
    
        Waitms 1500
    
        I2cstart
    
        If TWSR = &H08 Then                           ' Start wurde abgesetzt 
            I2cwbyte Pcf_write                        ' Slaveadresse ausgeben 
    
            If TWSR = &H18 Then                       ' Slave hat sich gemeldet 
                I2cwbyte &H55                         ' Datenbyte ausgeben 
    
                If TWSR <> &H28 Then                  ' Byte erfolgreich übertragen 
                    Print "Byte mit NACK quittiert !"
                End If
            Else
                Print "kein Slave !"
            End If
        Else
            Print "Fehler bei Start"
        End If
    
        ' Immer Stop, damit die Buspegel wieder stimmen 
        I2cstop
    
        Print "E " ; Err                              ' Err = 0 -> kein Fehler ! 
    
        Waitms 1500
    
    Loop
    
    End
    ich habe die fragwürdige zeile mal mit "?FEHLER?" markiert.

    meines erachtens sollte es nicht " If TWSR <> &H28 Then ' Byte erfolgreich übertragen " heissen sondern " If TWSR = &H28 Then ' Byte erfolgreich übertragen "

    da kann ja mal einer drüberschauen.

    gruss klaus

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    na ja, == &H28 hiesse, "Byte übertragen + ACK empfangen"
    da passt der Kommentar Text nicht dazu.

    In der situation kann eigentlich nur
    &H28 (transmitted + ACK)
    oder
    &H30 (transmitted + NOT ACK)
    kommen
    (von extrafehlern mal abgesehen)

    So gesehen stimmt das Code beispiel schon, <> 28 (also 30 ) ist ja wirklich "transmitted und NOT ACK"
    andererseits kann man da aber nicht von erfolgreich sprechen

    Du hast aber recht, die Sache ist wirr, denn nur bei TWSR = &H28 würde der Master in ev. weiteres Byte übertragen wollen. Jeder x-beliebige andere Code müsste zu Abbruch (=Misserfolg) führen.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    08.11.2006
    Ort
    olargues
    Beiträge
    776
    hallo picnick,

    danke mal für die antwort.
    irgendwie hast du mich zunächst verwirrt, da du "na ja, == &H28 hiesse"
    geschrieben hast. ich bin leider kein c-typ. aber eine Suche im wörterbuch
    für C"ryptische dialekte" hat mich dann wieder beruhigt.

    zudem hast du mir natürlich die augen geöffnet, da ich die doppelte negierung: "Print "Byte mit NACK quittiert !" " überlesen hatte.

    nun gut.. ich selbst hatte nur ein kurzes problem damit.
    wollte aber verhindern, dass da noch einer gegen die gleiche parkuhr rennt.

    gruss klaus

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    22.05.2005
    Ort
    12°29´ O, 48°38´ N
    Alter
    48
    Beiträge
    2.731
    Hallo,

    das ist kein Fehler, das ist nur Ausbaufähig


    Wenn man bedenkt, dass die Bascom internen Befehle sich überhaupt nicht für den Status interessieren, ist das schon um Welten besser !

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    08.11.2006
    Ort
    olargues
    Beiträge
    776
    hallo linux80,

    das, was du sagst ist mir dieser tage auch sehr klar geworden.
    in der Bascom help fand ich einen hinweis auf die variable ERR ohne jedoch eine beschreibung zu finden.
    als ich dann irgendwann auf die irrwitzige idee kam , ERR auszudrucken, kam ich dann dahinter, dass es wohl nur ein flag ist.

    also irgendwie hatte ich halt gedacht, es wäre nett, wenn es bei twi (i2c) auch ein handshake gäbe, ohne diese undefinierbaren waitzyklen , die mitlerweile wohl jeder da einbaut.

    > NO FLOW CONTROL .. ZU KEINEM WOHL <

    ich hatte heute mal zum testen zwischen die befehle für twi dann
    solche dinge eingebaut:

    'Do : Loop Until Twsr = &H18

    das hat sich im laufe des nachmittags aber dann garnicht bewährt,
    da, wenn nun etwas schief-geht.... garnix mehr geht.

    evt. muss noch ein timer-timeout her. aber dann stellt sich wieder die frage, ob es mit den wait_xx nicht doch schon immer ging und im endeffekt weniger code erzeugt wird.

    gruss klaus

Berechtigungen

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