Unverständniss mit Datenblattangabe: MCP3425 per I²C abfragen

[IsquareC-Hans (Gast)]

Guten morgen Leute!

Ich habe ein wenig Probleme, Daten von einem MCP3425 (16Bit SD-Wandler 
I²C) zu bekommen.

Ich muss dazu sagen, dass ich mit I²C noch nie gearbeitet habe und daher 
auch ein wenig Probleme bei der Umsetzung meiner State-Machine habe. 
Aber vorher muss ich erstmal die Angabe im Datenblatt verstehen.

Es geht also um das auslesen des Wandler-Wertes. Laut DB kommen bei 
einer Abfrage immer 3 Datenbytes. 2 Sind das Wandlerergebnis, das dritte 
das Configuration-Byte, welches die aktuellen Einstellungen des Wandlers 
mitsendet.

Ich habe dazu mal den Text und das dazugehörige Bild angehängt.

So wie ich das verstehe, kommen halt diese drei Datenbytes und im 
Config-Byte ist das Bit 0x80 die Angabe, ob das Wandlerergebnis, welches 
zuvor gesendet wurde, aktuell ist.

Sollte das Bit gesetzt sein, so ist das Ergebnis nicht aktuell. Jetzt 
steht hier, dass ich einfach weiterclocken kann, und der MCP dann stets 
weiter Daten sendet. Jetzt ist mir nicht ganz klar, ob er stets wieder 3 
Bytes sendet, oder eben nur das Config-Byte, in dem ich das RDY-Bit 
abfragen kann.

Durch ein NACK, ein STOP oder wieder ein START würde die aktuelle 
Übertragung abgebrochen und man kann eine neue Abfrage starten, in der 
dann der aktuelle Wert gesendet wird.

Theoretisch kann ich doch dann eh einfach immer eine komplette Abfrage 
von vorne starten und das Bit auswerten. Falls nicht gelöscht, neue 
Übertragung starten. Falls nurnoch das Config-Byte gesendet wird, habe 
ich Vorteile dadurch? Wirklich schneller geht die Übertragung dadurch ja 
auch nicht.

Hat den schonmal jemand benutzt?

[Programmierer (Gast)]

Du kriegst nur noch das Config-Byte und musst dann eine neue Abfrage 
starten, wenn aktuellere Messwerte bereit stehen.

[IsquareC-Hans (Gast)]

OK, danke schonmal.

Jetzt nochmal eine generelle Frage zum I²C:

Ich sende Daten (Adresse) zum Slave, er sendet ein ACK, indem er beim 9. 
Puls die SDA-Leitung auf low zieht.

Jetzt takte ich weiter und empfange Bytes vom Master, die ich jeweils 
selber mit einem ACK im neunten CLK-Puls beantworte.

Was ist jetzt nach dem dritten Byte? ACK oder NACK? Im Wiki steht NACK 
und dann STOP. Im DB vom MCP3425 steht ACK/NACK nach dem letzten Byte 
und dann STOP.

Das STOP ist ja nur ein Pegelwechsel ohne CLK, oder? Alsoo SCL ist schon 
high, weil released und da SDA vom letzten ACK noch low sein sollte, 
nurnoch ein Pregelwechsel auf high.

Aber was ist jetzt, wenn als letztes ein NACK war, dann ist SDA ja noch 
high. Was ist jetzt? Ist es dann gleichzeitig die STOP-Bedingung, oder 
muss dann noch ein Wechsel von high auf low und wieder high? Wäre ja ein 
Takt mehr :-\ Eher nicht, oder?

[Stefan (Gast)]

Wenn der Master fortlaufend Daten vom Slave empfängt, beendet er die 
Kommunikation, wann er will durch NACK+Stop. Das NACK sagt dem Slave 
"jetzt ist Schluss, ich habe genug".

Wenn der Slave eine vordefinierte Anzahl von Bytes liefert (was seltener 
vorkommt), kann der Master das letzte Byte wahlweise mit NACK+Stop oder 
ACK+Stop bestätigen.

Du hast korrekt erkannt, dass der Master unmittelbar nach einem NACK 
kein Stop Signal senden kann, weil dann ja SDA schon auf High steht und 
dort auch bleibt.

Aus diesem Grund verhält sich der Slave beim Senden von Daten (in der 
Regel) sowohl beim NACK als auch beim STOP Signal gleich. In beiden 
Fällen beendet er das Senden von Daten.

[Rufus Τ. F. (rufus)]

IsquareC-Hans schrieb:
> Jetzt takte ich weiter und empfange Bytes vom Master, die ich jeweils
> selber mit einem ACK im neunten CLK-Puls beantworte.

Besser:

Jetzt takte ich weiter und empfange Bytes vom Slave ...

[IsquareC-Hans (Gast)]

Stefan schrieb:
> Aus diesem Grund verhält sich der Slave beim Senden von Daten (in der
> Regel) sowohl beim NACK als auch beim STOP Signal gleich. In beiden
> Fällen beendet er das Senden von Daten.

Alles klar, vielen Dank! Dann werde ich es jetzt mal versuchen.

Rufus Τ. Firefly schrieb:
> Jetzt takte ich weiter und empfange Bytes vom Slave ...

Ja, natürlich! Das muss natürlich Slave hin.

[IsquareC-Hans (Gast)]

Aber wie kann er denn das hier:

Stefan schrieb:
> Wenn der Master fortlaufend Daten vom Slave empfängt, beendet er die
> Kommunikation, wann er will durch NACK+Stop.

? Es ist doch dasselbe wie:

Stefan schrieb:
> Du hast korrekt erkannt, dass der Master unmittelbar nach einem NACK
> kein Stop Signal senden kann

Was ist denn dann jetzt NACK+Stop?

[IsquareC-Hans (Gast)]

Ich bekomme vom ADC irgendwie nur Müll zurück ;-( Ich mache es jetzt so:

START
8 CLKs Adresse senden
ACK mittels eines weiteren CLKs abfragen
(N)ACK auswerten (ist low: ACK), also weiter
8 CLKs senden und Antwortbyte speichern
ACK mittels eines weiteren CLK-Pulses ('low') senden
8 CLKs senden und Antwortbyte speichern
ACK mittels eines weiteren CLK-Pulses ('low') senden
8 CLKs senden und Antwortbyte speichern - dieses auf 0x80 prüfen. Wenn 
high (busy)
ACK mittels eines weiteren CLK-Pulses ('low') senden
8 CLKs senden und Antwortbyte speichern - dieses auf 0x80 prüfen. Wenn 
high (busy)
...und so weiter, bis Bit7 mal nicht gesetzt ist.

Aber das Ergebnis des dritten Bytes (Config) besteht meist immer nur 
einsen, also fast alles gesetzt, was laut DB per default nicht der Fall 
ist, sondern nur das Bit für den Conversion-Mode (continous) ist 
gesetzt.

Auch die Datenbytes ändern sich nicht, wenn ich am Poti drehe. Auf Grund 
der stetigen 1 auf 0x80 im Config-Byte hängt das ganze dann eh immer in 
oben gezeigter Abfrage.

Ich verzweifel.

[IsquareC-Hans (Gast)]

So Leute - ich melde mich mal zurück.

Also...es klappt jetzt. Jetzt wollte ich mal berichten, wie man sich das 
Leben unnötig schwer machen kann:

Ich wollte mir das Signal des MCP natürlich am Oszi angucken. Aber ich 
konnte meine Haken für die Tastköpfe nicht finden. Also dachte ich 
mir...bauste dir eben ein paar Kabel selber und machst da direkt Stifte 
dran, dann kannste das ganze ins Steckbrett stecken. BNC-Stecker hatte 
ich noch und ne Crimpzange auch. Kabel? Da waren noch zwei Meter 
12-poliges Kabel.

Jetzt dachte ich mir, das Kabel ist natürlich nicht geschirmt, also 
nimmste rot als + und den Rest als Masse. Also NUR AM STECKER, nicht am 
Ende, alle anderen zusammengelötet (vorne wollte ich jeweils ein schönes 
Kabel heraus haben für + und - und kein zusammengelötetes Knubbel an dem 
-Pin).

Nicht wirklich drüber nachgedacht, dass ich mir grad folgendes aufgebaut 
habe:

[+] ---------------------------------->

[-] ---------------------------------->
[-] ------------------------------
[-] ------------------------------
...
[-] ------------------------------

Also zwischen jeder -Leitung und der einen +Leitung einen C. Vielleicht 
zuviel für eine saubere Übertragung.

Das ist zumindest meine Vermutung...denn jetzt mit ordentlichen Kabeln 
klappt es.


Könnte es daran liegen?