mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik I2C Takt merkwürdig, keine Kommunikation möglich


Autor: Marco D. (Gast)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Servus Leute,

ich versuche mich gerade das erste mal in der Kommunikation mittels 
I2C-Schnittstelle zwischen meinem uC Board und einer Platine die mir im 
Rahmen einer HiWi-Arbeit zur Verfügung gestellt wurde. Die Platine ist 
nichts spektakuläres, da sind hauptsächlich ein paar LED-Treiber drauf 
sowie ein Temperatursensor mit I2C-Schnittstelle den ich auslesen 
möchte. Ich verwende ein STM32F302R8 Board.

Ich habe mittels CubeMX eine SPI-Schnittstelle konfiguriert und dann 
mittels  HAL_I2C_Master_Transmit(...) ein Signal an den Sensor gesendet. 
Da sich nichts getan hat, habe ich die Transmit-Funktion in die 
while(1)-Schleife gepackt und SCL und SCA auf einem Oszi ausgeben 
lassen. Ich bekomme ein sehr merkwürdiges SCL Signal welches ich auch 
nicht triggern kann. Im Anhang ein Single Bild. Die Tastköpfe sind 
abgeglichen.

Hat jemand eine Idee warum das Signal so verzerrt ist ?

Autor: A-Freak (Gast)
Datum:

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

Autor: stm32 (Gast)
Datum:

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

Autor: Christian S. (roehrenvorheizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielleicht müßte eine kleinerer Pullup-Widerstand angeschlossen sein 
oder die Frequenz vermindert werden. Dann sieht man auch das ACK.
Wobei hier SCL abgebildet sein dürfte.

MfG

Autor: Marco D. (Gast)
Datum:

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

Autor: HildeK (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Chris K. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Marco D. schrieb:
> Ich dachte der uC schaltet die intern dazu.

Glauben ist nicht Wissen

Autor: Wolfgang (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: stm32 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Ingo L. (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco D. schrieb:
> Ich dachte der uC schaltet die intern dazu.
Er hat interne Pull-ups, die sind aber für I2C viel zu hochohmig

Autor: Johannes S. (jojos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ein Bus sollte eh auf beiden Seiten abgeschlossen werden!

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

Gruss Chregu

Autor: Mad (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TrollJäger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Christoph db1uq K. (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. Also sollten da Treiber 
dazwischen, die noch nebenbei die Pegelwandlung übernehmen. Bei GPIB 
sind Widerstände auf beiden Seiten üblich, aber da geht es auch um 
TTL-Signale über mehrere Meter Entfernung mit entsprechenden 
Leitungskapazitäten.
Das Oszillogramm zeigt klar einen zu hochohmigen Pullupwiderstand. 
Irgendwo muss aber einer sein, der Tastkopf gibt jedenfalls keine 
Spannung ab.

: Bearbeitet durch User
Autor: Fred R. (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mad (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: TrollJäger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fred R. (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Alles klar direkt an den Pins den Pegel auf H ziehen ist bescheuert.
Wieder was gelernt. Danke

Autor: HildeK (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Boris O. (bohnsorg) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Leicht off-topic: Ein RTB2004 mit USB-Schnittstelle und ohne 
Screenshot-Funktion? Oder hat der Internet-Zugangspunkt keine 
USB-Schnittstelle?

Autor: Roland F. (rhf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

Boris O. schrieb:
> Leicht off-topic: Ein RTB2004 mit USB-Schnittstelle und ohne
> Screenshot-Funktion? Oder hat der Internet-Zugangspunkt keine
> USB-Schnittstelle?

Bei R&S braucht man für ein Bildschirmfoto kein USB, da reicht ein 
Netzwerkkabel und ein Internet-Browser.

rhf

Autor: TrollJäger (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Roland F. (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

TrollJäger schrieb:
> Zum Thema Dimensionierung:
>
> http://www.ti.com/lit/an/slva689/slva689.pdf

Sehr interessant, aber wäre es da nicht einfacher sich mit einem 
Oszilloskop die Signale anzusehen und dann einfach den richtigen 
Widerstand per probieren auszuwählen? Das ist zwar dann nicht das reine 
Vorgehen eines Ingenieurs, eliminiert aber vielleicht einige 
Einflussfaktoren die bei einer reinen Rechnung nicht sofort ersichtlich 
sind.

rhf

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fred R. (fredylich)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TrollJäger schrieb:
> Ob das sinnvoll ist und eines
> Ingenieurs würdig, das mus jedes einzele Individuum für sich selber
> beantworten...

Hatte mich doch bedankt.
Nicht jedes Individuum ist ein würdiger Ingenieurs wie Du.
Bin nur Techniker also der Langsamere.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph db1uq K. schrieb:
> Das Oszillogramm zeigt klar einen zu hochohmigen Pullupwiderstand.

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

Autor: HildeK (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: TrollJäger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christoph db1uq K. (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob man das wired-AND oder wired-OR nennt hängt nur von der Bezeichnung 
der Pegel ab. Bei GPIB wird "mindestens ein Open-collector 
durchgeschaltet" als High bezeichnet, obwohl das Signal dann auf GND 
liegt. Wenn man bei I2C die üblichen TTL-Bezeichnungen nimmt, ist das 
ein wired-AND, die Schaltung ist aber identisch.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph db1uq K. (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das funktioniert vermutlich auch mit solchen runden Flanken, aber es 
ist nicht zuverlässig. Wenn es so aussieht sollte man die Schaltung 
nochmal überdenken.

Zum Thema GPIB gibt es eine Bachelorarbeit aus Wien.
http://elektronomikon.org/wp-content/uploads/2017/...
Hier werden normalerweise Treiber bestückt, aber man kann sie auch durch 
Null-Ohm-Widerstände ersetzen. Dann bekommt man aber Probleme mit 
gemischten Betriebsspannungen.
Dasselbe gilt auch für I2C. Es kann gut gehen, muß aber nicht. Wenn ein 
neu angeschlossenes Gerät einen pull-up nach +5V hat, dann ist das für 
nicht-tolerante 3,3V-Logik ein Problem.

Autor: TrollJäger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TrollJäger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin S. (martin_s86)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Erst die Flanken in Ordnung bringen!
> Dafür ist ein Oszi gut geeignet.

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.

Christoph db1uq K. schrieb:
> Ja das funktioniert vermutlich auch mit solchen runden Flanken, aber es
> ist nicht zuverlässig. Wenn es so aussieht sollte man die Schaltung
> nochmal überdenken.

Ihr solltet alle mal euer Geschreibsel hier überdenken.

I2C hat immer "kräftige Verrundungen". Das ist das Prinzip hinter einem 
Open-Collector.

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.

Nur Unwissende behaupten, dass an dem Bild definitiv eine zu langsame 
steigende Flanke vorliegt.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco D. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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)

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marco D. schrieb:
> HAL_StatusTypeDef

Da sind ja return Werte drin, die du mal abfragen solltest. Generell 
gibt es bei I²C immer die Unsicherheit, welche Library welche 
Adressierung verwendet.

Da gibt es 7-bit Adressen + RW-Bit die z.B. beim Standard EEPROM (24C02) 
als 0x50 + R/W bit benutzt werden (7-bit Adresse), aber auch die 
Notation '0xA0 | R/W Bit', so das beim Lesen 0xA1 und beim Schreiben 
0xA0 als Adresse benutzt wird.

Dieser EEPROM hat z.B. auch noch die Besonderheit der 'Restart 
Condition', die mögl. auch dein Sensor braucht. Dabei wird erstmal die 
gewünschte Registeradresse mit I2C Write gesetzt, dann kommt eine 
Re-Adressierung mit gesetztem Read-Bit, um das Register zu lesen. 
Überprüfe das Datenblatt des I²C Slaves darauf.

Aus dem HAL Aufruf schliesse ich eher auf letztere Variante (8-bit 
Adressen), die zumindest bei der SPL auch üblich war. Da wir nicht 
wissen, welchen Chip du ansprechen willst, bleibts erstmal dabei. Hat 
denn das periphere Board jemals funktioniert? Oder liegt da evtl. ein C 
noch direkt an SCL und/oder SDA?

: Bearbeitet durch User
Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
  * @param  DevAddress Target device address The device 7 bits address value
  *         in datasheet must be shifted to the left before calling the interface

: Bearbeitet durch User
Autor: Klaus (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.