ESP8266 Stürzt ab

[TR.OLL (Gast)]

Hallo,

ich habe einen ESP8266 und folgendes Problem:

Wenn ich eine Exception schmeiße stürzt der ESP ab.

Exception:

struct NtpError_EXCEPTION : public std::exception
{
    const char* what() const throw ()
    {
        return "NTP failed";
    };

    const uint16_t code() const throw ()
    {
        return 10;
    };
};

Schmeißen der Exception:

throw NtpError_EXCEPTION();

Exceptions sind aktiviert und ich lade diese Library:

#include <exception>

Kennt jemand eine Lösung für das Problem?
Danke im Vorraus.

TR.OLL

[TR.OLL (Gast)]

Platformio.ini

[env:d1_mini]
platform = espressif8266@2.0.4
board = d1_mini
framework = arduino
monitor_speed = 115200
build_flags = -fexceptions
build_unflags = -fno-exceptions


lib_deps = 
  git+https://github.com/xreef/PCF8591_library.git#master
  git+https://github.com/ich423/LCDMenuLib2.git
  ;git+https://github.com/Jomelo/LCDMenuLib2.git
  git+https://github.com/adafruit/RTClib.git#master

[Stefan F. (Gast)]

Hast du die Exception auch gefangen, oder bricht dann dein "Programm" 
ab?

[Peter K. (pkap)]

Allgemein würde ich im Embedded Bereich von Excpetions jeglicher Art 
abraten.

Passiert es bereits beim werfen der Exception oder erst wenn du mit der 
Exception nach dem Fangen irgendetwas machst?

[TR.OLL (Gast)]

Peter K. schrieb:
> Passiert es bereits beim werfen der Exception oder erst wenn du mit der
> Exception nach dem Fangen irgendetwas machst?

Stürzt beim werfen ab.

[Stefan F. (Gast)]

TR.OLL schrieb:
> Stürzt beim werfen ab.

Jetzt wären detaillierte Angaben angebracht, welche Beobachtung dich zu 
diesem Schluss gebracht hat.

Denke immer dran, wir sehen nicht, was du siehst.

[TR.OLL (Gast)]

Peter K. schrieb:
> Allgemein würde ich im Embedded Bereich von Excpetions jeglicher Art
> abraten.

Warum?

[Stefan F. (Gast)]

Unabhängig vom Quelltext würde ich gerne auch mal sehen, wie du die 
Stromversorgung gelöst hast. Schaltplan und Foto. Weil: Mangelhafte 
Stromversorgung ist nach meiner Erfahrung die häufigste Ursache von 
Ausfällen dieser Art.

[Einer K. (Gast)]

Wenn man unbehandelte Exceptions sehen möchte, sollte man die Baudrate 
des Seriellen Monitors (oder eines beliebigen Terminals) auf 74880 Baud 
stellen.


Ansonsten, fix mal eben getestet unter Arduino, Exceptions 
funktionieren, kein "Absturtz".
Und das mit einer Stromversorgung, von der Stefanus unbeirrbar 
behauptet, dass sie nicht funktioniert.


Testcode:

#include <Streaming.h>
#include <exception>

struct NtpError_EXCEPTION : public std::exception
{
  const char* what() const throw ()
  {
    return "NTP failed";
  };

  const uint16_t code() const throw ()
  {
    return 10;
  };
};


void setup()
{
  Serial.begin(74880);
 
  Serial << "Start: " << __FILE__ << endl;
}

void loop()
{
  try
  {
    throw NtpError_EXCEPTION();
  }
  catch (const NtpError_EXCEPTION& e)
  {
    Serial << "Exception gefangen" << endl;
  }

  delay(1000);
}

Ausgabe:

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

load 0x4010f000, len 1392, room 16 
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
~ld
Start: ESP_Exception_001.ino
Exception gefangen
Exception gefangen
Exception gefangen
// usw

[Stefan F. (Gast)]

Arduino Fanboy D. schrieb:
> Und das mit einer Stromversorgung, von der Stefanus unbeirrbar
> behauptet, dass sie nicht funktioniert.

Was soll diese Verleumdung? Ich habe zur Stromversorgung deines 
aktuellen Aufbaus gar nichts behauptet.

[TR.OLL (Gast)]

Stefan ⛄ F. schrieb:
> nabhängig vom Quelltext würde ich gerne auch mal sehen, wie du die
> Stromversorgung gelöst hast. Schaltplan und Foto. Weil: Mangelhafte
> Stromversorgung ist nach meiner Erfahrung die häufigste Ursache von
> Ausfällen dieser Art.

Über den USB-Anschluss von einem wemos d1 mini.

[Stefan F. (Gast)]

TR.OLL schrieb:
> Über den USB-Anschluss von einem wemos d1 mini.

Wenn er bei Exceptions immer abstürzt, wird die Stromversorgung wohl 
nicht die Ursache sein. Passiert es aber nur manchmal, empfehle ich Dir 
ein möglichst dickes USB Kabel und einen 100µF Kondensator direkt am 
ESP-Modul an VCC und GND. Das NodeMCU Board, das offenbar als Vorlage 
für die Wemos D1 Boards verwendet wurde, hat diesen Kondensator mit 
drauf.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> Was soll diese Verleumdung? Ich habe zur Stromversorgung deines
> aktuellen Aufbaus gar nichts behauptet.


Naja. nach einem Streit über gefühlte 100 Beiträge, kann ich das mit der 
"Verleumdung" nun wirklich nicht akzeptieren.

Es ist dieses Board gemeint: https://www.ebay.de/itm/233174130261

[TR.OLL (Gast)]

Stefan ⛄ F. schrieb:
> TR.OLL schrieb:
>> Über den USB-Anschluss von einem wemos d1 mini.
>
> Wenn er bei Exceptions immer abstürzt, wird die Stromversorgung wohl
> nicht die Ursache sein. Passiert es aber nur manchmal, empfehle ich Dir
> ein möglichst dickes USB Kabel und einen 100µF Kondensator direkt am
> ESP-Modul an VCC und GND. Das NodeMCU Board, das offenbar als Vorlage
> für die Wemos D1 Boards verwendet wurde, hat diesen Kondensator mit
> drauf

Ohne Exceptions stützt der ESP nich ab, also ist die Stromversorgung 
nicht das Problem.

Arduino Fanboy D. schrieb:
> Es ist dieses Board gemeint: Ebay-Artikel Nr. 233174130261

Ich nutze dieses Board: https://wiki.wemos.cc/products:d1:d1_mini

[Einer K. (Gast)]

TR.OLL schrieb:
> Ich nutze dieses Board: https://wiki.wemos.cc/products:d1:d1_mini

Den Link mag mein Browser nicht.
Aber das Bord ist ein übliches Dingen.
Exceptions sollten damit funktionieren.

Zeige doch mal die Bootmeldungen.....
Ein Log.

[bingo (Gast)]

Ich habe mich in den letzten Tagen intensiv mit der Stromversorgung der 
ESP8266 beschäftigt, Stefan F. (stefanus) hat recht; oft fehlt ein 
100µF, auf den Wemos und Nachbauten sind meist nur 3x 10µF drauf, die 
zudem noch andere Chips versorgen, auf dem blanken ESP8266 ist gar 
keiner drauf, drinnen vermutlich ein 100nF, auf manchen Lolin Borads 
tatsächlich 100µF. Ausserdem werden oft MCP1700 u.ä. verbaut, die sind 
zu schwach, liefern nur 250mA (und dann mit leichtem Spannungseinbruch), 
der ESP8266 zieht aber bis zu 400mA.

[TR.OLL (Gast)]

Arduino Fanboy D. schrieb:
> TR.OLL schrieb:
>> Ich nutze dieses Board: https://wiki.wemos.cc/products:d1:d1_mini
>
> Den Link mag mein Browser nicht.
> Aber das Bord ist ein übliches Dingen.
> Exceptions sollten damit funktionieren.
>
> Zeige doch mal die Bootmeldungen.....
> Ein Log.

Ist im Anhang.

[Apollo M. (Firma: @home) (majortom)]

Arduino Fanboy D. schrieb:
> Und das mit einer Stromversorgung, von der Stefanus unbeirrbar
> behauptet, dass sie nicht funktioniert.

es ist ein grosser unterschied, ob einige am küchentisch funktionieren, 
wie bei dir, oder in einer serienproduktion ohne nennenswerte ausfälle!

ich kann jede aussage von stefan zur esp8266 stromversorgung nur 
unterstreichen und bestätigen.

mit weniger verständnis und erfahrung sieht vieles leichter aus.
man könnte auch sagen - doof, aber glücklich und das ja auch nicht so 
schlecht als über-/lebenstrategie.


mt

[Einer K. (Gast)]

TR.OLL schrieb:
> Ist im Anhang.

Also keine Meldung in der Form:
> User exception (panic/abort/assert)
> Unhandled C++ exception: NTP failed

Sondern:
> Abort called

Also kein willkürlicher "Absturz" durch z.B. Stromversorgung, sondern 
ein kontrolliertes Abbrechen in irgendeinem Programmteil.

Der Stackdump zeigt dir wo Abort aufgerufen wird.



> rst cause:2
Ist in dem Fall ok

  reset causes:
        0:
        1: normal boot
        2: reset pin
        3: software reset
        4: watchdog reset

[TR.OLL (Gast)]

Arduino Fanboy D. schrieb:

> Sondern:
>> Abort called
>
> Also kein willkürlicher "Absturz" durch z.B. Stromversorgung, sondern
> ein kontrolliertes Abbrechen in irgendeinem Programmteil.
>
> Der Stackdump zeigt dir wo Abort aufgerufen wird.

Und sorgt man darf das der ESP das Programm nicht abricht und neustartet 
sonder weiterläuft.

[Einer K. (Gast)]

TR.OLL schrieb:
> Und sorgt man darf das der ESP das Programm nicht abricht und neustartet
> sonder weiterläuft.

?

[Einer K. (Gast)]

Apollo M. schrieb:
> es ist ein grosser unterschied, ob einige am küchentisch funktionieren,
> wie bei dir, oder in einer serienproduktion ohne nennenswerte ausfälle!
Die Adapter werden in Serie produziert!

Auf Nachfrage wo der Stefanus mal irgendwann davon gehört hat, ob ein 
solcher Adapter jemals versagt hat, kamen Plattitüden.

Apollo M. schrieb:
> ich kann jede aussage von stefan zur esp8266 stromversorgung nur
> unterstreichen und bestätigen.
Ich kann bestätigen, dass der ESP bei zu großen Schwankungen versagt.


Wobei "mir" das mit "dem" Adapter noch nicht passiert ist.
Auch nicht mit seinen Brüdern.

Der Adapter ist mit einem 1000µF Stützkondensator auf der 3,3V Seite 
ausgerüstet.
Stefanus fordert irgendwo 100µF

Der darauf befindliche Regler wird bei dieser Exception 
Beispielanwendung mit weniger als 80mA versorgt, im Mittel.
Der Regler zeigt eine Erwärmung von ca 10°C über Umgebung im 
Dauerbetrieb.

Die Spannung am aufgesteckten ESP Board zappelt zwischen 3,33V und 
3,26V.
Das ist voll im Rahmen.

Jetzt kannst du natürlich behaupten, dass meine ganzen diese Adapter 
Ausnahmefälle sind und nur durch Zufall funktionieren.

Apollo M. schrieb:
> mit weniger verständnis und erfahrung sieht vieles leichter aus.
> man könnte auch sagen - doof, aber glücklich und das ja auch nicht so
> schlecht als über-/lebenstrategie.
Und mich auch für blöd erklären, wenn es dir damit besser geht.

[Andreas B. (bitverdreher)]

Es ist Fakt daß der ESP recht anspruchsvoll ist, was die Stromversorgung 
betrifft. Insofern hat Stefan Recht.
Er hat hier auch nirgendwo behauptet, daß das in diesem Fall auch so 
ist.
Ob das jetzt für Deinen oder den Aufbau des TO zutrifft, weiß aufgrund 
fehlender Infos niemand.
Und ja, solche Abstürze führen oft zu denn merkwürdigsten Effekten.

[Stefan F. (Gast)]

Leute, kommt mal wieder runter. Ich denke, diese Diskussion um die 
Stromversorgung hilft dem TO nicht weiter. Sein Modul stürzt 
reproduzierbar immer an der gleichen Exception ab und nicht bei anderen 
Aktionen. Damit ist die Stromversorgung sicher nicht seine aktuelle 
Problemursache.

[Andreas B. (bitverdreher)]

Stefan ⛄ F. schrieb:
> Damit ist die Stromversorgung sicher nicht seine aktuelle
> Problemursache.

Bei Arduino Fanboy funktioniert es ja. Insofern bin ich mir da nicht so 
sicher.

[Einer K. (Gast)]

Andreas B. schrieb:
> Und ja, solche Abstürze führen oft zu denn merkwürdigsten Effekten.
Welche dann an unterschiedlichsten Stelle auftauchen können.

Hier haben wir keinen willkürlichen Absturz.
Sondern einen Abort.
Scheinbar reproduzierbar.

Und ja, über den Grund kann man nur spekulieren......
Denn der verursachende Code ist ja geheim, und damit völlig untestbar.
Und der Stackdump unausgewertet.




Dieser Code funktioniert:
(nochmal leicht modifiziert, das (nötige?) virtual hinzugefügt und ein 
überflüssiges const entfernt, usw)

#include <Streaming.h>
#include <exception>


class NtpError_EXCEPTION : public std::exception
{
  public:
  virtual const char* what() const throw() override
  {
    return "NTP failed";
  };

  virtual uint16_t code() const throw()
  {
    return 10;
  };
};



void setup()
{
  Serial.begin(74880);
 
  Serial << "Start: " << __FILE__ << endl;
}

void loop()
{ 
  try
  {
    throw NtpError_EXCEPTION();
  }
  catch (const NtpError_EXCEPTION& e)
  {
    Serial << "Exception gefangen! " 
           << " Code: " << e.code()
           << " What: " << e.what() 
           << endl;
  }

  delay(1000);
}

[TR.OLL (Gast)]

Arduino Fanboy D. schrieb:
> Andreas B. schrieb:
>> Und ja, solche Abstürze führen oft zu denn merkwürdigsten Effekten.
> Welche dann an unterschiedlichsten Stelle auftauchen können.
>
> Hier haben wir keinen willkürlichen Absturz.
> Sondern einen Abort.
> Scheinbar reproduzierbar.
>
> Und ja, über den Grund kann man nur spekulieren......
> Denn der verursachende Code ist ja geheim, und damit völlig untestbar.
> Und der Stackdump unausgewertet.

Bei mir geht der Code auch.

Codeteil der die Exceptions nutzt:

time_t getNtpTime()
{
    try {
        IPAddress ntpServerIP; // NTP server's ip address
        while (Udp.parsePacket() > 0); // discard any previously received packets
        // get a random server from the pool
        WiFi.hostByName(ntpServerName, ntpServerIP);
        Serial.print("ntpServerName: ");
        Serial.println(ntpServerName);
        Serial.print("ntpServerIP: ");
        Serial.println(ntpServerIP);
        sendNTPpacket(ntpServerIP);
        uint32_t beginWait = millis();
        while (millis() - beginWait < 5000) {
            int size = Udp.parsePacket();
            if (size >= NTP_PACKET_SIZE) {
                Udp.read(packetBuffer, NTP_PACKET_SIZE);  // read packet into the buffer
                // convert four bytes starting at location 40 to a long integer
                secsSince1900 = (unsigned long)packetBuffer[40] << 24;
                secsSince1900 |= (unsigned long)packetBuffer[41] << 16;
                secsSince1900 |= (unsigned long)packetBuffer[42] << 8;
                secsSince1900 |= (unsigned long)packetBuffer[43];
                timeSource = true;

                if (rtcRunning == false && timeSource == true) {
                    rtc.adjust(DateTime(year(), month(), day(), hour(), minute(), second()));
                    rtcRunning = true;
                }
                return secsSince1900 - 2208988800UL + timeZone * SECS_PER_HOUR;
            }
        }
        Serial.println("ERROR NTP");
        if (rtcConnected == true && rtcRunning == true) {
            throw NtpError_EXCEPTION();
        }
        else {
            return 0;
        }
    }
    catch (NtpError_EXCEPTION& e) {
        if (e.code() == 10) {
            if (rtcConnected == true && rtcRunning == true) {
                DateTime now2 = rtc.now();
                timeSource = false;
                return (now2.unixtime() - secs_between_1900_and_1970) - 2208988800UL + timeZone * SECS_PER_HOUR;
            }
            else {
                return 0;
            }
        }
    }
  return 0;
}

[TR.OLL (Gast)]

Arduino Fanboy D. schrieb:

> Also kein willkürlicher "Absturz" durch z.B. Stromversorgung, sondern
> ein kontrolliertes Abbrechen in irgendeinem Programmteil.

Wie kann man das kontrollierte abrechen verhindern?

[Stefan F. (Gast)]

TR.OLL schrieb:
> Wie kann man das kontrollierte abrechen verhindern?

Indem man (also du) den Fehler in deinem immer noch geheimen Programm 
korrigiert.

[Einer K. (Gast)]

TR.OLL schrieb:
> Wie kann man das kontrollierte abrechen verhindern?


Die Ursache suchen!
z.B. den Stackdump analysieren.
In der Arduino Welt gibt es den "ESP Exception Decoder"
Da könntest du eine Chance mit haben.

Ansonsten gefällt mir diese Zeile nicht wirklich.
> while (millis() - beginWait < 5000)
Ein delay(0) oder yield() in der Schleife ist sicherlich kein Fehler.
Denn der ganze WLAN Kram läuft in einer anderen Task und benötigt Zeit.

[TR.OLL (Gast)]

Hier der Teil von dem Programm, wo der Fehler liegt:

Exceptions.h

//exceptions.h
#ifndef EXCEPTIONS_H
#define EXCEPTIONS_H

#include <exception>

struct NtpError_EXCEPTION : public std::exception
{
    const char* what() const throw ()
    {
        return "NTP failed";
    };

    const uint16_t code() const throw ()
    {
        return 10;
    };
};

#endif

Timecontrol.cpp (der Code mit dem Problem).

#include "TimeControl.h"
#include <ESP8266WiFi.h>
#include <WiFiUdp.h>
#include <exception>
#include "RTClib.h"

#include "config.h"
#include "exceptions.h"

#define NTP_PACKET_SIZE 48

WiFiUDP Udp;
RTC_DS1307 rtc;

static const char ntpServerName[] = "pool.ntp.org";
unsigned int localPort = 8888;
int timeZone;
byte packetBuffer[NTP_PACKET_SIZE];
unsigned long secsSince1900;
bool rtcConnected = false, rtcRunning = false;
bool timeSource = true; // true = NTP, false = rtc


time_t getNtpTime();
void sendNTPpacket(IPAddress &address);

TimeControl& TimeControl::getInstance()
{
  static TimeControl instance;
  return instance;
}

TimeControl::TimeControl()
{
}

void TimeControl::start()
{
  //loadUtcDiff(&timeZone);
  //loadSummertimeAuto(&summerTimeAuto);
    if (rtc.begin() == true) {
        rtcConnected = true;

        if (rtc.isrunning() == true) {
            rtcRunning = true;
            Serial.println("RTC is running");
        }
        else {
            Serial.println("Rtc is not running");
            rtcRunning = false;
        }
    }
    else {
        Serial.println("Rtc disconnected");
        rtcConnected = false;
    }

  Udp.begin(localPort);
  setSyncProvider(getNtpTime);
  setSyncInterval(3600);
}

void TimeControl::getTime(uint8_t *hh, uint8_t *mm, uint8_t *ss)
{
  *hh = hour();
  *mm = minute();
  *ss = second();
  if (summerTimeAuto && isSummertime())
  {
    *hh += 1;
    if(24 == *hh)
    {
      *hh = 0;
    }
  }
}


unsigned long TimeControl::secSince1970(){
 return now(); 
}

void TimeControl::rtcSync()
{
    if (timeSource == true) {
        rtc.adjust(DateTime(year(), month(), day(), hour(),minute(),second()));
    }
}

time_t getNtpTime()
{
    try {
        IPAddress ntpServerIP; // NTP server's ip address
        while (Udp.parsePacket() > 0); // discard any previously received packets
        // get a random server from the pool
        WiFi.hostByName(ntpServerName, ntpServerIP);
        Serial.print("ntpServerName: ");
        Serial.println(ntpServerName);
        Serial.print("ntpServerIP: ");
        Serial.println(ntpServerIP);
        sendNTPpacket(ntpServerIP);
        uint32_t beginWait = millis();
        while (millis() - beginWait < 5000) {
            int size = Udp.parsePacket();
            if (size >= NTP_PACKET_SIZE) {
                Udp.read(packetBuffer, NTP_PACKET_SIZE);  // read packet into the buffer
                // convert four bytes starting at location 40 to a long integer
                secsSince1900 = (unsigned long)packetBuffer[40] << 24;
                secsSince1900 |= (unsigned long)packetBuffer[41] << 16;
                secsSince1900 |= (unsigned long)packetBuffer[42] << 8;
                secsSince1900 |= (unsigned long)packetBuffer[43];
                timeSource = true;

                if (rtcRunning == false && timeSource == true) {
                    rtc.adjust(DateTime(year(), month(), day(), hour(), minute(), second()));
                    rtcRunning = true;
                }
                return secsSince1900 - 2208988800UL + timeZone * SECS_PER_HOUR;
            }
        }
        Serial.println("ERROR NTP");
        if (rtcConnected == true && rtcRunning == true) {
            throw NtpError_EXCEPTION();
        }
        else {
            return 0;
        }
    }
    catch (NtpError_EXCEPTION& e) {
        if (e.code() == 10) {
            if (rtcConnected == true && rtcRunning == true) {
                DateTime now2 = rtc.now();
                timeSource = false;
                return (now2.unixtime() - secs_between_1900_and_1970) - 2208988800UL + timeZone * SECS_PER_HOUR;
            }
            else {
                return 0;
            }
        }
    }
  return 0;
}


void sendNTPpacket(IPAddress &address)
{ // set all bytes in the buffer to 0
  memset(packetBuffer, 0, NTP_PACKET_SIZE);
  // Initialize values needed to form NTP request
  // (see URL above for details on the packets)
  packetBuffer[0] = 0b11100011;   // LI, Version, Mode
  packetBuffer[1] = 0;     // Stratum, or type of clock
  packetBuffer[2] = 6;     // Polling Interval
  packetBuffer[3] = 0xEC;  // Peer Clock Precision
  // 8 bytes of zero for Root Delay & Root Dispersion
  packetBuffer[12] = 49;
  packetBuffer[13] = 0x4E;
  packetBuffer[14] = 49;
  packetBuffer[15] = 52;
  // all NTP fields have been given values, now
  // you can send a packet requesting a timestamp:
  Udp.beginPacket(address, 123); //NTP requests are to port 123
  Udp.write(packetBuffer, NTP_PACKET_SIZE);
  Udp.endPacket();
}


bool TimeControl::isSummertime(void)
{
  if (month() < 3 || month() > 10) return false; // keine Sommerzeit in Jan, Feb, Nov, Dez
  if (month() > 3 && month() < 10) return true; // Sommerzeit in Apr, Mai, Jun, Jul, Aug, Sep
  if ((month() == 3 && (hour() + 24 * day()) >= (1 + timeZone + 24 * (31 - (5 * year() / 4 + 4) % 7))) || (month() == 10 && (hour() + 24 * day()) < (1 + timeZone + 24 * (31 - (5 * year() / 4 + 1) % 7))))
    return true;
  else
    return false;
}


void TimeControl::setTimeZone(int newTimezone)
{
  timeZone = newTimezone;
  //saveUtcDiff(timeZone);
  //setSyncProvider(getNtpTime);
}

int TimeControl::getTimeZone()
{
 return timeZone;
}


void TimeControl::setSummertimeAuto(bool newState)
{
 summerTimeAuto = newState;
 //saveSummertimeAuto(summerTimeAuto);
}


bool TimeControl::getSummertimeAuto()
{
 return summerTimeAuto;
}

Platformio.ini

;PlatformIO Project Configuration File
;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html

[env:d1_mini]
platform = espressif8266@2.0.4
board = d1_mini
framework = arduino
monitor_speed = 115200
build_flags = -fexceptions
build_unflags = -fno-exceptions


lib_deps = 
  git+https://github.com/xreef/PCF8591_library.git#master
  git+https://github.com/ich423/LCDMenuLib2.git
  ;git+https://github.com/Jomelo/LCDMenuLib2.git
  git+https://github.com/adafruit/RTClib.git#master

[Einer K. (Gast)]

TR.OLL schrieb:
> Hier der Teil von dem Programm, wo der Fehler liegt:
Wo du meinst, dass der Fehler sein müsste.

Leider ist auch dieser Code untestbar, da aus dem Zusammenhang gerissen.
Auch sind meine Vorschläge/Korrekturen dort noch nicht eingearbeitet.
Zusätzlich: Aktiviere doch mal alle Warnungen und beseitige diese.

Was hat der ESP Exception Decoder ergeben?
Bestätigt dieser deine Diagnose?

TR.OLL schrieb:
> Bei mir geht der Code auch.
Immerhin ist damit klar, dass Exceptions grundsätzlich funktionieren, 
oder habe ich dich falsch verstanden?

[Peter K. (pkap)]

TR.OLL schrieb:
> Peter K. schrieb:
>> Allgemein würde ich im Embedded Bereich von Excpetions jeglicher Art
>> abraten.
>
> Warum?

Ist zwar schon ein weilchen her, aber ich Antworte da dennoch drauf.

Excpetions sind in Programmen welche gewisse Echtzeitbedinungen erfüllen 
müssen besonders kritisch, weil Exceptions je nach Implementierung 
extrem lange brauchen. Das fügt einen relativ großen Jitter ein weil 
eine Funktion viel viel länger benötigt wenn eine Exception geworfen 
wird als wenn das nicht der Fall ist.
Bei einem einfachen Returnvalue ist das nicht der Fall.
Das betrifft allerdings nur Codepfade welche eine konstante oder 
möglichst kurze Laufzeit haben sollten, in anderen ist es durchaus 
möglich.

Exceptions verleiten aber auch oft dazu Code zu schreiben welcher den 
Heap verwendet, was bei Embedded Systemen ohne Speicherbereinigung nicht 
passieren sollte.
Jede Speicherallocation auf dem Heap kann zu dessen Fragmentierung 
führen und irgendwann kann es sein, dass der Heap derart fragmentiert 
ist, dass ein call von new malloc oder alle anderen Dinge welche 
implizit den Heap verwenden nicht mehr funktionieren.

Der ISO C++ Standard schreibt dazu:
A throw-expression initializes a temporary object, called the exception 
object. The memory for the exception object is allocated in an 
unspecified way.

Es ist also nicht definiert wo und wie dieser Speicher erzeugt wird und 
es kann daher durchaus sein, dass der Speicher auf dem Heap alloziert 
wird.

Bei uns in der Arbeit haben wir daher in den Codingguidelines Excpetions 
komplett verboten und wir machen alles über Returnvalues. Das ist zwar 
mehr schreibarbeit, führt aber zu einem mehr vorhersehbaren Code.