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

[kolisson]

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_I2C_Master#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: "



$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

[PicNick]

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.

[kolisson]

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

[linux_80]

Hallo,

das ist kein Fehler, das ist nur Ausbaufähig
:mrgreen:

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

[kolisson]

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