Hatte es auch schon so probiert, mit dem gleichen Erfolg. In Highbyte
steht immer 85 und in Lowbyte immer 213:
1
Do
2
3
I2cstart
4
I2cwbyte &H54
5
I2cwbyte &HB6
6
I2cstop
7
8
I2cstart
9
I2cwbyte &H55
10
Waitms 100
11
I2crbyte Highbyte , Ack
12
Waitms 100
13
I2crbyte Lowbyte , Nack
14
Waitms 100
15
I2cstop
16
17
18
Print #2 , Highbyte
19
Print #2 , Lowbyte
20
21
Temp1 = Highbyte
22
Temp1 = Temp1 * 256
23
Temp1 = Temp1 + Lowbyte
24
Temp1 = Temp1 * 0.01
25
26
27
Print #2 , "Temp: " ; Temp1
28
29
Waitms 500
30
31
Loop
Das Verhalten ist aufgetreten, seitdem der Hersteller folgende Änderung
hinzugefügt hat:
The I2C hardware module was change with respect to the SCL “latch-up”
issue. The
modified I2C module will not pull down SCL to signal the master to wait
for calculation of
data anymore. Therefore the master has to add wait times to ensure that
the slave will be
able to organize the data.
For standard data transmission (like reading temperatures) 1ms of time
is sufficient for
the slave to arrange the data.
Kommt Bascom´s i2crbyte damit irgendwie nicht klar?
Wenn das jetzt mit der WH I2C Lib ist, würd' ich's mit der Softlib
versuchen. Möglicherweise war das auch nicht die einzige Änderung des
Herstellers.
Auch mal Err auswerten und anzeigen lassen, um zu sehen, ob das Lesen
erfolgreich war.
Sorry, Buchstabendreher, sollte HW = Hardwarelib heissen.
Wenn explizit die i2c_TWI.lib eingebunden wird, verwendet Bascom die
Hardwarelib, also die I2C Unit im µC.
Wenn diese Lib nicht eingebunden ist, wird die Softwarelib verwendet.
Ein wichtiger Unterschied: Die HW Lib kann ohne externen Pullups
betrieben werden, die SW Lib dagegen nicht.
Ich verwende die Software-Lib. Hier ist das gesamte Testprogramm:
1
$regfile = "m644pdef.dat"
2
$crystal = 16000000
3
$hwstack = 128
4
$framesize = 128
5
$swstack = 128
6
$baud = 38400
7
$baud1 = 9600
8
9
Open "COM2:" For Binary As #2
10
11
Config Sda = Portd.5
12
Config Scl = Portd.4
13
14
Wait 2
15
16
Dim Highbyte As Byte
17
Dim Lowbyte As Byte
18
Dim Temp1 As Single
19
20
Temp1 = 0
21
22
23
Do
24
25
I2cstart
26
Waitms 10
27
I2cwbyte 84
28
Waitms 10
29
I2cwbyte 182
30
Waitms 10
31
I2cstop
32
33
I2cstart
34
Waitms 10
35
I2cwbyte 85
36
Waitms 10
37
I2crbyte Highbyte , Ack
38
Waitms 10
39
I2crbyte Lowbyte , Nack
40
I2cstop
41
42
43
44
45
Print #2 , Highbyte
46
Print #2 , Lowbyte
47
48
Temp1 = Highbyte
49
Temp1 = Temp1 * 256
50
Temp1 = Temp1 + Lowbyte
51
Temp1 = Temp1 * 0.01
52
53
54
Print #2 , Err
55
56
Print #2 , "Temp: " ; Temp1
57
58
Waitms 500
59
60
Loop
61
62
End
An den SDL und SDA Leitungen hängen jeweils ein 10k Pullup.
Bin ratlos, da ja anscheinend etwas gelesen wird, aber die Werte falsch
sind und sich auch nicht verändern.
Gerade noch die Softlib durchgesehen, Err wird dort nur beim wbyte
berücksichtigt.
I2CInit scheint mir für die Softlib nicht notwendig, aber schaden tät's
auch nicht. Mach' mal die Kommunikation mit CONFIG I2CDELAY langsamer.
Funktionierte dieser Code bereits mit einem Vorgängersensor ? Gehört der
Sensor initialisiert ?
Ansonsten, wenn's die Beschaltung zulässt, auch mal testweise die HW Lib
verwenden.
Habe gerade i2cdelay und i2cinit getestet - keine Änderung.
Der Code funktioniert mit der Vorgängerversion einwandfrei.
Die neuen Sensoren wurden sogar zum Hersteller eingeschickt, dort wurden
die gerprüft und funktionieren.
HW i2c ist nicht ohne Weiteres möglich :(
Die Soft-I2C hat nen "bug", das I2Cstart wird als
Restart ausgeführt, warum, das wissen nur die Leuts von
MCS.
Ich hatte da bei anderem Baustein mal meine liebe Mühe.
Kann man nur umgehen indem man die start-condition
quasi manuell programmiert ... bin aber grad am
falschen Rechner um nen Codeschnipsel rauszusuchen.
Könnte daran hängen.
edit:
wenn Du den ersten I2Cstop raus nimmst könnts schon was werden.
Soweit ichs noch weis war der Restart so, das nochmal stop und dann
start
gesendet wird.
> Die Soft-I2C hat nen "bug", das I2Cstart wird als Restart ausgeführt,> warum, das wissen nur die Leuts von MCS.> Soweit ichs noch weis war der Restart so, das nochmal stop und dann> start gesendet wird.
Das ist Käse.
http://www.i2c-bus.org/repeated-start-condition/
Ein Restart ist einfach ein weiterer Start zwischen Start und Stop OHNE
ein Stop zu senden. Deshalb wird's in der Lib auch genauso gehandhabt,
nämlich als normales Start. Nur die TWI Unit im µC macht intern eine
Unterscheidung. Da die Softlib aber keine Emulation der TWI Unit
aufbaut, ist die gesonderte Behandlung des Restart überflüssig.
Hast Du jetzt mal mit z.B. CONFIG I2CDELAY = 20 den Takt auf 50kHz
runtergesetzt ?
MWS schrieb:
> Das ist Käse.
dann erzähl das mal der C3188 was die dazu meint :o)
Das Datenblatt behauptet die Pullups seien schon integriert,
mach Deine mal weg zum Test. (I2C pull-up resistors are provided on the
sensor)
> Link? nö, eigene Erfahrung.> probieren geht über studieren :o)
Na super... Eigene Erfahrung schlägt natürlich Datenblätter und
Information aus so "nutzlosen" Weblinks s.o. :-(
Kleiner Auszug aus dem ATM644P Datenblatt:
A special case occurs when a new START condition is issued between a
START and STOP condition. This is referred to as a REPEATED START
condition, and is used when the Master wishes to initiate a new transfer
without relinquishing control of the bus. After a REPEATED START, the
bus is considered busy until the next STOP. This is identical to the
START behavior, and therefore START is used to describe both START and
REPEATED START for the remainder of this datasheet, unless otherwise
noted.
Ein Stop würde die Kontrolle über den Bus abgeben, das wäre dann
besagter Käse.
Les' gerade im TSEV01CL55 DB, daß I2C max. 3.6V verträgt und wie schon
winbauer gesagt hat interne PUp's im TSEV01CL55 vorhanden sind.
Wenn, dann was für PUp's verwendest Du ? Wo angeschlossen ? PUp's sind
nichte nötig, aber wenn das nicht der einzige Teilnehmer am Bus ist,
dann musst Du 'ne andere Lösung suchen, d.h. Pegelwandler.
> Also ich verwende 10k PullUps auf VCC.> Vom Hersteller habe ich die Info, dass die Internen Pullups ebenfalls> 10k sind.
Falls VCC = 5V ist, dann hast Du hier wahrscheinlich Deinen Fehler. Aus
dem Datenblatt: Input High Level 2 --- 3.6 ist anzunehmen, daß die PUp's
intern auf einer niedrigeren Spannung liegen, werden um die 3V sein. Das
sollte sich an den Eingängen des Sensors messen lassen. Mit PUp's auf 5V
bringst Du das sehr wahrscheinlich durcheinander.
Und Filth, sei so gut und poste mit richtigem Namen, damit ich mir das
nächste Mal überlegen kann, ob ich antworte. Ich persönlich mag keine
Crossposter, siehe MCS Forum. Damit ist diese Antwort auch mein letztes
Post in diesem Thread.
Thread beobachten
Seitenaufteilung abschalten