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.
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.
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. ;-)
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?
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.
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.
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.
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.
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
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.
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.
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.
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.
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!
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.
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?
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"?
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.
