Hallo zusammen, ich hab das Problem, dass ich 2 Sensoren via I2C auf einem Arduino auslesen möchte. Die Sensoren werden auch erkannt, jedoch funktionieren sie nur wenn ich sie einzeln in einem separaten Programm betreibe. Wenn ich beide Sensoren gleichzeitig betreiben möchte, kommt immer die Fehlermeldung dass einer nicht erkannt wird. SDA/SCL von Sensor 1 hängen über Pullup-Widerstände direkt am 3,3V Ausgang des Arduinos, SDA/SCL von Sensor 2 hängen über Pullup-Widerstände auf einem 3,3V Spannungsregler, der wiederum am 5V Ausgang des Arduinos hängt. Ist das auch schon das Problem oder kann es an etwas anderem liegen?
Flets G. schrieb: > dass ich 2 Sensoren via I2C auf einem Arduino auslesen möchte. Die müssen naturgemäss geheim bleiben, sonst wäre es ja zu leicht für die Leserschaft zu lösen .....
Flets G. schrieb: > Ist das auch schon das Problem Durchaus Flets G. schrieb: > oder kann es an etwas anderem liegen Durchaus Es wurden I2C Levelschifter erfunden. (irgendwann mal) Erstaunlich finde ich, dass Sensoren und Arduino geheim bleiben. Soll das die Frage interessanter machen?
Die zwei geheimen Sensoren haben nicht zufällig die gleiche I²C-Adresse?
Flets G. schrieb: > Ist das auch schon das Problem oder kann es an etwas anderem liegen? Haben Beide evtl. dieselbe I2C-Adresse?
Flets G. schrieb: > ich hab das Problem, dass ich 2 Sensoren via I2C auf einem Arduino > auslesen möchte. Dann löse dein Problem. Um welche Sensoren handelt es sich genau und wie sind sie verschaltet.
Angehängte Dateien:
-
MPU6050.JPG
290 KB -
BMP280.JPG
200 KB
Es handelt sich um einen BMP280 und MPU6050 Adressen sind unterschiedlich
Bei beiden I2C Teilnehmern ist der I2C Bus mit Widerständen gegen 3,3 Volt geschaltet. Einmal Busabschluss reicht.
Hannes schrieb: > Bei beiden I2C Teilnehmern ist der I2C Bus mit Widerständen gegen 3,3 > Volt geschaltet. > Einmal Busabschluss reicht. ~1k8 sollte jeder I²C-Teilnehmer treiben können. Mit welcher Bitrate wird der Bus den betrieben? Wurde "A direct connection between CSB and VDDIO is recommended" beachtet?
Wie kommst Du auf 1,8kOhm? Die Widerstände sind parallel geschaltet und das ist wohl etwas weniger!
EAF schrieb: > Es wurden I2C Levelschifter erfunden. Ja, aber die braucht man nur in speziellen Fällen.
Hannes schrieb: > Wie kommst Du auf 1,8kOhm? > Die Widerstände sind parallel geschaltet und das ist wohl etwas weniger! 2.2kΩ parallel zu 10kΩ ergeben 1.8kΩ
Hannes schrieb: > Die Widerstände sind parallel geschaltet und das ist wohl etwas weniger! das kann man rechnen, wie rechnest du? Stefan ⛄ F. schrieb: > 2.2kΩ parallel zu 10kΩ ergeben 1.8kΩ danke Stefan, dann muss ich nicht rechnen der Rechner sagt aber auch 1,80327k also ich kann 1,8k bestätigen oder eher mehr statt weniger
Parallel Schaltung 1/R1 + 1/R2 1/2.2 + 1/10 = ?
Joachim B. schrieb: > das kann man rechnen, wie rechnest du? Rges = 1/( (1/R1) + (1/R2) ) > also ich kann 1,8k bestätigen oder eher mehr statt weniger Die Parallelschaltung der beiden Widerstände hat effektiv 1,8kΩ und das ist so technisch völlig in Ordnung.
Ähm 1x I²C und 1x SPI Mischen? Das muss Probleme geben, da quatscht dir die SPI Device immer ins I²C Signal.
Patrick L. schrieb: > Ähm 1x I²C und 1x SPI Mischen? nein, der Chip von Bosch kann SPI und I²C. Hier wird er im I²C Modus verwendet.
Stefan ⛄ F. schrieb: > nein, der Chip von Bosch kann SPI und I²C. Hier wird er im I²C Modus > verwendet. Da wäre ich mir nicht so sicher ob der das dann auch versteht. Ich sehe keine Probleme mit den PullUps, da ist I²C eigentlich recht unempfindlich. Aber ich sehe Probleme wenn da ja DO und DI mit dem µC Verbunden sind, das doch ein BusMix entsteht. LA dran hängen, Bus loggen und dann wird die Wahrheit ans Licht kommen.
Stefan ⛄ F. schrieb: > Joachim B. schrieb: >> das kann man rechnen, wie rechnest du? > > Rges = 1/( (1/R1) + (1/R2) ) Stefan die retorische Frage ging an Hannes weil er das nicht glauben wollte also ich kann 1,8k bestätigen oder eher mehr statt weniger > Die Parallelschaltung der beiden Widerstände hat effektiv 1,8kΩ ist mir egal was effektiv rauskommt, ich habs sogar 2x gerechnet R1 * R2 / (R1 + R2) = 1/(1/R1 + 1/R2) und beide Male über 1,8k ist effektiv MEHR als 1,8k und widerspricht dem Hannes Hannes schrieb: > Wie kommst Du auf 1,8kOhm? > Die Widerstände sind parallel geschaltet und das ist wohl etwas weniger!
Aus dem Datenblatt lese ich speziell zu I2C(S.28): CSB must be connected to VDDIO to select I²C interface. Nur ist er im Schaltplan über einen Pull-Up Widerstand an Vcc angeschlossen. Auch das ist das Connection Diagram(S.37) anders aufgebaut als im Schaltplan. Die I2C-Leitung im besten Fall so kurz wie möglich gestalten.
Rainer S. schrieb: > CSB must be connected to VDDIO to select I²C interface. Denke ich auch. Verbinde mal CSB direkt mit 3V3. LG, Sebastian
mh schrieb: > ~1k8 sollte jeder I²C-Teilnehmer treiben können. > Mit welcher Bitrate wird der Bus den betrieben? Es kommt nicht auf die Größe des Widerstandes, sondern auf den Strom an. Der maximale Strom sollte normalerweise eigentlich im Datenblatt unter Absolute Maximum Ratings angegeben sein. Manche Hersteller scheinen das aber nicht für nötig zu halten. Im Kapitel 16.1 der I2C Spezifikation (S.38f) ist die Dimensionierung der Pull-Up Widerstände für den I2C im Standard-Mode beschrieben. http://i2c2p.twibright.com/spec/i2c.pdf Joachim B. schrieb: > der Rechner sagt aber auch 1,80327k also ich kann 1,8k bestätigen oder > eher mehr statt weniger Das "eher mehr statt weniger" kannst man sich sparen. Bei einem heutigen 1,8kΩ Widerstand mit 1% Toleranz lohnt es nicht, über die dritte Stelle mach dem Komma nachzudenken.
Wolfgang schrieb: > Das "eher mehr statt weniger" kannst man sich sparen. Bei einem heutigen > 1,8kΩ Widerstand mit 1% Toleranz lohnt es nicht, über die dritte Stelle > mach dem Komma nachzudenken. weiss ich doch, wer mehr als 3 Stellen hinterm Komma angegeben hatte wurde zu meiner Studienzeit vom Professor persönlich aus dem E-Labor geworfen. Es ist halt nur so das 1,803k eben mehr ist als 1,8k und nicht weniger wie Hannes schrieb.
:
Bearbeitet durch User
Patrick L. schrieb: > Da wäre ich mir nicht so sicher ob der das dann auch versteht. Was ist dir an der Aussage "If CSB is connected to VDDIO, the I²C interface is active." (Datenblatt 5.1 Interface selection) unklar? Rainer S. schrieb: > Aus dem Datenblatt lese ich speziell zu I2C(S.28): > CSB must be connected to VDDIO to select I²C interface. CSB hat sogar einen internen Pull-Up, d.h. wenn CSB nicht auf Gnd gezogen wird, sollte der BMP280 das I2C-Interface aktivieren. Leider scheint im Datenblatt keine Spezifikation für die IOs angegeben zu sein. Ob der interne Pull-Up reicht, ggf. zusammen mit den 10kΩ auf dem Modul ausreicht, um einen sicheren H-Pegel zu generieren, sollte doch festzustellen sein ;-) Und die Tatsache, dass das Modul einzeln funktioniert, spricht dafür, dass der BMP280 richtig in den I2C Modus geht. Oder gibt es bei der Verdrahtung der Gesamtschaltung noch Dinge, die man wissen müsste? Geht CSB sonst noch irgendwo hin? Nur mal so als Denkanstoß: Könnte es vielleicht an der (unbekannten) Software liegen?
Sebastian schrieb: > Rainer S. schrieb: >> CSB must be connected to VDDIO to select I²C interface. > > Denke ich auch. Verbinde mal CSB direkt mit 3V3. Laut Datenblatt, wird er dir den I²C ZeitweiseBlokieren, wer sagt das der µC nicht mal schnell den CSB auf "low" zieht? Ich denke dass da das Problem liegt. Was die Software im µC macht verrät uns die "Glaskugel" ja auch nicht. Und der Kaffeesatz wurde schon im Kompost entsorgt, kann es also da auch nicht mehr rausleasen.
:
Bearbeitet durch User
Joachim B. schrieb: > Es ist halt nur so das 1,803k eben mehr ist als 1,8k und nicht > weniger wie Hannes schrieb. Woher weißt du das? Der Ausgangswert kann keine größere Genauigkeit als die Eingangswerte haben. Dein Professor hat meine volle Unterstützung ;-)
Patrick L. schrieb: > LA dran hängen, Bus loggen und dann wird die Wahrheit ans Licht kommen. Ein Logikanalyzer ist hier für die erste Messung zu binär. Ich würde angesichts der fraglichen Anzahl an beteiligten Pullups ganz einfach erst mal die Pegel und Flanken mit einem Oszillosokop ansehen. Und erst, wenn da alles im grünen Bereich ist, kommt der LA zum Einsatz. Flets G. schrieb: > kommt immer die Fehlermeldung dass einer nicht erkannt wird. Wer generiert diese Fehlermeldung? Und wie kommt er zu diesem Schluss?
:
Bearbeitet durch Moderator
Joachim B. schrieb: > Es ist halt nur so das 1,803k eben mehr ist als 1,8k und nicht > weniger wie Hannes schrieb. Das hat er bestimmt anders gemein.
Patrick L. schrieb: > Laut Datenblatt, wird er dir den I²C ZeitweiseBlokieren, wer sagt das > der µC nicht mal schnell den CSB auf "low" zieht? Der µC hat an CSB überhaupt nichts zu suchen. Vielleicht wird das noch etwas mit einem VOLLSSTÄNDIGEN Schaltplan, nicht nur irgendwelche Modulfetzen.
Wolfgang schrieb: > CSB hat sogar einen internen Pull-Up, d.h. wenn CSB nicht auf Gnd > gezogen wird, sollte der BMP280 das I2C-Interface aktivieren. Der CSB-Pullup ist allerdings nur für die SPI-Schnittstelle beschrieben :) LG, Sebastian
Wolfgang schrieb: > Der µC hat an CSB überhaupt nichts zu suchen. Klar, Nur verrät uns dass weder die Glaskugel, noch der TO.... Es wird nur ein "Symptom" präsentiert, ein par Rädchen vom Salami hingelegt, und der Rest ist ein wildes Ratespiel. Fact: 1.)Kommunikation klemmt, wen beide Sensoren parallel betrieben werden. 2.)Vermutungen wegen Pullup Problemen werden geäußert. 3.)Komplette Schaltung Unbekannt 4.)CSB hängt nicht wie im Datenblatt gefordert auf 3V3 Vermutungen: zu 1.) Alles mögliche weil viele Unbekannte. zu 2.) Halte ich für unwahrscheinlich, wenn die Datenrate nicht knapp an der Grenze liegt (Neue Unbekannte) zu 3.) Typische Salamitaktik zu 4.) kann da unbekannt was an CSB (noch) dranhängt die Ursache sein aber eben auch (Unbekannt) Also ERGO: Ein wildes Ratespiel. Scope/LA Messung würde mindestens da unterstützen.
Sebastian schrieb: > Der CSB-Pullup ist allerdings nur für die SPI-Schnittstelle beschrieben > :) Hääh? Der Pull-Up hat überhaupt nichts zu melden, wenn der Pin hart auf Gnd gezogen wird.
Angehängte Dateien:
Wolfgang schrieb: > Und die Tatsache, dass das Modul einzeln funktioniert, spricht dafür, > dass der BMP280 richtig in den I2C Modus geht. Oder, dass die Software der Einzelprogramme anders am CSB-Pin herumzerrt... Aber es kostet ja nichts, den R16 einfach mal durch eine schlichte Brücke zu ersetzen. Dann zerrt sicher keiner an dem Pin herum und die Forderung nach einem definierten Pegel driekt beim Einschalten ist sicher erfüllt. Flets G. schrieb: > Es handelt sich um einen BMP280 und MPU6050 Nur, falls ich es überlesen habe: welcher davon wird eigentlich "nicht erkannt"? Nicht, dass das noch der MPU6050 ist...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > R16 einfach mal durch eine schlichte Brücke zu ersetzen Beide Seiten von R16 sind nach draussen geführt ... LG, Sebastian
Flets G. schrieb: > Wenn ich beide Sensoren gleichzeitig betreiben möchte, kommt immer die > Fehlermeldung dass einer nicht erkannt wird. Dann Fang damit an, dass dieses Programm auch läuft, wenn nur 1 IC steckt. Und dann entferne Mal das eine, Mal das andere IC. Mögliche Fehler: * Schlechte Pegel (--> oszi, 3,3V/5V, zuviele pullups) * Multitasking (IC Zugriff gleichzeitig) * Umschaltung SPI/I2C per uC (also fest an gnd bzw. Vcc Nägeln) * Beliebige SW-Fehler Fange in SW damit an, dass Du nur auf das ACK beider ICs achtest. IC 1 anwählen, led1 toggeln, wenn ACK. Ic2 anwählen, led2 toggeln wenn ACK. Pause 0,5s und von vorne. Wenn beide laufen, dann mit einfacher Antwort erweitern. Es ist wichtig zuerst zu erkennen, ob es SW ist oder HW.
Joachim B. schrieb: > wer mehr als 3 Stellen hinterm Komma angegeben hatte wurde zu meiner > Studienzeit vom Professor persönlich aus dem E-Labor geworfen. Warum Stellen nach dem Komma anders sind, habe ich nie verstanden. (Und die Tischmultimeter entsorge ich kostenlos bei ihm)
Sebastian schrieb: > Beide Seiten von R16 sind nach draussen geführt ... Ja, dann muss er halt rausgehen, um den zu brücken und diesen Pin zuverlässig auf den richtigen Pegel zu fixieren. Carsten W. schrieb: > Bitte stelle einen Schaltplan ein. Und zwar nicht einen von jedem verwendeten Modul, sondern einen, der zeigt, wie der ganze Klimbim tatsächlich verschaltet ist. Den muss man dann möglicherweise tatsächlich selber malen...
Lothar M. schrieb: > Oder, dass die Software der Einzelprogramme anders am CSB-Pin > herumzerrt... Sag ich ja, ohne die geheime Software und einen Schaltplan der aufgebauten Schaltung ist das hier alles müßig. Erste Tat in solchen Fällen ist bei mir immer, einen I2C-Scanner auf den µC zu spielen, der einem auflistet, auf welchen Adressen sich ein I2C-Slave angesprochen fühlt.
Wolfgang schrieb: > Erste Tat in solchen Fällen ist bei mir immer, einen I2C-Scanner auf den > µC zu spielen, der einem auflistet, auf welchen Adressen sich ein > I2C-Slave angesprochen fühlt. Und wenn nix anderes Bezahlbar ist bekommt man für Lau ein BusPirat, oder macht ihn nach Anleitung auf HackaDay selber. https://hackaday.com/tag/bus-pirate/ Dan hast du ein Werkzeug das dir in vielen Situationen Hilft. Es sei den du hast schon ein LA und/oder Oszi.
A. S. schrieb: > Warum Stellen nach dem Komma anders sind, habe ich nie verstanden. rechnerisch ist vieles möglich sogar 1/0 oder -3 Fahrgäste im Bus und 3 müssen einsteigen damit der endlich ohne Fahrgäste ist. Mesgeräte mit besser 1/10 % Messtoleranz wurden uns vorenthalten.
:
Bearbeitet durch User
Wolfgang schrieb: > Ob der interne Pull-Up reicht, ggf. zusammen mit den 10kΩ auf dem Modul > ausreicht, um einen sicheren H-Pegel zu generieren, sollte doch > festzustellen sein ;-) Eher nicht zuverlässig, da das Datenblatt sagt: "A direct connection between CSB and VDDIO is recommended." Patrick L. schrieb: > Laut Datenblatt, wird er dir den I²C ZeitweiseBlokieren, wer sagt das > der µC nicht mal schnell den CSB auf "low" zieht? Nö, das Datenblatt sagt: "After CSB has been pulled down once [...], the I²C interface is disabled until the next power-on-reset." Also nix mit "ZeitweiseBlokieren" sondern "dauerhaft SPI". Die Frage "Mit welcher Bitrate wird der Bus den betrieben?" habe ich übrigens nicht wegen der Pull-ups gestellt. Es gibt Zeitgenossen, die mit jedem I²C-Bus-Teilnehmer mit deren max. Bitrate sprechen wollen und dabei eben vergessen, dass alle anderen auch mithören können müssen. Irgendwas läuft hier gründlich schief. Die Wortklauberei in Beiträgen die in diesem Forum stattfindet sollte lieber auf Datenblätter angewendet werden. Auf der anderen Seite die Geheimniskrämerei der Fragensteller aus Angst zu viel zu schreiben, um zu vermeiden, dass ein Wortklauber die Anfrage komplett zerlegt. Und zu guter letzt noch das Herumreiten auf komplett irrelevanten Sachen wie dem Widerstandswert und der (Un-)Fähigkeit diesen zu berechnen um den Thread zur kompletten Unlesbarkeit aufzublähen. Wie im Kindergarten hier. Sorry, aber das musste raus...
mh schrieb: > Herumreiten auf komplett irrelevanten Sachen wie dem Widerstandswert stimmt, aber jeder hat so seine Fanboys und welche die IMMER widersprechen müssen, Falschaussagen dürfen aber IMHO widersprochen werden sonst: Wenn ständig die Klügeren nachgeben regieren irgendwann die Dummen. Der rechnerische Wert von 2,2k || 10k ist nun mal größer als 1,8k auch wenn das egal ist.
:
Bearbeitet durch User
Patrick L. schrieb: > Es sei den du hast schon ein LA und/oder Oszi. Ein LA, der als Frontend über USB am PC hängt und seinen Zweck in solchen Fällen erfüllt, kostet keine 10€. Selbst vom Taschengeld lässt sich diese Investition stemmen ;-)
Patrick L. schrieb: > Und wenn nix anderes Bezahlbar ist bekommt man für Lau ein BusPirat, Der I2C-Scanner ist für lau, wenn man schon den Arduino hat: https://www.arduino.cc/reference/en/libraries/i2cscanner/
Angehängte Dateien:
-
uC.JPG
260 KB
Also der BMP ist nur über 3.3V, GND, SDA und SCL mit dem Arduino verbunden, MPU über 5V, GND, SCA und SCL CSB Anschluss führt nirgendwo hin Im Anhang die Anschlüsse zum Arduino
1 | #include <pitches.h> |
2 | #include <Wire.h> |
3 | #include <SPI.h> |
4 | #include <Servo.h> |
5 | #include<SD.h> |
6 | #include <I2Cdev.h> |
7 | #include <MPU6050_6Axis_MotionApps20.h> |
8 | #include <Adafruit_BMP280.h> |
9 | |
10 | Adafruit_BMP280 bmp; |
11 | MPU6050 mpu; |
12 | |
13 | #define MPU6050_ADDR 0x68
|
14 | #define MPU6050_ACCEL_CONFIG 0x1C
|
15 | #define MPU6050_PWR_MGT_1 0x6B
|
16 | #define MPU6050_INT_PIN_CFG 0x37
|
17 | #define MPU6050_INT_ENABLE 0x38
|
18 | #define MPU6050_LATCH_INT_EN 0x05
|
19 | #define MPU6050_ACTL 0x07
|
20 | #define MPU6050_WOM_EN 0x06
|
21 | #define MPU6050_WOM_THR 0x1F
|
22 | #define MPU6050_MOT_DUR 0x20
|
23 | #define MPU6050_ACCEL_INTEL_CTRL 0x69
|
24 | #define MPU6050_SIGNAL_PATH_RESET 0x68
|
25 | #define INTERRUPT_PIN 2
|
26 | |
27 | bool LEDtrigger=true; |
28 | volatile bool mpuInterrupt = false; |
29 | bool dmpReady = false; |
30 | uint8_t mpuIntStatus; |
31 | uint8_t devStatus; |
32 | uint16_t packetSize; |
33 | uint16_t fifoCount; |
34 | uint8_t fifoBuffer[64]; |
35 | |
36 | void setup() |
37 | {
|
38 | |
39 | Serial.begin(115200); |
40 | Wire.begin(); |
41 | Wire.setClock(400000); |
42 | |
43 | mpu.initialize(); |
44 | pinMode(INTERRUPT_PIN, INPUT); |
45 | devStatus = mpu.dmpInitialize(); |
46 | |
47 | mpu.setXGyroOffset(11); |
48 | mpu.setYGyroOffset(34); |
49 | mpu.setZGyroOffset(58); |
50 | mpu.setZAccelOffset(1197); |
51 | |
52 | if (devStatus == 0) { |
53 | mpu.CalibrateAccel(6); |
54 | mpu.CalibrateGyro(6); |
55 | mpu.PrintActiveOffsets(); |
56 | mpu.setDMPEnabled(true); |
57 | |
58 | attachInterrupt(digitalPinToInterrupt(INTERRUPT_PIN), dmpDataReady, RISING); |
59 | mpuIntStatus = mpu.getIntStatus(); |
60 | dmpReady = true; |
61 | packetSize = mpu.dmpGetFIFOPacketSize(); |
62 | }
|
63 | |
64 | if(!bmp.begin()) { |
65 | Serial.println("BMP nicht erkannt"); |
66 | for(int i=0;i<10;i++) |
67 | {
|
68 | tone(buzzer,NOTE_C7,100); //Alarm wenn BMP nicht erkannt wird |
69 | delay(150); |
70 | tone(buzzer,NOTE_A6,100); |
71 | delay(100); |
72 | }
|
73 | }
|
74 | |
75 | |
76 | if(!dmpReady) { |
77 | Serial.println("MPU nicht erkannt"); |
78 | for(int i=0;i<10;i++) |
79 | {
|
80 | tone(buzzer,NOTE_C7,100); //Alarm wenn MPU nicht erkannt wird |
81 | delay(150); |
82 | tone(buzzer,NOTE_A6,100); |
83 | delay(100); |
84 | }
|
85 | }
|
86 | |
87 | |
88 | void loop () |
89 | {
|
90 | .
|
91 | .
|
92 | .
|
93 | }
|
94 | |
95 | |
96 | void writeRegister(uint16_t reg, byte value) |
97 | {
|
98 | Wire.beginTransmission(MPU6050_ADDR); |
99 | Wire.write(reg); |
100 | Wire.write(value); |
101 | Wire.endTransmission(); |
102 | }
|
103 | |
104 | void motion() |
105 | {
|
106 | accEvent = true; |
107 | detachInterrupt(2); |
108 | }
|
109 | |
110 | void dmpDataReady() { |
111 | mpuInterrupt = true; |
112 | }
|
Das sind die relevanten Ausschnitte aus dem Code, ich überprüfe gleich am Anfang die Verfügbarkeit der Sensoren, der BMP wird im Gegensatz zum MPU nie erkannt.
Und im Grunde hab ich hier eigentlich nur 1:1 die Breakoutboards der Sensoren nachdesignt um alles einheitlich auf einer Platine zu haben, deswegen findet sich beim MPU Schaltplan auch ein Spannungsregler, der in diesem Fall hier unnötig ist, da ich VCC eigentlich direkt an 3,3V des Arduinos anschließen hätte können.
Joachim B. schrieb: > A. S. schrieb: >> Warum Stellen nach dem Komma anders sind, habe ich nie verstanden. > > rechnerisch ist vieles möglich sogar 1/0 oder -3 Fahrgäste im Bus und 3 > müssen einsteigen damit der endlich ohne Fahrgäste ist. > > Mesgeräte mit besser 1/10 % Messtoleranz wurden uns vorenthalten. hat das irgendwas mit Joachim B. schrieb: > Stellen hinterm Komma zu tun? 1k234 ist identisch zu 1234R oder 0,001234M
Flets G. schrieb: > CSB Anschluss führt nirgendwo hin Dann leg den jetzt direkt auf 3V3, wie es das DB empfiehlt. Flets G. schrieb: > Und im Grunde hab ich hier eigentlich nur 1:1 die Breakoutboards der > Sensoren nachdesignt Hast du den gemeinsamen Betrieb der einzelnen Module auf dem Steckbrett auch ausprobiert? Geht da dann auch nichts? Und wie gesagt: die I²C-Signale mal mit dem Oszi anschauen.
:
Bearbeitet durch Moderator
mh schrieb: > Irgendwas läuft hier gründlich schief. Die Wortklauberei in Beiträgen > die in diesem Forum stattfindet sollte lieber auf Datenblätter > angewendet werden. Auf der anderen Seite die Geheimniskrämerei der > Fragensteller aus Angst zu viel zu schreiben, um zu vermeiden, dass ein > Wortklauber die Anfrage komplett zerlegt. Und zu guter letzt noch das > Herumreiten auf komplett irrelevanten Sachen wie dem Widerstandswert und > der (Un-)Fähigkeit diesen zu berechnen um den Thread zur kompletten > Unlesbarkeit aufzublähen. Wie im Kindergarten hier. Sorry, aber das > musste raus... Full ACK !!! Sowas nervt einfach nur noch Zum Problem: Hier muss unbedingt gemessen werden. Und nicht nur SDA und SCL einzeln, sondern zusammen damit man einen zeitlichen Zusammenhang hat. Alles andere ist nur Raten..
:
Bearbeitet durch User
Der Nano Every ist ein Exot. Nicht alle Libs können damit umgehen. Durchaus möglich, dass sich da die I2C Implementierungen ins Gehege kommen. Z.B die eine Lib nutzt Wire und die andere BitBanging Was sagt der I2C Scanner? Wenn der nicht beide findet, liegt ein Verkabelungsproblem vor.
EAF schrieb: > Was sagt der I2C Scanner? Der I2C Scanner erkennt beide Sensoren, sonst würden sie im Einzelnen ja auch nicht funktionieren
Flets G. schrieb: > Der I2C Scanner erkennt beide Sensoren, sonst würden sie im Einzelnen ja > auch nicht funktionieren Dann wird es wohl an deiner Software liegen. Nur für's Protokoll: Erkennt der Scanner den BMP280 auch als I2C-Slave, wenn CSB nicht direkt, sondern über den 10kΩ Pull-Up an 3.3V liegt?
Wolfgang schrieb: > Erkennt der Scanner den BMP280 auch als I2C-Slave, wenn CSB nicht > direkt, sondern über den 10kΩ Pull-Up an 3.3V liegt? Ja tut er
Vielleicht bin ich doof, aber ich habe nicht verstanden, ob der I²C Scanner die Chips beide zusammen angeschlossen erkannt hat, oder nur einzeln.
Mmh, das ist mysteriös. Hast du es zur Fehlersuche schon mal mit 100kHz probiert? LG, Sebastian
Sebastian schrieb: > Mmh, das ist mysteriös. Hast du es zur Fehlersuche schon mal mit 100kHz > probiert? DAS war die Lösung!!! Ich danke dir vielmals!!!!!!
Theoretisch müsste es auch 400 kHz funktionieren, der Bosch Sensor kann sogar mehr als 3 MHz. Ein Oszilloskop-Bild von SDA und SCL könnte helfen.
Flets G. schrieb: > DAS war die Lösung!!! > Ich danke dir vielmals!!!!!! Die hättest du aber auch schon um 10:52 haben können;-) Patrick L. schrieb: > zu 2.) Halte ich für unwahrscheinlich, wenn die Datenrate nicht knapp an > der Grenze liegt (Neue Unbekannte) Aber egal Hauptsache es läuft jetzt, gut das [Sebastian] nochmals explizit darauf hingewiesen hat, sonnst hätten wir wohl noch lange gerätselt :-D
Stefan ⛄ F. schrieb: > Theoretisch müsste es auch 400 kHz funktionieren einzeln oft, aber auch ich merkte schon das mit geringerem Pegel 3,3V statt 5V, erstmalig am ESP32 die Kabel entscheidend werden sprich der pullup und die Kabelkapazität. 100kHz läuft stabiler und sicherer. Da schlägt die Praxis wieder mal die Theorie, 400kHz sind kritischer wenn die pullups hochohmig sind. Noch schlimmer 2 pullups 2,2k & 10k an verschiedenen Punkten evt. blöd sitzen. Sternverkabelung am I2C ist auch kein Bus, ich bin sicher es wurde Stern verkabelt! Der TO könnte mal einen echten Verdrahtungsplan malen oder zeigen!
:
Bearbeitet durch User
Ja stimmt, jetzt wo du es sagst... Aber auf jeden Fall Dankeschön fürs lange Rätsel raten :-D
Joachim B. schrieb: > Da schlägt die Praxis wieder mal die Theorie, 400kHz sind kritischer > wenn die pullups hochohmig sind. Noch schlimmer 2 pullups 2,2k & 10k an > verschiedenen Punkten evt. blöd sitzen. Man könnte die Pull-Ups so weit verkleinern, wie es die I2C-Spezifikation zulässt. Was passiert bei 400kHz, wenn man noch 2,7kΩ od. 3,3kΩ Widerstände zusätzlich einbaut, um der steigenden Flanke etwas auf die Sprünge zu helfen.
Wolfgang schrieb: > Was passiert bei 400kHz, wenn man noch 2,7kΩ > od. 3,3kΩ Widerstände zusätzlich einbaut, um der steigenden Flanke etwas > auf die Sprünge zu helfen. klaro aber dann sollte man den pullup am Ende der langen Leitung setzen und einen Bus und keinen Stern verkabeln, denn das ist so gefordert, auch wenn Stern bedingt oft klappt ist es falsch.
:
Bearbeitet durch User
Flets G. schrieb: > Sebastian schrieb: >> Mmh, das ist mysteriös. Hast du es zur Fehlersuche schon mal mit 100kHz >> probiert? > DAS war die Lösung!!! Was für ein brutaless Gefrickel! Solche elementaren Probleme sieht man mit einem Oszi nach 1 Minute. Und man kann auch gleich noch beurteilen, wo es denn klemmt. Patrick L. schrieb: > Aber egal Hauptsache es läuft jetzt Was sagt da der durchschnittliche Softie mit stolzgeschwellter Brust? "Mein Programm ist fertig!" Joachim B. schrieb: > Der TO könnte mal einen echten Verdrahtungsplan malen oder zeigen! Nicht nötig, es läuft!
Mit 400kHz sollte es auch gehen, insbesonders mit 1k8 Pullups wie jetzt, da ist irgendwo noch ein Wurm drin, und es ist nicht gesagt das der sich nicht auch bei 100kHz, nur seltener, zeigt. LG, Sebastian
Lothar M. schrieb: > Was sagt da der durchschnittliche Softie mit stolzgeschwellter Brust? > "Mein Programm ist fertig!" sogar bei C&P
Joachim B. schrieb: > klaro aber dann sollte man den pullup am Ende der langen Leitung setzen Das ist ausgesprochen schwierig. Je nach dem, aus welchem Blickwinkel du guckst, sitzt der Pull-Up mal am Anfang und mal am Ende der Leitung.
Joachim B. schrieb: > klaro aber dann sollte man den pullup am Ende der langen Leitung setzen > und einen Bus und keinen Stern verkabeln, denn das ist so gefordert, > auch wenn Stern bedingt oft klappt ist es falsch. Was ist denn "Bus statt Stern"? Und warum sollten Pullups vorne oder hinten (oder im sternpunkt) relevant sein?
Frag schrieb: > Und warum sollten Pullups vorne oder hinten (oder im sternpunkt) > relevant sein? Üblicherweise wegen der Terminierung, aber diesen Begriff kennt I2C eh nicht. Oder andersrum: für eine Terminierung müssten die Widerstände irgendwo im Bereich um/unter 100 Ohm haben. Denn in diesem Bereich spielt auch die Leitungsimpedanz.
Lothar M. schrieb: > Frag schrieb: >> Und warum sollten Pullups vorne oder hinten (oder im sternpunkt) >> relevant sein? > Üblicherweise wegen der Terminierung, aber diesen Begriff kennt I2C eh > nicht. Pull-Up Widerstände am Sternpunkt hätten nichts mit Terminierung zu tun. I2C sieht allerdings die Möglichkeit von Serienwiderständen bei jedem Client vor. Geschwindigkeitsbegrenzend wirkt sich auch die Leitungskapazität aus. Ohne Kenntnis des realen Aufbaus und ein Oszilloskop bleibt die Ursachenforschung für die beobachteten Probleme allerdings reines Stochern im Nebel.
Frag schrieb: > Was ist denn "Bus statt Stern"? dein google kaputt? https://technikkram.net/wp-content/uploads/2020/05/NetzwerkTopologien.png
Joachim B. schrieb: > dein google kaputt? > https://technikkram.net/wp-content/uploads/2020/05/NetzwerkTopologien.png Und bei 3 Teilnehmern ist der Bus bei I2c besser als Stern? (Wobei der Stern bei deinem Bild und 3 teilnehmern exakt Linie oder Baum entspricht) Bist du sicher, dass du das nicht mit terminierten Bussen verwechselst?
Frag schrieb: > Und bei 3 Teilnehmern ist der Bus bei I2c besser als Stern? Das kommt auf die Kabellängen an.
Wolfgang schrieb: > Frag schrieb: >> Und bei 3 Teilnehmern ist der Bus bei I2c besser als Stern? > > Das kommt auf die Kabellängen an. ähh ?!? LOL gut wenn man aneinander Vorbeiredet. ist natürlich immer Bus bei 3 Teilnehmer. Höchstens "Ring" wäre noch möglich. Aber für 1²C gibt es ganz gute "Appnotes" und wenn die Kabel ganz lang werden ein Busrepeater oder Treiber beim Master setzen oft auch sehr Hilfreich. Ich habe Anwendungen Realisiert wo ich jede Device über einen ADuMxxx sogar galvanisch trenne, weil sonst ev. Störung oder Zerstörung eintreten kann. Und wenn die Leitungen extrem lang weerden sogar auf 12V Hochgesetzt, anständig Terminiert, und das geht dann über Gaaanz lange Leitungen sehr gut. Aber das ist hier eindeutig am Thema vorbei. An den TO: Frag Tante Gurgel nach Appnotes für I²C Bus, es gibt sogar mittlerweile Onlinecalculatoren um die Widerstände nach Bus-länge und Eigenschaften so wie Geschwindigkeit zu berechnen.
Patrick L. schrieb: >> Das kommt auf die Kabellängen an. > > ähh ?!? LOL gut wenn man aneinander Vorbeiredet. Tun wir sicher nicht. Bei ein paar Zentimetern ist es völlig egal, ob linearer Bus oder Stern. Erst bei langen Leitungen spielt die Topologie eine Rolle, weil dann ohne Terminierung bei zu steilen Signalen durch Signalreflektion die Flanken kaputt gehen. Im Fall von I2C helfen die Serienwiderstände, da die normalen Treiber nicht auf Leitungsterminierung mit Kabelimpedanz ausgelegt sind.
Wolfgang schrieb: > Tun wir sicher nicht. Es bezieht sich hier auf rein: Bus vs Stern bei 3 Teilnehmer, ist es egal ob der Master: 1.) Am Anfang 2.) In der Mitte 3.) Oder Am Ende sitzt, es ist immer Bus. Man könnte besten falls bei Variante 2 noch von "V Anordnung" sprechen. Aber sicher nicht von Stern. Da ging der "Wink mit dem Zaunpfahl" von [Frag (Gast)] hin. Deshalb aneinander vorbeigeredet ;-) Klar gehen die Flanken ohne Abschlusswiderstände an A.. logisch da spielen Leitung's-Induktivitäten und Kapazitäten eine große Rolle. und ein I²C bus der nur Aktiv auf GND zieht, ist da um so anfälliger drauf. Ohne Widerstände bleibt die Spannung ja immer zwischen "0" und "Floatend", aber niemals ein sauberes "1".
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.