Nabend
Bis gerade eben lief alles problemlos...
Ich programmiere die NodeMCU über die Arduino IDE (Windows10).
Aber seit einer Stunde bekomme ich nach dem flashen immer folgendes im
SerialMonitor angezeigt:
1
Soft WDT reset
2
3
ctx: cont
4
sp: 3ffef790 end: 3ffef9d0 offset: 01b0
5
6
>>>stack>>>
7
3ffef940: 40213743 00000004 0000000a 3fffdc20
8
3ffef950: 402138c8 00000004 00000000 4020cef9
9
3ffef960: 4020cf5d 60000a00 0000000a 3fffdc20
10
3ffef970: 00030005 00030003 00030003 00030004
11
3ffef980: 00000000 00000002 40203454 3ffee890
12
3ffef990: 40201170 00000000 3ffee970 40202640
13
3ffef9a0: 3fffdc20 3ffe8340 3ffee970 40201915
14
3ffef9b0: 00000000 00000000 3ffee994 40202271
15
3ffef9c0: 00000000 00000000 3ffee9b0 40100114
16
<<<stack<<<
Es gibt dazu einen Thread auf github:
https://github.com/esp8266/Arduino/issues/428
Aber dass einzige was ich dort verstehe ist, dass es was mit dem
Watchdog zu tun haben kann.
Der Fehler ist unabhängig vom Sketch (auch mit einem leeren) und trat
plötzlich auf.
Kennt da Problem hier jemand?
Danke und Gruß Kolja
Hallo,
Kolja L. schrieb:> Der Fehler ist unabhängig vom Sketch (auch mit einem leeren) und trat> plötzlich auf.
es gab einen Fehler, daß falsche Daten im RTC-Bereich den ESP schon beim
Booten crashen lassen.
Sollte in den aktuellen SDKs eigentlich behoben sein.
Komplett neu flashen mit einem der ESP-Tools, die AT-Software hat bei
mir weitergeholfen, speziell die _esp_init_data_default.bin dürfte dafür
zuständig sein.
Aufpassen auf die Speicheraufteilung für Dein Modul, NodeMCU hat einen
32MBit-Flash, also 4MB.
Kaputter machst Du ihn mit Versuchen nicht, der eigentliche Bootloader
ist fest im ROM.
Wie es bei mir damasl zustande gekommen ist, weiß ich auch nicht, die
ArduinoIDE hat da keinen direkten Anteil dran.
Ich habe im Moment nicht mehr allzuviel finden können:
http://www.esp8266.com/viewtopic.php?p=43753
und der Link darin:
https://nodemcu.readthedocs.org/en/dev/en/flash/
Gruß aus Berlin
Michael
Seit heute morgen gibt es eine neue NodeMCU Version 2.1.
Ich freute mich, aber nix da, immer noch der Mist mit dem WDT.
Ich konnte in den letzten 30 Verschen nur einmal erfolgreich flashen
und, was mich am meisten wundert, auch bei einer neuen NodeMCU geht es
nicht.
Das Flashtool läuft leider nicht mit Windows 10.
Zumindest bekomme ich beim Starten immer eine Fehlermeldung, dass das
Programm nicht ausgeführt werden kann.
Verflixter Sonntag :-(
Hallo,
wenn meine Annahme mit der Ursache zutrifft. ist es fast egal, was man
drauf flasht. Der besagte Bereich wird genaugenommen weder direkt
genutzt oder verändert. Der muß also auch vom NodeMCu-update nicht
unbedingt überhaupt mitgeflasht werden.
>Ich konnte in den letzten 30 Verschen nur einmal erfolgreich flashen>und, was mich am meisten wundert, auch bei einer neuen NodeMCU geht es>nicht.
Wie meinst Du das? Brachen die anderen Flashversuche ab oder hat er
einaml ohne den Fehler gebootet?
Gruß aus Berlin
Michael
Das Flashen läuft lt der Anzeige unten in der Arduino IDE durch,
aber auf dem SerialMonitor kommt immer nur der o.g. Code.
Und ich habe es jetzt bestimmt schon 50 Mal versucht,
mittlerweile immer ohne Erfolg...
Kann vielleicht mal jemand die beiden (64 und 32 Bit) Windowsversionen
des Flashtools testen?
https://github.com/nodemcu/nodemcu-flasher
Ich kann keine unter Windows 10 64 Bit starten...
Danke und Gruß Kolja
Hallo,
kein Win10 hier, vielleicht läuft das Flash-Download-Tool.
http://www.electrodragon.com/w/ESP8266_firmware_flasher
Archiv-Passwort merken, steht beim Link...
Für die zu flashenden .bin mußt Du Dir evtl. eine AT-Software suchen.
Wenn die sich dann meldet, kannst Du Deine Firmware wieder flashen.
Gruß aus Berlin
Michael
Nabend
Danke für den Link, das Toll kann ich immerhin starten.
Aber ne neue Firmware bekomme ich nicht drauf.
Einstellungen so wie hier angegeben:
http://www.electrodragon.com/w/File:V1.3.0.2_AT_Firmware.bin.zip
Firmware diese hier:
D0 mit GND verbunden und die Flash Taste gedrückt.
Als Ergebnis leider nur das hier:
1
test offset : 0 0x0
2
case ok
3
(True, [[u'C:\\Users\\Kolja\\Desktop\\v1.3.0.2 AT Firmware.bin', 0]])
Hallo,
der ESP war nicht im Flash-Mode.
D0 vom NodeMCU ist doch GPIO16, der ist uninteressant, beim NodeMCU muß
nichts gebrückt werden.
Flash-Taste festhalten, dann kurz Reset drücken und dann kann man Flash
schon wieder loslassen. Dann ist der ESP im Programmier-Mode.
Falls die NodeMCU-Logik da reinpfuscht bzw. das Flash-Tool an DTR
und/oder RTS wackelt: Reset und Flash gedrückthalten und wenn obiger
Text kommt ERST Reset und DANN Flash loslassen.
Gruß aus Berlin
Michael
OK, mit der Methode "beide festhalten" hat es funktioniert:
1
vendor: 224
2
mode: 64
3
size: 22
4
mode: 0
5
size : 4
6
sel.freq: 26000000
7
tttttest crystal : 1
8
filename: C:\Users\Kolja\Desktop\Flash tool 2.4\bin_tmp\downloadPanel1\v1.3.0.2 AT Firmware.bin_rep
9
offset : 1032192
10
Erasing flash...
11
head: 4 ;total: 255
12
erase size : 1028096
13
mode: 0
14
size : 4
15
sel.freq: 26000000
16
tttttest crystal : 1
17
Writing at 0x001fac00... (99 %)
18
Leaving...
19
com closed
(Ist die Startadresse richtig?)
Aaaber, nach dem Flashen mit der Arduino IDE bleibt es bei:
[code]
Soft WDT reset
ctx: cont
sp: 3ffef920 end: 3ffefb50 offset: 01b08/code]
Versucht habe ich es mit beiden NodeMCUs.
So langsam verzweifele ich hier....
edit: Vielen Dank für deine Unterstützung!
Hallo,
ich habe mal die alten .bin angehängt, im Readme steht das Flash-Layout,
wo die hin sollen.
Leider für die 512k Version, bei der 1MB-Version vom NodeMCU müßte
esp_init_data_default.bin---->0x7C000
blank.bin-------------------->0x7E000
auf 0xFC000 und 0xFE000 geflasht werden. Flash es einfach auf beide
Adressen, stört erstmal nicht weiter.
Entscheidend müßte der esp_init_data_default.bin sein.
Sonst muß ich nochmal ziemlich kramen gehen...
Hat mich damals auch ziemlich Nerven gekosten. ;-)
Gruß aus Berlin
Michael
Hallo,
habe gerade mal mit meinem NodeCU rumgespielt, bekomme es aber
eigentlich nicht richtig zu Deinem Fehler.
Im Anhang oben mal ein leeres Flashfile.
Spiele die 4MB-Version mal mit dem Flashtool ab 0x00000 rauf, dauert
eine Weile.
Falls das nicht hilft, es schadet zumindest nicht...
Ich habe danach eine recht aktuelle AT-Thinker-Verision geflasht, die
meldete sich auch, crashte aber bei eineigen Kommandos, warum auch
immer.
NodeLUA ließ sich auch flashen und meldete sich zumindest ordnungsgemäß,
genauso mein Webserver aus der ArduinoIDE incl. SPIFFS.
Ich habe im Moment sonst keine Idee, was bei Dir passiert ist.
Du kannst in der ArduinoIDE die Baudrate mal auf 74880 stellen und
schauen, was der Bootloader des ESP nach Reset meldet.
Gruß aus Berlin
Michael
Hallo Michael
Hab noch keine Zeit gefunden, deine neuen Datein zu flashen.
Aber, darf ich dich und vielleicht auch den arbeitenden Gast um eine
klarstellung der Nomemklatur bitten?
Ein NodeMCU hat eine eigene Firmware, das was wir gerade versuchen
zurückzusetzen.
Dann hat der ESP auch eine Firmware(?) und meinen eigentlichen Sketch.
Und "flashen" ist immer das Beschreiben eines µC?
Also in allen o.g.drei Fällen?
Danke und Grüße
Kolja
Hallo,
zum Sortieren:
der ESP hat einen Rom-Bootloader, mit dem er über Seriell, SD-Card oder
SPI-Flash booten kann.
Das wird beim Reset über den Statur von GPIO0 und GPIO15 festgelegt.
GPIO0 = H und GPIO15 = L (hat auf dem NodeMCU-Board einen passenden
PullDown) wird vom SPI-Flash gebootet, der ist auf den ESP-Modulen
drauf.
SD-Card ist theoretisch, die nötigen Leitungen sind nicht alle
rausgeführt und es gibt meines Wissens auch keine offizielle
Softwareunterstützung dafür.
Mit GPIO0 = L und GPIO15 = L Mit GPIO0 = L und GPIO15 = L wird von der
Seriellen gebootet.
Das ist die Version, die wir nutzen.
Es wird vom Flashprogramm (egal, ob NodeMCU-Flasher, ArduinoIDE usw.,
eine passende Flash-Routine in den ESP-Ram geschickt und gestartet. Die
übernimmt jetzt das holen der Programmdaten und das Flashen. Details
müßte ich auch nachlesen...
Beim Boot aus dem Flash wird vom Bootloader eine feste Adresse
angesrungen, da muß dann eben das auszuführende Programm (System)
starten.
Ob das NodeLUA, Dein selbstgeschriebener Sketch, ESP-Basic oder was auch
immer ist, interessiert den ESP-Prozessor garnicht, der muß es eben nur
ausführen können.
Wenn der Flash jetzt komplett leer ist, müßte man mal nachschauen, was
die Espressif-CPU mit dem dann gelesenen OP-Code 0xFF anfängt, letztlich
egal, es wird in einem Absturz enden.
Vorteil des Konstrukts ist, man kann den Rom-Laoder nicht kaputt machen,
den ESP also direkt nicht kaputtflashen.
Problemstelle: es gibt über bestimmte Detail der ESP-eigenen
SDK-Bibliotheken nur recht verstreute Informationen.
Die müssen ja generell mit eincompiliert werden, WLAN z.B. und noch
etliche fertigen Sachen. Werden sie auch von der Arduino-IDE im
Hintergrund. Das sind dann die rund 2xx kB, die auch bei leerem Sketch
geflasht werden.
Es gab und gibt dort immer mal Querelen, die ein Starten verhindern
können.
Eins davon war mal, daß es Bereiche im Flash gibt, die ESp reserviert
hat, der blanc.bin und bestimmte Voreinstellungen für ihren Chip in den
init.bin Daten. Wenn die leer sind, setzt die Firmware die normalerweise
auf default-Daten, mit denen alles spielt.
Bei der RTC (der ESP hat theoretisch eine, die kann sogar
Batteriegepuffert laufen) war es vor einiger Zeit so, daß das nicht
klappte. Bestimmte verfälschte Daten aus dem RTC-Bereich wurden
vermutlich ungeprüft übernommen und es gab einen Absturz,
Eigentlich ist dieses Problem seit wohl SDK 1.0 behoben, es gint jetzt
eigentlich beim Start nur die Meldung "MEM CHECK FAILED" irgendwo beim
Start (leider kaum lesbar, die Baudrate ist da meist noch auf 74880 oder
9600 oder 57600...).
Du kannst das auch noch näher ergründen, was schief läuft:
Wenn Du in der ArduinoIDE das Tool
https://github.com/me-no-dev/EspExceptionDecoder
installiertst (Link zum Download ist im dortigen Text bei Installation)
kannst Du evtl. auch mehr in Erfahrung bringen.
Wenn es installiert ist: leeren Sketch für den ESP compilieren und
Flashen.
Wenn er dann abgestürzt ist, die Ausgabe des Stack-Traces ind das
Fenster des Decoders kopieren und das Ergebnis anschauen.
Zeilenzurdnungen stimmen leider nicht immer, weil die Optimierung des
Compilers die beeinflußt. Die zuletzt aufgerufenen Routinen (von oben
nach unten) geben aber vielelicht Hinweise. Normalerweise gibt er auch
die lokalen Pfade zu den Sourcen richtig mit aus.
Wenn ich jetzt was vergessen habe, frage nochmal...
PS: vergleiche es mit Deinem PC: der Bootlaoder ist das BIOS, NodeMCU,
AT-Thinker, Deine Sketche sind die "Betriebssysteme" wie Windows, Linux
usw.
Hinkt wie jeder Vergleich, passt aber ganz gut.
Warum jetzt sozusagen Windows uns nach dem "installieren" (flashen) beim
Start um die Ohren fliegt, wissen wir noch nicht...
Gruß aus Berlin
Michael
Nabend
Danke für die ganzen Erklärungen.
Ich habe jetzt erst die leere.bin geflasht,
dann die beiden alten und dann mein Sketch.
Es funktioniert, aber am Anfang habe zwischen meinen Ausgaben auf dem
seriellen Monitor wieder diese WDT Ausgeben gehabt.
Daraufhin habe ich diesen Trace Decoder installiert.
Seit dem sind die Dinger nicht mehr aufgetaucht.
Aber zwischendurch bekomme ich jetzt das angezeigt:
f r0, scandone
no PRSM found, reconnect after 1s
reconnect
Und PRSM ist unser WLAN.
Ganz merkwürdig...
Hallo,
Kolja L. schrieb:> Es funktioniert, aber am Anfang habe zwischen meinen Ausgaben auf dem> seriellen Monitor wieder diese WDT Ausgeben gehabt.> Daraufhin habe ich diesen Trace Decoder installiert.> Seit dem sind die Dinger nicht mehr aufgetaucht.
das kommt mir irgendwie bekannt vor, irgendwas an meinen Sachen
umgebaut, geflasht und Neustart durch den WatcgDogTimer.
Dumm angeschaut, Rest gedrückt, geht und hing danach immer...
Habe ich nicht weiter verfolgt.
Wenn Du bei Googel nach
esp8266 f r0, scandone
suchst, gibt es bei Espressif ein paar Sachen, scheint mit der
SDK-Version zusammenzuhängen. Du programmierst aus der ArduinoIDE?
Welche Version und welches ESP8266 Version? Die aktuelle ISE 1.6.8 hatte
mit schon irgendeine störende Sache beschert, weiß jetzt nicht was, und
ESP v2.1.0 stürzt bei mir reporduzierbar ab, wenn ich einen
Telnet-Server aufmache und dann dann
TelnetServer.setNoDelay(true);
aufrufe.
Bin erstmal bei IDE 1.6.7 und ESP 2.0.0 geblieben.
Gruß aus Berlin
Michael
Ich nutze die Scherereien - Versionen 1.6.8 und 2.1.0 :-(
Beim nächsten rumzicken wird erstmal gedowngraded.
Laufen die Nodes bei dir im Betrieb denn zuverlässig?
Hallo,
es gibt bei mir in dem Sinne wenig wirklich fertiges bisher, mehr
Spielwiesen für mögliche Anwendungen.
8 oder 9 ESP sind im Einsatz, meist als MQTT-Client und/oder mit
Webserver drauf.
http://www.avr.roehres-home.de/
ist leider nicht vollständig...
Es gibt noch eine WLAN-Steckdose, einen Sensor für Temperatur und
Feuchte,
eine Anzeige für MQTT-Messages, eine Handscanner, der die gescannte
EAN-Sendet, eine Pearl-Laufschrift, die Texte anzeigt, eine
Badlichtüberwachung (ESP mit StepDown parallel zu den 12V Halogenern)
der per MQTT mittelt, daß das Badklicht an ist weil ich das manchmal
vergesse auszuschalten.
Aktuell noch einen ICECast-Steming-Client mit Hardware-MP3-Decoder am
ESP, der zum mitnhemen im WLAN-Bereich meine Musik spielt.
Fast alles noch ohne endgüligen Zweck. Alle Komponenten laufen seit
Wochen stabil, sehr selten WLAN-reconnects, daran sind aber die
WALN-Verhältnisse hier im Umfeld schuld.
MQTT mit PubSubClient, neuerdings auch mit dem Wrapper für den
ESp-MQTT-Client.
Fast alle Komponenten mit OTA-Update installiert, will die ja nicht
immer an den PC stecken müssen, wenn ich was ändere.
Gruß aus Berlin
Michael
So, jetzt gab es doch wieder ein Stack.
Und hier mal seine Übersetzung:
1
Decoding 11 results
2
0x4021115f: pm_set_sleep_mode at ?? line ?
3
0x402112e5: pm_wakeup_init at ?? line ?
4
0x4020a7ed: test_tout at ?? line ?
5
0x4020a851: test_tout at ?? line ?
6
0x40205358: system_adc_read at ?? line ?
7
0x40201170: __analogRead at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/core_esp8266_wiring_analog.c line 31
8
0x40203165: Print::println(unsigned long, int) at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/Print.cpp line 192
9
0x4020246a: loop at C:\Users\Kolja\Documents\Arduino\hacked_Servo_ext_Poti_seriel/hacked_Servo_ext_Poti_seriel.ino line 35
10
0x40202f38: Print::println(char const*) at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/Print.cpp line 156
11
0x4020280c: loop_wrapper at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/core_esp8266_main.cpp line 43
12
0x40100114: cont_norm at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/cont.S line 109
Schlau werde ich daraus aber nicht...
Gruß Kolja
P.S. hast du Erfahrungen mit einem Mesh-Netzwerk zwischen den ESPs?
Und wieder:
> Ich habe jetzt erst die leere.bin geflasht,> dann die beiden alten und dann mein Sketch.
Aber schon wieder n Stack:
1
Decoding 7 results
2
0x40205358: system_adc_read at ?? line ?
3
0x40201170: __analogRead at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/core_esp8266_wiring_analog.c line 31
4
0x40202721: Print::write(char const*) at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/Print.h line 60
5
0x4020246a: loop at C:\Users\Kolja\Documents\Arduino\hacked_Servo_ext_Poti_seriel/hacked_Servo_ext_Poti_seriel.ino line 35
6
0x40202f38: Print::println(char const*) at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/Print.cpp line 156
7
0x4020280c: loop_wrapper at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/core_esp8266_main.cpp line 43
8
0x40100114: cont_norm at C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.1.0\cores\esp8266/cont.S line 109
Diesmal aber was anderes.
Das kann doch langsam nicht mehr wahr sein :-(
Hallo,
kann ich Dir nur teilweise helfen, das war jetzt mit Deinem Sketch?
Von oben nach unten lesen (raten...):
Der Sleepmode sollte gesetzt werden,
WakeUp wurde initialisiert, davor eben der ADC gelesen und irgendwelche
Stringbearbeitung gemacht.
println wurde aufgerufen usw.
Kann bei Dir liegen, ein Pufferüberlauf bei den println-Sachen möglich?
Ist eigentlich generell ein guter Anwärter, den ESP abschmieren zu
lassen.
Erst überschreibt ein Variablenzugriff (Arrayzugriff) den Stack wegen
überlauf und danach ist er im weißen Sand, wenn er von Stack unerwartete
Rücksprungadressen holt.
Zumindest hat er sich in der hacked_Servo_ext_Poti_seriel.ino
rumgetrieben, die Zeile 35 wird aber sicher nicht passen wegen der
Optimierung des Compilers.
Vielleicht hilft es Dir ja etwas weiter.
Gruß aus Berlin
Michael
Nabend
Danke für die Erklärungen, jetzt verstehe ich zumindest das Prinzip :-)
Die beiden Meldungen sind ja doch recht ähnlich.
Vielleicht hat ja noch jemand einen Hinweis.
Ansonsten würde ich jetzt vielleicht umsatteln.
Gibt es eine Alternative die wir nutzen können?
Damit meine ich in erster Linie die Software.
Also NodeMCU, Arduino IDE oder Windows?
Gruß Kolja
Hallo,
wenn Dein Sketch kein Geheimnis ist, schick ihn doch mal oder häng ihn
hier ran.
Wann passiert das? Gleich, Zufällig irgendwann? Nach bestimmten
Aktionen?
Gruß aus Berlin
Michael
Die test Funktion dient nur als Ablage,
genauso wie der auskommentierte Block.
Eigentlicher Code sind nur die ersten 50 Zeilen.
Ich habe den Rest nur mit eingestellt, falls es zur Fehlerfindung dient.
Ist also voll c&p.
Die Hardware besteht aus einem Servo, ohne Elektronik,
welches über einen Transistor (Pin D0) geschaltet wird.
Es kann nur in eine Richtung drehen.
Das Poti aus dem Servo hat keine mechanische Blockierung mehr
(das Servo auch nicht) und wird als Spannungsteiler betrieben
und über A0 ausgelesen.
Der Sketch soll die Umdrehungszeit des Servos ermitteln,
was es auch tut.
Habe mich gerade mit dem selben Problem rumgeschlagen:
Soft WDT reset
ctx: cont
sp: 3ffef710 end: 3ffef910 offset: 01b0
>>>stack>>>
3ffef8c0: 3ffe8ade 00000000 00000000 4010651a
3ffef8d0: 3fffdad0 3ffee6fc 3ffee8c4 40201f9c
3ffef8e0: 00000063 3ffee6fc 3ffee8c4 402020e8
3ffef8f0: 3fffdad0 00000000 3ffee8e0 402024ac
3ffef900: feefeffe feefeffe 3ffee8f0 40100108
<<<stack<<<
auf NodeMCU 1.0 / ArduinoIDE
Konnte das Problem lokalisieren:
void wait_RFM12() {
digitalWrite(nSEL_Pin,LOW);
while(digitalRead(SDI_Pin) == LOW) {
}
}
Zu Testzwecken hatte ich in einer while-Schleife darauf gewartet, dass
ein Pin auf low geht. Ich vermute, dass der Watch Dog Reset ausgelöst
wurde, weil der ESP8266, gefangen in dieser Schleife, keine Möglichkeit
hatte den Watch dog timer zurückzusetzen.
Lösung des Problems:
void wait_RFM12() {
digitalWrite(nSEL_Pin,LOW);
while(digitalRead(SDI_Pin) == LOW) {
delay(0);
}
}
Mit delay(0) kann man ihn scheinbar zum housekeeping schicken.
Seit dem kein WDT-Rest mehr :-)
Hallo,
Kolja L. schrieb:> Oder yield() ;-)
richtig, dafür ist yield() da.
Sein Programmteil mit der IO-Abfrage ist blockieren und darf nicht
länger als wenige ms sein wegen der Hintergrundroutinen für WLAN usw.
In yield() kann man sich übrigens reinhängen, wenn man was hat, das
unbedingt unabhängig oft genug aufgerufen werden soll, das muß natürlich
schnell genug abgearbeitet sein...
Gruß aus Berlin
Michael
Die Benutzung von yield() (oder delay()) KANN wiederum den
Speicherbedarf drastisch erhöhen und damit ein neues Problem bringen.
Eigentlich ist der Plan, dass die loop() Funktion nach weigen
Millisekunden fertig sein muss. Wenn man wartet, dann indem man
innerhalb der loop bei jedem Durchlauf prüft, ob das Ereignis
stattgefunden hat, aus das man wartet. Aber nicht mit einer
Endlosschleife.
Endliche Automaten sind sehr hilfreich dabei das umzusetzen. Wenn man
die richtig (also ohne Warteschleifen) einsetzt, wird MultiTasking auch
relativ einfach.
Hallo,
Stefanus F. schrieb:> Die Benutzung von yield() (oder delay()) KANN wiederum den> Speicherbedarf drastisch erhöhen und damit ein neues Problem bringen.
wenn Du das schaffst... ;-)
Man soll ja yield() auch nicht wie Streusand verteilen.
Sein Programmteil ist aber genau ein Fall, wo die direkte IO-Abfrage
sinnvoll ist und yield() damit zwingend auf dem ESP8266.
Meine aus alten Zeiten übernommene RFM12-Routine incl. Soft-SPI hat auf
dem ESP8266 auch nur ein paar wenige genau plazierte yield() bekommen.
Gruß aus Berlin
Michael
Möchte noch anmerken, dass diese Funktion, die abhängig vom Zustand des
SDI-Pins das Programm anhält, kein Beispiel für gute Programmierung ist
und nur zu Testzwecken entstanden ist.
Das gehört, wie Stefanus F. angemerkt hat, in eine state machine
integriert.
An (mindestens) einem strategisch günstig positionierten yield() oder
delay() kommt man aber trotzdem nicht vorbei.
Hallo,
Florian W. schrieb:> Möchte noch anmerken, dass diese Funktion, die abhängig vom Zustand des> SDI-Pins das Programm anhält, kein Beispiel für gute Programmierung ist> und nur zu Testzwecken entstanden ist.>> Das gehört, wie Stefanus F. angemerkt hat, in eine state machine> integriert.
ich kann es nicht lassen, deshalb eine Anmerkung:
wir sind hier auf einem µC-System, daß je nach Projekt einen festen
Funktionsumfang hat. Wenn jetzt der komplette Ablauf von einer
bestimmten Aktion abhängt, kann ich auf diese warten, egal wie. Der µC
kann ohnehin nichts anderes machen außer warten. Der ESP mit seinem WLAN
ist hier einfach ein Grenzfall, speziell im Zusammenspiel mit der
ArduinoIDE. Das WLAN will eben bedient werden. Ob jetzt die loop()
nichts macht weil es nichts zu tun gibt und bei jedem ihrer Durchläufe
intern yield() aufruft oder ob ich in einer Busy-Loop auf einen Pin
warte und yield() aufrufe.
In meinem Fall war lief die Ursprungsroutine im Pichange-IRQ und holte
innerhalb der IRQ das komplette Datenpaket ab. Es gab nichts anderes,
was dabei beachtet oder erledigt hätte weren können.
Selbiges Konstrukt ist 1:1 auf dem ESP gelandet, auch im IRQ. Nur
yiled() muß den ESP ranlassen. Im Loop() kann erst wieder was passieren,
wenn aus der IRQ das Flag "Daten da" gesetzt wurde. Daten kommen von
Sensoren zufällig ca. alle 30s an, in diesem Abstand wird also das
System kurz (knapp 20ms) "komplett angehalten" ohne das es überhaupt
Auswirkungen auf die restlichen Funktionen haben könnte.
Letzte Anmerkung: ich programmiere als Hobby seit Z80-Zeiten und immer
so, daß es genau den angestrebten Zweck erfüllt, "gute Programmierung"
ist für mich ein Schlagwort wenn es als Synonym für ein Paradigma dient.
Gruß aus Berlin
Michael
Kolja L. schrieb:> Soft WDT reset
Spannungsversorgung aus USB und angeschlossene devices?
- Peaks! Hänge einen 100uF Elko zwischen Vcc und GND, nahe dem MCU rein.
Dann gibt's keine Probleme beim flashen. Zumindest wenn der Rest richtig
eingestellt ist.
- Hänge die Verbraucher (Servo etc.) während dem flashen ab. Noch besser
speise das ganze mit einen ordentlichen Netzteil.
Und dann sehe ich noch
> C:\Users\Kolja\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266
\2.1.0\cores\esp8266/hardware 2.1.0
- bringe die Arduino IDE auf 1.8.5
- aktualisiere im Boardverwalter das ESP Modul. 2.1.0 ist Asbach Uralt
Kolja L. schrieb:> Zum Zeitpunkt des Fehlers war es vielleicht aktuell ;-)
Ouups, da habe ich wohl einen alten Thread erwischt :)
Aber der Elko ist immer noch gültig und nutzbar.
Hatte ähnliche Spinnereien mit einem D1.
Thread beobachten
Seitenaufteilung abschalten