mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ESP8266 + Kapazitiver Sensor


Autor: Alexander B. (alexander95)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
volatile unsigned int i_pulse; 

void setup() 
{             
  Serial.begin(9600);
//  Serial.begin(115200);

  delay(3000);
  Serial.println("Serial OK");
  // Diese Ausgabe kam noch, danach war schluss und die Fehlermeldung trat auf.
}

void loop() 
{
  Serial.println("Soil moist value: " + String(readCapSensor()));
  delay(1000);
}

volatile unsigned int readCapSensor()
{
  i_pulse = 0;                             // Anzahl der Pulse auf 0 setzen
  attachInterrupt(14, zaehlen, RISING);    // Interrupt aktivieren: Steigende Flanken
  delay(10);
  detachInterrupt(14);                     // Interrupt deaktivieren
  
  return i_pulse;
}

void zaehlen(){ i_pulse++; }

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.
Soft WDT reset

ctx: sys 
sp: 3ffffd80 end: 3fffffb0 offset: 01b0

>>>stack>>>
3fffff30:  3fff00d4 4022640b 3ffecdf8 3ffefd14  
3fffff40:  4022630a 3ffecdf8 3ffecdf8 3ffebc10  
3fffff50:  3ffebc10 000000ab 00000000 00000026  
3fffff60:  00000000 000000ab 4021d5d3 3ffecdf8  
3fffff70:  3ffebc04 3fffdcc0 3ffe9420 3ffe9420  
3fffff80:  00000080 3ffecdf8 00000000 3ffee3e0  
3fffff90:  4021cf0f 3fffdab0 00000000 402022b7  
3fffffa0:  3ffe9420 40000f49 3fffdab0 40000f49  
<<<stack<<<

 ets Jan  8 2013,rst cause:2, boot mode:(1,7)

LG
Alex

Autor: Rainer B. (katastrophenheinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alexander B. (alexander95)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
 
value: 1240

Soft WDT reset

ctx: sys 
sp: 3ffffcc0 end: 3fffffb0 offset: 01b0

>>>stack>>>
3ffffe70:  402222f9 00000000 00000006 00000090  
3ffffe80:  00000017 3ffed6dc ffffffc0 00000000  
3ffffe90:  000000a7 00000020 00000000 3ffe9cc6  
3ffffea0:  4022692e 00000000 3ffefd14 ffffffc0  
3ffffeb0:  00000000 00000018 3ffed664 00000000  
3ffffec0:  000000f5 00000001 00000000 3ffecda8  
3ffffed0:  00000000 00110b0b 00640104 0000004e  
3ffffee0:  3ffe9ce0 00000083 3ffe9cfe 3ffe9cd4  
3ffffef0:  00000000 3ffe9ce0 3ffe9cf5 00000000  
3fffff00:  00000000 00000000 00000000 00000000  
3fffff10:  00000000 00000000 00000000 00000000  
3fffff20:  00000000 00000000 00000020 00000000  
3fffff30:  3fff00d4 40226407 3ffecda8 3ffefd14  
3fffff40:  00000000 3ffedcd8 3ffecda8 3ffe9cbc  
3fffff50:  3ffe9cbc 000000ab 00000000 00000020  
3fffff60:  00000000 000000ab 4021d5cf 3ffecda8  
3fffff70:  3ffe9cb0 3fffdcc0 3ffe9510 3ffe9510  
3fffff80:  00000080 3ffecda8 00000000 3ffee3e0  
3fffff90:  4021cf0b 3fffdab0 00000000 402022b3  
3fffffa0:  3ffe9510 40000f49 3fffdab0 40000f49  
<<<stack<<<

Autor: TestX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mach doch mal die 3000 am Anfang kleiner oder gehe von int auf long.

: Bearbeitet durch User
Autor: Zeno (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Zeno (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Zeno (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
Autor: Zeno (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: who_feedt_the_wdt (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Zeno (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeno schrieb:
> Leichtes sein mal die Implementierung von delay zu posten,
Dein Google kaputt?
https://github.com/esp8266/Arduino/blob/633e48f3ae...

Zeno 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.

Autor: who_feedt_the_wdt (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert

volatile unsigned int i_pulse; 

void setup() 
{             
  Serial.begin(9600);
//  Serial.begin(115200);

// weg damit!
//   delay(3000);

  Serial.println("Serial OK");
  // Diese Ausgabe kam noch, danach war schluss und die Fehlermeldung trat auf.
}

void loop() 
{

// wie oft willst du den Interrupt aktivieren in dieser Schleife 
// ohne nur ein einziges mal den Interrupt zu clearen?
// was wer wenn soll er danach auslösen, auswerten ect?
// wo ist deine routine zum Interrupt clearen 

  Serial.println("Soil moist value: " + String(readCapSensor()));

// weg damit!
// delay(1000);

}

volatile unsigned int readCapSensor()
{
  i_pulse = 0;                             // Anzahl der Pulse auf 0 setzen

// hier aktivierst du..
  attachInterrupt(14, zaehlen, RISING);    // Interrupt aktivieren: Steigende Flanken

// weg damit du du irretierst den Interrupt mit deiner eigen aggierung 
// delay(10);

// hier deaktivierst du..
  detachInterrupt(14);                     // Interrupt deaktivieren
  
  return i_pulse;
}

// das ist deine ISR routine
// aber wo setzt du den ISR zurück ( clearen ) ?
void zaehlen(){ 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

Autor: who_feedt_the_wdt (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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


:=)

Autor: who_feedt_the_wdt (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: who_feedt_the_wdt (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: who_feedt_the_wdt (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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:

void setup() 
{             
  Serial.begin(9600);
  Serial.println("Serial OK");
}

void loop() 
{
  Serial.println("Ich teste mich jetzt - ich habe Recht\n");
  delay(1000);
}



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

;-)

Autor: Christoph S. (mcseven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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#issue...

- 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

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kurt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal mit ner höheren Baudrate versucht?

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alexander B. (alexander95)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rednu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit welcher Spannung versorgst du den Sensor?
Welche Spannung liefert der High Pegel des Sensors?

Autor: Alexander B. (alexander95)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich versorge den Sensor mit 3V3. Ich weiss allerdings grad nicht 
was der Sensor für einen High Pegel liefert.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Alexander B. (alexander95)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das ist der IC der sich da drauf befindet.
http://cdn-reichelt.de/documents/datenblatt/A240/S...

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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Schaltung erwartet über 5V am Eingang.
Der Logikbaustein erwartet, und liefert, 5V
Der ESP ist mit 5V am Eingang völlig überfordert.(Todesgefahr)

: Bearbeitet durch User
Autor: Christoph S. (mcseven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Alexander B. (alexander95)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Rednu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rednu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder die Frequanz zu hoch. Kommt auf deine Entwicklungsumgebung an.
Siehe: http://www.esp8266.com/viewtopic.php?f=24&t=1486

Autor: Alexander B. (alexander95)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Alexander B. (alexander95)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :(

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rednu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du in fest in der Hand hältst, sollte er etwa 20khz ausgeben.
In Wasser etwa 2 Khz und weniger.

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rednu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Markforum gibt es einen Beitrag drüber, wie der ESP mit dem Sensor 
zusammenarbeitet:
Beitrag "[V] Bausatz für Giess-o-mat Sensor"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.