CFSensors XGZP6857D Drucksensor Informationen

Moin, Da du interessante Informationen lieferst, aber keine Frage stellst, würde ich vorschlagen aus dem Text einen Artikel für die Artikelsammlung zu erstellen. Hier im Forum verschwindet der sonst irgendwann auf den nächsten Seiten, wenn andere wichtige und "wichtige" Fragen stellen.

Rahul D. schrieb:

Moin, Da du interessante Informationen lieferst, aber keine Frage stellst, würde ich vorschlagen aus dem Text einen Artikel für die Artikelsammlung zu erstellen. Hier im Forum verschwindet der sonst irgendwann auf den nächsten Seiten, wenn andere wichtige und "wichtige" Fragen stellen.

Moin Rahul,

Wenn Du meinst, dann werde ich gescheit machen müssen, wie man es macht. Aber ich stimme Dir bei, daß es hier verloren gehen wird.

Gruß, Gerhard

"Global Partner"-Beschränkungen

Das bedeutet, Trump lässt den Export nach Kanada nicht mehr unbehindert zu? Feindliches Ausland, das irgendwann Teil der USA werden muss? Der Zar hat auch mal "russische Erde gesammelt", bis er am Pazifik angekommen war.

Ist der Softwareunterschied Absicht des Herstellers, oder ein Versehen?

Christoph db1uq K. schrieb:

"Global Partner"-Beschränkungen

Das bedeutet, Trump lässt den Export nach Kanada nicht mehr unbehindert zu? Feindliches Ausland, das irgendwann Teil der USA werden muss? Der Zar hat auch mal "russische Erde gesammelt", bis er am Pazifik angekommen war.

Ist der Softwareunterschied Absicht des Herstellers, oder ein Versehen?

Moin,

Uff - Viele Fragen auf einmal.

Nein. Die "Global Partner" Einrichtung ist ein internationales Partner Netzwerk und da wird dadurch das Angebot vergrössert. Leider fallen dann bei jeder Bestellung rund $38 an zusätzlichen Lieferkosten an und oft stören dann auch MOQs. Da ist nichts Böses daran.

Und male den Teufel nicht an die Wand - was 51st State "Anschluß" betrifft reagieren wir neuerdings sehr empfindlich auf solche Anspielungen:-)

Der SW-Unterschied ist eine Hersteller Entscheidung. Es hat mich schon sehr gewundert. Zur Zeit warte ich auf eine Rückantwort vom FEI.

Was die I2C Transaktionen betrifft, möchte ich mich noch näher hineinknien.

Ich habe am iPad einige I2C Bausteine Datenblätter begutachtet und fest gestellt, daß ACK/NAK Protokol Details je nach Hersteller unterschiedlich sein können. Ein LM75 braucht ein NAK als Bestätigung beim letzten gelesenen Byte vor der STOP Anweisung. Andere Bausteine begnügen sich mit ACK vor dem STOP. Das muß man in jeden Fall berücksichtigen. Bei Abweichungen kann es passieren, daß folgende Datenabfragen inkorrekt ausgehen. Das ist bei jeden Baustein unterschiedlich. Bei dem besagten Drucksensor passiert es, daß bei ACK folgende Abfragen fehlerhaft sind. Was Arduino WIRE betrifft, ist das so eine Sache, weil die Multi-Byte Daten Abfrage kein NAK am letzte Byte ausgeben soll. Ich probierte eine Arduino Drucksensor Lib damit aus und die funktioniert. Da ich immer meine eigenen Treiber mit SoftI2CMaster schreibe, fiel es mir auf, daß es auch bei Einzelabfragen mit ACK Folgefehler gibt. Wenn ich NAK verwende funktioniert es zuverlässig. Eine Multi-Byte Abfrage funktioniert nur dann zuverlässig mit 4xACK + 1xNAK. Warum die Arduino Lib funktioniert kann ich noch nicht erklären. Ich möchte mich etwas tiefer damit befassen. Auch möchte ich abwarten wie CFSensor dieses ACK/NAK Abwicklung sieht.

Im Datenblatt geben sie ein 8051 Beispiel an. In diesem Beispiel Programm wird der ACK/NAK nicht vom Host gesetzt, sondern nur abgefragt. Das widerspricht dem Standard I2C Protokoll - Der Bus Teilnehmer (Slave) erwartet eine solche Bestätigung vom Controller nach jedem Lesen eines Bytes, das machen sie aber in dem Programm nicht.

Falls es keine weitere Überraschungen gibt, muss ich davon ausgehen, daß die Beschreibung im Datenblatt unzuverlässig ist. In früheren Datenblättern (vor V2.9) wird das ACK beim Lesen überhaupt nicht angegeben, was eine Protokollverletzung des Standards ist. Im neuesten Datenblatt wurde diese Unterlassung behoben und ein ACK angegeben. Ich kann das momentan nicht aktuell testen, weil mir momentan noch kein neuester Sensor zur Verfügung steht. Nun, Abweichungen gibt es - Man denke nur an den ersten Intersema MS5344 Sensor. Bei dem war das I2C Protokol auch "verballhornend" umgesetzt und konnte nur als einzelner Busteilnehmer eingesetzt werden. Spätere Versionen wurden dann dem I2C Standard angeglichen. Wahrscheinlich haben sich damals viele Kunden beschwert.

Fazit:

Ich habe aus langjährigen Gebrauch der SoftI2CMaster vollstes Vertrauen. Ich schreibe mir fast immer meine eigenen I2C Treiber nach Datenblatt Vorgaben und hatte bis jetzt 100% die zu erwartenden Erfolge damit gehabt. Ein Fehler der Bibliothek ist also ausgeschlossen. Bei dem besagten Drucksensor funktioniert er nur dann zuverlässig wenn ich, wie beschrieben mit ACK/NAK umgehe. Warum das Arduino Beispiel funktioniert ist mir noch nicht erschlossen und werde es bald näher untersuchen. Ich ziehe die SoftI2CMaster ASM Bibliothek vor, weil sie sehr schlank ist und nicht von den HW Pins abhängig ist. Sie verbraucht kein SRAM und beansprucht nur 240 Bytes. Die Wire Bibliothek ist diesbezüglich wesentlich anspruchsvoller. Hat allerdings auch gewisse vorteilhafte Eigenschaften. Aber in meiner Anwendung ist mir Schlankheit und Freiheit der Pin Zuordnungen wichtiger.

Fortsetzung folgt

Gruß, Gerhard

Nachtrag:

Im Anhang auf Seite 18 kann man sehr schön nachvollziehen, wie das ACK/NAK-Spiel abläuft.

Die "Bottom Line" lautet:

1. Der Controller sendet ein Write an das Target, das Target quittiert mit ACK.
2. Der Controller empfängt Daten vom Target. Danach sendet der Controller ein ACK, wenn er weiter lesen möchte, oder ein NAK, um dem Target mitzuteilen, dass die Transaktion beendet ist (ggf. zusammen mit Stop).

Im Datenblatt des Sensors wird im Diagramm auf Seite 5 farblich angezeigt, wer wem was sendet. Bis kurz vor dem Abschluss ist das korrekt. An der markierten Stelle müsste das "A" jedoch vom Controller kommen und nicht vom Target, also mit weißem Hintergrund dargestellt sein. Der Sinn dieser Bestätigung ist, dem Target zu signalisieren, dass das übermittelte Byte erfolgreich empfangen wurde.

Da im Datenblatt fälschlich ein "A" vom Target angegeben ist, würde das Target eigentlich im aktuellen Zustand verbleiben, wenn nicht das Stop-Signal alles intern zurücksetzen würde. Hier scheint das jedoch nicht zuverlässig zu passieren.

Wie bereits erwähnt: Auch beim Lesen eines einzelnen Werts mit vorgegebener Pointer-Adresse und anschließendem ACK liefert ein weiteres Lesen mit anderer Pointer-Adresse falsche Werte. Erst wenn mit NAK gearbeitet wird, funktioniert alles wie erwartet. Auf das Stop allein kann man sich offenbar nicht verlassen.

Meine Tests zeigen: Der XGZP erwartet NAK und Stop, um den Datenverkehr zu beenden und die State-Maschine in den Wartezustand zu versetzen. Wird nur ACK und Stop gesendet, bleibt der Datenzeiger anscheinend stehen. Darum geht es hier: um die unklare interne Reaktion des Targets in diesem Fall.

Wie versprochen, möchte ich das noch genauer prüfen, um 100 % sicher zu sein. Auch will ich mir die Signale noch einmal mit dem Oszilloskop ansehen. Oft erkennt man schon an kleinen Spannungsschwankungen gut, wer gerade sendet. Mit kleinen Serienwiderständen lässt sich die Datenrichtung zudem leichter beobachten.

Erstaunlich finde ich, dass der Hersteller keine sequenzielle Lesemöglichkeit dokumentiert. Dabei genügt es, vor dem Lesen die Startadresse zu senden und dann fünfmal hintereinander zu lesen (4× mit ACK), beim letzten Mal mit NAK und Stop – das funktioniert zuverlässig. Warum wird diese Information verschwiegen?

Ehrlich gesagt sind die Datenblätter der bekannten Platzhirsche in dieser Hinsicht deutlich zuverlässiger. Meist funktioniert das Treiber-Design nach deren Angaben sofort. Naja – Steine werfen möchte ich trotzdem nicht;-)

Ich bin gespannt, ob es dazu eine Stellungnahme gibt, und werde berichten.

Mich würde außerdem interessieren, ob hier im Forum jemand ebenfalls mit diesen Bausteinen gearbeitet hat und ähnliche Erfahrungen gemacht hat.

Gerhard

Nachtrag:

Ich habe noch bei CFSensors herumgestöbert und fand ein ähnliches Sensor Datenblatt (XGZP6810D), wo das I2C Kommunikationsprotokoll korrekt dokumentiert ist (Seite 5) und sich mit meinen Erfahrungen deckt. Hier ist der Link:

https://cfsensor.com/wp-content/uploads/2025/04/XGZP6810D-Pressure-Sensor-V1.1.pdf

Ich habe mir neugierigerweise noch einige andere Sensoren dieser Firma angesehen. Alle solcher I2C Typen haben das gleiche Protokoll bezüglich NAK + STOP wie der obige 6810 und dieser Ansatz funktioniert auch bei mir wie berichtet.

Moin,

Es fällt mir auf, dass der Informationsgehalt in diesem Thread wiederholt durch Negativbewertungen systematisch kritisiert wird. Konstruktive Hinweise oder Korrekturen fehlen jedoch dabei, sodass eine sachliche Diskussion erschwert wird. Vor diesem Hintergrund wirken die fortlaufenden Negativbewertungen eher willkürlich und lassen vermuten, dass persönliche Abneigungen des Lesers gegenüber dem Verfasser eine Rolle spielen.

Duck und weg, Gerhard