Announcement: there is an English version of this forum on Hallo, Helden der Elektronik! Ich habe einen Feuchtesensor mit I2C-Schnittstelle, der aber abgekündigt und teuer ist. Sein Nachfolger ist deutlich günstiger, gut zu beschaffen aber das I2C Protokoll hat sich gehändert. Gibt es eine "einfache" Lösung mittels passendem Brückenbaustein, der die Kommunikation des alten Sensors rausgibt, obwohl der neue Sensor verbaut ist. Bin bei einem µC hängen geblieben, der als Übersetzer arbeiten würde. Aber vielleicht gibt es ja einer einfachere und günstigere Lösung, die ich nicht kenne. Auf den Master habe ich keinen Zugriff, sodass ich dort nichts ändern kann. Viele Grüße Karlsquell
Arduino F. schrieb: > Karls Q. schrieb: >> Bin bei einem µC hängen geblieben, der als Übersetzer arbeiten würde. > > Genau so! z.B. ein PIC16(L)F18325, hat 2x I2C, allerdings 14 Pins
:
Bearbeitet durch User
Stephan S. schrieb: > z.B. ein PIC16(L)F18325, hat 2x I2C, allerdings 14 Pins In Richtung "neuer Sensor" kann jeder µC als I2C Master fungieren. Der hat ja dort nicht viel mehr zu tun als mit den Pins zu zappeln. Und das die Geschwindigkeit ist bei einer Feuchtemessung sicher nit kritisch. Nur in Richtung "alter Master" sollte der µC ein I2C Slave Interface in Hardware haben. Ich würde einen 8-Pin AVR nehmen wie den Tiny85 oder Tiny412.
Lothar M. schrieb: > Stephan S. schrieb: >> z.B. ein PIC16(L)F18325, hat 2x I2C, allerdings 14 Pins > In Richtung "neuer Sensor" kann jeder µC als I2C Master fungieren. Der > hat ja dort nicht viel mehr zu tun als mit den Pins zu zappeln. Und das > die Geschwindigkeit ist bei einer Feuchtemessung sicher nit kritisch. Kommt drauf an. Wenn man die relevanten Meßwerte periodisch aus dem neuen Sensor lesen kann und im uC puffert, kann der echte I2C Zugriff vom Master auf den Emulator in Echtzeit erfolgen. Wenn man aber, warum auch immer, den direkten Zugriff vom echten I2C in Echtzeit auf den falschen I2C machen muss, wird es kniffelig. Da kann man nur hoffen, daß der Master Clock stretching mit SEHR großen Timeouts unterstützt. ;-)
Falk B. schrieb: > in Echtzeit Luftfeuche? Ein 3 Minuten auslese Takt, sollte doch "Echtzeit" zur genüge sein.
Arduino F. schrieb: >> in Echtzeit > > Luftfeuche? > Ein 3 Minuten auslese Takt, sollte doch "Echtzeit" zur genüge sein. Lies meinen Text nochmal und denk drüber nach.
Karls Q. schrieb: > Ich habe einen Feuchtesensor mit I2C-Schnittstelle, der aber abgekündigt > und teuer ist. Sein Nachfolger ist deutlich günstiger, gut zu beschaffen > aber das I2C Protokoll hat sich gehändert. Wenn du uns sagst, welchen Sensor du austauschen willst, können wir dir vielleicht besser helfen. Das I2C-Protokall jedenfalls hat sich nicht geändert. Möglicherweise sprach der alte Sensor (SHT75?) ja gar nicht I2C?
:
Bearbeitet durch User
Karls Q. schrieb: > Ich habe einen Feuchtesensor mit I2C-Schnittstelle, der aber abgekündigt > und teuer ist. Sein Nachfolger ist deutlich günstiger, gut zu beschaffen > aber das I2C Protokoll hat sich gehändert. Wie wärs, ganz einfach mal beide Typen zu nennen.
Falk B. schrieb: > Lothar M. schrieb: >> Stephan S. schrieb: >>> z.B. ein PIC16(L)F18325, hat 2x I2C, allerdings 14 Pins >> In Richtung "neuer Sensor" kann jeder µC als I2C Master fungieren. Der >> hat ja dort nicht viel mehr zu tun als mit den Pins zu zappeln. Und das >> die Geschwindigkeit ist bei einer Feuchtemessung sicher nit kritisch. > > Kommt drauf an. Wenn man die relevanten Meßwerte periodisch aus dem > neuen Sensor lesen kann und im uC puffert, kann der echte I2C Zugriff > vom Master auf den Emulator in Echtzeit erfolgen. Wenn man aber, warum > auch immer, den direkten Zugriff vom echten I2C in Echtzeit auf den > falschen I2C machen muss, wird es kniffelig. Da kann man nur hoffen, daß > der Master Clock stretching mit SEHR großen Timeouts unterstützt. ;-) Der von mir genannte PIC16(L)F18325 hat für I2C Slave und Master-Mode und beherrscht Clock-Stretching. Gibt es im DB ein extra Kapitel dazu.
Karls Q. schrieb: > Bin bei einem µC hängen geblieben, der als Übersetzer arbeiten würde. > Aber vielleicht gibt es ja einer einfachere und günstigere Lösung, die > ich nicht kenne. Kommt drauf an, wie schnell dein I2C-Master ist, ob er evtl. mit Clock Stretching umgehen kann und ob du willens bist, die Umsetzung als Programmcode zu formulieren bzw. formulieren zu lassen.
Stephan S. schrieb: >> Kommt drauf an. Wenn man die relevanten Meßwerte periodisch aus dem >> neuen Sensor lesen kann und im uC puffert, kann der echte I2C Zugriff >> vom Master auf den Emulator in Echtzeit erfolgen. Wenn man aber, warum >> auch immer, den direkten Zugriff vom echten I2C in Echtzeit auf den >> falschen I2C machen muss, wird es kniffelig. Da kann man nur hoffen, daß >> der Master Clock stretching mit SEHR großen Timeouts unterstützt. ;-) > > Der von mir genannte PIC16(L)F18325 hat für I2C Slave und Master-Mode > und beherrscht Clock-Stretching. Das nützt gar nichts, wenn der Master das nicht auch macht. Und für den Sensor reicht I2C per Software. Also geht fast jeder 08/15 uC mit EINEM echten I2C Slave Interface.
Guten Morgen, danke für die konstruktiven Beiträge. Dann lag ich ja mit dem zusätzlichen µC ganz richtig. Die Lösung mit dem Software-I2C werde ich testen, würde jedenfalls die Kosten deutlich senken. Ich glaube die Bewertungsmöglichkeit, ob ein Beitrag lesenswert ist, oder auch nicht, wird hier ad absurdum geführt. Scheinbar haben hier manche Leute viel Langeweile, schade.
Karls Q. schrieb: > Ich glaube die Bewertungsmöglichkeit, ob ein Beitrag lesenswert ist, > oder auch nicht, wird hier ad absurdum geführt. So sind Bewertungsfunktionen im Internet häufiger mal. Der Bewerter sollte kompetenter sein, als der Schreiber des Beitrags. Ist leider nicht immer gegeben. Es soll die Qualität des Beitrags bewertet werden, wird aber gerne als anonymes Mobbinginstrument missbraucht.
Karls Q. schrieb: > Aber vielleicht gibt es ja einer einfachere und günstigere Lösung, die > ich nicht kenne. Das wird dir keiner sagen können, solange nicht klar ist, was bei der Umsetzung genau passieren muss, d.h. um welche Sensoren es sich handelt und was von den Fähigkeiten des alten Sensors von dir genutzt wird. So bleibt es dann erstmal bei Allgemeinplätzen
Karls Q. schrieb: > Guten Morgen, > danke für die konstruktiven Beiträge. Bitteschön! Aber du könntest auch mal einen konstruktiven Beitrag leisten, indem du uns sagst, um welche Sensoren es sich handelt!
> Software-I2C werde ich testen, würde jedenfalls die Kosten deutlich > senken. Naja kosten.... ICh denke ein CH32V003 koennte das problemlos und der kostet ja nix. Ein kleines Problem gibt es aber schon. Dein Mastercontroller koennte den Sensorwert abfragen, dann fragt dein neuer Controller den Sensor ab und liefert die Antwort an den Master. So bekommst du einen aktuellen Messwert, aber musst selber Clockstreching machen und veraenderst das Timing des Hauptprogramms. Das kann gehen, oder auch nicht. Der neue Controller liefert immer sofort einen Wert den er bereits hat, muss dafuer aber selber regelmaessig den eigentlichen Sensor abfragen. Das kann den Stromverbrauch erhoehen. Der neue Controller liefert immer sofort einen Wert und liesst erst danach einen aktuellen Wert vom Sensor ein. Dann bekommst du Messungen zeitverzoegert. Was davon am sinnvollsten ist muss man selber anhand der Anwendung entscheiden. Vanye
Ja, man kann nur viel spekulieren, da ja bisher null Informationen vorliegen. Bisher wurde nur gesagt, daß es um Feuchte geht und I2C gesprochen wird. Wie ich das hasse, immer diese Geheimniskrämerei.
Es geht um den Sensirion SHT10 und SHT20. Und jetzt bin ich mal gespannt, welche neuen Informationen und Lösungsvorschläge kommen.
Karls Q. schrieb: > Es geht um den Sensirion SHT10 und SHT20. Und jetzt bin ich mal > gespannt, welche neuen Informationen und Lösungsvorschläge kommen. Welcher ist der Alte und welcher der Neue?
Sind beides alte Versionen. Aktuell ist der SHT40, welcher dann auch als Ersatz eingesetzt werden soll.
Karls Q. schrieb: > Es geht um den Sensirion SHT10 und SHT20. Karls Q. schrieb: > der SHT40, welcher dann auch als > Ersatz eingesetzt werden soll. Interessante Sache!
Arduino F. schrieb: > Karls Q. schrieb: >> Es geht um den Sensirion SHT10 und SHT20. > > Karls Q. schrieb: >> der SHT40, welcher dann auch als >> Ersatz eingesetzt werden soll. > > Interessante Sache! Das musst du mir bitte näher erklären.
Karls Q. schrieb: >> Interessante Sache! > > Das musst du mir bitte näher erklären. Er meinte mit leicht sarkastischem Unterton, daß deine Kommunikation und Logik ausbaufähig ist. . . "Perfekte Menschen" hätten in ersten Beitrag schon geschrieben, daß die alten SHT10 und SHT20 jetzt durch einen SHT40 ersetzt werden, der alte Master aber einen SHT10/20 erwartet und somit eine Emulation des SHT10/20 mit Hilfe eines SHT40 und Mikrocontrollers benötigt wird.
Hat SHT10 nicht den Sensibus, und nicht I2c? Den SHT20 kenn ich nicht...
Falk B. schrieb: > Er meinte mit leicht sarkastischem Unterton, daß deine Kommunikation und > Logik ausbaufähig ist. . . So ähnlich.... Mich interessiert die Psychologie dahinter, hier hinter der Salamitaktik. Weis aber auch, dass ich Foren die Klientel nicht dazu befragen darf, da dann Dämme brechen können.
Eduard I. schrieb: > Hat SHT10 nicht den Sensibus, und nicht I2c? Den SHT20 kenn ich nicht... Ja, aber der alte SHT20 spricht schon I2C. Genauso wie der neuere SHT3x und der aktuelle SHT4x. Um was für ein Messgerät geht es da, wenn man das auch fragen darf (Hersteller)? Und wenn's auch ein SHT15 sein darf, da hätte ich noch ein, zwei neue hier liegen. Wenn Interesse besteht, dann bitte PM!
:
Bearbeitet durch User
Karls Q. schrieb: > Und jetzt bin ich mal gespannt, welche neuen Informationen und > Lösungsvorschläge kommen. Muss man die wirklich alles aus der Nase Ziehen? Wenn der Master mit der Emulation umgehen soll, wäre es wahrlich gut, auch etwas mehr über den Master und die Software zu wissen, z.B. ob er mit Clock Stretching umgehen kann, mit welcher Geschwindigkeit er mit dem Sensor kommuniziert und wie das Timing für die Abfrage aussieht.
:
Bearbeitet durch User
Vanye R. schrieb: > Der neue Controller liefert immer sofort einen Wert den er bereits hat, > muss dafuer aber selber regelmaessig den eigentlichen Sensor abfragen. > Das kann den Stromverbrauch erhoehen. Und die Latenz und damit den Regelkreis irritieren. Ach, es gibt keinen, nur eine Anzeige?
Karls Q. schrieb: > Und jetzt bin ich mal gespannt, welche neuen Informationen ... kommen. Ja, so wie die deinen eben: Salamischeibchen für Salamischeibchen immer nur auf Nachfrage. So wie der Fehlerbericht eines Piloten: "Irgendwas im Cockpit klappert!" und dann die Fehlerbehebung des Technikers: "Irgendwas im Cockpit festgeschraubt." Eine ganz wichtige (wenn auch versteckte) Frage war übrigens das, was dort im Beitrag "Re: I2C Brücke bzw emulation eines alten Sensors" geschrieben wurde: wie oft wird der Sensorwert abgefragt? Wie aktuell muss der Sensorwert sein, den du "emulierst"?
Ja, die sind schön unterschiedlich: SHT10: Spezialprotokoll, max 5MHz SHT20: I2C, max 400kHz SHT40: I2C, max 1MHz
Peter D. schrieb: > Ja, die sind schön unterschiedlich: Dann nimmt man eben einen Holzhammer: RP2040 Rainer W. schrieb: > mit Clock Stretching umgehen kann, mit welcher Geschwindigkeit er mit > dem Sensor kommuniziert und wie das Timing für die Abfrage aussieht. Steht im Datenblatt. Bei >= 20 ms Messzeit des Sensors wohl kein Thema.
Rainer W. schrieb: > z.B. ob er > mit Clock Stretching umgehen kann Da bei diesen Sensoren Clock nur ein Eingang ist, wird der Master auch kein Clock Stretching erwarten. Man könnte aber mit einem Oszi mal mitlauschen, wie hoch die maximale Taktrate des Masters wirklich ist. Interessant wäre, was denn nun wirklich am Master angeschlossen ist, ob er beide unterstützt, ob er die automatisch unterscheiden kann oder konfiguriert werden muß. Ja, das ist schon einer der extremsten "alles aus der Nase ziehen müssen" Threads.
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.