Hallo zusammen,
Gleich vorweg... ich bin eigentlich Softwareentwickler und habe mit
Hardware relativ wenig Erfahrung...
Ich habe eine Frage zu einer möglichen Schaltung um Reed-Kontakte
("beliebig viele") mit einem uC(Esp32) auszulesen. Dabei soll der uC
sich möglichst immer im DeepSleep befinden und nur bei Statusänderung
eines der Reedkontakte aufgeweckt werden, die Zustände der Kontakte
verarbeiten und anschließend wieder schlagen gehen (Batteriebetrieb).
Das aufwecken passiert dabei bei einer steigenden oder Fallenden Flanke
am Pin IO_RST.
Folgende Schaltung habe ich bereits für 1 Kontakt funktionstüchtig...
(1reed.png)
Die "Erweiterung" um einen zweiten(n-ten) Kontakt funktioniert zwar
halbwegs, die Potentiale an IO_RST und den jeweiligen PINs für den
Schalter passen - aber sobald der zweite Schalter den gleichen Status
einnimmt, den der erste schon hat, toggelt der IO_RST natürlich nicht...
(2reed.png)
Wie würdet ihr so etwas realisieren? Vermutlich bin ich total auf dem
Holzweg. Ein Stups in die richtige Richtung wäre super!
Vielen Dank
:
Bearbeitet durch User
Florian W. schrieb: > Folgende Schaltung habe ich bereits für 1 Kontakt funktionstüchtig... > (1reed.png) Was heißt hier "funktionstüchtig"? Wieso braucht man für den einen verschissenen Kontakt zwei Eingänge? Wozu soll das gut sein, was macht die Hardware, was die Software daraus? > Die "Erweiterung" um einen zweiten(n-ten) Kontakt funktioniert zwar > halbwegs Inwiefern "halbwegs". Was soll passieren, was passiert tatsächlich? Außerdem: wenn "Erweiterung um einen zweiten Kontakt" , was soll den der dritte Kontakt im Schaltplan bewirken?
In einem AVR wuerde ich PinChangeInterrupts konfigurieren, ein Pin fuer jedes in Frage kommende Signal. Sowas wird es ja im Esp32 auch geben. wendelsberg
c-hater schrieb: > Florian W. schrieb: > >> Folgende Schaltung habe ich bereits für 1 Kontakt funktionstüchtig... >> (1reed.png) > > Was heißt hier "funktionstüchtig"? Wieso braucht man für den einen > verschissenen Kontakt zwei Eingänge? Wozu soll das gut sein, was macht > die Hardware, was die Software daraus? Verschissene Kontakte hab ich nicht... Maximal verlötete... Ich hol mal ein bisschen weiter aus: Ich habe N Reedkontakte. Deren jeweiligen Status offen/geschlossen möchte ich an einen MQTT Broker per WiFi verschicken (den Softwareteil kriege ich alleine hin...). Die gesamte Schaltung muss per Batterie funktionieren. Deshalb der Deepsleep mit externen Interrupt. >> Die "Erweiterung" um einen zweiten(n-ten) Kontakt funktioniert zwar >> halbwegs > > Inwiefern "halbwegs". Was soll passieren, was passiert tatsächlich? > Außerdem: wenn "Erweiterung um einen zweiten Kontakt" , was soll den der > dritte Kontakt im Schaltplan bewirken? Der zweite Kontakt bewirkt das gleiche wie der erste (und jeder weitere). Sobald sich der Status des Reed-Schalters ändert, muss sich die Flanke am Reset-Pin ändern, damit der uC aufwacht. Anschließend werden die IOs abgefragt, verarbeitet, versendet und der uC geht wieder schlafen - bis zum nächsten Pegelwechsel an RST - also dem nächsten betätigen eines beliebigen Reeds Meine Schaltung war nur meine Naive Idee, wie das funktioniert... Wenn du eine bessere Lösung hast, gerne her damit!
ERGÄNZUNG: Anstelle des Pegelwechsels kann ich am Reset-Pin auch auf ein kurzes High oder kurzes Low Signal reagieren um den uC aufzuwecken.... Sollte die Beschaltung damit einfacher realisierbar sein...
Florian schrieb: > Meine Schaltung war nur meine Naive Idee, wie das funktioniert Ja, sie berücksichtigt halt nicht den Unterschied zwischen dem, was an Reset passieren soll und dem, was zur Abfrage der Kontakte nötig ist. Die Lösung ist: Reset benötigt eine Flanke, die Kontaktabfrage einen Pegel. Du mußt also eine Schaltung finden, die das separiert. Man kann das durch Differenzierglieder (AKA: Kondensatoren) erledigen, für jeden einzelnen Kontakt. Die Ergebnisse dieser Differenzierglieder führt man dann zusammen. Je nachdem, ob RST high- oder low-aktiv ist, über ein "wired-OR" oder ein "wired-AND". Beide bestehen aus je einer Diode pro Kanal (sprich: Kontakt) und einem gemeinsamen Lastwiderstand. Der Unterschied besteht nur in der Polung der Dioden und darin, ob der Lastwiderstand gegen Vcc oder GND gelegt wird.
Florian schrieb: > muss sich > die Flanke am Reset-Pin ändern Glaub ich nich, der ESP32 hat Pin-Change-Interrupt! Du brauchst den Reset Eingang also garnicht.
Florian W. schrieb: > Reed-Kontakte ("beliebig viele") mit einem uC(Esp32) auszulesen. > Das aufwecken passiert dabei bei einer steigenden oder Fallenden > Flanke am Pin IO_RST. Das sollte nur bei einer fallenden Flanke passieren. Dann funktioniert es mit den meisten I2C Port Expandern. Diese Bausteine brauchen nur 3.3V und einen Kondensator und haben für jeden Reedkontakt einen Eingangspin. Intern reagieren sie auf jede Änderung an einem dieser Eingänge und erzeugen jedes Mal eine fallende Flanke an ihrem Ausgang INT. "beliebig viele" ist ein hartes Wort; mit dem PCA9505 sind 320 Kontakte noch trivial. Der Baustein hat 40 Eingänge und man kann 8 Stück an einem I2C-Bus betreiben. Mit I2C-Multiplexern lässt sich das "fast beliebig" erweitern, eine Grenze dürfte der Platzbedarf für die Anschlußkabel sein. Solange kein Kontakt geschlossen ist, ist der Stromverbrauch vernachlässigbar. Jeder geschlossene Kontakt braucht ca. 50uA, irgendwann macht's die Masse. Eine Schaltung, die offen und geschlossen praktisch nichts verbraucht, wäre mit Umschaltkontakten noch relativ einfach (plus 1 IC für 2 bis 4 Kontakte). Mit einem einfachen Reedkontakt fallen mir jetzt aus dem Stand nur ziemlich aufwendige Schaltungen ein.
c-hater schrieb: > Du mußt also eine Schaltung finden, die das separiert. Man kann das > durch Differenzierglieder (AKA: Kondensatoren) erledigen, für jeden > einzelnen Kontakt. > Die Ergebnisse dieser Differenzierglieder führt man dann zusammen. Je > nachdem, ob RST high- oder low-aktiv ist, über ein "wired-OR" oder ein > "wired-AND". Beide bestehen aus je einer Diode pro Kanal (sprich: > Kontakt) und einem gemeinsamen Lastwiderstand. Der Unterschied besteht > nur in der Polung der Dioden und darin, ob der Lastwiderstand gegen Vcc > oder GND gelegt wird. Ein Bild sagt mehr als Tausend Worte... @TO: So wie du dir das vorstellst, wird das wohl nur was mit Umschaltekontakten, nicht mit einfachen Kontakten. Vielleicht ist regelmäßiges Aufwachen und Abfragen der Kontakte ja auch eine Option.
Florian W. schrieb: > 2reed.png > ... > Das aufwecken passiert dabei bei einer steigenden oder Fallenden Flanke > am Pin IO_RST. > Die "Erweiterung" um einen zweiten(n-ten) Kontakt funktioniert zwar > halbwegs, die Potentiale an IO_RST und den jeweiligen PINs für den > Schalter passen ... Das wage ich zu bezweifeln, jedenfalls wenn deine gezeigte Schaltung zu dem tatsächlichen Aufbau passt. IO_RST hängt lt. Schaltskizze fest auf VCC und es sollte mit dem Teufel zu gehen, wenn dort irgendwelche Flanken auftreten.
Angehängte Dateien:
-
Multi_IO_Int.png
7,5 KB
Hi Wenn du mehrere Kontakte mit nur einem Interrupt erfassen willst, oder einer anderen Ereignisebene, dann solltest du die Kontakte über Dioden auf den Ereigniseingang schalten. Nicht die Pull-Up oder Pull_Down Widerstände vergessen. Je nach Polung der Eingänge sind die zu schalten. Aber manchmal sagen Skizzen mehr als tausend Worte... Gruß oldmax
Wobei man dazu sagen muß, daß man nur erkennen kann, wenn ein einziger Pin aus der Reihe tanzt. Wenn das schon einer getan hat und ein weiterer dazu kommt, erkennt man das mit der Schaltung nicht. Die kommt auch eher aus der Zeit, als Pin Change Interrupt noch nicht Standard war.
Hi Lutz schrieb: > Wobei man dazu sagen muß, daß man nur erkennen kann, wenn ein einziger > Pin aus der Reihe tanzt. Wenn das schon einer getan hat und ein weiterer > dazu kommt, erkennt man das mit der Schaltung nicht. Hä.. Also, natürlich wird der Int-Eingang auf eine ISR geleitet, in der dann die Bits der anderen Eingängen eingelesen und abgelegt werden. Danach kann mit einer gepollten normalen Routine die Kontakte ausgewertet werden. Und es muss schon ein wahnsinniger Zufall sein, wenn da ein Signal so ungünstig kommt, das noch die Bearbeitung in der ISR hinter dem Einlesen der Eingänge und vor dem Verlassen der ISR ist. Aber ok, wenn jeder Eingang Interrupt fähig ist, dann ist das natürlich vorzuziehen. Hat der TO allerdings diese Option nicht, dann sollte der Vorschlag den Interrupt über Dioden auszulösen eine mögliche Lösung sein. Egal, ob das die Lösung aus dem Mittelalter ist. Gruß oldmax
Martin V. schrieb: > Hä.. Wieso Hä? Wenn ein Kotakt geschlossen ist und bleibt, blockiert er die anderen, weil ja jetzt Dauer-H (oder L im zweiten Bild) auf deiner Interupt-Leitung liegt.
Hi zusammen, sorry, dass ich so lange nichts hab von mir hören lassen. Arbeit, Kind, etc... Teo D. schrieb: > Glaub ich nich, der ESP32 hat Pin-Change-Interrupt! Stimmt - aber nur im light-sleep Modus wenn ich die Doku richtig verstehe. Ich würde ihn aber gerne in den deep-sleep schicken, da dort der Batterieverbrauch um ca. Faktor 10 kleiner wäre. Lutz schrieb: > Ein Bild sagt mehr als Tausend Worte... > > @TO: So wie du dir das vorstellst, wird das wohl nur was mit > Umschaltekontakten, nicht mit einfachen Kontakten. > Vielleicht ist regelmäßiges Aufwachen und Abfragen der Kontakte ja auch > eine Option. Die Kontakte sind nicht austauschbar, da bereits verbaut. Eine Option ist das sicherlich - sofern es keine halbwegs einfache Schaltungstechnische Lösung gibt, wohl ein notwendiges Übel - auch wenn das natürlich zum einen eine Totzeit bedingt - zum anderen natürlich zu vermutlich 95% unnötige Aufwachvorgänge wären. Zur Präzision: "beliebig viele" ist hier eine "beliebige" Anzahl zwischen 1 und 8 - Die IOs des ESP sind demnach nicht das Problem :) Soweit ich das gerade Überblicke, macht ein Port-Expander an Pin INT genau das, was ich für den Reset des ESP brauche. Die Status der einzelnen Eingänge könnte ich dann über I2C einlesen, richtig? Danke für den Hinweis @c-hater https://www.mikrocontroller.net/articles/Port-Expander_PCF8574 Pin7 wäre dann ein Beispiel für die Beschaltung eines Reedkontakts, richtig? Könnt ihr mir noch Hilfestellung zur Auswahl des richtigen Bausteins geben? Rahmenbedingungen sind 3.3V und möglichst Stromsparend :) Ich würde anschließend mal versuchen mit Hilfe des Datenblattes die Schaltung selbst zu zeichnen und von euch nochmal absegnen lassen ;)
Angehängte Dateien:
-
Impuls.png
2,3 KB
Hi Nun, soweit ich das Problem verstanden habe, geht es darum, den Controller aufzuwecken, um Strom zu sparen. Ich weiß jetzt grad nicht, ob der Portexpander mit so wenig Stromm auskommt oder ob man da gleich den Controller betriebsbereit halten kann. Ja, ich weiß, das alles steht im Datenblatt, aber da ich das ja nicht bauen will oder muß, interessiert es mich nicht sonderlich. Aber um den Int-Eingang nicht mit einem (dauerhaft) geschlossenen Kontakt zu blockieren, denke ich, die angehängte Skizze mit einem Kondensator und einem hochohmigen Widerstand das Problem durch einen kurzen Schaltimpuls auf den Int-Eingang löst. Allerdings fließt da auch ein Strom, solange der Kontakt geschlossen ist und das bei jedem Kontakt. Na ja, ich für meinen Teil würd da ein wenig experimentieren, um eine zuverlässige und für die Bedingungen akzeptable Lösung zu finden, auch mit einem Portexpander. Nur der TO kennt die realen Anforderungen. Wenn er von der Hardware eben nicht die Ahnung hat, sind auch unterschiedliche Hinweise manchmal hilfreich. Hat er die Möglichkeit, einen Hardwareentwickler aus seinem Umfeld zu fragen, sollte er sich sowieso besser an diesen wenden, denn in einem Forum läuft man auch leicht Gefahr, sein Problem total zerpflückt zu bekommen. Gruß oldmax
:
Bearbeitet durch User
Florian W. schrieb: > Teo D. schrieb: >> Glaub ich nich, der ESP32 hat Pin-Change-Interrupt! > > Stimmt - aber nur im light-sleep Modus wenn ich die Doku richtig > verstehe. Ich würde ihn aber gerne in den deep-sleep schicken, da dort > der Batterieverbrauch um ca. Faktor 10 kleiner wäre. "Hibernation mode: The internal 8-MHz oscillator and ULP co-processor are disabled. The RTCrecovery memory is powered down. Only one RTC timer on the slow clock and certain RTC GPIOs areactive. The RTC timer or the RTC GPIOs can wake up the chip from the Hibernation mode. .... HibernationRTC timer only 5μA" Wenn (was immer das auch genau bedeuten mag) "RTC GPIOs" dir keinen Strich duch die Rechnung macht, wäre das doch genau was Du suchst und hast nochmals 50% an Strom gespart!?
Wenn man wirklich Strom sparen will, muss man den Strom durch die Kontakte sparen. Das geht mit Umschaltern oder indem man die Pull-Up Widerstände nur alle paar Sekunden für 1ms (oder so) einschaltet. Wenn man Pech (bzw. billige Kontakte) hat, brauchen die Kontakte mehrere mA um zuverlässig zu schalten. Florian W. schrieb: > Soweit ich das gerade Überblicke, macht ein Port-Expander an Pin INT > genau das, was ich für den Reset des ESP brauche. Die Status der > einzelnen Eingänge könnte ich dann über I2C einlesen, richtig? > https://www.mikrocontroller.net/articles/Port-Expander_PCF8574 Genau so; der PCF8574 macht das im Prinzip richtig, aber er hat keinen Reset-Eingang. Man liest hier immer wieder, dass sich "I2C aufhängt", dagegen hilft so ein Eingang. Die PCA9557, PCA9538 und PCAL9538 können das. Außerdem haben die keine internen Pull-Up, was eher ein Vorteil ist. Externe Widerstände kann man passend zu den Kontakten dimensionieren und ggf. Strom sparen. Beim PCF8574 würde jeder geschlossene Kontakt 300uA brauchen.
Teo schrieb: > Hibernation mode: Gute Idee, da wäre jetzt tatsächlich eine Abschätzung nötig... Ist es "günstiger" den uC regelmäßig per RealTimeClock aus dem Hibernate aufzuwecken (regelmäßig bedeutet dann maximal alle 60 Sekunden für meinen Anwendungsfall) oder den DeepSleep+PortExpander zu benutzen und den uC nur bei Statusänderungen aufzuwecken. Allerdings "there’s no way we can preserve any data during hibernation mode." - Damit wäre es nicht möglich den letzten bekannten Status der Kontakte lokal zu merken, sprich dieser müsste jedesmal über WiFi von extern abgefragt werden. (MQTT, zentrale Komponente zur Weiterverarbeitung - siehe irgendwo oben im Thread) Und spätestens hier wird die Einsparung mehr als überkompensiert - Demnach leider keine gute Lösung :)
Florian W. schrieb: > "there’s no way we can preserve any data during hibernation mode." Ich denke schon die ganze Zeit, ob man nicht lieber einen richtigen uC verwenden sollte...
Florian W. schrieb: > Allerdings "there’s no way we can preserve any data during hibernation > mode." - Damit wäre es nicht möglich den letzten bekannten Status der > Kontakte lokal zu merken, Muss das Speichern wirklich sein?! Ist denn, den aktuellen Zustand aus den Schalterstlungen herzustellen, wirklich schädlich?!
Der ESP8266 hat ein paar Bytes im RAM der RTC frei, welche auch den tiefsten Schlafmodus überleben. Kann der ESP32 das nicht auch?
Teo schrieb: > Muss das Speichern wirklich sein?! Ist denn, den aktuellen Zustand aus > den Schalterstlungen herzustellen, wirklich schädlich?! Naja... Sinn und Zweck der Übung ist ja, das teure WiFi nur zu nutzen, um Änderungen der Schalterstellung an die Serverkomponente zu propagieren. Wenn ich den alten Stand der Schalter nicht kenne, weiß ich ja nicht, ob es wirklich notwendig ist den Server zu informieren... Oder wie meinst du das?
Stefan ⛄ F. schrieb: > Der ESP8266 hat ein paar Bytes im RAM der RTC frei, welche auch den > tiefsten Schlafmodus überleben. Kann der ESP32 das nicht auch? Im tiefsten Schlafmodus (hibernate beim esp32) wird das RTC RAM abgeschaltet. Also Nein. Das geht nur im DeepSleep - also dem zweittiefsten Modus (der aber auch OK wäre...).
Ach so, dann ist der Knackpunkt, dass der ESP32 noch tiefer schlafen kann, als der ESP8266. Was ja an sich nicht schlecht ist.
Florian W. schrieb: > Naja... Sinn und Zweck der Übung ist ja, das teure WiFi nur zu nutzen, > um Änderungen der Schalterstellung an die Serverkomponente zu > propagieren. Wenn ich den alten Stand der Schalter nicht kenne, weiß ich > ja nicht, ob es wirklich notwendig ist den Server zu informieren... Natürlich hat sich was geändert, deswegen ist er doch aufgewacht und ob man nu den Zustand eines oder 8 Schaler überträgt, sollte doch egal sein?!
Teo D. schrieb: > Natürlich hat sich was geändert, deswegen ist er doch aufgewacht Womit wir wieder genau am Anfang meiner Frage sind. Wie kann man durch die externe Beschaltung den uC wecken, wenn sich etwas ändert? (bisher bekannte Möglichkeit: Port-Expander -> Nachteil Stromverbrauch??) Das Speichern des letzten Zustandes ist natürlich nur dann relevant, wenn der uC zeitlich gesteuert aufgeweckt wird. (Nachteil: Viel unnötiges Aufwachen)
Wir drehen uns im Kreis, da du scheinbar keinen der genannten Vorschläge umsetzen willst. Sollen wir nochmal oben anfangen? Genannt wurden: - Portexpander - Separaten Mikrocontroller mit Sleep - Schaltung mit Kondensatoren und/oder Dioden Du musst dich nur für einen Lösungsansatz entscheiden. Sind sie dir zu umständlich? Dann lass es halt bleiben. Wir können nicht hexen.
Florian W. schrieb: > Teo D. schrieb: >> Natürlich hat sich was geändert, deswegen ist er doch aufgewacht > > Womit wir wieder genau am Anfang meiner Frage sind. > Wie kann man durch die externe Beschaltung den uC wecken, wenn sich > etwas ändert? > (bisher bekannte Möglichkeit: Port-Expander -> Nachteil > Stromverbrauch??) Ich dachte damit wären wir wieder beim Hibernation-Mode und dem mir noch ominösen RTC-GPIOs, mit denen er sich wecken läst?!
Florian W. schrieb: > Stefan ⛄ F. schrieb: > >> Der ESP8266 hat ein paar Bytes im RAM der RTC frei, welche auch den >> tiefsten Schlafmodus überleben. Kann der ESP32 das nicht auch? > > Im tiefsten Schlafmodus (hibernate beim esp32) wird das RTC RAM > abgeschaltet. Also Nein. Das geht nur im DeepSleep - also dem > zweittiefsten Modus (der aber auch OK wäre...). 8 Register mit 32 bit überleben auch das...
Stefan ⛄ F. schrieb: > Wir drehen uns im Kreis, da du scheinbar keinen der genannten Vorschläge > umsetzen willst. Sollen wir nochmal oben anfangen? > > Genannt wurden: > - Portexpander > - Separaten Mikrocontroller mit Sleep > - Schaltung mit Kondensatoren und/oder Dioden > > Du musst dich nur für einen Lösungsansatz entscheiden. Sind sie dir zu > umständlich? Dann lass es halt bleiben. Wir können nicht hexen. So war's garnicht gemeint. War nur auf den Beitrag von Theo bezogen. Wenn ich das eine habe, brauche ich das jeweils andere nicht....
Lutz schrieb: > Florian W. schrieb: >> Stefan ⛄ F. schrieb: >> >>> Der ESP8266 hat ein paar Bytes im RAM der RTC frei, welche auch den >>> tiefsten Schlafmodus überleben. Kann der ESP32 das nicht auch? >> >> Im tiefsten Schlafmodus (hibernate beim esp32) wird das RTC RAM >> abgeschaltet. Also Nein. Das geht nur im DeepSleep - also dem >> zweittiefsten Modus (der aber auch OK wäre...). > > 8 Register mit 32 bit überleben auch das... Kannst du bitte noch etwas näher erläutern was genau du meinst?
Na gut, aber nur weil heute Freitag ist: ESP32 Manual sagt: Hibernatation mode: ... 8 x 32 bits of data are kept in general-purpose retention registers. ... Steht auf S. 682 meiner Version (ist wirklich copy&paste, nur für den Fall, daß Linguisten aufbegehren wollen). Also hast du 32 Register (RTC_CNTL_STOREn_REG, n = 0-7) mit jeweils 32 bit, die im "Hibernatation" Mode auch wirklich erhalten bleiben. Wäre auch ziemlich sinnlos, wenn der Chip sowas nicht hätte. Andererseits ist es natürlich Espressif... Also kannst du da immer den aktuellen Port-Status ablegen und nach dem wake up ist es noch da. Je nach Zeit, Lust und Gehirnschmalz kannst du das Ganze auch noch weiter optimieren: Beim Abfragen der Kontakte läßt du den pull-up da an, wo es geht und aktivierst den pin change interrupt. Hat den Vorteil, daß dort auch vor Ablauf der Aufwachzeit auf das Schließen des Kontaktes reagiert werden kann. Mündet dann im Wechsel auf nur noch pin change statt timer, wenn alle Kontakte offen sind.
naturally like your website but you have to test the spelling on quite a few of your posts. A number of them are rife with spelling problems and I find it very troublesome to inform the truth on the other hand I will certainly come again again.
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.