STM32, PCA8575 I2C Kommunikationsproblem

Hallo

Hier nochmal der Link zum Datenblatt:
http://www.nxp.com/documents/data_sheet/PCA8575.pdf

Vielleicht kann mir ja einer sagen wie man das Diagramm auf Seite 8 
interpretieren soll?
Laut der Zeichnung braucht man am Ende keine Stop-Condition senden?

Das Diagramm zum Lesen ist mir noch unklarer. Was bedeutet denn "data 
from port 0" und "data into port 0"?


Vielen Dank und Gruß

Der I2C-Bus braucht immer die STOP-Bedingung, wenn eine Übertragung 
beendet wurde. Das erste Timing-Diagramm ist für Kontinuierliche 
Ausgabe, da könnte man ohne erneute Adressübertragung beliebig lange 
Daten rausschreiben.
Beim Timing-Diagramm zum Lesen ist halt mit angegeben, wann sich die 
externen Daten am Baustein ändern dürfen und zu welchen Zeitpunkten die 
Daten gesampled werden.
Die Adressberechnung in den Funktionen ist nur dann Sinnvoll, wenn Du 
mehrere Bausteine auf einem Bus betreiben willst. Mit nur einem Baustein 
würde ich da Konstanten setzen, das ist etwas klarer. Wie werden die 
Funktionen in der Applikation aufgerufen - besonders die übergebene 
Adresse? Passt die zur Beschaltung der Hardware?
Deine Lesefunktion schreibt in den Buffer[], der als lokale Variable 
deklariert ist. Da wirst Du wohl von außen kaum drankommen...

Vielen Dank für deine Antwort.

Das mit dem Stop habe ich mir fast gedacht. Sende ich ja auch.

Das mit dem Timing Diagramm macht Sinn.

Die Adressberechnung ist tatsächlich drin weil ich zwei Bausteine habe. 
16 Ausgänge und 16 Eingänge. Der dritte IC ist z.Z. nicht angeschlossen.

Der Aufruf erfolgt wie folgt im main:

1

uint16_t daten_out = 0xffaa;

2

PCA8575_setze_Ausgang(daten_out, 0);

3

4

PCA8575_lese_Eingang(1);

Die Lese-Funktion hat keinen Rückgabewert, das ist korrekt. Ich halte 
z.Z. immer nach der Stop-Bedingung mit dem Debugger an und gucke mir die 
Werte an.
Ich komme aber gar nicht bis zum Ende, da das Programm ja wie erwähnt 
schon vorher stehen bleibt.

Den Hardwareaufbau habe angehängt.

Gruß Frank

Mein Pin- und Adresskompatibler PCA9555 funktioniert problemlos. Der hat 
als Unterschied noch Port-Direction-Register, die in init gesetzt 
werden.
Ich betreibe da ein LDC und ein Tastenkreuz dran.

Dass SDA auf 0 liegt ist nicht korrekt. Da musst Du mal die Hardware auf 
Kurzschlüsse oder Dein Programm auf ungereimtheiten Checken (als 
"Energiesparer" schaltet man gerne mal komplette Ports auf 0 und 
deaktiviert eventuell Zweitfunktionen damit...)
An welcher Stelle bleibt das Programm hängen? Was siehst Du in den 
Statusregistern des I2C-Controllers?

Hallo Bernhard,

vielen Dank für deine Antwort.
Ich habe nochmal die Hardware überprüft, konnte aber keine Fehler oder 
Kurzschlüsse feststellen.

Das Problem ist weiterhin, dass die SDA Leitung auf Null ist. Das wird 
auch durch das Busy Bit im SR2 Register angezeigt.

Dadurch bleibt das Programm natürlich schon an der ersten Zeile

1

while(I2C_GetFlagStatus(I2C2,I2C_FLAG_BUSY));

hängen. Auch auskommentieren bringt ja nix, dann bleibt er bei der 
nächsten while-Schleife hängen.

Die weiteren Register habe ich überprüft, ich konnte aber keine 
Besonderheiten feststellen.

Ich verstehe nicht wieso die Leitung auf low ist obwohl ich noch keine 
Kommunikation begonnen habe. Ach das Takten "per Hand" hat wie oben 
schon beschrieben nicht funktioniert.

Hast du vielleicht noch eine Idee?

Wie sind denn die Pins konfiguriert? (Welches Gehäuse)

Ansonsten hat hier scheinbar jemand ein ähnliches Problem:
Beitrag "TPA81 an STM32F103 I2C Problem"

Hallo Bernhard,

ich habe nochmal ein wenig probiert und bin einen Schritt weiter 
gekommen.
Das Problem, dass der Bus schon zu Beginn Busy ist, ist behoben.
Jetzt bleibt das Programm an folgender Stelle hängen:

1

  //warte auf I2C

2

  while(I2C_GetFlagStatus(I2C2,I2C_FLAG_BUSY));

3

  //Start

4

  I2C_GenerateSTART(I2C2, ENABLE);

5

  while(!I2C_CheckEvent(I2C2, I2C_EVENT_MASTER_MODE_SELECT));

Er sollte eigentlich die Start-Bedingung senden, bleibt aber in der 
letzten while Schleife hängen. Im Anhang einmal der Verlauf auf dem 
Ossi.

Ich prüfe jetzt nochmal genau die Flags, vielleicht habe ich da etwas 
übersehen.

Hat vielleicht noch jemand eine Idee?


Danke und Gruß Frank

Hab die Register überprüft.
Die zwei entscheidenden Bits, die auch in der letzten while Schleife 
abgefragt werden, sind im Status Register 2:
- Bit 1 Busy
- Bit 0 MSL

Auf diese beiden Bits wird abgefragt, sie sind jedoch nicht gesetzt.
Stellt sich die Frage warum nicht.

Laut Referenz Manual sollen beide Bits per Hardware gesetzt werden.