ADS1115 I2C AD-Wandler Programmierung

[alexander_ro]

Hi ... Mädels ... Jungs ...

Ich bin gerade dabei mir eine C++ Klasse für den ADS1115 zu bauen. Ich verstehe nur gerade nicht so ganz wie das Teil Programmiert werden soll. Der hat mehrere Register welches man davon anspricht wird über das "Address Pointer Register" eingestellt. Schreibt man jetzt eine "1" in das "Address Pointer Register" gehen die nächsten Zugriffe auf das "Config Register". Will man aber jetzt zum Beispiel die Daten des Wandlers lesen woher weiß der nun das der nächste Schreibvorgang wieder das "Address Pointer Register" betrifft?

Mein Problem gerade ist das ich nur wenn ich bei jedem Wert den ich lese vorher die ganze Konfiguration mit sende funktioniert das. Wenn ich nur versuche in einer schleife zu warten bis die Wandlung fertig ist und dann die Daten der Wandlung lese gerät nach einigen Wandlungen das "Config Register" durcheinander. Ich vermute mal das das Umschalten zwischen dem "Config Register" und dem "Conversion Register" irgendwann durcheinander gerät.

Im Datenblatt beschreiben die zwar was die einzelnen Register oder Bits machen. Für den Ablauf der Programmierung habe ich aber nicht wirklich was gefunden.

Viele Grüße
Alexander

[Ceos]

Ich hole mal wegen I2C etwas weiter aus, du sendest immer erst eine I2C Adresse in der im niederwertigsten Bit codiert ist ob man lesen oder schreiben will. Alles was danach kommt ist entsprechend der Doku zu interpretieren und wer Sendet ist durch das R/W Bit geklärt.

Deine Nachricht nach der Doku zu lesen sieht also folgendermaßen aus:

(MACK/MNACK Master, SACK/SNACK Slave)
(*1) Sollte nach I2C Spec immer ein NACK sein nach dem letzten Byte, der Chip erlaubt aber beides

Schreiben only: START -> Adresse + W -> SACK -> APReg -> SACK -> MSB -> SACK -> LSB -> SACK -> STOP

Lesen only: START -> Adresse + R -> SACK -> MSB -> MACK -> LSB -> MACK/MNACK(*1) -> STOP

Wobei eine vollständige Lesen Routine folgendermaßen aussieht:

Lesen mit APReg: START -> Adresse + W -> SACK -> APReg -> SACK -> STOP+START/RESTART -> Adresse + R -> siehe oben...

die Doku sagt, ein REgister weiderholt zu lesen geht indem man nur einmal das APReg schreibt und dann wiederholt ließt
schreiben braucht aber immer das APReg bei jedem Schreibvorgang

[alexander_ro]

Bei einer "singel conversion" muss ich ja immer erst eine "1" in das Bit 15 schreiben damit ich einen neuen Wert bekomme. Dann ist es schon so das ich in diesem Fall immer das "Config Register" neu schreiben muss. Dann warten bis der Wert im Bit 15 beim lesen wieder "1" wird und dann das "Address Pointer Register" umschreiben um den Wert aus dem "Conversion Register" lesen.

Der ADS1115 erwartet also beim schreiben immer vorher einen Wert für das AP-Register und dann den Wert der in das dann gewählte Register geschrieben werden soll. Nur beim mehrfachem lesen liest er aus dem zuletzt im AP-Register eingestellten Register. Der Hinweis war gut das hatte ich nicht so richtig verstanden. Was vermutlich daran liegt das die immer in so einer unverständlichen Sprache schreiben ...

Ich will ja erst mal Temperaturen messen. Da reicht die "singel conversion" weil der Wert sich nur relativ langsam verändert. Würde man dann bei einer "continuous conversion" die Werte einfach in einer Schleife aus dem "Conversion Register" lesen ohne das Bit 15 abzufragen. Woher weiß man dann denn das man nicht zweimal den gleichen Wert liest?

[Ceos]

Woher weiß man dann denn das man nicht zweimal den gleichen Wert liest?

Gegenfrage, warum muss einen das interessieren
Es geht ja um Temperaturen und solange ich jetzt nicht direkt einfach häufiger lese als er sampeln kann, sollte ich eher mal einen Wert verpassen als einen doppelt zu lesen, aber das sollte doch keine signifikante Wirkung auf die Aufgabe dahinter haben oder?

Edit: Will damit sagen, dass mir jetzt kein konkreter Anspruch einfällt der sowas erforderlich machen würde und cih daher keinen GRund sehe da unnötig Zeit zu investieren Vll. hat der ja einen physischen Pin um neue Samples zu melden statt das Register zu befragen, habe jetzt nicht tiefer in die Doku hineingelesen.

[White_Fox]

Gegenfrage, warum muss einen das interessieren
Es geht ja um Temperaturen und solange ich jetzt nicht direkt einfach häufiger lese als er sampeln kann, sollte ich eher mal einen Wert verpassen als einen doppelt zu lesen, aber das sollte doch keine signifikante Wirkung auf die Aufgabe dahinter haben oder?

Genau dieser Umstand war der Grund, warum bei uns in einem Uniprojekt die fabelhaft einfachen, arduinoartigen Bibliotheken für den STM32 wieder rausgeflogen sind. Für jede lächerlich einfache Art der Signalverarbeitung ist es schon sinnvoll zu wissen, ob ich den gleichen Wert ein- oder zweimal gelesen habe. Und sei es nur um mit mehreren Werten das Rauschen rauszumitteln. In unserem Fall damals wollten wir eine Sprungantwort einfach nur aufzeichnen. Selbst sowas geht nicht, wenn du keine Kontrolle darüber hast daß du keine Werte doppelt liest/überspringst.

[Ceos]

Für jede lächerlich einfache Art der Signalverarbeitung ist es schon sinnvoll zu wissen, ob ich den gleichen Wert ein- oder zweimal gelesen habe.

Je nach Aufgabe sollte man aber die Kirche im Dorf lassen. Eine Druckmessung sollte schon so schnell wie möglich sein damit ein heftiger Transient rechtzeitig unterdrückt werden kann und nicht das Rohr samt Sensor platzt.

Bei einer Temperaturmessung sind wir schon bei einer ganz anderen Prozessgeschwindigkeit. Wenn dieser Sensor keine physische Leitung präsentiert und obendrein auch noch erfordert multiple mal ein Status Register auf relativ aufwendige Weise auszulesen um dann den eindeutig neuen Messwert zu erfahren, hat man schlicht den falschen Sensor gewählt.

Meiner Meinung nach wäre hier der genau richtige Zeitpunkt zu hinterfragen ob man diese Messgeschwindigkeit benötigt oder die einfachste Lösung hinreichend ist (Free Run und langsamer als die Sampletime auslesen)

Und sei es nur um mit mehreren Werten das Rauschen rauszumitteln.

Das wäre auch mit o.g. Messmethode möglich, spricht jetzt effektiv nicht dagegen.

In unserem Fall damals wollten wir eine Sprungantwort einfach nur aufzeichnen.

Dann brauch man halt einen anderen Sensor der einem neue Samples einfacher zugänglich signalisiert.

-----------------------

Aber nochmal zurück zum eigentlichen Problem: wenn du uns etwa code zeigst (auch den I2C part) wie du derzeit deinen Sensor ausließt könnte man vielleicht mal drüber schauen ob es da einen Fehler im Ablauf gibt der das korrumpierte Config Register erklärt. Oder eine Beschreibung was genau du sendet und empfängst.