ESP8266 startet ständig neu

[Max M. (maxmicr)]

Ich arbeite aktuell mit dem espressif NONOS_SDK 3.1 für den ESP8266. 
Gerade bin ich dabei, die Temperaturdaten aus einem BMP280 auszulesen. 
Das klappt soweit schonmal (siehe Anhang).

Meine user_main.cpp sieht so aus:

extern "C" {
    #include "user_interface.h"
    #include "ets_sys.h"
}

#include "I2C_OLED.h"
#include "BMP280.h"

#if ((SPI_FLASH_SIZE_MAP == 0) || (SPI_FLASH_SIZE_MAP == 1))
#error "The flash map is not supported"
#elif (SPI_FLASH_SIZE_MAP == 2)
#define SYSTEM_PARTITION_OTA_SIZE              0x6A000
#define SYSTEM_PARTITION_OTA_2_ADDR              0x81000
#define SYSTEM_PARTITION_RF_CAL_ADDR            0xfb000
#define SYSTEM_PARTITION_PHY_DATA_ADDR            0xfc000
#define SYSTEM_PARTITION_SYSTEM_PARAMETER_ADDR        0xfd000
#elif (SPI_FLASH_SIZE_MAP == 3)
#define SYSTEM_PARTITION_OTA_SIZE              0x6A000
#define SYSTEM_PARTITION_OTA_2_ADDR              0x81000
#define SYSTEM_PARTITION_RF_CAL_ADDR            0x1fb000
#define SYSTEM_PARTITION_PHY_DATA_ADDR            0x1fc000
#define SYSTEM_PARTITION_SYSTEM_PARAMETER_ADDR        0x1fd000
#elif (SPI_FLASH_SIZE_MAP == 4)
#define SYSTEM_PARTITION_OTA_SIZE              0x6A000
#define SYSTEM_PARTITION_OTA_2_ADDR              0x81000
#define SYSTEM_PARTITION_RF_CAL_ADDR            0x3fb000
#define SYSTEM_PARTITION_PHY_DATA_ADDR            0x3fc000
#define SYSTEM_PARTITION_SYSTEM_PARAMETER_ADDR        0x3fd000
#elif (SPI_FLASH_SIZE_MAP == 5)
#define SYSTEM_PARTITION_OTA_SIZE              0x6A000
#define SYSTEM_PARTITION_OTA_2_ADDR              0x101000
#define SYSTEM_PARTITION_RF_CAL_ADDR            0x1fb000
#define SYSTEM_PARTITION_PHY_DATA_ADDR            0x1fc000
#define SYSTEM_PARTITION_SYSTEM_PARAMETER_ADDR        0x1fd000
#elif (SPI_FLASH_SIZE_MAP == 6)
#define SYSTEM_PARTITION_OTA_SIZE              0x6A000
#define SYSTEM_PARTITION_OTA_2_ADDR              0x101000
#define SYSTEM_PARTITION_RF_CAL_ADDR            0x3fb000
#define SYSTEM_PARTITION_PHY_DATA_ADDR            0x3fc000
#define SYSTEM_PARTITION_SYSTEM_PARAMETER_ADDR        0x3fd000
#else
#error "The flash map is not supported"
#endif

static const partition_item_t at_partition_table[] = {
    { SYSTEM_PARTITION_RF_CAL,              SYSTEM_PARTITION_RF_CAL_ADDR,             0x1000},
    { SYSTEM_PARTITION_PHY_DATA,             SYSTEM_PARTITION_PHY_DATA_ADDR,           0x1000},
    { SYSTEM_PARTITION_SYSTEM_PARAMETER,         SYSTEM_PARTITION_SYSTEM_PARAMETER_ADDR,       0x3000},
};

extern "C" void ICACHE_FLASH_ATTR user_pre_init(void) {
    if(!system_partition_table_regist(at_partition_table, sizeof(at_partition_table)/sizeof(at_partition_table[0]),SPI_FLASH_SIZE_MAP)) {
    os_printf("system_partition_table_regist fail\r\n");
    while(1);
  }
}

extern "C" void ICACHE_FLASH_ATTR user_init(void) {
    BMP280 bmp_280 = BMP280();

    while(true) {
        int32_t temperature = bmp_280.read_temperature();
        os_printf("Temperature: ");
        os_printf("%d\r\n", temperature);
        os_delay_us(2000000);
    }
}

Mit dem 2s Delay hatte ich eigentlich gedacht, dem ESP8266 genügend 
Spielraum für interne Angelegenheiten zu geben, die Ausgabe habe ich 
auch angehängt.

Ich komme genau 2 mal dazu die Temperatur auszulesen, dann startet der 
ESP8266 neu.

Hat dazu jemand eine Idee?

[Michael U. (amiga)]

Hallo,

ich treibe mich auf den ESPs aus Bequemlichkeit in der ArduinoIDE rum, 
aber trotzdem: was meldet der ESP8266 als Resetgrund (Baudrate ist 
74880)?
Ich habe mich jetzt nicht nach unten gekramt, aber sicher, daß 
os_delay_us die anderen Tasks bedient und nicht nach rund 6s einfach der 
WDT zuschlägt?

Gruß aus Berlin
Michael

[imkeller (Gast)]

Stromversorgung !
Elko direkt an ESP....
Alter Hut.

[Max M. (maxmicr)]

Ich hab das nun mit einem Software-Timer gelöst.

imkeller schrieb:
> Stromversorgung !
> Elko direkt an ESP....
> Alter Hut.

Ich hab ein Wemos D1 mini Board und hatte gehofft, damit etwaige 
Kondensator-Probleme zu umgehen?

[... (Gast)]

Ich kenne mich mit dem ESP nicht aus.

Zwei Punkte aber trotzdem:

1. Warum läuft die Schleife in der internen Funktion "user_init". Ein 
C-Programm beginnt immer mit "main".

2. Ein Delay ist mir bisher immer als tote Schleife untergekommen. Hier 
wird der Prozessor wirklich die ganze Zeit blockiert.

Ich tippe hier auf Watchdog.

[Franz (Gast)]

Du darfst das SDK nicht so lange blockieren. Keine so langen Sleeps und 
schon gar keine Endlosschleifen! Das Init muss wie jede andere Funktion 
zeitig verlassen werden.

[Max M. (maxmicr)]

Franz schrieb:
> Du darfst das SDK nicht so lange blockieren. Keine so langen Sleeps und
> schon gar keine Endlosschleifen! Das Init muss wie jede andere Funktion
> zeitig verlassen werden.

D.h. man sollte quasi alle wiederholenden Tätigkeiten in einen Timer 
auslagern und die Timerfunktion dann auch möglichst schnell abarbeiten?

[Karl M. (Gast)]

Max M. schrieb:
> D.h. man sollte quasi alle wiederholenden Tätigkeiten in einen Timer
> auslagern und die Timerfunktion dann auch möglichst schnell abarbeiten?

Nein man nutzt einen Timer als Zeitgeber und stößt die Abarbeitung von 
Aufgaben in der Mainloop, evtl. abhängig von Zeitintervallen, an.

Hängt immer von der Aufgabe und deren Teil-Prioritäten ab.

[Franz (Gast)]

Es gibt im NONOS SDK keine Mainloop. Das ist erstmal grundsätzlich zu 
begreifen, bevor man anfängt.

Timer und Events (Callbacks) sind der richtige Weg.