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 ?
Angehängte Dateien:
-
OSzi.jpg
230 KB
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?
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
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 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.
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
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?
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
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?
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.
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
Angehängte Dateien:
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.
Leicht off-topic: Ein RTB2004 mit USB-Schnittstelle und ohne Screenshot-Funktion? Oder hat der Internet-Zugangspunkt keine USB-Schnittstelle?
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
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
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
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.
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.
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?
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.
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.
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/12/Bakkarbeit.pdf 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.
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.
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.
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)
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
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.
Marco D. schrieb: > Die 7 Bit Adresse lautet 1001000 oder 0x48 Wie oben schon geschrieben, benutzen HAL und SPL 8-Bit Adressen. Probiere also mal 0x90 (schreiben) bzw. 0x91 (lesen).
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.