ESP8266 mit PCF8574 und Taster - Interrupt vom PCF "spinnt"?

[Markus F. (markus_f151)]

Hallo Leute,

ich habe eine Schaltung mit ESP8266 und PCF8574 welche Eingänge 
überwachen/abfragen soll. Die Eingänge sind mit einer Schutzschaltung 
versehen. Zum Testen hängen an den Eingängen Taster dran welche auf 
Masse ziehen. Wenn ich nun die Taster "normal" drücke, z.B. 500ms 
drücken und wieder loslassen, passt alles. Der Interrupt löst aus, wird 
entprellt und die Eingänge werden ausgelesen. Wenn ich die Taste aber 
z.B. Doppeldrücke d.h. erhöhtes Prellen auslöse, dann fängt der 
Interrupt-Ausgang vom PCF zum Spinnen an. Im Anhang ein Screenshot vom 
Oszi. Kann es sein, dass die verwendete Library 
(https://platformio.org/lib/show/1659/PCF8574_ESP) den PCF i2c-mäßig 
falsch konfiguriert? Den Schaltplan und das PlatformIO Demo-Projekt habe 
ich angehängt.

Hat jemand von euch eine Idee?

Besten Dank im Voraus.

Gruß
Markus

[Test (Gast)]

Definiere "spinnen"?

Der Interrupt wird durch einen Change am Pin ausgelöst und durch den 
nachfolgenden Lesevorgang (oder Schreibvorgang) am zugehörigen Port 
wieder zurückgesetzt. Leider reicht die Auflösung in deinem Oszillogramm 
nicht auf um zu erkennen, ob ein Lesevorgang zwischen den "Pulsen" am 
INT erfolgt ist.

[jo mei (Gast)]

PcfInterruptDetected = false;

wird nicht unter allen Umständen ausgeführt weil es innerhalb
der if-Klammer steht.

D.h. das Flag <PcfInterruptDetected > kann daher unter Umständen
länger bestehen bleiben als du es willst und erwartest.

[Markus F. (markus_f151)]

Test schrieb:
> Definiere "spinnen"?

Darunter verstehe ich, dass die Interrupt-Leitung, ohne Zutun einer 
Änderung am Eingang des PCF - ich habe die Tasten längst losgelassen und 
ein Prellen ist lange schon vorbei -, undefiniert den Zustand wechselt. 
Und zwar genau so chaotisch, wie es das Oszillogramm zeigt.

Test schrieb:
> und durch den
> nachfolgenden Lesevorgang (oder Schreibvorgang) am zugehörigen Port
> wieder zurückgesetzt

Das wusste ich gar nicht, dass der Interrupt erst durch einen 
Lese-/Schreibvorgang zurückgesetzt wird. Da muss ich wohl das Datenblatt 
nochmal genau lesen.

Test schrieb:
> Leider reicht die Auflösung in deinem Oszillogramm
> nicht auf um zu erkennen, ob ein Lesevorgang zwischen den "Pulsen" am
> INT erfolgt ist.

Was müsste ich liefern, damit du da was rauslesen kannst? Ich könnte 
Probes auf INT, SDA/SCL und auf einen Eingang hängen. Dann sollten die 
Zusammenhänge ersichtlich sein oder was denkst du?

jo mei schrieb:
> PcfInterruptDetected = false;
>
> wird nicht unter allen Umständen ausgeführt weil es innerhalb
> der if-Klammer steht.

Das ist mir bewusst. Ich hätte das Flag auch erst zurückgesetzt, wenn 
ich die Eingänge gelesen habe. Oder hab ich da einen Denkfehler? Erst 
wenn der Timer - gesetzt auf 50ms - einmal ohne Interrupt-Änderung 
abgelaufen ist, mache ich einen Lesevorgang.


Auch während des Betriebs, ohne Änderung an einem Eingang, passiert das 
Auslösen der Interrupts. Zusätzlich zu den Eingängen werden ja auch drei 
Pins des PCF als Ausgang genutzt. Da hängen drei LEDs via Transistoren 
dran. Vielleicht haben diese einen gewissen Einfluss?

[Peter D. (peda)]

Den Interruptausgang kann man nur dazu nehmen, um zu entscheiden, muß 
der Eingang neu eingelesen werden oder kann man einfach die letzte 
Lesung nehmen (kein I2C-Overhead).

Das Entprellen und Flanke erkennen macht man wie üblich im 
Timerinterrupt mittels Mehrfachabtastung.

Das Verwursten des Interrupts mit allesamt untauglichen 
Entprellversuchen kostet Dich nur unnütz Lebenszeit.

[Coronianer (Gast)]

Test schrieb:

> Der Interrupt wird durch einen Change am Pin ausgelöst und durch den
> nachfolgenden Lesevorgang (oder Schreibvorgang) am zugehörigen Port
> wieder zurückgesetzt.

Nö. Datenblatt lesen!

[Peter D. (peda)]

Markus F. schrieb:
> Da hängen drei LEDs via Transistoren
> dran. Vielleicht haben diese einen gewissen Einfluss?

Hängt von der Schaltung ab. Der PCF8574 kann nur low richtig treiben 
(25mA), also sollten Lasten low aktiv sein. Außerdem sind high aktive 
Lasten nach dem Power-On immer an.
Auch kann ein npn den Ausgang so belasten, daß er high ausgeben will, 
aber low zurück gelesen wird. Dann wird auch ein Interrupt signalisiert.

[Markus F. (markus_f151)]

Peter D. schrieb:
> Den Interruptausgang kann man nur dazu nehmen, um zu entscheiden, muß
> der Eingang neu eingelesen werden oder kann man einfach die letzte
> Lesung nehmen (kein I2C-Overhead).
>
> Das Entprellen und Flanke erkennen macht man wie üblich im
> Timerinterrupt mittels Mehrfachabtastung.
>
> Das Verwursten des Interrupts mit allesamt untauglichen
> Entprellversuchen kostet Dich nur unnütz Lebenszeit.

Werde ich mir ansehen. Dachte nur, dass sich der 
esp8266::polledTimeout::oneShotFastMs gut/elegant dafür verwenden lässt.
Weniger ist oft mehr, hast schon recht.
Hast du eine Referenzimplementierung zur Hand mit der du gute Erfahrung 
gesammelt hast? Man findet ja auch recht viel Müll dazu im i-net.

Peter D. schrieb:
> Hängt von der Schaltung ab. Der PCF8574 kann nur low richtig treiben
> (25mA), also sollten Lasten low aktiv sein. Außerdem sind high aktive
> Lasten nach dem Power-On immer an.
> Auch kann ein npn den Ausgang so belasten, daß er high ausgeben will,
> aber low zurück gelesen wird. Dann wird auch ein Interrupt signalisiert.

Das mit den nur 100uA Treiben-können habe ich leidvoll festgestellt, 
nachdem der Print fertig war. Wollte eine LED mit NPN Transistor 
ansteuern. Hab da jetzt auf Low-Aktiv umgelötet. Einfach den Pull-Down 
(R21) auf Pull-Up geändert, ging sich mit den Leiterbahnen gut aus. Die 
anderen zwei Ausgänge sind via PNP/NPN Stufe gelöst (weil eben die 
Ausgänge des PCF zu begin als Eingänge konfiguriert sind). Du kannst den 
Schaltplan im initialen Post von mir sehen. Vielleicht fällt dir da was 
auf.

EDIT: hab meinen Code ein klein wenig umgebaut. Mit den selben 
Komponenten. Funktioniert bislang gut. Siehe Anhang.

[Stefan F. (Gast)]

Peter D. schrieb:
> Auch kann ein npn den Ausgang so belasten, daß er high ausgeben will,
> aber low zurück gelesen wird. Dann wird auch ein Interrupt signalisiert.

Das ist mir auch aufgefallen, bei LED1.

messe mal während dieses Fehler die Spannung an allen acht Px 
Anschlüssen mit einem Multimeter sowohl gegen GND als auch gegen VCC. 
Wenn einer der Pins nicht eindeutig HIGH oder LOW ist, hast du den 
Übeltäter.

[Markus F. (markus_f151)]

Stefan ⛄ F. schrieb:
> messe mal während dieses Fehler die Spannung an allen acht Px
> Anschlüssen mit einem Multimeter sowohl gegen GND als auch gegen VCC.
> Wenn einer der Pins nicht eindeutig HIGH oder LOW ist, hast du den
> Übeltäter.

Danke, werde ich machen.

[Test (Gast)]

Coronianer schrieb:
> Test schrieb:
>
>> Der Interrupt wird durch einen Change am Pin ausgelöst und durch den
>> nachfolgenden Lesevorgang (oder Schreibvorgang) am zugehörigen Port
>> wieder zurückgesetzt.
>
> Nö. Datenblatt lesen!

Ich lese da:

An interrupt is generated by any rising or falling edge of the port 
inputs in the input mode. After time ,tiv, INT is valid. *** Resetting 
and reactivating the interrupt circuit is achieved when data on the port 
is changed to the original setting or data is read from, or written to, 
the port that generated the interrupt ***. Resetting occurs in the read 
mode at the acknowledgebit after the rising edge of the SCL signal,or in 
the write mode at the acknowledgebit after the high-to-low transition of 
the SCL signal.

[Markus F. (markus_f151)]

Test schrieb:
> Resetting and reactivating the interrupt circuit is achieved when data
> on the port is changed to the original setting

Das kann natürlich bei einem „floating“ Eingang zu meinem Problem 
führen.

Danke fürs Rauskopieren.

[Markus F. (markus_f151)]

Gestern hab ich die Pins vom PCF gemessen, als die Interrupt-Leitung 
flippte, allerdings war kein Pin dabei, der nicht einen definiert High- 
bzw. Low-Pegel aufwies. Werde wohl nach und nach die Pins von der 
Schaltung entfernen müssen, damit ich dem Übeltäter auf die Spur kommen 
kann.

[Peter D. (peda)]

Markus F. schrieb:
> damit ich dem Übeltäter auf die Spur kommen
> kann.

Der Übeltäter ist allein die falsche Herangehensweise. Der Interrupt ist 
nicht dazu da, bestimmte Aktionen auszuführen, sondern allein dazu, die 
lokale Kopie im RAM upzudaten, sobald sie gebraucht wird.

Z.B. prüft der 10ms Timerinterrupt vor dem Entprellen die 
Interruptleitung. Ist sie nicht aktiv, macht er sein Ding mit der 
lokalen Kopie. Ist sie aktiv, dann startet er den I2C-Interrupt und 
übergibt diesem als Callback die weitere Entprellung.

[Markus F. (markus_f151)]

Peter D. schrieb:
> Der Übeltäter ist allein die falsche Herangehensweise. Der Interrupt ist
> nicht dazu da, bestimmte Aktionen auszuführen, sondern allein dazu, die
> lokale Kopie im RAM upzudaten, sobald sie gebraucht wird.

Dann denke ich da wohl falsch. Ich hätte den Interrupt dazu verwendet, 
die Eingänge nicht pollen zu müssen, sondern nur bei Änderung aktiv 
abzufragen. Aber stimmt schon. Auch wenn ich in der ISR das Flag zum 
Neueinlesen der Ports setze, muss der Lesevorgang in der Loop 
stattfinden. Ich gewinne somit nicht wirklich was.

Was ich mir nicht so wirklich vorstellen kann ist, dass meine 
Ansteuerung des PCF zu so einem Interrupt-Verhalten führen kann.

[Stefan F. (Gast)]

Ich würde schon bei deinem Ansatz bleiben, die Interrupt-Leitung ruhig 
zu bekommen. Wenn sie wild flackert ohne dass es einen Zusammenhang zu 
den 8 Port-Pins gibt, dann ist da was faul. Welchen Sinn sollte die 
Leitung haben, wenn sie keine Klare Aussagekraft hat?

[Markus F. (markus_f151)]

Weiter geht's. Ich habe nun am PCF nur mehr die Taster dranhängen.
Ein paar Tests mit Oszillogrammen im Anhang:

D0: INT
D1: CLK
D2: DATA
D3: Taster 1
D4: Taster 2
D5: Taster 3
D6: Taster 4

Oszillogramm (OG) 01: ich habe eine Taste mehrfach hintereinander 
gedrückt. Aus dem OG ist zu erkennen, dass offensichtlich nicht alle 
Statusänderungen via I2C abgeholt wurden. Mein Code ist da wohl zu 
langsam.

OG 02: Taste gedrückt und dann wieder losgelassen. Interessanterweise 
prellt der Interrupt beim Loslassen der Taste. Details siehe OG 03 und 
04. Wie kann sowas kommen?

OG 05: hier habe ich eine Taste jetzt sehr schnell hintereinander 
gedrückt. I2C wird nur einmal gelesen - man sieht allerdings kein CLK 
(siehe OG 06) - , die Interrupt-Leitung folgt der Taste, allerdings 
massiv viel prellen, bis schlussendlich ein Dauerprellen läuft.

OG 07: Taste mäßig schnell hintereinander gedrückt. Interrupt-Leitung 
prellt zwar, aber er wird wieder inaktiv. I2C Lesevorgänge sind zu 
sehen.

Ich kann mir das Prellen der Interrupt-Leitung nicht erklären.
Spielt da vielleicht meine Schutzschaltung mit der RC/Dioden Kombi rein?

Was sagt ihr dazu?

[jo mei (Gast)]

Kannst du nochmal erklären wo im Schaltplan genau dein Taster
angeschlossen ist?

Ich kann das aus deinem Schaltplan nicht erkennen.

Oder ist der Schaltplan nach aktuellem Stand nicht mehr gültig?

[Markus F. (markus_f151)]

Ich habe die Verbindung mal eingezeichnet.
Zwischenzeitlich habe ich einen Taster direkt auf den PCF Eingang 
gelötet und getestet.
Wenn ich ordentlich die Taste prellen lasse, fängt der Interrupt mit dem 
Dauerprellen an. Meine Schutzschaltung sollte also auch kein Problem 
sein.

[jo mei (Gast)]

Markus F. schrieb:
> Ich habe die Verbindung mal eingezeichnet.

Ich wollte den Taster wissen wo er angeschlossen ist.

[Markus F. (markus_f151)]

jo mei schrieb:
> Ich wollte den Taster wissen wo er angeschlossen ist.

Sorry, nicht genau genug gelesen. Siehe Anhang.

Ich habe am PCF jetzt nur mehr folgende Pins beschalten:
VSS
VDD
A0, A1, A2 auf VSS
SDA
SCL
INT
P3

Die restlichen PINs floaten zwar, sind aber als Eingänge konfiguriert 
(High)

Trotzdem prellt der INT.

[jo mei (Gast)]

Markus F. schrieb:
> Trotzdem prellt der INT.

Kein Wunder, denn die Zeitkonstanten für die RC-Glieder sind
viel zu kurz. Ausserdem für Low und High sehr unterschiedlich
lang. So gesehen ist die Schaltung auch falsch. Der Low-Wert
kann unter Umständen nicht richtig erreicht werden.

Eine Zeitkonstante im Bereich 1-10msec wäre sinnvoll und
funktional, mit deiner Beschaltung werden sicherlich mehrere
Interrupts pro Tastendruck ausgelöst. Und das sehr kurz
hintereinander. Das wird dem Interrupt-Handling zu schaffen
machen.

[Markus F. (markus_f151)]

jo mei schrieb:
> Kein Wunder, denn die Zeitkonstanten für die RC-Glieder sind
> viel zu kurz

Da habe ich mich auf einen Schaltungsvorschlag im Internet verlassen.

Mein letzter Versuch war allerdings nur mehr mit einem Taster beschalten 
und da auch direkt GND auf den Pin tasten ohne dem RC Glied. Führte 
trotzdem zum Dauerprellen des INT.

[jo mei (Gast)]

Markus F. schrieb:
> direkt GND auf den Pin tasten ohne dem RC Glied.

Das ist (noch grösserer) Mist. Dann bekommst du jede Prellung
mit, aber das scheinst du ja zu wollen....

[jo mei (Gast)]

Markus F. schrieb:
> Da habe ich mich auf einen Schaltungsvorschlag im Internet verlassen.

.... und alles was im Internet geschrieben steht ist wahr.

[Markus F. (markus_f151)]

jo mei schrieb:
> Das ist (noch grösserer) Mist. Dann bekommst du jede Prellung
> mit, aber das scheinst du ja zu wollen....

In diesem Falle ja. Damit wollte ich die Nebenwirkungen von der 
Schutzschaltung, welche durch das RC-Glied ja dann wohl auch eine 
Hardwareentprellung darstellen soll, ausschließen. Es ist bei mir leider 
schon viel zu lange her, dass ich mit den Grundlagen der Elektronik zu 
tun hatte.

jo mei schrieb:
> .... und alles was im Internet geschrieben steht ist wahr.

Nein, das gewiss nicht. Kommt halt immer drauf an ob man eine 
Unwahrheit, trotz fehlendem Wissens, erkennen kann. Hier offensichtlich 
nicht.

Dann mach ich mich mal dran korrekte Werte für die Rs und den C zu 
ermitteln.
Danke für den Hinweis.

[Markus F. (markus_f151)]

Bin glaub ich grad völlig überfordert mit den Grundlagen.
Rechnerisch müsste 100k und 100nF die gesuchten 10ms ergeben oder?
Der Taster prellt aber trotzdem noch wie Hölle.

Welche Werte würdest du für die beiden Rs und den C verwenden?
Bitte um deinen Vorschlag.

[jo mei (Gast)]

Markus F. schrieb:
> Bitte um deinen Vorschlag.

Grundsätzlich: Wenn wir mal annehmen dass die Programmierung
um den Interrupt funktioniert, bleibt ja nur noch an die
Hardware zu denken und was man da falsch machen kann (die
Chips werden ja wohl funktionieren wie sie sollen).

Also die Entprellung und der Aufbau selbst.

Zur Entprellung: Ich verwende gerne einen Vorschlag eines
Herstellers von Dreh-Encodern, er funktioniert bei mir
wunderbar mit der Abweichung dass ich um einen Faktor 10 in
der Zeitkonstante höher ansetze (100nF statt 10nF). Die
Schaltung hat drei wesentliche Merkmale:

- die Low- und High-Zeitkonstanten müssen nicht weit
voneinander abweichen.
- die Low- und High-Pegel werden vollständig erreicht.
- Der (möglicherweise schädliche Spitzen-) Strom durch den
Taster ist gering.

Der Aufbau selbst:

Den müssten wir uns ansehen, ich vermute da ist viel zu
kritisieren. Vorab schon mal: es fehlt auf jeden Fall ein
Abblock-Kondensator am PCF8574. Und eine weitere Vermutung
wäre dass der ESP so gierig in der Stromaufnahme ist dass er
die restliche Schaltung massiv stört. Meist ist es nicht ein
konstanter hoher Strom der stört sondern die Schankungen die
aufgrund der Arbeitsweise des Controllers entstehen. Dann
sind eventuell weitere "Entstörmassnahmen" erforderlich.

[Stefan F. (Gast)]

jo mei schrieb:
> Kein Wunder, denn die Zeitkonstanten für die RC-Glieder sind
> viel zu kurz.

Ich hate gedacht, dass er den Kondensator zum Entprellen eingebaut hat. 
Wohl eher zum Schutz gegen elektromagnetische Störungen.

Markus, besorge Dir mal ein Oszilloskop. Wenn es billig sein muss, dann 
ein DSO138. Damit kannst du die Signale an den Eingängen prima 
untersuchen.

[jo mei (Gast)]

Stefan ⛄ F. schrieb:
> Ich glaube nicht, dass er den Kondensator zum Entprellen eingebaut hat.
> Wohl eher zum Schutz gegen elektromagnetische Störungen.

.... und weiter?

Was machen wir jetzt mit deiner nullkommanullwenig Hilfe?

[Helmut -. (dc3yc)]

Schau dir doch mal das Datenblatt des LM1117 an. Der will am Ausgang 
100µF sehen! Ein weiterer 100µF direkt am ESP schadet auch nicht. Und 
dem PCF8574 solltest du auch 100nF spendieren. Für die Tastenentprellung 
würde ich auch statt 100pF 10-100nF vorsehen und den Pullup 
niederohmiger (10k). Je nach Kontaktmaterial der Taster gibts sonst 
Probleme mit der Oxidschicht.

[Stefan F. (Gast)]

jo mei schrieb:
> Was machen wir jetzt mit deiner nullkommanullwenig Hilfe?

Nun, da war eine Frage zwischen den Zeilen, um an die nötigen Infos zu 
kommen. Denn ich habe bemerkt, dass wir aneinander vorbei diskutieren, 
weil zwei Entscheidende Sachen unklar sind.

Das habe ich wohl nicht klar genug formuliert. Ich versuche es nochmal:

Frage 1:

Welchen Zweck haben die Kondensatoren an den Taster-Eingängen?

a) Schutz gegen Radiowellen
b) Kontakt entprellen
c) ______________________ (bitte ausfüllen)

Frage 2:

Wie lange wechselt dein Interrupt-Signal nach Betätigung des Tasters 
wild hin und her?

a) nur wenige ms (<100ms)
b) sehr viel länger (>100ms)
c) für immer

Was ist das überhaupt für ein Taster, zeige mal!

Und beachte die Hinweise von Helmut, ich halte sie für wichtig. Erst 
danach macht weitere Fehlersuche Sinn.

[jo mei (Gast)]

Stefan ⛄ F. schrieb:
> Frage 1:

Sollen die Fragen dein Unwissen verringern oder sind das
rhetorisch-erzieherische Masssnahmen für den TO?

Nur mal nebenbei: Radiowellen empfängt man mit Antenne, Schwing-
kreis und Detektor-Diode.

[Stefan F. (Gast)]

jo mei schrieb:
> Radiowellen empfängt man mit Antenne, Schwing-
> kreis und Detektor-Diode.

Die Frage war schon ernst gemeint. Radiowellen empfängt man auch 
unabsichtlich durch Leitungen. Da reichen schon wenige Zentimeter, 
insbesondere bei diesen schwachen Pull-Up Widerständen, die der TO da 
eingebaut hat.

Derart kleine Kondensatoren an externen Anschlüssen findet man auf sehr 
vielen Platinen um genau dies zu verhindern. Deswegen macht die Frage 
meiner Meinung nach durchaus Sinn.

Die Schutzdioden hat er ja wohl nicht ohne Grund eingebaut. Wenn da 
keine Störungen erwartet würden, hätte er diese gesamte Gruppe von 
Bauteilen weglassen können, so dass der Taster ganz alleine ohne weitere 
Bauteile direkt am PCF8574 hängt.

Wie hatten hier auch einige andere Leute, die davon ausgegangen waren, 
dass die Kontakte prellen sollen und dies per Software gefiltert wird.

[Markus F. (markus_f151)]

jo mei schrieb:
> Zur Entprellung: Ich verwende gerne einen Vorschlag eines
> Herstellers von Dreh-Encodern

Die Schaltungsvariante habe ich zwischenzeitlich auch gefunden. Fraglich 
ist, ob ich ohne Schmitt Trigger davonkomme. Dann müsste ich am PCB 
nichts ändern. Wenn nötig zeichne ich der Funktionswillen auch gerne um.

jo mei schrieb:
> Der Aufbau selbst:
>
> Den müssten wir uns ansehen, ich vermute da ist viel zu
> kritisieren.

Immer her damit. Ich bin für jede Hilfe dankbar, Hauptsache die 
Schaltung funktioniert zuverlässig.

Stefan ⛄ F. schrieb:
> Ich hate gedacht, dass er den Kondensator zum Entprellen eingebaut hat.
> Wohl eher zum Schutz gegen elektromagnetische Störungen.

Völlig korrekt. Die RC/Dioden Kombination stammt von einer 
Schutzschaltung. Ich muss nämlich mit längeren Leitungen 1-2m rechnen. 
Die genaue Quelle finde ich nicht mehr aber in diese Richtung geht‘s: 
https://www.digikey.com/en/articles/protecting-inputs-in-digital-electronics

Stefan ⛄ F. schrieb:
> Markus, besorge Dir mal ein Oszilloskop.

Stefan, ich habe eines. Ohne hätte ich glaub ich schon lange aufgegeben 
?
Rigol DS1104Z+ mit dem Logicanalyzer Zusatz. Außer es war ironisch 
gemein und das Rigol ist kein vernüftiges Oszi ?

Helmut -. schrieb:
> Schau dir doch mal das Datenblatt des LM1117 an

Danke Helmut, da muss ich stark nachbessern.

Stefan ⛄ F. schrieb:
> Frage 1:
>
> Welchen Zweck haben die Kondensatoren an den Taster-Eingängen?
>
> a) Schutz gegen Radiowellen
> b) Kontakt entprellen

Schutz und Entstörung langer Leitungen.

Stefan ⛄ F. schrieb:
> Frage 2:
>
> Wie lange wechselt dein Interrupt-Signal nach Betätigung des Tasters
> wild hin und her?
> a) nur wenige ms (<100ms)
> b) sehr viel länger (>100ms)
> c) für immer

Es treten alle drei Zustände auf. Je nachdem ich den Taster langsam 
(drücken und 500ms halten), schnell (wirklich nur kurz drücken) oder 
richtig prellend betätige. Genau die Reihenfolge gilt für a, b und c. 
Richtig prellend führt zum Endlosflimmern des INT.

Stefan ⛄ F. schrieb:
> Was ist das überhaupt für ein Taster, zeige mal!

Sowas: 
https://www.digikey.at/product-detail/de/te-connectivity-alcoswitch-switches/1825910-6/450-1650-ND/1632536


Eins noch hintennach. Ich bin begeistert mit wieviel Engagement und 
Herzblut ihr hier weiterhelft ?

[Helmut -. (dc3yc)]

Markus F. schrieb:
> Sowas:
> 
https://www.digikey.at/product-detail/de/te-connectivity-alcoswitch-switches/1825910-6/450-1650-ND/1632536

Das wichtigste fehlt wieder mal im Datenblatt: das Kontaktmaterial! Bei 
Goldkontakten würde ich ja im µA-Bereich arbeiten, aber bei Bronze, 
Silber oder ähnlichem hab ich gerne etwas mehr Schaltstrom.

[Markus F. (markus_f151)]

Im Echtbetrieb habe ich es statt der Taster mit Relais-Kontakten zu tun. 
Die Relais kenne ich allerdings nicht.

[jo mei (Gast)]

Markus F. schrieb:
> Immer her damit. Ich bin für jede Hilfe dankbar, Hauptsache die
> Schaltung funktioniert zuverlässig.

Damit meinte ich dass du deinen Aufbau zeigen musst.

[Markus F. (markus_f151)]

Stefan ⛄ F. schrieb:
> Markus, besorge Dir mal ein Oszilloskop. Wenn es billig sein muss, dann
> ein DSO138. Damit kannst du die Signale an den Eingängen prima
> untersuchen.

Stefan, ein paar Oszillogramme habe ich hier in Beiträgen schon 
angehängt. Z.B. hier 
Beitrag "Re: ESP8266 mit PCF8574 und Taster - Interrupt vom PCF "spinnt"?"

[Markus F. (markus_f151)]

jo mei schrieb:
> Damit meinte ich dass du deinen Aufbau zeigen musst.

Den Schaltplan habe ich im ersten Post angehängt. Die Platine 
fotografisch hier angehängt. Ich kann später noch die Eagle Dateien 
hochladen.

Bei den RC Gliedern hab ich ein wenig herumprobiert, daher sind 
unterschiedliche Kondensatoren und auch Lötbrücken drauf.

Die kleine Platine ist nur zum Testen gedacht. Es kommen auf sie 
Hauptplatine dann Phönix Klemmen drauf.

[Stefan F. (Gast)]

Markus F. schrieb:
> Schutz und Entstörung langer Leitungen.
> Richtig prellend führt zum Endlosflimmern des INT.

Ok, dann habe ich dich also doch von Anfang an richtig verstanden. Wir 
diskutieren hier also nicht um Kondensatoren zum Entprellen, sondern 
um eine mutmaßliche Fehlfunktion des PCF8574.

Was ist mit den Abblock-Kondensatoren um den Spannungsregler herum und 
am PCF8574? Hast du die inzwischen hinzugefügt? Wenn ja, liefert der 
Chip immer noch dauerhaft Interrupts, obwohl alle Eingänge auf einem 
stabilen Logikpegel verharren?

Was die Taster angeht: Nach meiner Erfahrung funktionieren sie anfangs 
mit beliebig niedrigen Strömen, beginnen dann aber irgendwann, 
Wackelkontakte zu haben oder man muss sehr feste drauf drücken. Das 
Problem tritt sehr viel weniger auf, wenn man mindestens 1mA Strom 
verwendet, also 2,2kΩ Pull-Up Widerstände.

Der Vorschlag "besorge Dir ein Oszilloskop" war nicht böse gemeint. Ich 
habe ganz vergessen, dass du bereits ein Bild von deinem Oszilloskop 
gezeigt hattest. Ich hatte einen Logic-Analyzer in Erinnerung.

[Markus F. (markus_f151)]

Stefan ⛄ F. schrieb:
> Ok, dann habe ich dich also doch von Anfang an richtig verstanden. Wir
> diskutieren hier also nicht um Kondensatoren zum Entprellen, sondern um
> eine mutmaßliche Fehlfunktion des PCF8574.

Ja genau. Aber über eine HW Entprellung muss ich mir ggf. doch auch 
Gedanken machen, falls der PCF mit den Gegebenheiten nicht klar kommt.

Stefan ⛄ F. schrieb:
> Was ist mit den Abblock-Kondensatoren um den SPannungsregler herum und
> am PCF8574?

Der Spannungsregler ist Ein- und Ausgangsseitig mit 10uF gestützt. Ist, 
wie Helmut schrieb, deutlich zu wenig. Da muss ich zum Testen noch was 
dranhängen. Zusätzlich sind noch für die höherfrequenten Anteile 100nF 
vorhanden. Der PCF selbst hat nicht unmittelbar Kondensatoren daneben.

Stefan ⛄ F. schrieb:
> liefert der Chip immer noch dauerhaft Interrupts, obwohl alle Eingänge
> auf einem stabilen Logikpegel verharren?

Mit den 10uF Kondensatoren und dem fehlenden 100nF neben dem PCF, ja.

Stefan ⛄ F. schrieb:
> Der Vorschlag "besorge Dir ein Oszilloskop" war nicht böse gemeint. Ich
> habe ganz vergessen, dass du bereits ein Bild von deinem Oszilloskop
> gezeigt hattest. Ich hatte einen Logic-Analyzer in Erinnerung.

Keine Sorge, ich habe das nicht negativ aufgefasst. Habe aber wie du 
vermutet hast, den Logicanalyser für die Messungen verwendet. Kann 
natürlich auch die Tastköpfe und Oszi-Funktion nehmen.

[Stefan F. (Gast)]

Markus F. schrieb:
> Der PCF selbst hat nicht unmittelbar Kondensatoren daneben.

Rüste das nach. Und zwar bevor du weiter fummelst.

[Markus F. (markus_f151)]

Stefan ⛄ F. schrieb:
> Rüste das nach. Und zwar bevor du weiter fummelst

Danke, mache ich. Werde aber erst am Abend soweit sein.

[Peter D. (peda)]

Markus F. schrieb:
> Wenn ich ordentlich die Taste prellen lasse, fängt der Interrupt mit dem
> Dauerprellen an.

Das deutet umso mehr auf einen Ablauffehler in der Software hin (race 
condition). Denn wenn es Störungen wären, dann sind die ja von der 
Geschwindigkeit unabhängig.

[Markus F. (markus_f151)]

Peter D. schrieb:
> Das deutet umso mehr auf einen Ablauffehler in der Software hin (race
> condition). Denn wenn es Störungen wären, dann sind die ja von der
> Geschwindigkeit unabhängig.

Ja, da gebe ich dir auf alle Fälle recht. Da muss ich auch noch 
nachbesseren. Deinen Vorschlag mit dem Timer-Interrupt kann ich bei der 
Arduino-Umgebung so nicht umsetzen. Da hab ich keine Timer. Da werde ich 
wohl weiterhin mit durchdachten Delays arbeiten müssen.

[Peter D. (peda)]

Markus F. schrieb:
> Arduino-Umgebung so nicht umsetzen. Da hab ich keine Timer.

Das wäre mir aber neu. Die AVRs haben in der Regel mehrere Timer. Die 
Arduino-Lib hat sogar einen 1ms Systick, darin kann man prima bis 10ms 
zählen.

[Markus F. (markus_f151)]

Ja, der ESP hat doch einen freien Timer. Der Timer 1. Muss ich mir 
ansehen.

[Carl D. (jcw2)]

Offtopic: entfern die beiden (oben/unten) Kurzschlußringe um die 
Antenne.

[Markus F. (markus_f151)]

Carl D. schrieb:
> Offtopic: entfern die beiden (oben/unten) Kurzschlußringe um die
> Antenne.

Danke Carl, werde ich machen.
Der Empfang ist so eh mehr als bescheiden.

[Markus F. (markus_f151)]

Hallo zusammen,

habe heute wieder Zeit gehabt an der Schaltung zu arbeiten.
Die angesprochenen Kondensatoren habe ich nachgerüstet, die Werte der 
Schutzschaltung bei einem Taster angepasst. Statt 100pF/100k nun 
100nF/10k. Code habe ich den alten belassen. Trotz der 
Hardwareanpassungen hat sich am Verhalten nichts geändert. Somit ist 
wohl klar, dass Softwareseitig was zu tun ist. Habe daraufhin den Code 
zum Auslesen der Eingänge von Interrupt gesteuert auf Timer mit 
Debouncing umgestellt. Das Zeugs funktioniert nun in meiner 
Testapplikation. Im Produktivcode ist es noch etwas komplizierter, da 
dort das Zeitverhalten auf Grund von anderen Sensoren und einem 
WebServer, anders ist. Nun weiß ich aber, dass die Eingänge passen.

Ich habe noch ein paar Oszillogramme erstellt, welche ich mit euch 
teilen möchte.

OG 01: PCF ist noch nicht außer Tritt gebracht.
OG 02: PCF wurde mit absichtlichem Prellen außer Tritt gebracht. Wenn 
die Interruptleitung eine Änderung anzeigt, prellt diese massiv
OG 03: Neuer Auslesecode mit 100nF/10k RC-Glied
OG 04: Neuer Auslesecode mit 100pF/100k RC-Glied (ist sauberer als OG 
03)
deb-10: Debounce mit 10ms - alle Wechsel wurden erkannt
deb-30: Debounce mit 30ms - alle Wechsel wurden erkannt
deb-40: Debounce mit 40ms - manche Wechsel verloren
deb-50: Debounce mit 50ms - viele Wechsel verloren

Outcome:
Ich werde die RC-Glieder mit 100pF/100k belassen.
Der neue Code sollte soweit funktionieren. Im Gesamtkonstrukt muss ich 
noch nachbessern.
Ich hätte ehrlich gesagt nicht gedacht, dass man mit einer 
ungünstigen/fehlerhaften Software die Hardware so außer Tritt bringen 
kann.