I2C Takt merkwürdig, keine Kommunikation möglich

Da ist wohl entweder der Pullup-Widerstand oder die parasitäre Kapazität 
(lange Leitungen) zu groß, oder der Takt zu schnell.

Zeig doch mal deinen Schaltplan. Deine Pullup Widerstände scheinen 
falsch gewählt zu sein. Welchen Wert hast du gewählt und warum?

Ich hab keine Pullups dazugeschaltet, ich hänge die Leitungen direkt ans 
Oszi. Ich dachte der uC schaltet die intern dazu.

Marco D. schrieb:
> Hat jemand eine Idee warum das Signal so verzerrt ist ?

Es ist nicht verzerrt.
Bei I2C wird die steigende Flanke über den Pullup gemacht, die fallende 
wird aktiv nach unten gezogen. Dann sieht das im Prinzip immer so aus, 
warum so deutlich, wurde genannt.
Höher als 5k-10k (bei 5V-Systemen) bzw. 3k3-5k bei 3.3V-Systemen würde 
ich mit dem Widerstand nicht gehen.

Marco D. schrieb:
> Ich dachte der uC schaltet die intern dazu.

Glauben ist nicht Wissen

Marco D. schrieb:
> Ich habe mittels CubeMX eine SPI-Schnittstelle konfiguriert und dann
> mittels  HAL_I2C_Master_Transmit(...) ein Signal an den Sensor gesendet.

SPI ist nicht I2C

Wolfgang schrieb:
> Marco D. schrieb:
>> Ich habe mittels CubeMX eine SPI-Schnittstelle konfiguriert und dann
>> mittels  HAL_I2C_Master_Transmit(...) ein Signal an den Sensor gesendet.
>
> SPI ist nicht I2C

Guter Punkt. Habe ich völlig überlesen.

Oder besser richtige Open Drain ohne PullUp, aber die hat der STM soweit 
ich weiß nicht.
Das Oszi hat auch einen USB Anschluss, über einen Memorystick bekommt 
man schönere Hardcopies vom Bildschirm.

Ein Bus sollte eh auf beiden Seiten abgeschlossen werden!

Das gälte auch für Z80 u.ä. Systeme!

Gruss Chregu

Marco D. schrieb:
> Ich bekomme ein sehr merkwürdiges SCL Signal welches ich auch
> nicht triggern kann.

Auf fallende Flanke triggern und das Trigger-Level mal in die Mitte von 
VCC schieben, dann wirds auch was mit dem Trigger....

Christian M. schrieb:
> Ein Bus sollte eh auf beiden Seiten abgeschlossen werden!
> Das gälte auch für Z80 u.ä. Systeme!

Verwechselst du da nicht was?

Z80 ist doch kein Bus.
Und zwei Enden zum Abschließen hat man z.B. bei 10-Base-2, Can, RS-485, 
ISDN, aber sicher nicht bei I²C.

Christian M. schrieb:
> Ein Bus sollte eh auf beiden Seiten abgeschlossen werden!
>
> Das gälte auch für Z80 u.ä. Systeme!
>
> Gruss Chregu

I2C beidseitig abschließen? Nicht dein Ernst (zumindest nicht bis 
400kHz, und darum geht es hier).

Wired-AND bzw. Funktionsweise I2C-Bus ist aber schon ein Begiff, oder?

Christoph db1uq K. schrieb:
> Das Oszillogramm zeigt klar einen zu hochohmigen Pullupwiderstand.
> Irgendwo muss aber einer sein, der Tastkopf gibt jedenfalls keine
> Spannung ab.

Garnix klar.

I2C lässt im Standard-Mode 1µs Rise-Time zu. Mehr als den Verdacht, dass 
diese Anforderung gerade so erfüllt bzw. nicht erfüllt ist, lässt dieses 
Bild garnicht zu.

Ich behaupte die Probleme kommen nicht von einem zu hohen Pull-Up.

Fred R. schrieb:
> TrollJäger schrieb:
>> I2C beidseitig abschließen? Nicht dein Ernst (zumindest nicht bis
>> 400kHz, und darum geht es hier).
>
> Warum nicht gibt es da einen Nachteil wenn ich sage mal ab 1Meter
> Leitung und 5Volt auf beide Seiten je 10kOhm anschließe?

Das ist in etwa so sinnvoll, wie pro Platine 500 0R-Widerstände 
aufzulöten... machbar aber bescheuert. Aber manche stehen halt auf 
sowas.

Fred R. schrieb:
> Alles klar direkt an den Pins den Pegel auf H ziehen ist bescheuert.

Bescheuert ist das nicht.
Die LH-Flanke durch den Pullup im I2C-Signal ist relativ uninteressant, 
bis auf die Rise-Time (<1µs im Standard-Mode). Wo auch immer der PU 
sitzt, ist egal, Hauptsache sein Wert ist für die Anwendung, 
Spezifikation der Teilnehmer und die Geschwindigkeitsklasse richtig. 
Siehe I2C-Spezifikation, die im Netz zu finden ist.
Im Anhang ein Auszug über den Wert des PU (Rp). [Rs ist ein optionaler 
Serienwiderstand an den Pins].

Ich würde ihn auf jeden Fall nahe an einem der beteiligten ICs setzen, 
denn dort habe ich sowieso VCC zur Verfügung anstatt irgendwo, wo ich 
mir noch 'ne extra Leitung für VCC hinlegen muss.

HildeK schrieb:
> dort habe ich sowieso VCC zur Verfügung anstatt irgendwo, wo ich
> mir noch 'ne extra Leitung für VCC hinlegen muss.

Wo benötigt man I2C auf der Platine aber keine Versorgung? (Mir bisher 
in 20 Jahren nicht begegnet) Der Bus geht zu einem IC hin, der dann auch 
üblicherweise mit Vcc versorgt werden muss...

Fred R. schrieb:
> Alles klar direkt an den Pins den Pegel auf H ziehen ist bescheuert.

Da bringst du was durcheinander... Hast grad deine Tage? Scheinst ja im 
"Wörter nach eigenem Gusto umdrehen" gerade den Weltrekord zu brechen 
:-)

Wie auch immer, nochmal - nur diesmal langsamer und detaillierter für 
die Langsameren unter uns: Du kannst auch 500 Widerstände nehmen, und 
diese alle 2mm an die Leitungen hängen, solange der Gesamtwiderstand 
(und Kapazität) im Rahmen bleibt. Ob das sinnvoll ist und eines 
Ingenieurs würdig, das mus jedes einzele Individuum für sich selber 
beantworten...

Zum Thema Dimensionierung:

http://www.ti.com/lit/an/slva689/slva689.pdf

TrollJäger schrieb:
> Wo benötigt man I2C auf der Platine aber keine Versorgung?

Das meinte ich nicht. Sondern irgendwo im 'freien Platinenfeld' muss 
nicht immer VCC auch geführt sein, am IC schon.

Roland F. schrieb:
> dann einfach den richtigen Widerstand per probieren auszuwählen?

Kann man machen, wird aber nichts bringen. Die gezeigten Signale sind 
ok, tausend mal gemacht. Kann man aber auch hier im Forum nachlesen. In 
jedem I2C Thread kommt das so:

>> Mach mal die Pullups kleiner!
> hat nichts gebracht

Meist kommt dann noch:

>> Da fehlt der Abblockkondensator!
> hab ich eingelötet, geht trotzdem nicht

Un zu guter letzt:

>> Mach das ganze viel langsamer!
> geht immer noch nicht

MfG Klaus

Christoph db1uq K. schrieb:
> Wobei das Wired-OR zu Zeiten reiner 5V-Logik noch kein Problem war.
> Ich möchte einen GPIB-Bus (der arbeitet nur mit wired-OR) am Raspberry
> PI betreiben, der eigentlich nur 3,3V mag.

I²C ist Wired-AND.

Dann manchst du halt die Pull-Up Widerstände an 3,3V. Ich sehe da kein 
Problem.

Christoph db1uq K. schrieb:
> Das Oszillogramm zeigt klar einen zu hochohmigen Pullupwiderstand.

Wie kannst du das erkennen, ohne zu wissen, wie die Taktflanken liegen?

Wolfgang schrieb:
> Wie kannst du das erkennen, ohne zu wissen, wie die Taktflanken liegen?

Das sieht man an der kräftigen Verrundung. Der Beginn der Flanken ist 
auch ganz klar: da wo der Knick vom LOW zur steigenden Flanke ist.

Fred R. schrieb:
> Nicht jedes Individuum ist ein würdiger Ingenieurs wie Du.

Ist auch gut so... Wo kämen wir hin ohne fähige Bäcker, Schreiner oder 
Klemptner? Solange sie ihren Job beherrschen ist doch alles in Butter. 
Und genau hier liegt der Hund begraben: auch Elektronik sollte man mit 
ausreichend Fachwissen bauen und nicht irgendwie zusammenschustern. Hat 
man dieses Fachwissen nicht, so sollte man dies schleunigst nachholen. 
Ist ja kein Hexenwerk. Früher musste man dazu noch Bücher wälzen, heute 
geht das wesentlich einfacher (wenn auch qualitativ deutlich schlechter)

Komischerweise würde jeder schreien, wenn ein gelernter Metzger sich als 
Bäcker ausgibt und in dem Beruf arbeitet.  Aber wenn Elektronik 
"entwickelt" wird, so ist jeder noch so unbedarfter zumindest ein 
"Maker" wenn nicht gleich ein "Entwickler".

> Bin nur Techniker also der Langsamere.

Was hat das eine mit dem anderen zu tun?

HildeK schrieb:
> Das sieht man an der kräftigen Verrundung. Der Beginn der Flanken ist
> auch ganz klar: da wo der Knick vom LOW zur steigenden Flanke ist.

Was SDA macht, solange SCL auf LOW ist, ist völlig Schnuppe. Dafür ist 
der Takt da. Vor der steigenden Flanke von SCL kann SDA beliebig rund 
sein.

Christoph db1uq K. schrieb:
> Wenn ein
> neu angeschlossenes Gerät einen pull-up nach +5V hat, dann ist das für
> nicht-tolerante 3,3V-Logik ein Problem.

Wobei dies dann unter "Basteln" fällt, da man einen 3V3-Bus und einen 
5V-Bus getrennt betrachten sollte.

nxp hat da einige Dokumente dazu, hier zwei als Auswahl:

https://www.nxp.com/docs/en/application-note/AN10441.pdf

https://www.nxp.com/docs/en/application-note/AN10418.pdf

Wolfgang schrieb:
> Was SDA macht, solange SCL auf LOW ist, ist völlig Schnuppe. Dafür ist
> der Takt da. Vor der steigenden Flanke von SCL kann SDA beliebig rund
> sein.

Keineswegs.

Wenn SDA seinen Pegel ändert, während SCL auf LOW ist, dann bedeutet 
dies entweder ein START oder ein STOP Signal.

Christoph db1uq K. schrieb:
> aber es
> ist nicht zuverlässig. Wenn es so aussieht sollte man die Schaltung
> nochmal überdenken.

Das ist aber nicht das Problem. Beim TO geht es zuverlässig, nämlich 
immer gar nicht.

MfG Klaus

Mal eine ganz triviale Idee: schifte doch mal die Adresse um eins nach 
rechts und teste mal ob du ein ACK vom Slave bekommst. In manchen 
Datenblättern steht es etwas merkwürdig formuliert.

Tipp am Rande: wenn an deiner Arbeitsstelle ein R&S Oszi steht, so haben 
sie auch ganz sicher einen Logic-Analyzer. Das wäre dann das geeignete 
Werkzeug...

TrollJäger schrieb:
> Tipp am Rande: wenn an deiner Arbeitsstelle ein R&S Oszi steht, so haben
> sie auch ganz sicher einen Logic-Analyzer. Das wäre dann das geeignete
> Werkzeug...

Erst die Flanken in Ordnung bringen!
Dafür ist ein Oszi gut geeignet.
Ein LA eher nicht, denn der schleift das Signal "schön" rechteckig.

Später, wenn die Grundfunktion gewährleistet ist, dann ist ein LA das 
richtige, um das Protokoll, bzw. den Datenstrom, zu untersuchen.

Ich möchte erwähnen, dass nicht alle Slaves eine "richtige" I²C 
Schnittstelle gemäß der Spezifikation von NXP haben (mit Tiefpass-Filter 
und Schmitt-Trigger). Diese reagieren schlecht auf so extrem flache 
Flanken, wie wir sie auf dem Oszilloskop-Bild sehen.

Martin S. schrieb:
> Ihr solltet alle mal euer Geschreibsel hier überdenken.

Und du solltest nicht Sinn verzerrend zitieren!

Es kann sein dass du manche Texte nicht verstehst, aber das berechtigt 
dich nicht zu öffentlichen Urteilen.

Martin S. schrieb:
> Das einzige was man hier offensichtlich erkennen kann, ist dass die
> Rise-Time in der Dimension um 1µs liegt. Alles andere ist Glaskugel. Im
> Standard-Mode wie bereits angemerkt sollte die Rise-Time unter 1µs
> liegen. Es lohnt also eine konkrete Messung. Die wurde hier bisher nicht
> gemacht bzw. ist nicht vom Bild ablesbar.

Und selbst wenn der Wert von 1µs gerissen wird, ist das Fehlerbild 
nicht: "geht gar nicht". Hier bellt der Hund den falschen Baum an.

MfG Klaus

Stefanus F. schrieb:
> Christian M. schrieb:
>> Ein Bus sollte eh auf beiden Seiten abgeschlossen werden!
>> Das gälte auch für Z80 u.ä. Systeme!
>
> Verwechselst du da nicht was?
>
> Z80 ist doch kein Bus.
> Und zwei Enden zum Abschließen hat man z.B. bei 10-Base-2, Can, RS-485,
> ISDN, aber sicher nicht bei I²C.

Nein nein, ich verwechsle nichts. Nur weil man es nicht macht, ist das 
technisch noch lange nicht sauber.

Jeder Bus, also jede Leitung eines Buses, sollte am Ende abgeschlossen 
werden. Bidirektionale Leitungen an beiden Enden.

Und dazu gehören auch I²C und auch z.B. die Datenleitungen eines 
Z80-Systems. Wobei es normal bei so kurzen Leitungen nicht gemacht wird, 
da Reflektionen keinen grossen Einfluss auf die Flanken haben.

Bei I²C wird nur auf das Wired-OR geschaut und Refektionen ausser acht 
gelassen, darum nur jeweils ein R irgendwo.

Ich persönlich mache auf beiden Seiten ein R rein, habe so auch längere 
Leitungen ohne Probleme realisiert (>10m).

Gruss Chregu

Klaus schrieb:
> Selbst wenn der Wert von 1µs gerissen wird, ist das Fehlerbild
> nicht: "geht gar nicht". Hier bellt der Hund den falschen Baum an.

Das nicht, aber es ist ein deutlicher hinweis, was man mit geringstem 
Aufwand als erstes versuchen sollte.

Wenn mein Fahrrad plötzlich schwergängig wird und es pfffft macht, 
greife ich schließlich auch zuerst nach der Luftpumpe.

Martin S. schrieb:
> HildeK schrieb:
>> Das sieht man an der kräftigen Verrundung. Der Beginn der Flanken ist
>> auch ganz klar: da wo der Knick vom LOW zur steigenden Flanke ist.

Du solltest verstehen, worauf ich mich bezogen hatte.
Es wurde behauptet, man kann nicht wissen, wo die Taktflanken liegen:

Wolfgang schrieb:
> Wie kannst du das erkennen, ohne zu wissen, wie die Taktflanken liegen?

Wir sehen nach Aussagen des TO im ersten Post auf dem Skope SCL. Und wo 
die Flanken liegen, ist dort eindeutig zu erkennen. Ob es mit dem SDA 
zusammenpasst, kann man nicht sehen.

Und weil die Anstiegszeit bei rund 1µs (ich hätte eher gesagt, noch 
mehr) liegt, ist auch die I2C-Spezifikation ev. verletzt. So eine müde 
Flanke lässt auf einen zu hochohmigen PU oder zu hohe kapazitive Last an 
SCL schließen.
Nichts anderes hat Christoph db1uq K. behauptet.
Das hat auch der TO bestätigt:

Marco D. schrieb:
> Ich hab keine Pullups dazugeschaltet, ich hänge die Leitungen direkt ans
> Oszi. Ich dachte der uC schaltet die intern dazu.

Marco D. hat seither nichts mehr dazu gesagt. Vielleicht haben 
brauchbare PUs sein Problem schon gelöst.

Habe die Pullups hinzugefügt und den Takt etwas runtergeschraubt. Jetzt 
sieht es schon ordentlich uas und ich kann auch das Adressbyte über den 
Master versenden was ich mir an meinem Oszi anzeigen lassen kann. Ich 
bekomme allerdings kein ACK-Bit vom Slave. Habe von meinem Betreuer 
erfahren das er selbst Probleme damit hat. Er meinte es liege wohl an 
einer Busyflag die vom Master gesetzt aber nicht zurückgenommen wird und 
somit den Slave blockiert. Hat jemand von euch Erfahung damit gemacht ? 
Ich verwende die Funktion:

HAL_StatusTypeDef HAL_I2C_Master_Transmit(I2C_HandleTypeDef *hi2c, 
uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout)

ich hatte vor kurzem auch einen zickigen Sensor, da hatten dann 
Serienwiderstände von 100R in den SDA/SCL Leitungen geholfen.
Beitrag "Omron D6T Thermal Sensor"
Die HAL möchte 8 Bit Adressen, findet man in den Parameterbeschreibungen 
in den Quellen.

1

  * @param  DevAddress Target device address The device 7 bits address value

2

  *         in datasheet must be shifted to the left before calling the interface

Ich zitier mich mal selber

Klaus schrieb:
> Kann man machen, wird aber nichts bringen. Die gezeigten Signale sind
> ok, tausend mal gemacht. Kann man aber auch hier im Forum nachlesen. In
> jedem I2C Thread kommt das so:
>
>>> Mach mal die Pullups kleiner!
>> hat nichts gebracht
>
> Meist kommt dann noch:
>
>>> Da fehlt der Abblockkondensator!
>> hab ich eingelötet, geht trotzdem nicht
>
> Un zu guter letzt:
>
>>> Mach das ganze viel langsamer!
>> geht immer noch nicht

Marco D. schrieb:
> Habe die Pullups hinzugefügt und den Takt etwas runtergeschraubt. Jetzt
> sieht es schon ordentlich aus und ich kann auch das Adressbyte über den
> Master versenden was ich mir an meinem Oszi anzeigen lassen kann. Ich
> bekomme allerdings kein ACK-Bit vom Slave.

Stefanus F. schrieb:
> Klaus schrieb:
>> Selbst wenn der Wert von 1µs gerissen wird, ist das Fehlerbild
>> nicht: "geht gar nicht". Hier bellt der Hund den falschen Baum an.
>
> Das nicht, aber es ist ein deutlicher hinweis, was man mit geringstem
> Aufwand als erstes versuchen sollte.
>
> Wenn mein Fahrrad plötzlich schwergängig wird und es pfffft macht,
> greife ich schließlich auch zuerst nach der Luftpumpe.

Wenn du schon vergleichst, solltest du ein Fahrrad nehmen, bei dem sich 
die Räder noch nie gedreht haben.

MfG Klaus

Johannes S. schrieb:
> Die HAL möchte 8 Bit Adressen, findet man in den Parameterbeschreibungen
> in den Quellen.

Jedes I2C Device will mit 8 Bit angesprochen werden, nämlich 7Bit + Read 
oder Write im LSB. Bei vielen Devices sind auch noch 1-3Bit zusätzlich 
vorhanden, um die Adresse modifizieren zu können.
Die Fragen sind aber:
- wie ist der Wert im Datenblatt gemeint. Manche nennen eine 7Bit-, 
andere zwei 8Bit-Adressen.
- wie spricht die SW das Device an, als z.B. über zwei Funktionen Read 
und Write mit 7Bit-Adresse, die dann schiebt und R bzw W hinzufügt oder 
eine Funktion, der man Rd bzw. Write in der 8Bit-Adresse mit übergeben 
muss.

Es gibt auch (sicherlich wenige) Devices, die im Timing kritisch sind. 
Wir haben das an einem Imager mal erlebt. Da könnten schon 
unterschiedliche Leitungslängen von SCL und SDA zuschlagen. Das führt 
aber meist nur zu sporadischen Fehlern.

Ich möchte den Temperatursensor LM75B auslesen. Mit einem Genuino Board 
hat es jetzt funktioniert die Register auszulesen, daher kann ich sicher 
sein, dass der IC funktionsfähig ist. Hier der Arduino Code:

#include<Wire.h>

void setup() {
 Serial.begin(9600);
 Wire.begin();
 }

void loop() {
 Wire.beginTransmission(72);

 Wire.write(3); //register 0x03 auslesen

 Wire.endTransmission();

 Wire.requestFrom(72,2);

 while(Wire.available() == 0);

 int antwort = Wire.read();
 Serial.print(antwort);
 antwort = Wire.read();
 Serial.print(antwort);
 Serial.println("\n");

 delay(1000);
}

Die 7 Bit Adresse lautet 1001000 oder 0x48. Mit dem Nucleo habe ich es 
versucht mit:

if(HAL_I2C_IsDeviceReady(&hi2c2,0x48<<1,10,10) == HAL_OK){
      HAL_GPIO_TogglePin(GPIOB,GPIO_PIN_13);
    }
Nichts tut sich, daher sollte ich ausschließen können das es an meinem 
Code liegt, es sei denn ihr seht noch einen Fehler. Ich hab es auch mit 
der mem_read Funktion versucht was auch nichts gebracht hat. Scheinbar 
hat mein Betreuer recht und es liegt am HAL code.

Hab ich auch schon versucht, tut sich auch nichts.

Wire.BeginTransmission(73)? du willst ja was hinschreiben
( gesetztes RW-Bit )

Wie bereits geschrieben habe ich mit dem Arduino die Register von dem IC 
ausgelesen und nicht reingeschrieben. Das hat auch funktioniert, die 
Antwort des IC's war die erwartete.