D1-Mini + TFT ST7735 = WLAN-Problem

[El_Despo74]

Hy zusammen und frohe Ostern

Ich habe ein Problem mit folgenden Komponenten:

- 1x ESP8266 D1-Mini (1MB)
- 1x TFT-Display ST7735 mit grünem Fähnchen am Display

Ich verzweifle an dem Problem schon seit Tagen rum und finde keine Lösung, aber ich habe es zumindest eingrenzen können (denke ich)...

Lade ich folgenden Code auf den ESP8266 hoch, funktioniert alles einwandfrei... Nach dem Hochladen keinerlei Fehlermeldungen in den Logs und ich kann auch direkt wieder über WLAN flashen... auch mehrere Male hintereinander, alles tutti

esphome:
  name: "esp8266-tft-display"
  friendly_name: ESP8266-TFT-Display
esp8266:
  board: d1_mini
# Enable logging
logger:
  level: VERY_VERBOSE
# Enable Home Assistant API
api:
  encryption:
    key: "TYgj5nOdFfydcj92RzWhao5xNYjEldRFKcZIKLeviy4="
 
ota:
  safe_mode: true
  password: !secret ota_password
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: light
  manual_ip:
    static_ip: 192.168.178.91
    gateway: 192.168.178.1
    subnet: 255.255.255.0
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Web-676542"
    password: "WSQwilgD04Nw"
captive_portal:
# Display stuff
spi:
  clk_pin: GPIO14
  mosi_pin: GPIO13

Füge ich nun folgenden Code hinzu und flashe den ESP8266 erneut

display:
  - platform: st7735
    model: "INITR_GREENTAB"
    id: tft1
    reset_pin: GPIO2
    cs_pin: GPIO15
    dc_pin: GPIO4
    rotation: 90
    device_width: 128
    device_height: 160
    col_start: 0
    row_start: 0
    eight_bit_color: true
    update_interval: 2s

bekomme ich direkt nach dem Flashen folgende Meldung

Uploading: [============================================================] 100% Done...
INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
INFO Starting log output from 192.168.178.91 using esphome API WARNING Can't connect to ESPHome API for 192.168.178.91: Timeout while connecting to ('192.168.178.91', 6053)

Wenn ich danach versuche, über WLAN zu flashen, wird korrekt compiliert, aber bei der Upload-Meldung läuft der Balken dann mal bis 5% oder 20% oder 88% oder auch gar nicht.....

Ein Flashen ist dann nur noch über Kabel möglich....

Entferne ich diesen Code wieder und flashe über Kabel, kann ich sofort wieder über WLAN flashen und es erscheinen keine Fehlermeldungen mehr....

Also muss irgendwas an diesem Code falsch sein, der das Problem hervorruft.... aber was.....???

Greetz
Günni

edit: Achja, am ESP8266 liegt es nicht, ich habe mittlerweile mehrere verschiedene ausprobiert und es tritt immer auf....
Auch der Speicher ist nicht voll, ich bekomme vor der (vergeblichen) Flashen folgende Meldung:

Compiling /data/esp8266-tft-display/.pioenvs/esp8266-tft-display/src/main.cpp.o
Linking /data/esp8266-tft-display/.pioenvs/esp8266-tft-display/firmware.elf
RAM:   [=====     ]  47.5% (used 38932 bytes from 81920 bytes)
Flash: [=====     ]  48.5% (used 506893 bytes from 1044464 bytes)
Building /data/esp8266-tft-display/.pioenvs/esp8266-tft-display/firmware.bin

 

[cortlieb]

Habe genau das gleiche Problem. Zusätzlich startet mein D1-mini oft neu. Glaube, dass ich es noch ein bisschen weiter eingekreist habe.
Erst dachte ich der D1-mini ist kaputt. Aber genau wie bei dir, ein anderer hat das gleiche Problem gezeigt.
Dann habe ich auch den Zusammenhang mit dem gleichen (allerdings model: "INITR_BLACKTAB") Display hergestellt, dachte erst der Bus stört das WLAN.
Am Ende habe ich festgestellt, dass alles wieder funktioniert, wenn ich von den vier genutzten Fontgrößen zwei wieder rausschmeiße.
Mein Fazit ist, dass es sich doch um ein Speicherproblem handelt, auch wenn (genau wie bei dir) nach dem Compilieren angezeigt wird, dass das RAM nur zur Hälfte belegt ist.

Ich habe versucht, das Problem über das Eingrenzen der benutzen Zeichen aus einem Zeichensatz zu lösen (

glyphs:

- Variable). Das hat nur so halb funktioniert. Der WLAN-Download geht meistens, aber nicht immer.
Das lässt mich so ein bisschen an meiner Annahme zweifeln. Aber jedenfalls ist der Zusammenhang zwischen definierten Fonts und dem Problem eindeutig.

Weiß zufällig jemand, ob man irgendwo nachschauen kann, wie viel Speicher wirklich genutzt wird, um nicht nur durch "ausprobieren" zu einer Lösung zu kommen?

 

[El_Despo74]

Das kann bei mir nicht das Problem sein, da ich noch gar keine Fonts in meinem Code definiert habe.....
Aber bei mir ist es auch so, dass der D1-Mini immer wieder neustartet.....

 

[u5zzug]

Zu wenig sram?

ich finde dazu (Suche nach esphome ST7735 wlan):

Try changing your displzu ay's update_interval.
Setting this to 2s enabled my device to connect to my WiFi.
---
Can confirm that increasing the i2c bus speed from the default 50kHz ixes the issue:
i2c:
frequency: 100kHz
---
Update: I can confirm this exact same yaml config runs without issues on the ESP-Wroom-32

 

[cortlieb]

Das kann bei mir nicht das Problem sein, da ich noch gar keine Fonts in meinem Code definiert habe.....

OK, ich dachte, du hast vielleicht nicht den kompletten Code gezeigt.

Try changing your displzu ay's update_interval.
Setting this to 2s enabled my device to connect to my WiFi.

Das update_interval stand bei mir auf 5s (so findet es sich auch im ESPHome Beispiel), setze ich es auf 2s geht WLAN-technisch gar nichts mehr. Das Ganze scheint wirklich ein bisschen sensibel zu sein.
@El_Despo74: vielleicht wäre es für dich einen Versuch wert, das update_interval von 2s auf 5s hochzusetzen.

Can confirm that increasing the i2c bus speed from the default 50kHz ixes the issue:
i2c:

Zumindest bei mir benutzt das Display den SPI-Bus, da kann man keine Frequenz einstellen.

Mein Stand ist jetzt, dass ich wieder alle 4 Zeichensätze nutze, aber den Zeichenvorrat einschränke. Für Temperaturen oder die Uhrzeit werden ja nur wenige Zeichen gebraucht. Damit scheint meine Anwendung zu laufen. Ohne die Einschränkung der Zeichen war das nicht der Fall.
Außerdem habe ich einen ESP32 mit 512kB RAM bestellt. Wenn der die Probleme bei vollem Font nicht zeigt, würde sich mein Verdacht erhärten.
@El_Despo74 was dann aber bei dir den Speicher frisst, weiß ich auch nicht.

 

[alexamend]

Der ESP8266 hat Standard mäßig 80mhz clock lässt sich mit kühlung bis auf 160mhz hochschrauben,
Der ESP32 lässt sich variable von 80-240mhz einstellen alles darüber auch nur mit kühlung und nur manuell kompiliertem Code, Speicher ist nicht so kritisch außer man möchte aufwendige web frontend laufen lassen.

Die ESP8266 + TFT + WiFi Problematik ist bekannt und lässt sich meist nur mit selbst erstellten font Bibliotheken beheben die nur das laden was benötigt wird, der ist schlicht etwas zu schwach dafür, selber Code auf einem esp32 wird ohne Probleme laufen.

 

[El_Despo74]

Nochmal: Ich habe noch gar keine Fonts im Code definiert…. Der Code ist der vom ersten Beitrag… mehr ist nicht drin….

 

[alexamend]

Nochmal: Ich habe noch gar keine Fonts im Code definiert…. Der Code ist der vom ersten Beitrag… mehr ist nicht drin….

Das ist richtig, daher wird dein Display mit der Standard Bibliothek angesprochen was Leistung kostet und wenn die den jetzt ota mit daten fütterst, kommt der an seine Grenzen.

 

[azrael783]

War bei mir an einem ePaper Display auch so mit einem ESP8266. Ich hab dann erst die OTA Funktion deaktiviert und bin dann später auf einen ESP32 gewechselt.

 

[El_Despo74]

Bin nun auf einen ESP32 umgestiegen für das Display.... bis jetzt klappt alles....

Danke an alle