Sketch startet nur nach Reset

Hallo Ihr lieben,

ich habe seit kurzem das Problem, dass auf meinem Arduino Uno Wifi der Sketch nach dem Spannunganlegen an de Arduino nicht mehr alleine durchstartet, sondern erst ein Reset duchgeführt werden muss.

Da es dazu bereits Threads gibt, welche ich auch gelesen haben, aber leider keine Antwort für mein Problem finden konnte, wende ich mich nun an euch, die Experten :slight_smile:

Was ich bereits versucht habe, ist einen kompletten neuen Uno Wifi mit meinem Sketch zu bespielen, leider dasselbe Resultat.

Da ein Beispiel-Sketch sofort läuft, schätze ich, dass es an meinem Sketch liegt.
An was kann es denn liegen, dass der Bootloader oder ähnliches im Arduino wegen eines Sketches aussteigt?

Im Sketch werden nur Ausgänge beschaltet welche vorher mit pinMode(4, OUTPUT); initialisiert wurde sowie 2 AnalogWerte eingelesen werden

va_druck = analogRead(A0)-107.0;
  va_druck = va_druck*(12.0/805.0);

Vllt kann mir ja wer einen Tipp geben :slight_smile:

robotsox:
Da ein Beispiel-Sketch sofort läuft, schätze ich, dass es an meinem Sketch liegt.

Vllt kann mir ja wer einen Tipp geben :slight_smile:

Evtl den Sketch posten?

Moko:
Evtl den Sketch posten?

Jop Sketch wäre hilfreich.

robotsox:
im Anhang der Sketch:)

Den Sketch bitte direkt im Forum posten.
Setze den bitte in Code-Tags.

Verwende dazu die Schaltfläche </> oben links im Editorfenster.
Das kannst du auch nachträglich machen.
Dazu den Sketch markieren und die Schaltfläche klicken.

Damit wird dieser für alle (auch mobil) besser lesbar.

Du hättest es in zwei Teilen posten können, aber ok.
Habe mir den Sketch angesehen, der allerdings komplett ohne Dokumentationen ist und somit für andere schlecht lesbar.
Einen richtigen Fehler konnte ich nicht finden.

Kannst du denn nicht zurück verfolgen, ab wann das Problem auftrat und evtl. den Sketch soweit zurück bauen um die Ursache zu erkunden ?

Hab mal den Sketch überflogen.
Dein Problem ist sicher ein zu großer RAM-verbrauch.
Verwende das F() Makro bei allen client.print() und Serial.print() von Texten. So bleibt der Text im Flasch und wird nicht in RAM zwischengespeichert.

client.println(F("HTTP/1.1 200 OK"));

Grüße Uwe

uwefed:
Hab mal den Sketch überflogen.
Dein Problem ist sicher ein zu großer RAM-verbrauch.
Verwende das F() Makro bei allen client.print() und Serial.print() von Texten. So bleibt der Text im Flasch und wird nicht in RAM zwischengespeichert.

client.println(F("HTTP/1.1 200 OK"));

Grüße Uwe

Hallo Uwe,

guter Tipp, aber wird das nicht in der IDE angezeigt ?

Ich habe hier sofort eine rote Zeile im unteren Fenster der IDE.

guter Tipp, aber wird das nicht in der IDE angezeigt ?

z.B. die String Klasse betreibt dynamische Speicherreservierung.
Und diese wird in dem Programm reichlich genutzt.

Die IDE kann nicht vorausahnen, was diese ganzen Stringobjekte dann irgendwann belegen werden.
Deswegen ist es eine gute Idee möglichst viel RAM frei zu schaufeln, damit Raum zum Jonglieren bleibt.

So bequem die String Klasse auch ist, genau so viel Probleme trägt die Verwendung in sich.

z.B. ist es oft eine gute Idee, in setup(), das String Objekt dazu zu zwingen einen festen Bereich zu reservieren. Das verhindert die Speicher Fragmentierung.

combie:
z.B. die String Klasse betreibt dynamische Speicherreservierung.
Und diese wird in dem Programm reichlich genutzt.

Die IDE kann nicht vorausahnen, was diese ganzen Stringobjekte dann irgendwann belegen werden.
Deswegen ist es eine gute Idee möglichst viel RAM frei zu schaufeln, damit Raum zum Jonglieren bleibt.

Ja, ok...da bin ich bei dir.

Ich kann mich allerdings an ein Projekt erinnern, da habe ich mit einem Ethernetshield einen Web-Server aufgebaut und wurde ständig von der IDE wegen zu wenig Ram angemeckert.
Daraufhin habe ich alles mit "F-Makro" aufgebaut und kein Gemecker mehr. Das läuft seit dem über längere Zeit (ca. 1,5 Jahre) auch sehr stabil.
Und es waren deutlich mehr Stringobjekte vorhanden, als im hier vorliegenden Sketch.

Die Hauptsache ist meistens dass String Literals anders als man vielleicht denkt RAM belegen. Das zeigt die IDE an und dagegen hilft das F()-Makro.

Dass String Objekte zu viel belegen kann passieren wenn man sehr viele Daten einliest. Da muss man sich eben mal überlegen wie viel man einlesen kann und auch muss.
Manche Leute machen auch den totalen Blödsinn, dass sie vor der Ausgabe ein String Objekt basteln und dieses dann mit einem einzelnen print() senden. Das ist RAM Verschwendung pur. Statt einfach mehrmals print() zu machen

Beim kompilieren kann der Kompiler den Verbrauch des RAMs für Variablen abschätzen. RAM wird jedoch auch während der Ausführung verbraucht und dies weiß der Kompiler nicht.
Grüße Uwe