Arduino Mega hängt wenn String nicht global definiert ist

Bob A. schrieb:
> Erklären kann ich es mir nur so halb: Dadurch dass die Strings lokal
> waren hat das das Speichermanagement durcheinander gebracht und der µC
> hing irgendwo fest.

An den lokalen Strings liegt das sicher nicht. Du hattest wahrscheinlich 
einen Speicherueberlauf. Oder Serial.print in einer ISR.

leo

Bob A. schrieb:
> Irgendwo wird in einen Bereich geschrieben wo Programmcode
> steht...
Eher unmöglich.

So viel Text, so wenig Code...

Bob A. schrieb:
> deswegen würde mich
> interessieren ob ich mit meiner Vermutung richtig liege?

Keine Ahnung, was du da falsch gemacht hast....
Und zeigen tust du es ja nicht.

Als wenn dich eine fundierte Problemanalyse überhaupt nicht 
interessieren würde.

Bob A. schrieb:
> Meinst du meinen Beitrag, oder dass ich im sketch viel Text (html-Seite)
> und wenig Code habe?

Deinen Beitrag, wir können nichts prüfen, was wir nicht sehen.

Bob A. schrieb:
> Das Ganze ist recht umfangreich und geht über mehrere Dateien. Da wusste
> ich nicht was ich alles hier zeigen soll. Was für ein Teil wäre denn
> interessant zu sehen?

Naja im Idealfall baust du ein Minimal-Beispiel, bei dem der Fehler 
auftritt.

Wenn das nicht klappt, hilft's nichts, dann eben alles posten.

Bob A. schrieb:
> Es ist halt recht viel Code, dachte das sprengt den Rahmen zum Zitieren
> dann hier...

Minimalbeispiel wurde schon gesagt ...

leo

Bob A. schrieb:
> dachte
Ja...
Ich glaube, das größte Problem im Leben eines Menschen, ist die Wahl der 
richtigen Gedanken.

Bob A. schrieb:
> Es ist halt recht viel Code, dachte das sprengt den Rahmen zum Zitieren
> dann hier...

also her damit, sonst ist der Speicher für den Thread verschwendet.

Falls wir hier von einem ESP8266 reden:

Lokale Variablen liegen auf dem Stack, der sehr viel kleiner ist, als 
der Speicher für globale Variablen. Siehe 
http://stefanfrings.de/esp8266/index.html#fallstricke

Das ist bei Arduino mit AVR ganz anders, da darf der Stack den gesamten 
freien RAM nutzen.

Bob A. schrieb:
> Nein, ein Arduino Mega2560v3

Da haben wir die erste Scheibe Salami. Möchtest du nicht deinen 
Quelltext zeigen?

Stefan ⛄ F. schrieb:
>> Nein, ein Arduino Mega2560v3
>
> Da haben wir die erste Scheibe Salami

Du haettest auch das Subject lesen koennen.

leo

leo schrieb:
> Du haettest auch das Subject lesen koennen.

Facepalm. Stimmt.

Ich könnte mir vorstellen, dass das

1

handleWebRequest();

zu selten passiert und dann der Buffer vom WebServer vollläuft.

Bob A. schrieb:
> alle 250ms

Daher meine Vermutung. Ich rate ja nicht...

Welche "string definition" ist denn die eine, um die es geht?

Programmcode gehört in *.c Dateien, nicht in *.h Dateien.

1

unsigned int uiSensor01Intensity = 0.0;

2

unsigned int uiSensor01DiodeTemperature = 0.0;

3

unsigned int uiSensor01DiodeTemperature1 = 0.0;

4

unsigned int uiSensor01DiodeTemperature2 = 0.0;

5

unsigned int uiSensor01uCTemperature = 0.0;

6

unsigned int uiSensor05Intensity = 0.0;

7

unsigned int uiSensor05DiodeTemperature = 0.0;

8

unsigned int uiSensor05DiodeTemperature1 = 0.0;

9

unsigned int uiSensor05DiodeTemperature2 = 0.0;

10

unsigned int uiSensor05uCTemperature = 0.0;

11

unsigned int uiSensor07Intensity = 0.0;

12

unsigned int uiSensor07DiodeTemperature = 0.0;

13

unsigned int uiSensor07DiodeTemperature1 = 0.0;

14

unsigned int uiSensor07DiodeTemperature2 = 0.0;

15

unsigned int uiSensor07uCTemperature = 0.0;

Warum speicherst du Fließkommazahlen in Integer Variablen?

> Krass dass es da kein Gemecker vom Compiler gibt (-Wall)

Vermutlich gilt für die Null eine Ausnahme.

Mir ist aufgefallen, dass du eine größere Menge Debug Meldungen 
eingebaut und wieder auskommentiert hast. Anstatt sie immer wieder 
mühsam zu aktivieren und zu deaktivieren, könntest du ein Makro 
verwenden. Zum Beispiel:

1

#ifdef DEBUG_MESSAGES

2

  printf(...);

3

#endif

Und dann schreibst du in deiner *.ino Datei ganz oben noch vor dem 
Include:

1

#define DEBUG_MESSAGES

oder eben nicht, wenn du sie deaktvieren willst.

Bob A. schrieb:
>> Welche "string definition" ist denn die eine, um die es geht?
> String sHtmlHeader;
> String sHtmlData;
> String sHtmlFooter;
> in Servers.h

Da sammelst du ziemlich viele Daten ein.

Globale Variablen liegen zusammen mit dem Heap an einem Ende des RAM. 
Der Stack beginnt am anderen Ende. Beide wachsen aufeinander zu.

Prüfe mal, wie viel Platz dazwischen noch frei ist, nachdem du die 
langen Strings befüllt hast. 
https://playground.arduino.cc/Code/AvailableMemory/

Ich weiß nicht, wie viel RAM das Arduino Framework braucht. Die avr libc 
braucht etwas weniger als 100 Bytes. Weniger als 100 Bytes sollten es 
sicherheitshalber nicht sein.

Wenn du ganz knapp an der Grenze bist, könnte es Zufall sein, dass das 
Verschieben der Variablen zum Erfolg führte.

Was ich noch prüfen würde: Wenn WebClient.println(x) fertig ist, wird x 
danach noch gebraucht, oder kannst du den Speicherplatz danach anders 
benutzen? Es könnte sein, dass WebClient.println() nur ein Ethernet 
Paket (also einen Teil des Strings) sofort sendet und den Rest später im 
Hintergrund abarbeitet. Greift er dann später noch auf die 
Speicherzellen des Strings zu? Oder legt er gar eine weitere Kopie an?

Bob A. schrieb:
> Stefan ⛄ F. schrieb:
>> Programmcode gehört in *.c Dateien, nicht in *.h Dateien.
> In der Arduino-IDE ist das alles etwas sonderbar...

Nö, da ist auch nicht anders. Die einzige Besonderheit ist, dass es 
zusätzlich noch .ino Dateien gibt.
Da muss man dann aufpassen in welcher Reihenfolge das alles eingebunden 
wird.

> Stefan ⛄ F. schrieb:
> Programmcode gehört in *.c Dateien, nicht in *.h Dateien.

Besser *.cpp - Arduino ist ja überwiegend C++.

Bob A. schrieb:
> In der Arduino-IDE ist das alles etwas sonderbar...
Nein!

Bob A. schrieb:
> Das waren mal floats... Ist mir wohl entgangen das mit zu ändern
> Krass dass es da kein Gemecker vom Compiler gibt (-Wall)

Teste:

1

unsigned int uiSensor01Intensity  {0];

2

unsigned int uiSensor01DiodeTemperature  {0.0];

Bob A. schrieb:
> freeMemory1()=-6391
> freeMemory2()=2313

Misst, das verwirrt nur noch mehr.

Habe den Code mal überflogen....

Im I2C Teil kann ein Bufferüberlauf stattfinden.
Achte auf die 24 und 29.

Ansonsten stört mich die inflationäre Verwendung von String.
Vieles davon lässt sich mit "Streamig" vermeiden.

Unmengen an Definitionen in *.h Dateien.
No!

Im Vorraus: hab von Arduinos Web-API keine Ahnung, was mir aber 
aufgefallen ist:

1

  if (WebServer.available())

2

  {

3

    WebClient = WebServer.available();

4

    ...

5

    WebClient.stop();

6

  }

Das sieht verkehrt aus.  Das .available() scheint einen Client 
zurückzuliefern, der explizit mit .stop() wieder freigegeben werden muß. 
Hier wird zweimal .available() aufgerufen aber nur einmal .stop(). 
Könnte ein Memory/Socket-Leak erzeugen (aber wie gesagt, keine Ahnung 
von der API - die Doku ist, wie üblich bei Arduino, unterirdisch).

Die Beispiele im Netz haben immer diese Form:

1

  WebClient = WebServer.available();

2

  if (WebClient)

3

  {

4

    ...

5

    WebClient.stop();

6

  }

Außerdem: auf einem Mikrocontroller mit 8kB RAM so mit Strings 
rumzuaasen zeugt von ziemlicher Blauäugigkeit ...

Bob A. schrieb:
> Krass dass es da kein Gemecker vom Compiler gibt

Bei euch Arduino-Hirnis schüttelt der Compiler nur leise den Kopf. Das 
Meckern hat er aufgegeben.

> Falls ich es richtig verstanden hat liefert der nur wieviel Zeichen im
> Puffer stehen.

Die macht definitiv mehr (ja, der Name ist beschissen gewählt). 
Verwende sie halt so, wie es in den Beispielen gemacht wird.  Ist ja 
nicht so, dass deine Variante irgendwie sinnvoll wäre ...

Bob A. schrieb:
>> Vieles davon lässt sich mit "Streamig" vermeiden.
> Beziehst du dich auf die Stream-Klasse der Arduinos?

Ich denke nicht. Er meinte damit, dass die ganzen String Verkettungen 
überflüssig sind. Du kannst die Antwort nach und nach generieren während 
sie übertragen wird. Das nennt man Streaming.

Alt:

1

    sHtmlData  = a;

2

    sHtmlData += b;

3

    sHtmlData += c;

4

    sHtmlData += d;

5

    sHtmlData += e;

6

    WebClient.print(sHtmlData);

Neu:

1

    WebClient.print(a);

2

    WebClient.print(b);

3

    WebClient.print(c);

4

    WebClient.print(d);

5

    WebClient.print(e);

Streaming, nicht streamig, hatte da ein n vergessen.

Streaming tuts mit allen Klassen, welche Stream oder Print 
implementieren.
Also z.B.  auch mit Serial, Wire, LCD, und eben mit allen Web Clients 
und Servern.
usw.

Kurzfassung:

1

#include <Streaming.h> // Die Lib findest du selber

2

3

/*

4

    sHtmlData  = a;

5

    sHtmlData += b;

6

    sHtmlData += c;

7

    sHtmlData += d;

8

    sHtmlData += e;

9

    WebClient.print(sHtmlData);

10

*/

11

WebClient << a << b

12

          << c << d

13

          << e;

Und schon ist sHtmlData flüssiger als Wasser.
Überflüssig

Ja Arduino ist C++.

Dahinter steckt Operator-Überladung. 
https://www.c-plusplus.net/forum/topic/232010/%C3%BCberladung-von-operatoren-in-c-teil-1

Bob A. schrieb:
> das ist jetzt C++?
Ja, Arduino, und seine Libs, ist in Hauptsache C++
Der Core  besteht viel aus C
Assembler, ist eher weniger vertreten.

Ich bin immer wieder verwundert, wie hier Leute runtergemacht werden, 
Threads geentert werden...................

Und dann mal wieder so was wie hier.
Konkrete und fachmännische Hilfe, TOLL.

Hut ab.

>Danke

Solar schrieb:
> wie hier Leute runtergemacht werden,

"Nicht wissen", ist nicht schlimm.
Aus der Ecke kamen wir alle mal.

Sobald "Nicht wissen" mit Arroganz und Uneinsichtigkeit im Verbund 
vorkommen, gehts ab....

Bob A. schrieb:
> Gleiches gilt aber auch für "Wissen" in Verbund mit Arroganz und
> Überheblichkeit...

ACK!

Bis vor nicht allzu langer Zeit, hat die bloße Erwähnung des Wortes 
"Arduino" einen reflexartigen shit storm ausgelöst.

Es hat etwas gedauert, die Meute zu dressieren(um konditionieren)... ;-)

Arduino Fanboy D. schrieb:
> Es hat etwas gedauert, die Meute zu dressieren(um konditionieren)... ;-)

Und das findest Du nicht "arrogant"?

Solar schrieb:
> Arduino Fanboy D. schrieb:
>> Es hat etwas gedauert, die Meute zu dressieren(um konditionieren)... ;-)
> Und das findest Du nicht "arrogant"?

Kann man durchaus so sehen(wenn man denn ernstlich will).

Ich halte das eher für "provozierend".

Am Rande:
Als ich hier einschlug, noch mit anderem Namen.
Wollte einem Arduino Jünger helfen.
Und war über den Shistorm überrascht.
Wie ich dann merken musste, kein Einzelfall, sondern die Normalität.
Auch und gerne von den(einigen) Moderatoren befeuert.

Da habe ich mich hier abgemeldet und gedacht: Arschlöcher!
Andererseits, finden hier interessante und lehrreiche Dialoge statt.
Eigentlich nicht das, worauf ich verzichten wollte.

Also hingesetzt, versucht die Situation zu analysieren...
Viele hier sind, zumindest bei einigen Ansichten, das was man "frozen" 
nennt. Eigentlich normal, hat wohl jeder irgendwo, aber für einen 
fruchtbaren Dialog ist das nicht unbedingt förderlich.

Die Kernfragen waren:
Wie kommt man an die militanten Arduinohasser ran?
So dass sie sich selber, ihren Hass, überdenken...
Versucht man einen militanten mit Argumenten zu überzeugen, wird er 
gegen argumentieren und damit die festigkeit seines "frozen" Status 
trainieren.


Da war die Idee schnell geboren!
"Überzeichnen"
Mich selber "Arduino Fanboy" nennen.
Damit war ich mir der Aufmerksamkeit bewusst.
Habe mich auf "viel Haue" eingestellt.
(hab recht behalten)
Die Hasser kamen also von selber, darüber brauchte ich mir mit dem Trick 
keine Sorgen machen.

Die Strategie:
Einfach nur Präsenz zeigen.
Möglichst korrekte Antworten geben.
Das Feuer, was sonst auch die anderen Arduino User trifft, auf mich 
lenken.

Und sich ab und an mal einen der Hasser Fraktion greifen und mit 
möglicht fachlichen Argumenten öffentlich zerlegen.

Das ist übrigens meist recht einfach...
Arduinohasser mögen meist kein C++, und haben sowieso wenig Ahnung von 
der IDE und den sonstigen Zusammenhängen in dieser konkreten Welt. Wenn 
dann noch Überheblichkeit, Arroganz usw. dazu kommt dann gelingt das um 
so besser.

Logischer weise macht man sich so nicht nur Freunde!
Sieht man z.b. daran, dass viele meiner Beiträge negativ bewertet 
werden, obwohl sie sachlich, fachlich und korrekt sind.
Ich schätze mal, das sind hauptsächlich Leute, denen ich so schon mal 
derbe an die Karre gefahren bin(hoffentlich fachlich), und jetzt zu 
feige sind sich öffentlich zu stellen, weil sie genau wissen, wie so 
eine Konfrontation aus geht.

Solar schrieb:
> Und das findest Du nicht "arrogant"?
Kann man durchaus so sehen(wenn man denn ernstlich will).

War ich das alleine?
Ganz sicher nicht.

Mittlerweile gehts immer mehr in diese Richtung:
Wo ich richtig liege, werde ich bestätigt, und wo ich falsch liege, 
gibts Haue.

Ich denke mal, so soll es sein, in einem Forum!

Danke!

Peter D. schrieb:
> Was aber nicht heißen muß, daß es besser mit RAM haushaltet. Die Strings
> a..e müssen ja trotzdem irgendwo zwischen gespeichert werden, bis die
> Ausgabe abgeschlossen ist. Vermutlich wird der Platz auf dem Stack
> angelegt.

"besser" ist immer so eine Frage...

Es bieten sich folgende Möglichkeiten:
Globaler Buffer, Stack, Heap.
Mehr Möglichkeiten sehe ich nicht.
Denn durchs Ram muss es sowieso.

Dass Heap auf kleinen Arduinos die schlechteste Möglichkeit ist, setze 
ich mal als Fakt fest.
Die vorher vom TE verwendete String Klasse, huddelt wie die bekloppte 
mit Heap rum.
String::reserve() mildert das Problem.

Bleibt also noch global, oder Stack
Globale, sollte man vermeiden, wenn nahezu kostenlos möglich.
Hier scheint mir Stack angemessen und brauchbar.