I2C Problem mit Sensor VEML6075

Gast #5847945
Hallo

Ich versuche diesen Sensor 
(https://eckstein-shop.de/Adafruit-VEML6075-UVA-UVB-and-UV-Index-Sensor-Breakout) 
in Betrieb zu nehmen.

Leider funktioniert die I2C Kommunikation nicht. Im Anhang ist ein Oszi 
Bild der SCL und SDA Signale direkt am Sensor gemessen. Wenn ich es 
richtig sehe, sendet der Sensor kein ACK. Die Adresse ist 0x10, Pullup 
1K, Frequenz 50kHz (Datenblatt: 10-100kHz). Habe ich vielleicht noch 
etwas übersehen? Woran könnte es liegen, dass der Sensor nicht 
antwortet? Was könnte ich noch ausprobieren?

Vielen Dank im Voraus für eure Tips!
Angehängte Dateien:
Gast #5848012
Hier der Schaltplan von der Breakout Platine:
https://cdn-learn.adafruit.com/assets/assets/000/062/587/original/adafruit_products_schem.png?1537993764
SDA und SCL sind 1 zu 1 mit 15cm Jumper Kabeln am Controller Board 
verbunden.

Spannugnsversorung 3,3V (direkt am Chip gemessen). Inwieweit der 
Prozessor (STM32) eine Rolle spielt, erschließt sich mir nicht ganz. Man 
sieht doch auf dem Oszilloskop Bild, dass die korrekte Adresse gesendet 
wird und kein ACK vom Sensor kommt. Sehe ich das falsch?
Gast #5848066
> Was könnte ich noch ausprobieren?

Viele interpretieren die Chips, als hätten sie 2 Adressen. Einmal zum 
Lesen und einmal zum Schreiben. Aber die I2C-Spezifikation spricht von 
einer Adresse und einem R/W-Bit. Demnach hättest du 0x08 adressiert. Es 
sei denn, 0x10 bezieht sich auf den "2-Adress-Quatsch".

Also probier in deinem Modell mal mit 0x20 zu adressieren.
Gast #5848067
STK500-Besitzer schrieb:
> Das war ein Wink mit dem Zaunpfahl!
> DEINEN Schaltplan sollst du posten.

Ich wüsste nicht, was ich noch dazu sagen soll. Die Breakout Platine ist 
- wie gesagt - direkt über Jumper Kabel mit dem Controller verbunden. 
Controller ist in diesem Fall ein STM32 Eval Nucleo Board.
Gast #5848080
Hallo,
aus dem DB wird man ja nicht schlau, wie die Übertragung durchgeführt 
werden muss. Aber ich denke mal, dass der Sensor wohl lieber Daten 
senden möchte, als parametriert zu werden. Daher vermute ich jetzt mal 
(spekulativ), dass die IIC Adresse mit einem gesetzten R/W-Bit (FÜR 
LESEN) übertragen werden sollte.
Vielleicht bringt das ja den Durchbruch.

Gruß
TK
Gast #5848155
neuer PIC Freund schrieb im Beitrag #5848066:
> Viele interpretieren die Chips, als hätten sie 2 Adressen. Einmal zum
> Lesen und einmal zum Schreiben. Aber die I2C-Spezifikation spricht von
> einer Adresse und einem R/W-Bit. Demnach hättest du 0x08 adressiert. Es
> sei denn, 0x10 bezieht sich auf den "2-Adress-Quatsch".
>
> Also probier in deinem Modell mal mit 0x20 zu adressieren.

Es lag doch daran! Jetzt funktioniert es. Vielen lieben Dank :)

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 7 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.