Hat jemand beide Sensoren auf dem gleichen I2C-Bus zum laufen bekommen?
In einem Test an einer Blue-Pill laufen beide Sensoren einzeln
problemlos, jedoch wenn man diese parallel schaltet, schlägt die
Initialisierung öfters fehl und es werden falsche Werte gelesen.
Zum Beispiel in einem Wohnraum:
1
AHT = 77.52 % 2.29 °C
2
BMP = 761.73 mBar 7.22 °C
Nun steht im Datenblatt tatsächlich drinn, das der AHT10 keine anderen
Götter neben sich auf dem Bus zu dulden scheint (s. Screenshot S. 8)
Andererseits werden scheinbar Module verkauft, wo zumindest ein AHT20
zusammen mit einem BMP280 betrieben wird:
http://embedded-things.blogspot.com/2021/02/test-aht20bmp280-temperature-humidity.html
Hat jemand bereits Erfahrungswerte dazu, bevor man viele (vergebliche)
Stunden in die Analyse des I2C Bus investiert?
Wolfgang schrieb:> Sobald schrieb:>> Mir ist aufgefallen, dass der Chip einen Adresspin hat. Das widerspricht>> der Aussage unter Punkt 3.>> Woran hast du das gesehen?>> Im Datenblatt AHT20 steht davon nichts (Table 5, S.6)> https://www.evelta.com/content/datasheets/AHT20.pdf
Könnte es daran liegen, dass Du ein Datenblatt eines ATH20 angehängt
hast, während der TO von einem ATH10 schreibt (siehe Eingangsbeitrag)?
Sobald schrieb:> Könnte es daran liegen, dass Du ein Datenblatt eines ATH20 angehängt> hast, während der TO von einem ATH10 schreibt (siehe Eingangsbeitrag)?
Ja, könnte sein. Dann soll der TO mal das Datenblatt verlinken. Ein
AHT20 ist kein AHT10, aber nach diesem User Guide sollte auch der AHT10
ein normales I2C Interface besitzen.
https://www.handsontec.com/dataspecs/sensor/AHT10.pdf
...-. schrieb:> https://server4.eca.ir/eshop/AHT10/Aosong_AHT10_en_draft_0c.pdf
Danke - merkwürdig das Asong beim AHT10 keine aktuelle Version auf der
Web-Site verlinkt hat.
In dem Datenblatt gibt es zwar den Pin 1 mit Bezeichnung "ADR", aber der
soll fest auf Gnd gelegt werden, ist also beim Betrieb des Sensors aus
dem Spiel. Auch ist die gleiche I2C-Adresse wie für den AHT20 angegeben
(0x38).
Karsten W. schrieb:> Hat jemand bereits Erfahrungswerte dazu, bevor man viele (vergebliche)> Stunden in die Analyse des I2C Bus investiert?
Dann wäre das jetzt eine gute Gelegenheit, um zu üben, damit es in
Zukunft schneller geht ;-)
Erstmal hilft vielleicht schon ein Oszi. Wie groß sind deine Pull-Ups
und mit welcher Spannung läuft dein I2C bzw. deine Sensoren?
Jobst Q. schrieb:> Notfalls nimmt man einen I2C- Multiplexer.
Was soll das den jetzt für ein Nebenschauplatz sein. Erstmal sollte man
doch klären, was los ist und nicht gleich vor dem Problem Reißaus
nehmen.
Beide Sensoren nennen ihre Schnittstelle I2C und die Adressen kommen
sich nicht in die Quere (AHT10/20: 0x38, BMP280: 0x76 oder 0x77).
Mehrere AHT10/20 auf einem Bus wird natürlich nichts, ist aber hier
nicht das Thema.
...-. schrieb:> Only a single AHT10 can be connected to the I2C bus and no other I2C> devices can be connected
Dann ist das Datenblatt falsch.
[ ] AHT10 ist kein I2C Device
[ ] "and no other I2C devices can be connected" ist falsch
Um zu verstehen, was dort los ist, müsste man eben mal auf den Bus
gucken und das Thema nicht einfach in die Cloud auslagern.
Mit Serienwiderstände in den Busleitung sieht man auch noch, von wem ein
(evtl. fehlerhafter) dominanter Pegel kommt.
...-. schrieb:> und 10k Pullup ist bei 3.3 Volt eh viel zu viel.
Meine Glaskugel ist leider etwas getrübt, aber vielleicht hat auch
einfach nur das Steckbrett Kontaktprobleme oder es fehlt eine
Masseverbindung ;-)
Wolfgang schrieb:> Dann ist das Datenblatt falsch.> [ ] AHT10 ist kein I2C Device> [ ] "and no other I2C devices can be connected" ist falsch
So ist es.
Entweder es ist ein I2C-Device, dann muss es mit anderen I2C-Devices auf
demselben Bus koexistieren können, solange jedes seine eigene Adresse
hat. Das macht halt schließlich einen Bus aus. Oder es ist halt kein
I2C-Device.
Also ist entweder das Device Schrott oder das Datenblatt. Oder beides...
Genauer kann man das halt nur mit einer Analyse der Bus-Kommunikation
herausbekommen.
Ich persönlich würde darauf tippen, dass die Aussage "and no other I2C
devices can be connected" falsch ist.
Das Problem steckt vermutlich hier:
> 5.1 Start sensor> [...]> After power-on, the sensor> needs at most 20 milliseconds time SCL is high) to> reach the idle state, ready to receive commands sent> by the host (MCU).
Das muss vermutlich ergänzt werden durch die Aussage: "If the startup
conditions are not satisfied (even due to accesses to concurrencing
I2C-devices), the sensor will never reach it's idle state".
Das würde sehr schön passen zu dem unsäglichen China-Arduino-Dreck.
Aber: bisher natürlich nur eine reine Vermutung. Wäre erstmal zu
beweisen. Dem TO sollte das sehr leicht fallen. Einfach nach dem PowerUp
eine hinreichend lange Pause einbauen, bevor das erste Mal auf dem
I2C-Bus gequasselt wir, mit wem auch immer.
c-hater schrieb:> Das Problem steckt vermutlich hier: ...
Da der BMP280 auch Mist macht, würde es entweder bedeuten, dass der
AHT10 in dem fehlerhaften Zustand blöd dazwischen quatscht oder der
Fehler im Aufbau/Programm vom TO steckt.
Schade, dass er sich seit seinen einführenden Worten nicht mehr gemeldet
hat und nichts zur Lösung SEINES Problems beiträgt.
Wolfgang schrieb:> In dem Datenblatt gibt es zwar den Pin 1 mit Bezeichnung "ADR", aber der> soll fest auf Gnd gelegt werden, ist also beim Betrieb des Sensors aus> dem Spiel. Auch ist die gleiche I2C-Adresse wie für den AHT20 angegeben> (0x38).
Korrekt - wenn man den AHT10 einzeln anschließt, dann wird dieser bei
einem Scan des Bus auf 0x38 gefunden.
Der BMP380 entsprechend auf 0x76.
Einzeln werden dann schön korrekte Werte gelesen:
1
BMP = 1004.57 mBar 23.54 °C
2
BMP = 1004.52 mBar 23.46 °C
3
4
AHT = 51.66 % 24.57 °C
5
AHT = 51.44 % 24.41 °C
> Erstmal hilft vielleicht schon ein Oszi. Wie groß sind deine Pull-Ups> und mit welcher Spannung läuft dein I2C bzw. deine Sensoren?
Das ist gerade in der Analyse ...
Die Pullup's sind diejenigen die auf den Sensor-Platinen als Standard
bereits vorhanden sind.
Das müssten bei dem BMP280 10K sein und bei dem AHT10 4K7.
Im parallelen Betrieb beider Sensoren also 3,2K was vielleicht schon zu
wenig ist?
Auf dem DHT10-Platinchen sind ein Spannungsregler und Pegelumsetzer mit
drauf.
Wolfgang schrieb:> Um zu verstehen, was dort los ist, müsste man eben mal auf den Bus> gucken und das Thema nicht einfach in die Cloud auslagern.> Mit Serienwiderstände in den Busleitung sieht man auch noch, von wem ein> (evtl. fehlerhafter) dominanter Pegel kommt.
Interessanter Tip - Danke!
Wolfgang schrieb:> Meine Glaskugel ist leider etwas getrübt, aber vielleicht hat auch> einfach nur das Steckbrett Kontaktprobleme oder es fehlt eine> Masseverbindung ;-)
Das ist schon ein Aufbau mit richtigen Platinen und Pin-Headern, wo die
Platinen aufgesteckt sind.
c-hater schrieb:> Das Problem steckt vermutlich hier:>>> 5.1 Start sensor>> [...]>> After power-on, the sensor>> needs at most 20 milliseconds time SCL is high) to>> reach the idle state, ready to receive commands sent>> by the host (MCU).>> Das muss vermutlich ergänzt werden durch die Aussage: "If the startup> conditions are not satisfied (even due to accesses to concurrencing> I2C-devices), the sensor will never reach it's idle state".>> Das würde sehr schön passen zu dem unsäglichen China-Arduino-Dreck.> Aber: bisher natürlich nur eine reine Vermutung. Wäre erstmal zu> beweisen. Dem TO sollte das sehr leicht fallen. Einfach nach dem PowerUp> eine hinreichend lange Pause einbauen, bevor das erste Mal auf dem> I2C-Bus gequasselt wir, mit wem auch immer.
Gute Idee - die Wartezeit ist schnell im Code integriert!
Aber erst einmal kurz ein Oszi drann.
Wolfgang schrieb:> Schade, dass er sich seit seinen einführenden Worten nicht mehr gemeldet> hat und nichts zur Lösung SEINES Problems beiträgt.
Hehehe - so ist das manchmal am Wochenende - da planen andere die Zeit
einfach weg ...
Hatte auch sein Gutes, denn nun kann mit jede Menge Ideen fortgefahren
werden. :-)
Karsten W. schrieb:> Die Pullup's sind diejenigen die auf den Sensor-Platinen als Standard> bereits vorhanden sind.> Das müssten bei dem BMP280 10K sein und bei dem AHT10 4K7.> Im parallelen Betrieb beider Sensoren also 3,2K was vielleicht schon zu> wenig ist?
Was ist denn das für eine eigenwillige Konfiguration?
An jede Busleitung gehört normalerweise ein einziger Pull-Up. Sonst
bricht der Bus zusammen, wenn man plötzlich mal auf die Idee kommt, 10
Module drauf zu hängen, aber sei´s drum. Zu wenig sind die 3.2kΩ
bestimmt nicht. Im Datenblatt des AHT10 ist ein Maximalstrom von 10mA
angegeben. Da liegst du einen Faktor 10 drunter - also alles gut. 1mA
sollte eigentlich ok sein.
Mit welchem Clock lässt du den I2C laufen?
Guck dir die Signale (Signalform, Ack, Dateninhalte, Startzeit) und dein
Programm an.
Karsten W. schrieb:> Auf dem DHT10-Platinchen sind ein Spannungsregler und Pegelumsetzer mit> drauf.
Ich blicke durch deine Schaltplanfragmente gerade nicht ganz durch. Was
ist mit den jeweils 4.7kΩ auf den Pegelwandlern. Ziehen die den Bus
nicht auch hoch?
So - hier die Oszi-Messungen:
Der Bus läuft mit 100 KHz und die Pegel sehen eigentlich immer sauber
aus.
Aber - wenn beide Sensoren angeschlossen sind ist es mir nur einmal
gelungen, auf SDA etwas nach einem Reset per Trigger aufzuzeichnen!
Wenn die Sensoren ausgelesen werden, triggert nichts mehr, weder auf SCL
noch auf SDA!
Wolfgang schrieb:> Ich blicke durch deine Schaltplanfragmente gerade nicht ganz durch. Was> ist mit den jeweils 4.7kΩ auf den Pegelwandlern. Ziehen die den Bus> nicht auch hoch?
Tssss - warum denn nicht - sind doch nur die üblichen China-Schaltpläne!
:-)
So wie dieser BME280, der in Wirklichkeit immer nur ein BMP280 ist
(rechtes Platinchen im Bild).
Die Pullup-Widerstände sind dort im Schaltbild gar nicht dargestellt.
Zu Deiner Frage: Wie bereits geschrieben wurden jeweils Module
verwendet, weil die kleinen Mistdinger von Sensoren sonst kaum
kontaktiert werden können.
Wenn es an den Pullup-Widerständen liegt, könnte man ja noch ein paar
einfach auslöten.
Karsten W. schrieb:> Aber - wenn beide Sensoren angeschlossen sind ist es mir nur einmal> gelungen, auf SDA etwas nach einem Reset per Trigger aufzuzeichnen!
Dann lass deinen µC auf irgendeinem GPIO ein Signal ausgeben, dass du
auf den Externen Trigger vom Welec geben kannst und dann zeichne mit
Single Shot auf.
Damit die Zeitzusammenhänge klar werden, solltest du SCL und SDA
parallel messen - wozu hat das Oszi mehrere Kanäle.
Die Signalqualität, insbesondere Flankenlage und -steilheit lassen sich
bei höherer Zeitauflösung besser beurteilen, auch wenn man dann nicht
das ganze Signal drauf hat.
Karsten W. schrieb:> Wenn es an den Pullup-Widerständen liegt, könnte man ja noch ein paar> einfach auslöten.
Solange der Gesamtwiderstand nicht unter 1.5kΩ ist, brauchst du bestimmt
nicht dranrum zu löten. Bei zu kleinem Widerstand würde in deinen
Signalen evtl. der L-Pegel ansteigen, aber der sieht gut aus.
I2C schrieb:> Und was ist DAS hier ... ???
Das ist wohl eine kleine Lücke zwischen Signal vom Master und dem Signal
vom Slave. Entscheidend ist, wie dir Flanken vom SCL dazu liegen.
Wolfgang schrieb:> Mit den vorgeschlagenen Serienwiderständen ließe sich sicher sagen, was> von wem kommt
Das kommt vom AHT10, siehe Grafik weiter oben. Bei einem I2C-Bus habe
ich das noch nie gesehen.
Sobald schrieb:> Du solltest das Datenblatt anhängen.>> Mir ist aufgefallen, dass der Chip einen Adresspin hat. Das widerspricht> der Aussage unter Punkt 3.
Der Download-Link wurde oben schon genannt.
https://server4.eca.ir/eshop/AHT10/Aosong_AHT10_en_draft_0c.pdf
Hier noch einmal als Upload.
Weitere Tests leider erst morgen, da erneut ein Zeitraub vorliegt ...
I2C schrieb:> Karsten W. schrieb:>> Der Bus läuft mit 100 KHz und die Pegel sehen eigentlich immer sauber>> aus.>> Und was ist DAS hier ... ???
Gute Frage - könnte ein Sampling-Fehler sein oder ein Glitch.
Müsste ich noch Mal genauer wiederholen und auflösen.
Wolfgang schrieb:> Das ist wohl eine kleine Lücke zwischen Signal vom Master und dem Signal> vom Slave. Entscheidend ist, wie dir Flanken vom SCL dazu liegen.
Bei einer Wiederholung müsste also direkt mit 2 Kanälen gearbeitet
werden.
Wolfgang schrieb:> p.s.> Mit den vorgeschlagenen Serienwiderständen ließe sich sicher sagen, was> von wem kommt
Nicht unbedingt, weil der Trigger irgendwie nicht geklappt hat.
Karsten W. schrieb:> Wolfgang schrieb:>> p.s.>> Mit den vorgeschlagenen Serienwiderständen ließe sich sicher sagen, was>> von wem kommt>> Nicht unbedingt, weil der Trigger irgendwie nicht geklappt hat.
Doch, jeder Slave hängt über ein eigenen Serienwiderstand am Bus. Dann
kann man mit einer Messung alles sehen.
Wenn die Widerstände unterschiedlich sind, erkennt man am Pegel auf dem
Bus, wer ihn runter zieht. Die Widerstände müssen so gewählt werden,
dass der L-Pegel auf dem Bus trotzdem noch sicher erreicht wird.
c-hater schrieb:> Das Problem steckt vermutlich hier:>>> 5.1 Start sensor>> [...]>> After power-on, the sensor>> needs at most 20 milliseconds time SCL is high) to>> reach the idle state, ready to receive commands sent>> by the host (MCU).>> Das muss vermutlich ergänzt werden durch die Aussage: "If the startup> conditions are not satisfied (even due to accesses to concurrencing> I2C-devices), the sensor will never reach it's idle state".>> Das würde sehr schön passen zu dem unsäglichen China-Arduino-Dreck.> Aber: bisher natürlich nur eine reine Vermutung. Wäre erstmal zu> beweisen. Dem TO sollte das sehr leicht fallen. Einfach nach dem PowerUp> eine hinreichend lange Pause einbauen, bevor das erste Mal auf dem> I2C-Bus gequasselt wir, mit wem auch immer.
Der I2C Bus wurde ohnehin erst nach 2 Sekunden mit Wire.begin()
initialisiert, weil zuvor noch eine Startmeldung auf einem LCD
ausgegeben wird.
Sicherheitshalber wird nun direkt nach dem Start SCL als Output
geschaltet und auf High gelegt, aber dies hat leider keine Änderung
erbracht.
Wolfgang schrieb:> Doch, jeder Slave hängt über ein eigenen Serienwiderstand am Bus. Dann> kann man mit einer Messung alles sehen.> Wenn die Widerstände unterschiedlich sind, erkennt man am Pegel auf dem> Bus, wer ihn runter zieht. Die Widerstände müssen so gewählt werden,> dass der L-Pegel auf dem Bus trotzdem noch sicher erreicht wird.
Gibt es einen konkreten Vorschlag für passende Widerstände?
Ein paar neue Messungen mit 2 Kanälen.
Wenn beide Sensoren angeschlossen sind passiert auf dem I2C-Bus nach dem
Power-On und der Initialisierung nichts mehr.
Offensichtlich läuft hier nur noch die Initialisierung des AHT10, welche
im Code zuerst stattfindet.
Interessanterweise gibt die Initialisierung des BMP280 keine
Fehlermeldung zurück.
Die Messwerte die von den Leseroutinen geliefert werden sind daher
Unsinn - diesbezüglich müsste der Code geprüft werden.
Die Software wurde nun dahingehend geändert, daß vor jeder einzelner
Abfrage komplett der I2C-Bus und der jeweilige Sensor neu initialisiert
wird.
Im Ergebnis schlägt die Initialisierung der Sensoren fehl, sobald beide
Sensoren am Bus angeschlossen sind.
Einzeln funktioniert dies wunderbar.
Somit ist die Aussage des Datenblatt vom AHT10 korrekt, daß nur ein
AHT10 an einem I2C-Bus angeschlossen sein kann.
Dieser Sensor ist als I2C-Device einfach nur Müll!
Eine weitere Analyse von chinesischem Design-Müll hilft hier daher nicht
weiter.
Man muß also einen AHT20 kaufen, wenn weitere Sensoren am gleichen Bus
betrieben werden sollen.
Hier ist übrigens der Kombisensor mit AHT20:
https://www.aliexpress.com/item/1005003128566196.html
Karsten W. schrieb:> Sicherheitshalber wird nun direkt nach dem Start SCL als Output> geschaltet und auf High gelegt, aber dies hat leider keine Änderung> erbracht.
SCL als Output zu schalten und auf High zu legen, kann bei einer
Push-Pull Ausgangsstufe ziemlich ins Auge gehen. Ein I2C-Slave, der aus
irgendeinem Grund die Busleitung auf Low ziehen will (z.B. Clock
stretching), beißt sich daran die Zähne aus und macht (im Rahmen seiner
Möglichkeiten) einen KURZSCHLUSS. Beim I2C ist für den High-Zustand der
Bus-Leitungen einzig und alleine der Pull-Up Widerstand zuständig.
Karsten W. schrieb:> Im Ergebnis schlägt die Initialisierung der Sensoren fehl, sobald beide> Sensoren am Bus angeschlossen sind.> Einzeln funktioniert dies wunderbar.>> Somit ist die Aussage des Datenblatt vom AHT10 korrekt, daß nur ein> AHT10 an einem I2C-Bus angeschlossen sein kann.
So weit warst du auch schon in deinem ersten Post.
Guck auf dem Bus nach, was bei der Initialisierung genau anders/schief
läuft, wenn du beide Sensoren dran hast. Nimm z.B. das lauffähige
Programm vom AHT10 und hänge dann den BMP280 zusätzlich mit auf den Bus,
ohne etwas am Code zu ändern.
Hast du einen Logikanalysator, der die Busaktivität etwas
übersichtlicher aufschlüsselt?
Karsten W. schrieb:> Gibt es einen konkreten Vorschlag für passende Widerstände?
In den Datenblättern steht der maximal zulässig Low-Pegel. Und der Rest
ist jeweils ein einfacher Spannungsteiler, bestehend aus den Pull-Ups
und dem Serienwiderstand.
Wenn selber rechnen zu mühselig ist, probier's aus. Bei Serienwiderstand
0 siehst du auf dem Oszi keinen Unterschied, bei zu hohem
Serienwiderstand steigt der L-Pegel auf der Bus-Leitung zu weit an und
der Empfänger kann die Daten nicht mehr lesen.
Wolfgang schrieb:> So weit warst du auch schon in deinem ersten Post.
Stimmt. Aber man durfte ja hoffen das es doch noch eine Lösung gibt.
> Guck auf dem Bus nach, was bei der Initialisierung genau anders/schief> läuft, wenn du beide Sensoren dran hast. Nimm z.B. das lauffähige> Programm vom AHT10 und hänge dann den BMP280 zusätzlich mit auf den Bus,> ohne etwas am Code zu ändern.
Nun - dann kann man auch direkt einen Pin von einem Port benutzen, um
wahlweise die Versorgungsspannung von einer der beiden Sensoren
aufzuschalten.
> Hast du einen Logikanalysator, der die Busaktivität etwas> übersichtlicher aufschlüsselt?
Ja - so einen China-Adapter, der scheinbar bei 3V3-Pegeln keine
brauchbaren Pegel erkennt.
Daher nur das Oszi.
Karsten W. schrieb:> Nun - dann kann man auch direkt einen Pin von einem Port benutzen, ...
Willst du verstehen, was los ist oder willst du nur irgendwie die Daten
lesen?
Wenn du einem Sensor die Versorgung abschaltest und ihn trotzdem auf dem
Bus lässt, wird der Sensor lt. Datenblatt anscheinend über den Bus
versorgt (parasitäre Versorgung über ESD Schutzdioden) - keine gute
Idee.
> Ja - so einen China-Adapter, der scheinbar bei 3V3-Pegeln keine> brauchbaren Pegel erkennt.
Da habe ich andere Erfahrung, aber es mag verschiedene geben.
Du hast doch die I2C Pegelwandler. Da könntest du dich notfalls mit dem
LA auf die 5V-Seite setzen.
Karsten W. schrieb:> AHT10-schematic.jpg
Wolfgang schrieb:> Wenn selber rechnen zu mühselig ist, probier's aus. Bei Serienwiderstand> 0 siehst du auf dem Oszi keinen Unterschied, bei zu hohem> Serienwiderstand steigt der L-Pegel auf der Bus-Leitung zu weit an und> der Empfänger kann die Daten nicht mehr lesen.
Es ist leider nur Zeitverschwendung die Design-Fehler einer chinesischen
Firma zu analysieren.
Fest steht das der I2C-Bus nicht mehr läuft, sobald ein AHT10 zusätzlich
angeschlossen ist.
Nun kann man nur noch einen weiteren I2C-Bus, oder wie bereits
vorgeschlagen einen TCA9548A verwenden, oder die Versorgungsspannung der
Sensoren schalten.
Die beste Lösung jedoch ist einen AHT10 nicht zu verwenden, wenn der
I2C-Bus noch für andere Clients zur Verfügung stehen soll.
Wolfgang schrieb:> Karsten W. schrieb:>> Nun - dann kann man auch direkt einen Pin von einem Port benutzen, ...>> Willst du verstehen, was los ist oder willst du nur irgendwie die Daten> lesen?
Die Verwendung von Sensoren hat im allgemeinen das Ziel damit Daten zu
erfassen und nicht Fehler zu analysieren, warum diese nicht
funktionieren. :-)
Chinesischer Schrott sollte auf jeden Fall keine schlaflosen Nächte
bereiten.
> Wenn du einem Sensor die Versorgung abschaltest und ihn trotzdem auf dem> Bus lässt, wird der Sensor lt. Datenblatt anscheinend über den Bus> versorgt (parasitäre Versorgung über ESD Schutzdioden) - keine gute> Idee.
Gutes Argument - also streichen wir diese Möglichkeit.
Diese wäre ohnehin keine elegante Lösung.
> Da habe ich andere Erfahrung, aber es mag verschiedene geben.
Kann sein - die Analyse dieses Problems führt zur Zeit leider ebenfalls
zu keiner neuen Lösung und motiviert daher nicht.
> Da habe ich andere Erfahrung, aber es mag verschiedene geben.> Du hast doch die I2C Pegelwandler. Da könntest du dich notfalls mit dem> LA auf die 5V-Seite setzen.
Nein - weil alles auf 3,3V Pegeln arbeitet.
Dennoch Danke für Eure Gedanken und Unterstützung.
Oftmals ist es einfach nur so, daß man etwas Triviales übersehen hat.
In jedem Fall wurde in diesem Thread dokumentiert, wann der Kauf eines
AHT10 nicht sinnvoll ist.
Wolfgang schrieb:> Karsten W. schrieb:>> Nein - weil alles auf 3,3V Pegeln arbeitet.>> Wozu ist dann der Pegelwandler da?> Manche Dinge muss man nicht verstehen ...
Weil dieser auf einem AHT10 Breakout nun Mal immer mit drauf ist.
Schließlich arbeitet der überwiegende Teil bei Arduino mit 5V Atmel und
da ist dies von Vorteil.
Im Einzelbetrieb stört dieser Pegelwandler ja anscheinend bei 3,3V
nicht.
In dem Bild sieht man sogar das Innenleben eines AHT10.
Karsten W. schrieb:> Schließlich arbeitet der überwiegende Teil bei Arduino mit 5V Atmel und> da ist dies von Vorteil.
Das könntest du auch tun und hättest dann keine Probleme mit dem Pegel
für den LA. Den BMP280 würde man dann auf der 3.3V-Seite mit auf den Bus
hängen, falls du einen Lötkolben besitzt, um ein paar Drähte an die
3.3V-Pull-Ups zu löten.
Hast du denn jetzt heraus bekommen, was sich an den Signalen auf dem Bus
ändert, wenn man beim funktionierenden AHT10-Aufbau den BMP280 mit auf
den Bus hängt?
Karsten W. schrieb:> AHT10-glitch.png
Das was du als Glitch bezeichnest, ist die Reaktionszeit des Sensors.
Die Daten kommen vom µC und das ACK müsste vom Sensor kommen. Hältst du
die Setup- und die Hold Zeit auf dem Bus ein - auch nach dem
Pegelwandler (falls der bei deinem aktuellen Aufbau im Signalweg sitzt)?
Auf deinen Oszi-Bilder reicht die Zeitauflösung leider nicht, um das zu
verifizieren. Vergleiche einfach mit den I2C-Zeitdiagrammen in den
Datenblättern.
Aber egal, du wirst schon eine Lösung finden oder es mit anderen
Komponenten probieren. Viel Erfolg
Wolfgang schrieb:> Das könntest du auch tun und hättest dann keine Probleme mit dem Pegel> für den LA. Den BMP280 würde man dann auf der 3.3V-Seite mit auf den Bus> hängen, falls du einen Lötkolben besitzt, um ein paar Drähte an die> 3.3V-Pull-Ups zu löten.
Das Breakout für den BMP280 hat keinen Pegelwandler mit drauf.
Deshalb harmoniert dieses sehr schön mit einer Blue-Pill.
> Hast du denn jetzt heraus bekommen, was sich an den Signalen auf dem Bus> ändert, wenn man beim funktionierenden AHT10-Aufbau den BMP280 mit auf> den Bus hängt?
Nein - leider habe ich wie gesagt die Lust verloren.
Es werden nur chinesische Probleme analysiert, die dann trotzdem nicht
abgestellt werden können.
> Karsten W. schrieb:> Das was du als Glitch bezeichnest, ist die Reaktionszeit des Sensors.> Die Daten kommen vom µC und das ACK müsste vom Sensor kommen. Hältst du> die Setup- und die Hold Zeit auf dem Bus ein - auch nach dem> Pegelwandler (falls der bei deinem aktuellen Aufbau im Signalweg sitzt)?
Es wird über #include <Wire.h> der Hardware-I2C vom STM32F103 benutzt.
Wohlwollend will ich davon ausgehen das dieser ein korrektes Timing hat.
Da es schwer ist im Detail den I2C durch den HAL bei einem ARM
nachzuverfolgen, kann es sein das hier der Bus bei Fehlern automatisch
deaktiviert wird.
Das würde zumindest erklären, warum weder SCL noch SDA zu messen ist,
wenn beide Sensoren angeschlossen sind.
> Auf deinen Oszi-Bilder reicht die Zeitauflösung leider nicht, um das zu> verifizieren. Vergleiche einfach mit den I2C-Zeitdiagrammen in den> Datenblättern.
Dieser Ehrgeiz besteht zur Zeit nicht.
> Aber egal, du wirst schon eine Lösung finden oder es mit anderen> Komponenten probieren. Viel Erfolg
Ja Danke - gerade wird der AHT10 auf die zweite Hardware I2C vom
Controller gelötet.
Abschließend soll hier noch eine funktionierende Lösung für das Problem
mit dem blockierten I2C-Bus weitergegeben werden.
Sowohl für die Nutzung der zweiten I2C-Schnittstelle als auch für eine
Software-I2C muß die Library für den AHT10 angepasst werden.
Da die Pins für die zweite I2C bereits belegt waren, wurde auf die
Software-I2C https://github.com/felias-fogg/SlowSoftI2CMaster
zurückgegriffen, da diese mit STM32Duino verwendet werden kann.
Die AHT-10 Library basiert auf https://github.com/enjoyneering/AHT10
Mit dieser Lösung können beliebige 2 Port-Pins verwendet werden, um
einen AHT10 auszulesen.
Thread beobachten
Seitenaufteilung abschalten