Help needed to recognize script problem (overflow?)

[Pewibe]

@gemu2015 please have a look at https://1drv.ms/f/s!AtbeSEYWgNo0vCq8YEgVKTLVTZPT?e=gieL53 to help as expert. First see video as problem description. Problem is reproductional but not always at same timing. Looks to me like stack overflow or something similar. The jpg-file shows the subroutine call flows. File console log shows first part with exception 28 and stack/heap/ram/slen in line 25. If you need to look into the script please see script file. This is my 1st script and I do not know the limits a several figures to recognize the reason of the problem. Can you say how many subroutine call levels are allowed? Is the call of an intrinsic function, e.g. s(x) like a subroutine call? How counts a command call per =>command?

[gemu2015]

Hallo

wir können hier gerne in Deutsch kommunizieren

Das sieht so aus als ob du Probleme mit dem Textkompressor hast. Wenn die scripte etwas größer werden kann es sein dass der Unishox Kompressor Fehler macht. (der ist eigentlich nur für kurze Texte gedacht)
Der Kompressor wird immer verwendet wenn die Buffergöße 2560 ist (default)

Bei Tasmotas mit Dateisystem nimmst du am besten eine Scriptbuffer Größe ohne Kompressor z.B.

#define UFSYS_SIZE 4096

Bei 1M Flashsystem den Spezialmodus

#define USE_EEPROM
#define EEP_SCRIPT_SIZE 8192

bei beiden Modi wird kein Kompressor verwendet.

Was den Stack angeht zählen nur die Script Subroutinen (=#sub) dort würde ich nicht mehr als 2 Schachtelungen vornehmen.

Das Zurückgeben mit ´return´ funktioniert zwar erzeugt aber einen zusätzlichen Stackframe, also besser vermeiden.

Gruß
Gerhard

[Pewibe]

Hier noch ein paar Schritte von mir nach deiner Antwort, die dich hoffentlich auch interessieren:

1. Ich dachte, das Script läuft auch mit einer kleineren Buffergröße als 2560. Ich habe sie auf 2500 gesetz in der Hoffnung, dass die Kompression damit ausgeschaltet ist. --> keine Verbesserung!
2. Da ich mit 3 subr calls schon eine mehr als deine Empfehlung habe, hat mich der weitere Stacklevel bei return geschockt. Ich habe die Funktion zur Subr zurückgebaut. --> Alles schein zu funktionieren, Kein unmotivierter Boot. Kein "Geister-Script".
   2a. Eine Func mit return habe ich benutzt, weil in der >W section zwar an der Stelle einer Variablen eine Func aufgerufen werden kann, aber keine Subr zum Setzen der Ergebnisvariable. Irgendeine Idee dazu? Script code in >W?
   2b. Deine Empfehlung mit max. 2 Subr sollte dann doch als Warnung in der Doc sein, da es die Freude an kurz gehaltenen Codestücken verdirbt. Ich frage mich hierzu eh, wofür 600 Byte benötigt werden, wenn die Schriptsprache keine lokalen Variablen kennt. Hat die CPU wirklich so viele Register?
   2c. Gerade nach ca. 15 min Scriptlaufzeit gab es doch einen Boot Vorgang. --> zu früh gefreut! Mehr Platz nötig und doch Kompession abschalten.
3. Zu "1M Flashsystem im Spezialmodus". --> Ist das wirklich ohne zusätzliche HW gedacht? Die Doc hält sich neutral und sagt weder SW- noch HW-EEPROM.

[gemu2015]

2a
statt return, einfach eine variable in der subroutine setzen und nach der subroutine die variable auslesen
2b
das sind nicht nur die register der cpu, sondern auch der stackframe des kompletten variablen decoders.

3. das ist ein ganz spezieller modus bei dem das script ganz hinten am ende des flash Speichers gespeichert wird. (hat entgegen dem Namen nichts mit Hardware EEPROm zu tun)
   sehr viele Leute benutzen das ohne Probleme zusammen mit dem SML decoder

[Pewibe]

2a. Ist nicht wirklich wichtig, aber ich meine, du hast meine Frage nicht richtig verstanden. Es geht um die Section >W. Die lässt keine Script Anweisungen wie den Aufruf einer Subroutine =#subr() zu, damit die Variable gesetzt wird, um sie dann im HTML code mit %var% zu benutzen.
3. Ich kompiliere das entsprechend deinem Vorschlag, weil das Script zwar sehr viel besser läuft und nicht mehr so "abstürzt", aber es geschehen immer noch seltsame Dinge wie z.B. eine Variable, die immer nur addierend verändert wird, ist auf einmal wieder auf 0. Wenn man damit die Scriptgröße von 2560 auf 8192 bekommt, was ist da so negativ oder warum machst du es nicht für Tasmota zu Standard?

[gemu2015]

2a.
subroutine in >W %=#sub

3. bei kleinen Skripten geht das ganz gut mit 2560 und Kompression. Es hat sich aber herausgestellt das der Kompressor gelegentlich Fehler macht wenn das script etwas grösser wird.
   bei 4M Flash devices ist das kein Problem da wird kein Kompressor verwendet.

bei den 1M devices hat dieser spezielle 8k modus das Problem dass er eben 8k RAM braucht im Gegensatz zu 2.56k und bei OTA Firmware updates kann das script gelegentlich gelöscht werden und muss neu übertragen werden

wenn bei dir Variablen plötzlich gelöscht werden stimmt sicher etwas nicht. auch Abstürze sollte es nicht geben. Ich betreibe sehr komplexe scripte schon seit Jahren ohne jeden Absturz.

da es keinerlei Syntaxcheck gibt sind es manchmal verstecke Syntaxfehler die zu Abstürzen führen.