Hey,
ich wollte jetzt mal für ein Projekt einen Kapazitiven Sensor
programmieren.
Die Hardware hab ich mir fertig gekauft und funktioniert mit dem Arduino
und dem selben Code bestens. Nur gibt es wieder Probleme mit dem Esp.
Ich hab den Sensor an einem Interrupt Pin (Pin 14) am Esp angeschlossen
und wollte über die Serielle Ausgabe schauen, welche Werte der Sensor
mir liefert. Dazu hab ich diesen Test geschrieben.
1
volatileunsignedinti_pulse;
2
3
voidsetup()
4
{
5
Serial.begin(9600);
6
// Serial.begin(115200);
7
8
delay(3000);
9
Serial.println("Serial OK");
10
// Diese Ausgabe kam noch, danach war schluss und die Fehlermeldung trat auf.
Sobald ich die Serielle Ausgabe starte, bringt der mir nur noch eine
Fehlermeldung. Was mach ich da falsch? Auf dem Arduino hat alles super
funktioniert und ich hab die Sensorwerte angezeigt bekommen?
Freue mich über jede Hilfe.
Tach,
die Fehlerursache steht doch da: Der Watchdog löst einen Reset aus.
D.h. irgendwo gibt es noch ne Hintergrundtask, die normalerweise den
Watchdog zurücksetzt, aber durch den Aufbau deines Programmes nicht mehr
"drankommt". Vielleicht ist das delay(1000) in "loop" schon zu lang.
Schon mal probiert, diesen Wert zu reduzieren? Oder gibt es in der von
dir verwendeten Umgebung eine Funktion, um das Watchdog-Timeout zu
verlängern oder den Watchdog ganz auszuschalten? Nur um erstmal den Bug
zu fixen.
Grundsätzlich ist aktives Warten mit delay() nicht das Gelbe vom Ei.
Besser einen Timer dafür nehmen und das eigentliche Doing in den
Callbacks.
Ich hab den delay aus der loop jetzt entfernt und tatsächlich hat der
mir einen Wert zurückgegeben. Leider nur einen und dann kam wieder die
Fehlermeldung.
Der esp8266 ist kein arduino! Du kannst nicht einfach im arduino style
programmieren und hoffen das es läuft ;)
Im Hintergrund laufen einige tasks im scheduler für wifi und co. delays
sind hier der tod. Schau dir mal die funktion yield() aus der esp8266
doku an...
Eigentlich ganz einfach!
Es liegt nicht an den delays!
Der Watchdog ist ja nichts weiter als ein Zähler der bei Überlauf einen
Softreset auslöst. Es gibt nur 2 Möglichkeiten dies zu verhindern:
1. Watchdog generell abschalten
2. Watchdog vor dem Zählerüberlauf zurück setzen
Für Deine Anwendung würde ich 1. bevorzugen. 2. nimmt man nur wenn man
auf einen "hängenden" µC reagieren will, aber dann sollte man keine
delay's benutzen.
Wie man den Watchdog abschaltet muß Du der Dokumentation zu Deinem µC
entnehmen.
Zeno
TestX schrieb:> Der esp8266 ist kein arduino! Du kannst nicht einfach im arduino style> programmieren und hoffen das es läuft ;)> Im Hintergrund laufen einige tasks im scheduler für wifi und co. delays> sind hier der tod. Schau dir mal die funktion yield() aus der esp8266> doku an...
Vorsicht!
Im delay() wird yield() aufgerufen.
Und auch vor jedem loop() Aufruf.
Das kann also hier nicht das Problem sein.
Zeno schrieb:> Wie man den Watchdog abschaltet muß Du der Dokumentation zu Deinem µC> entnehmen.
Falscher Ansatz.
Zeno schrieb:> aber dann sollte man keine> delay's benutzen.
Falsch!
Begründung schon gegeben.
Arduino F. schrieb:> Falscher Ansatz.
Na Du Superschlauer dann löse doch das Problem.
Es ist definitiv kein falscher Ansatz den Watchdog abzuschalten. Das
wird z.B. von TI in der MSP430 Doku bzw. den Examples so vorgeschlagen.
Den Watchdog braucht man nur in einem kritischen Umfeld, also dann wenn
der µC nicht hängen darf. Wenn dort die Routine die den Watchdog resetet
nicht mehr erreicht wird, dann wird der µC durch den Watchdog neu
gestartet wodurch wieder definierte Zustände erreicht werden sollen.
Wenn man diese Funktionalität nicht benötigt, dann schaltet man den
Watchdog ab.
Natürlich kann man auch dafür sorgen den Watchdog rechtzeitig vor
Überlauf zurückzusetzen. Wann der Überlauf statt findet muß man in der
Dokumentation nachlesen.
Zeno
Zeno schrieb:> Superschlauer
Selber!
Deine Erklärung des WDT ist super schön...
Deine Ausführungen, dass das delay() den WDT zur Auslösung zwingt, ist
falsch.
Das abschalten des WDT würde das Problem also nur am Symptom erwischen,
nicht an der Ursache.
Arduino F. schrieb:> Deine Ausführungen, dass das delay() den WDT zur Auslösung zwingt, ist> falsch.
Das habe ich nicht geschrieben !
Siehst Du in seinem Quelltext eine Codezeile wo er den Watchdog
zurücksetzt? Ich nicht nicht.
delay() zwingt nicht den Watchdog zur Auslösung aber wenn
Programmlaufzeit + delay() größer werden als die Zeit die der
Watchdog(timer) für den Überlauf braucht, dann löst er halt aus. Also
muß der TO den Watchdog vor Ablauf der Zeit reseten, unabhängig davon ob
er delays benutzt oder nicht.
Bei Benutzung von delays - was ich auch gelegentlich tue, z.B. bei
1-Wire, weil ich dort keine unkalkulierbaren Interupts brauchen kann und
deswegen selbige abschalte, muß ich dafür Sorge tragen das der
Watchdogtimer nicht überläuft, also selbigen reseten. In aller Regel
benötige ich die Watchdogfunktionalität nicht weshalb sie eigentlich
generell bei der Initialisierung disabled wird.
Zeno
Zeno schrieb:> Siehst Du in seinem Quelltext eine Codezeile wo er den Watchdog> zurücksetzt? Ich nicht nicht.
Ja!
Vor loop() wird yield() aufgerufen.
Und auch innerhalb von delay(), genügend oft.
yield() ruft intern den WDT Feed auf.
Zeno schrieb:> + delay()
Das ist falsch.
Zeno schrieb:> In aller Regel> benötige ich die Watchdogfunktionalität nicht weshalb sie eigentlich> generell bei der Initialisierung disabled wird.
Was du in deinem Kämmerlein tust, steht hier gar nicht zur Debatte!
Arduino F. schrieb:> Vor loop() wird yield() aufgerufen.> Und auch innerhalb von delay(), genügend oft.
Ah Du bist Hellseher. Vor loop() wird gar nichts aufgerufen. Beim
Hochfahren wird setup() auf gerufen und das war's. Das loop ist das
Äquivalent zur main() im Standard C Programm und das wird nur einmal
aufgerufen und zwar nach setup().
Kennst Du die Deklaration von delay()? Wird da wirklich yield()
aufgerufen und das auch gleich x-mal?
Da Du ja offensichtlich ein ganz Schlauer ist wäre es doch an der Zeit,
wenn Du dem TO endlich mal eine Lösung auf zeigen würdest. Oder
überfordert Dich das? Also streite Dich mit mir mal nicht über yield()
oder nicht yield(), weil das dem TO nicht weiter hilft.
Poste mal ne Lösung wenn Du dazu in der Lage bist, ansonsten trolle
Dich.
Zeno
Zeno schrieb:> Kennst Du die Deklaration von delay()?
Ja.
Auch die Definition.
Zeno schrieb:> Ah Du bist Hellseher.
Leider nicht.
Zeno schrieb:> Das loop ist das> Äquivalent zur main() im Standard C Programm und das wird nur einmal> aufgerufen und zwar nach setup().
Falsch!
Zeno schrieb:> wenn Du dem TO endlich mal eine Lösung auf zeigen würdest.
Nunja...
Das Programm des TE läuft schon ca 20 min im Test bei mir.
Ohne Probleme.
So einfach ist es also nicht....
Zeno schrieb:> weil das dem TO nicht weiter hilft.
Nebelkerzen helfen im erst recht nicht.
Zeno schrieb:> Wird da wirklich yield()> aufgerufen und das auch gleich x-mal?
Mindestens ein mal bei delay(0).
Bei anderen Werten darf der Scheduler dran. Auch der macht den WDT feed.
wenn ihr euch wieder eingefangen habt..
Arduino F. schrieb:> Deine Ausführungen, dass das delay() den WDT zur Auslösung zwingt, ist> falsch.
das delay() löst ohne den wdt zurück zu setzen den rst aus, wenn der
zähler insgesamt über 3 sekunden sich anhäuft.
an dieser aussage kommst du auch bei mir nicht vorbei.
jedes delay über 3 sekunden ohne den wdt zurück zu setzen, ist daher zu
vermeiden, steht auch in der api oder in der user define drin.
wenn ein delay unbedingt sein muss, dann nur in maximal 1sek delay
schritten und immer schön den wdt füttern.
wenn du dann ein 3 sek delay benötigst, dann
wdt feed
delay
wdt feed
delay
wdt feed
delay
man kann den wdt auch abschalten - das rate ich aber ab in solchen test
umgebungen und bei der derzeitigen hitzköpfigkeit.
da der TO hier mit arduino code und wahrscheinlich arduino ide
programmiert, nutzen ihm die api befehle der sdk wie
- system_soft_wdt_feed()
- system_soft_wdt_stop()
- system_soft_wdt_restart()
nicht sonderlich viel.
ich werde es nie verstehen, warum man nicht das original verwendet wenn
es einem zur verfügung gestellt wird.
nein ich habe nichts gegen die arduino ide -
aber es braucht sich keiner wundern, wenn manche sachen darin nicht
funktionieren wie sie bei arduino bausteinen und targets funktionieren;
sie laufen eben nur als esp target, wenn diese auch von der sdk in das
arduino format ( yield ) übertragen und integriert wurden.
es gibt eben sachen in der arduino ide - die eben noch nicht für den esp
ausgereift sind.
So Mister Superschlau bis jetzt waren Deine Posts nichts als heiße Luft.
Da Du es ja offensichtlich besser weißt, sollte es doch für Dich ein
Leichtes sein mal die Implementierung von delay zu posten, damit jeder
Deine Argumentation nach vollziehen kann, und dann sind hier alle
gespannt auf Deinen Lösungsvorschlag zum Problem des TO. Bisher enthälst
Du uns jeglichen Lösungsvorschlag vor. Also poste doch mal die
Problemlösung - sollte für Dich doch kein Problem sein.
Zeno
Zeno schrieb:> Leichtes sein mal die Implementierung von delay zu posten,
Dein Google kaputt?
https://github.com/esp8266/Arduino/blob/633e48f3aec5f1c3c11d4498fc90d378d49e6e9f/cores/esp8266/core_esp8266_wiring.cZeno schrieb:> Bisher enthälst> Du uns jeglichen Lösungsvorschlag vor. Also poste doch mal die> Problemlösung - sollte für Dich doch kein Problem sein.
Wie gesagt, kann ich bei mir nicht reproduzieren.
Würde ja gerne ...
who_feedt_the_wdt schrieb:> das delay() löst ohne den wdt zurück zu setzen den rst aus, wenn der> zähler insgesamt über 3 sekunden sich anhäuft.> an dieser aussage kommst du auch bei mir nicht vorbei.>> jedes delay über 3 sekunden ohne den wdt zurück zu setzen, ist daher zu> vermeiden, steht auch in der api oder in der user define drin.
Auch ein hochsetzen des delay auf 10 Sekunden löst den WDT nicht aus.
// weg damit du du irretierst den Interrupt mit deiner eigen aggierung
38
// delay(10);
39
40
// hier deaktivierst du..
41
detachInterrupt(14);// Interrupt deaktivieren
42
43
returni_pulse;
44
}
45
46
// das ist deine ISR routine
47
// aber wo setzt du den ISR zurück ( clearen ) ?
48
voidzaehlen(){i_pulse++;}
Hier sind Oberschlaue, die sich die Köpfe einschlagen wegen yield oder
nicht yield.
Ihr sollten beide noch mal von vorne anfangen und dem TO mitteilen,
dass er vergessen hat, den INTR zurück zu setzen und der Loop in der
Schleife durch den delay ewig läuft und durch das delay den wdt auslöst.
Somit sind beide Sachen vorhanden
- der delay löst den wdt aus
- vor dem loop ist kein yield
Euer
Superschlauer
und jetzt gebt ruh -
der TO muss erst seinen code vervollständigen
dann habt ihr wieder futter zum streiten.
wer darüber hinaus aber weiterstreitet,
hilft dem TO nicht.
daher - der thread ist zu schliessen
:=)
Arduino F. schrieb:> Auch ein hochsetzen des delay auf 10 Sekunden löst den WDT nicht aus.
Ich werde dich ignorieren, du suchst Streit.
Suche ihn auf der Strasse mit deinem Gesicht.
Der nächst beste 7.Klässer zeigt dir dann wo es lang geht, Schwätzer.
who_feedt_the_wdt schrieb:> - der delay löst den wdt aus
In delay() wird yield() aufgerufen.
who_feedt_the_wdt schrieb:> - vor dem loop ist kein yield
loop wird vom Scheduler aufgerufen.
Der Scheduler macht den WDT feed.
who_feedt_the_wdt schrieb:> Ihr sollten beide noch mal von vorne anfangen und dem TO mitteilen,> dass er vergessen hat, den INTR zurück zu setzen
Das wird alles automatisch erledigt
Tut keine Not sich darum zu kümmern.
who_feedt_the_wdt schrieb:> Arduino F. schrieb:>> Auch ein hochsetzen des delay auf 10 Sekunden löst den WDT nicht aus.>> Ich werde dich ignorieren, du suchst Streit.
Wenn du meinst...
Es läuft hier bei mir im Test.
Mehr kann ich dazu nicht sagen...
Arduino F. schrieb:> who_feedt_the_wdt schrieb:>> - der delay löst den wdt aus> In delay() wird yield() aufgerufen.>> who_feedt_the_wdt schrieb:>> - vor dem loop ist kein yield> loop wird vom Scheduler aufgerufen.> Der Scheduler macht den WDT feed.>> who_feedt_the_wdt schrieb:>> Ihr sollten beide noch mal von vorne anfangen und dem TO mitteilen,>> dass er vergessen hat, den INTR zurück zu setzen> Das wird alles automatisch erledigt> Tut keine Not sich darum zu kümmern.
Du hast irgendetwas nicht verstanden.
nochmals im Klartext für dich:
Der TO cleart den INTR nicht -
d.h. egal ob yield, oder nicht
egal ob Scheduler oder nicht.
Der WDT löst aus weil die Schleife hängt!
Selbst wenn der LOOP vom Scheduler aufgerufen wird,
ruft der Loop nur ein einzigen Mal den ISR auf,
nachdem der TO den verrückten delay von 3 sek entfernt hat,
darum bekommt er auch nur einmal einen Wert,
weil er im nächsten Moment zwischen attach und deattach
der delay aufläuft, weil kein INTR mehr auslöst.
So - da du Streit suchst,
ich aber keinen Streit suche
ich es weiss dass du falsch liegst
such dir den 7 Klässer auf der Strasse
und mess dich mit dem..
und der Klügere gibt nach und geht ins Bett.
Morgen ruft die Arbeit wieder.
Vieleicht sollstest du das auch tun.
Arbeiten - vieleicht auch mal an dir.
Du kannst auch gerne noch weiter aufzeigen
dazu wirst du jetzt öffentlich aufgefordert,
deinen Beweis zu erbringen,
wo der Scheduler oder das yield den WDT
in der Arduino IDE für den ESP das erledigt
was du angibst.
Es denken mehr Leute wie du, dass alles integriert ist in der IDE.
Ist es aber nicht.
Ich werde morgen mal reinschauhen wie es dir bei der Google
suche ergangen ist und welches Resultat du ablieferst.
Bisher leider nur heisse Luft.
Aber das wurde dir schon gesagt.
Arduino F. schrieb:> who_feedt_the_wdt schrieb:>> Arduino F. schrieb:>>> Auch ein hochsetzen des delay auf 10 Sekunden löst den WDT nicht aus.>>>> Ich werde dich ignorieren, du suchst Streit.>> Wenn du meinst...>> Es läuft hier bei mir im Test.> Mehr kann ich dazu nicht sagen...
Dein Test sieht so aus:
1
voidsetup()
2
{
3
Serial.begin(9600);
4
Serial.println("Serial OK");
5
}
6
7
voidloop()
8
{
9
Serial.println("Ich teste mich jetzt - ich habe Recht\n");
10
delay(1000);
11
}
Hast du auch in diesem Fall.
Baue eine INTR ein,
cleare in nicht
und die Geschichte sieht dann auch so aus
wie die des TO.
Der WDT löst aus.
So - aber jetzt -
Teste weiter - ich störe dich nicht mehr
;-)
Grüße *,
bevor ihr euch auf den Code versteift, der sollte funktionieren. Richtig
ist, daß ihr die (Arduino-)Delays solange machen könnt wie ihr wollt.
Der WDT wird vom Arduino-Framework zurückgesetzt im delay().
Schöner wäre natürlich, einen Ticker zu benutzen, um auch die
loop()-Funktion so kurz wie möglich zu halten, denn einer hat schon
richtigerweise geschrieben, daß der ESP einen Haufen Hintergrundtasks
hat, die alle laufen müssen und Busy-Waiting ist generell keine gute
Idee (Energieverbrauch, ...).
@OP: Ein paar Vorschläge.
- Es könnte am Printen liegen. Serial.print ist selbst
Interrupt-gesteuert, vielleicht beißen die sich. Lies den Wert einmal in
eine temporäre Variable vor dem Print, und printe dann die temporäre
Variable. Quelle:
https://github.com/esp8266/Arduino/issues/21#issuecomment-88597935
- Schau mal, ob das nicht was Elektrisches ist, ob also die
Versorgungsspannung stabil bleibt, die 100n's über + und - dran sind,
was über den Pin 14 für Ströme fließen (ideal natürlich Scope mit ~0,1
Ohm). Meine ESPs hier sind extrem picky, was ihre Stromversorgung und
die Pinbeschaltung angeht.
- Wenn's das nicht ist, welches SDK nutzt Du denn? Aktuelle IDE laden
und die 2.xx aus dem GIT nehmen, vielleicht ist in einer alten Version
noch irgendwo ein Bug drin.
Cheers, Christoph
Christoph S. schrieb:> - Es könnte am Printen liegen. Serial.print ist selbst> Interrupt-gesteuert, vielleicht beißen die sich.
Serial Print macht in ISRs Sorgen, ja, sobald der Buffer voll wird
verklemmt es, und der WDT wird zuschlagen.
Aber:
1. Ist das print nicht in einer ISR.
2. Sind das sowenig Ausgaben, die presst es bequem nebenbei raus.
Christoph S. schrieb:> bevor ihr euch auf den Code versteift, der sollte funktionieren.
Richtig, mein Reden.
Der Fehler liegt außerhalb des gezeigten Codes.
Ein irgendwie geartetes INTR ist nicht nötig.
Christoph S. schrieb:> daß der ESP einen Haufen Hintergrundtasks> hat, die alle laufen müssen und Busy-Waiting ist generell keine gute> Idee (Energieverbrauch, ...).
Delay() gibt den anderen Tasks Zeit.
Tut also hier nicht weh.
Ob das so schön ist, ist eine andere Frage.
Ansonsten:
Stromversorgung und SDK sind richtig gute Tipps.
Hallo,
installiere Dir mal den ESP Exception Decoder in der IDE, der hilft da
durchaus zur Fehlereingrenzung.
Spannungsversorgung ist bei den ESP durchaus ein Problem, ein 100-220µF
Elko an den GND/Vcc des ESP hilft da durchaus.
Zu dem ganzen yield(): delay() ruft yield() auf, im Programm sehe ich im
Moment aber keinen Grund für das Auslösen des WDT.
WDT abschalten geht beim ESP nicht wirklich, der Hardware-WDT schlägt im
Zweifel nach rund 6s zu, wenn der ESP nicht zum Zuge kam, das ist nicht
zu verhindern.
Passiert aber einegelich nur in Loops, dich wirklich nichts anderes
machen, z.B . while (digitalRead(Pin) == LOW) { }
Da muß dann ein yiled() in die Loop.
Möglich wäre noch eine "Nebenfunktion" des I/O-Pins, allerdings ist Pin
14 vom Hardware-SPI, da wüßte ich kein Problem.
Ansonsten mal zum Test Pin 4 oder Pin 5 nehmen, die sind
"rückwirkungsfrei".
Gruß aus Berlin
Michael
Arduino F. schrieb:> Auch ein hochsetzen des delay auf 10 Sekunden löst den WDT nicht aus.
Ich habe früher auch die Arduino Umgebung genutzt und bei 10 Sekunden
gab es unter integer immer Probleme.
Auch schon manchmal bei 3000.
Kann der TO doch einfach mal zum Testen auf 2000 setzen.
Neuer Tag, neues Glück!
Habe den Code aus dem Eingangsposting nochmal getestet.
Es funktioniert.
Ich kann den Fehler nicht reproduzieren.
Es liefert meist "Soil moist value: 10", manchmal 11, wenn ich einen
1kHz Rechteck auf GPIO14 gebe.
Die Baudrate hat keine Auswirkung, egal ob 9600 oder 115200.
Die Länge der Delays, hat keine Auswirkungen.
Und ein INTR ist flüssiger als Wasser, überflüssig.
Mein Schluss daraus:
Das Problem steckt außerhalb des gezeigten Codes.
Ich benutze genau diesen Kapazitiven Sensor den Rednu gerade gepostet
hat.
Könnte das vielleicht an dem Spannungsregler liegen der auf dieser
Platine mit integriert ist?
Alexander B. schrieb:> Könnte das vielleicht an dem Spannungsregler liegen der auf dieser> Platine mit integriert ist?Alexander B. schrieb:> ich versorge den Sensor mit 3V3.
Hmm...
Das "riecht" falsch.
Was für ein Regler ist da drauf?
Und was soll er tun?
Alexander B. schrieb:> Ich weiss allerdings grad nicht> was der Sensor für einen High Pegel liefert.
Das solltest du aber wissen!
Und wenn nicht, solltest du dich darum kümmern.
Das ist der IC der sich da drauf befindet.
http://cdn-reichelt.de/documents/datenblatt/A240/SMDHC14%23STM.pdf
Ich bin mir nicht mal sicher ob sich da drauf überhaupt ein
Spannungsregler befindet. Meiner Meinung nach nicht. Vielleicht könnt
ihr ja noch aus dem Schaltplan was lesen.
> Der ESP ist mit 5V am Eingang völlig überfordert.(Todesgefahr)
Da muß ich doch glatt einmal klugschießen :)
Der ESP hat natürlich clamping Dioden gegen die Versorgung (sonst
könnten wir das Teil gar nicht anfassen, ohne es zu zerstören). Das
heißt, man muß "nur" darauf achten, daß der Strom in den ESP rein nicht
zu groß wird und ihn z.B. über einen geeigneten Widerstand (URI!)
begrenzen. Die Clamping-Diode zieht die Spannung dann schon auf ein
geeignetes Niveau.
Wenn Du also dank niedriger Bandbreite des Signals die parasitären
Effekte eines R vernachlässigen kannst, sollte ein genügend großer
serieller Widerstand als Schutz ausreichen. Man muß keinen Aufwand mit
einem Pegelwandler betreiben.
Übrigens: Ich versorge in einem Projekt den ESP (-12F) direkt aus einer
4,2V LiPo-Zelle. Läuft seit Monaten ohne Abnippeln.
Heisst das ich ein paar Bauteile raus schmeißen muss ? Weil der ic
braucht doch mindestens 2V So wie ich das im datenblatt gelesen habe.
Oder lieg ich da falsch ?
Alexander B. schrieb:> Also ich versorge den Sensor mit 3V3. Ich weiss allerdings grad nicht> was der Sensor für einen High Pegel liefert.
Ahaaa. Da hast du dein Problem.
Du must den Spannungsregler "deaktivieren".
Löste den Transistor aus und/oder überbrücke ihn.
Der ist nur als Längsregler für Spannungen >5.2V gedacht.
Unter 3.3V wird da noch Spannungs am Transistor abfallen.
Wenn du ihn mit 3.3V versorgst, dann wird er auch ein Signal mit 3.3V
ausgeben.
Miss nach dem Überbrücken mal die Versorgungsspannung am IC.
Ich habe mal D1 und R1 entfernt. D1 habe ich überbrückt. Allerdings ging
der Sensor dann gar nicht mehr. Ich habe wahrscheinlich die Spannung zum
IC gekappt. Also seid ihr der Meinung, das ich nur T1 entfernen und
diesen Überbrücken soll?
Also ich hab den Spannungsregler vom Sensor jetzt entfernt. Aber ich hab
immer noch das selbe Problem. Der Sensor bekommt jetzt direkt die 3v3...
Der ESP stürzt trotzdem weiter ab :(
Der oben beschriebene Sensor erzeugt ohne in Erde oder Wasser zu stecken
gern mal Frequenzen um die 300kHz. Selbst in der Erde können es noch
mehr als 100kHz sein. Mit diesen Frequenzen Gpio-Interrups auf dem ESP
auszulösen ist meiner Meinung nach absolut grenzwertig, vor allem wenn
man bedenkt was alles laufen muss um die LwIp Stack und Wifi am laufen
zu halten.
Hast du mal die Frequenz des Sensors gemessen?
Sind die Probleme auch noch da wenn du den Pin wo der Sensor dran hängt
fest auf GND oder VCC legst?
Wenn dann die Probleme nicht mehr auftreten sollte die Ursache klar
sein.
Rednu schrieb:> Wenn du in fest in der Hand hältst, sollte er etwa 20khz ausgeben.> In Wasser etwa 2 Khz und weniger.
Wir wissen leider nichts vom mechanischem Aufbau des Sensors. Wenn es
der aus dem oben verlinkten Giess-o-Mat ist liegen die Werte deutlich
höher. Jedenfalls wenn für den zeitbestimmenden Widerstand 100k drin
sind und nicht nur ein dünner Lack zur Isolierung benutzt wird. Bevor
aber die Spekulationen ins Kraut schießen sollte das mal gemessen
werden.
Thread beobachten
Seitenaufteilung abschalten