Fehler in bus characteristic

Hallo

Du gibst 7FH als Adresse vor. Und genau das siehst du auch auf
dem dem Bild SDA.jpg.

Wenn die Adresse stimmt, sollte der slave SDA auf low ziehen.

Gruß
Joachim

Danke Joachim für die schnelle Antwort!

Die Adresse stammt aus dem Datenblatt des Sensors: "Sensor answers on 
data transfers with this address disregarding configured sensor 
address."

Hast du noch eine andere Idee, woran es liegen könnte?

Gib mal als Adresse FE an, da diese bei I2C um ein Bit geschiftet 
verwendet wird.

Gruss Klaus

Klaus schrieb:
> Gib mal als Adresse FE an, da diese bei I2C um ein Bit geschiftet
> verwendet wird.

Der I2C kann da nichts für, wenn BASCOM das so braucht.
Die I2C Adresse hat immer 7-bit (sofern man nicht 10-Bit Bausteine 
verwendet) und wird zusammen mit dem R/W-Bit im ersten Datenwort 
übertragen.

Willi schrieb:
> Die I2C Adresse hat immer 7-bit


Das ist schon richtig was du schreibst, aber schau Dir mal sein 
Oszi-Bild an dann siehst du dass das erste Bit (bei I2C wird MSB zuerst 
gesendet) auf 0 ist und das RW-Bit auf 1 und das entspricht der addresse 
3f mit gesetzten RW

Gruss Klaus

Also nochmal kurze Zusammenfassung:
Auf dem Oszi-Bild sieht man dass das erste Bit (bei I2C wird MSB zuerst
gesendet) auf 0 ist und der Rest auf 1.
Das entspricht der Adresse 3f mit gesetzten R/W-Bit.

Ausserdem sieht man auf dem rechten Bild (ev Auszug aus dem Datenblatt) 
dass der Slave auch eine richtige Addresse (die "any-Sensor" Adresse) 
nicht mit einem ACK beantwortet.
Dass ist ein Bruch zur I2C-Konvention!

Ich weiss nicht was BASCOM mit der Slave-Adresse macht, aber zumindest 
scheint die "i2creceive" Routine nicht zu funktionieren.

Ein Ausweg ist vielleicht es zu Fuss zu machen wie in Beispielen
vorgemacht:

    I2cstart
    I2cwbyte &HFF     Adresse mit gesetztem R/W zum Lesen des nächsten 
Byte
    I2crbyte X, NACK
    I2cstop

Vielleicht mach dann auch das fehlende ACK-Bit keine Probleme !!??

Gruss Klaus

Ich habe jetzt die "default-adress" gewählt. Der Sensor antwortet, indem 
er die SCL (siehe neuer Anhang) nach unten zieht, um zu messen.
Mein neues Problem besteht darin, dass die SCL aber nicht mehr High wird 
und somit die Datenübertragung stattfnden kann.

Vorschläge?


$regfile = "M8def.dat"
$crystal = 3686400
$baud = 9600

$lib "i2c_twi.lbx"

Config Scl = Portc.5
Config Sda = Portc.4

Dim B1 As Byte , B2 As Byte
Dim W As Word At B1 Overlay
W = 0

I2cinit
Config Twi = 50000

Dim B As Byte , X As Byte

Do
  I2cstart
  I2cwbyte &B11010001
  I2crbyte B2 , Nack
  I2cstop
  Print "Error : " ; Err
  Print "received A/D : " ; B2
  Waitms 500
Loop
End

Hallo

Das ist ja schon ein aussergewöhnliches Ding.
Ich glaube du kommst bei den Anforderungen nicht um eine 
Assembler-Routine herum bzw. um eine Eizelansteuerung der Port-Pins.

Dass bei einer "broadcast address" kein ACK kommt ist im Rahmen.
Auch dass der Slave den CLK Impuls verlängern darf ist bei I2C 
vorgesehen.
Dass er dies aber 40msec lang macht bis er seinen Wert fertig hat, das 
denke ich, erwartet keine Standard-Software.

Ob BASCOM überhaupt mit vom Slave verlängerten CLK-Impulsen umgehen kann 
weiss ich nicht. Da bin ich überfragt!!!

Gruss Klaus

Hallo,

ich hab jetzt nochmal nachhgeschaut.
Dieses "Clock stretching" sollte jede Implementation beherrschen.
Wenn die BASCOM-lib Routinen das könnten dürftest du davon nichts 
bemerken (ausser einer kleinen Verzögerung) !!!

siehe z.B. da:
http://www.robot-electronics.co.uk/acatalog/I2C_Tutorial.html

Gruss Klaus

Klaus schrieb:
> siehe z.B. da:
> http://www.robot-electronics.co.uk/acatalog/I2C_Tu...

siehe Abschnitt "wait a moment" und folgende

> Gruss Klaus

Vielen Dank für die hilfreichen Antworten. Jetzt ist alles in bester 
Ordnung.

Nach setzen einer 350us Pause bekomme ich jetzt das Data-Signal vom 
Sensor.

Gruss Martesy