Compare commits

...
Author SHA1 Message Date
raw-designsandClaude Opus 5 a3461fe960 fix(P4): Blaue Zwischenbilder beim Bildlauf beseitigt (1.6.26)
Ursache war der zweite Zeichenpuffer aus 1.6.25. esp_lcd_dpi_panel_draw_bitmap
lehnt eine Übertragung ab, solange die vorige noch läuft:

  ESP_RETURN_ON_FALSE(xSemaphoreTake(dpi_panel->draw_sem, 0) == pdTRUE,
                      ESP_ERR_INVALID_STATE, ...)

Mit zwei Puffern schickt LVGL die nächste Übertragung sofort los, statt auf
lv_disp_flush_ready zu warten. Die abgelehnte Übertragung fällt ersatzlos
aus, und der betroffene Bildbereich behält seinen alten oder noch nicht
geschriebenen Inhalt - sichtbar als blaue Zwischenbilder.

Der zweite Zeichenpuffer ist entfernt, lvgl_port_v9.c ist damit wieder
unverändert gegenüber der Hersteller-Portierung. Der eigentliche Gewinn
bleibt: Der Zwischenpuffer hat weiterhin volle Bildhöhe, ein Bildlauf
braucht einen Durchgang statt sechs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-02 03:47:59 +02:00
thomas 1a05f8e1b3 Merge pull request 'perf(P4): Zeichenpuffer für flüssigen Bildlauf (1.6.25)' (#53) from perf/zeichenpuffer-bildlauf into main 2026-09-02 03:38:44 +02:00
raw-designsandClaude Opus 5 dd8e641aa7 perf(P4): Zeichenpuffer für flüssigen Bildlauf (1.6.25)
Nach der Umstellung auf einen Bildspeicher war der Bildlauf sehr zäh. Grund
war der Zwischenpuffer: Mit 120 Zeilen brauchte ein Bildlauf über die ganze
Seite sechs Durchgänge, jeder mit eigener Übertragung in den Bildspeicher.

- CONFIG_EXAMPLE_LVGL_PORT_BUF_HEIGHT auf LCD_V_RES: ein Durchgang statt
  sechs.
- Zweiter Zeichenpuffer (LVGL_PORT_SECOND_DRAW_BUFFER), damit LVGL den
  nächsten Bereich zeichnen kann, während der vorige übertragen wird. Dafür
  eine kleine, markierte Änderung in lvgl_port_v9.c - der Hersteller-Port
  legt dort nur einen Puffer an.

Kosten 2 x 2,8 MB PSRAM. Das Startverhalten bleibt unberührt: Es handelt
sich um Zeichenpuffer, nicht um Bildspeicher der Anzeige - es bleibt bei
einem Bildspeicher.

Beide Panel-Varianten mit arduino-cli gegengebaut.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-02 03:37:19 +02:00
thomas 6201c1bc36 Merge pull request 'fix(P4): Nur ein Bildspeicher - Ursache des Startfehlers behoben (1.6.24)' (#52) from fix/ein-bildspeicher into main 2026-09-02 03:20:25 +02:00
raw-designsandClaude Opus 5 6d710f0129 fix(P4): Nur ein Bildspeicher - Ursache des Startfehlers behoben (1.6.24)
Mit dem Prüfbild bei num_fbs = 1 startet das Panel zuverlässig, mit zwei
Bildspeichern nicht. Das war der letzte verbliebene Unterschied zum
funktionierenden Werks-Testsketch - und die Ursache des ganzen
Startproblems: Der Hochlauf meldete durchgehend Erfolg, das Panel blieb
dunkel, erst ein Reset half.

- WS7_SINGLE_FB schaltet die Doppelpufferung für das Waveshare-Panel ab
  (EXAMPLE_LVGL_PORT_AVOID_TEAR_ENABLE = 0). LVGL zeichnet dann in einen
  Zwischenpuffer von 120 Zeilen im PSRAM, der per DMA in den einen
  Bildspeicher übertragen wird.
- num_fbs folgt wieder LVGL_PORT_LCD_BUFFER_NUMS, das in diesem Modus 1
  ist - die Sonderbehandlung im Prüfbild-Modus entfällt.
- WS7_PARTIAL_REFRESH ist damit wirkungslos und als solches vermerkt.
- PSRAM-Bedarf sinkt von 5,4 MB auf 2,8 MB.

Preis ist mögliches Tearing bei schnellen Bildwechseln.

Beide Panel-Varianten mit arduino-cli gegengebaut.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P7JsiDJ1QbNFLDz5chf8Jt
2026-09-02 03:19:00 +02:00
thomas 5cc71ffa92 Merge pull request 'diag(P4): Prüfbild mit genau einem Bildspeicher, wie im Testsketch (1.6.23)' (#51) from diag/pruefbild-ein-bildspeicher into main 2026-09-02 03:04:57 +02:00
raw-designsandClaude Opus 5 6bef94b8e1 diag(P4): Prüfbild mit genau einem Bildspeicher, wie im Testsketch (1.6.23)
Der Selbst-Neustart aus 1.6.22 reicht nicht - ein Software-Neustart setzt
offenbar nicht dasselbe zurück wie die Reset-Taste.

Damit zurück zu dem einen Unterschied zum funktionierenden Werks-Testsketch,
der bisher nie überprüft wurde: dsi-test.ino setzt num_fbs = 1, die Firmware
nutzt LVGL_PORT_LCD_BUFFER_NUMS = 2. Der Prüfbild-Test lief bislang ebenfalls
mit zwei Speichern und war damit nie ein echter Nachbau - er wich an genau
der offenen Stelle ab.

Mit WS7_TEST_PATTERN = 1 wird num_fbs jetzt fest auf 1 gesetzt. Erscheinen
die Farbbalken damit zuverlässig, liegt es an der Anzahl der Bildspeicher.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P7JsiDJ1QbNFLDz5chf8Jt
2026-09-02 03:03:33 +02:00
thomas 95e97e5937 Merge pull request 'fix(P4): Nach Kaltstart einmal selbst neu starten (1.6.22)' (#50) from fix/kaltstart-neustart into main 2026-09-02 02:45:31 +02:00
raw-designsandClaude Opus 5 8db8e166a2 fix(P4): Nach Kaltstart einmal selbst neu starten (1.6.22)
Der DSI-Ab- und Wiederaufbau aus 1.6.21 hat nicht geholfen, sondern das
Bild um einen Schritt verschlechtert: Einschalten - gar nichts, erster
Reset - nur Beleuchtung, zweiter Reset - Bild. Ein Neuaufbau im laufenden
Betrieb ist einem echten Chip-Reset also nicht gleichwertig.
WS7_DSI_RESTART steht wieder auf 0, der Schalter bleibt dokumentiert.

Stattdessen der Weg, den die Messungen stützen: Nach einem Kaltstart
startet der P4 sich genau einmal selbst neu, sobald der erste Hochlauf
durch ist. Ein Reset hat in jedem Versuch zuverlässig geholfen.

- Bedingung ist esp_reset_reason() == ESP_RST_POWERON, beim zweiten
  Durchlauf greift sie nicht mehr - keine Schleife möglich.
- Der Frühstart-Zähler der Absturzsicherung wird vorher zurückgesetzt,
  damit der gewollte Neustart nicht in den Update-Modus führt.
- Schalter WS7_COLD_BOOT_RESTART, kostet ~3 s beim Einschalten.

Das ist eine Umgehung, keine Erklärung: Warum das Panel den ersten Anlauf
nicht annimmt, bleibt offen - der Hochlauf meldet durchgehend Erfolg.

Beide Panel-Varianten mit arduino-cli gegengebaut.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P7JsiDJ1QbNFLDz5chf8Jt
2026-09-02 02:44:06 +02:00
thomas 1def9e45dc Merge pull request 'fix(P4): DSI-Strecke beim Hochlauf einmal neu aufbauen (1.6.21)' (#49) from fix/dsi-strecke-neu-aufbauen into main 2026-09-02 02:27:49 +02:00
5 changed files with 140 additions and 2 deletions
+71
View File
@@ -1,3 +1,74 @@
Version 1.6.26:
- Fehlerbehebung: Beim Bildlauf blitzten blaue Zwischenbilder auf. Ursache war der zweite
Zeichenpuffer aus 1.6.25. Der Panel-Treiber lehnt eine Uebertragung ab, solange die
vorige noch laeuft; mit zwei Puffern schickt LVGL die naechste aber sofort los. Die
abgelehnte Uebertragung faellt ersatzlos aus, und der betroffene Bildbereich behaelt
seinen alten Inhalt.
- Der zweite Zeichenpuffer ist deshalb wieder entfernt, die Herstellerdatei lvgl_port_v9.c
damit wieder unveraendert. Der eigentliche Gewinn beim Bildlauf bleibt erhalten: Der
Zwischenpuffer hat weiterhin volle Bildhoehe, ein Bildlauf braucht also einen Durchgang
statt sechs.
Version 1.6.25:
- Der Bildlauf war nach der Umstellung auf einen Bildspeicher sehr zaeh. Grund war der
Zwischenpuffer, in den LVGL zeichnet: Mit 120 Zeilen brauchte ein Bildlauf ueber die
ganze Seite sechs Durchgaenge, jeder mit eigener Uebertragung in den Bildspeicher.
- Der Zwischenpuffer hat jetzt volle Bildhoehe - ein Durchgang statt sechs. Dazu kommt ein
zweiter Puffer, damit LVGL bereits den naechsten Bereich zeichnen kann, waehrend der
vorige noch uebertragen wird.
- Kosten: 2 x 2,8 MB PSRAM zusaetzlich, bei 32 MB unkritisch. Am Startverhalten aendert
sich nichts: Diese Puffer sind Zeichenpuffer, keine Bildspeicher der Anzeige - es bleibt
bei EINEM Bildspeicher, und nur der war fuer den Startfehler verantwortlich.
Version 1.6.24:
- Ursache des unzuverlaessigen Starts gefunden und behoben: die Anzahl der Bildspeicher.
Mit zwei Bildspeichern kam nach dem Einschalten kein Bild - der Hochlauf meldete
durchgehend Erfolg, das Panel blieb dunkel, und erst ein Reset half. Mit genau einem
startet es zuverlaessig. Belegt wurde das mit den Prueffarbbalken: Sie erscheinen mit
einem Speicher sofort, mit zweien nicht. Der Werks-Testsketch benutzt ebenfalls einen -
das war der letzte verbliebene Unterschied zu ihm.
- Die Oberflaeche laeuft deshalb ohne Doppelpufferung: LVGL zeichnet in einen
Zwischenpuffer von 120 Zeilen im PSRAM, der dann in den einen Bildspeicher uebertragen
wird. Bei schnellen Bildwechseln kann kurz eine Kante sichtbar werden; ein zuverlaessig
startendes Display wiegt das auf.
- Schalter WS7_SINGLE_FB in pins_config.h. WS7_PARTIAL_REFRESH ist damit wirkungslos, weil
es ohne Doppelpufferung nichts umzuschalten gibt.
- Der PSRAM-Bedarf sinkt von 5,4 MB auf 2,8 MB.
- Die Umgehungen aus den Vorversionen bleiben erhalten: Anlaufzeit, wiederholte
Bridge-Grundeinstellung, wiederholte Weckbefehle und der Neustart nach Kaltstart. Ob
jede davon noch noetig ist, laesst sich jetzt einzeln pruefen - der Startfehler selbst
ist behoben.
Version 1.6.23:
- Der Selbst-Neustart aus 1.6.22 reicht nicht: Ein Software-Neustart setzt offenbar nicht
dasselbe zurueck wie die Reset-Taste. Der Schalter bleibt eingeschaltet, er schadet nicht,
loest das Problem aber nicht allein.
- Zurueck zu dem einen Unterschied zum funktionierenden Werks-Testsketch, der bisher nie
ueberprueft wurde: Dieser legt EINEN Bildspeicher an, die Firmware zwei. Der Pruefbild-Test
lief bislang ebenfalls mit zwei und war damit nie ein echter Nachbau des Testsketches - er
wich an genau der Stelle ab, die noch offen ist.
- Mit WS7_TEST_PATTERN = 1 wird jetzt genau ein Bildspeicher angelegt, wie im Testsketch.
Erscheinen die Farbbalken damit zuverlaessig, liegt es an der Anzahl der Bildspeicher, und
die Oberflaeche laesst sich darauf umstellen.
Version 1.6.22:
- Der Ab- und Wiederaufbau der DSI-Strecke aus 1.6.21 hat nicht geholfen, sondern das Bild
um einen Schritt verschlechtert: Nach dem Einschalten kam gar nichts mehr, nach dem
ersten Reset nur die Beleuchtung, erst nach dem zweiten das Bild. Ein Ab- und Wiederaufbau
im laufenden Betrieb ist einem echten Chip-Reset also nicht gleichwertig. WS7_DSI_RESTART
steht deshalb wieder auf 0; der Schalter bleibt samt Begruendung erhalten.
- Stattdessen der Weg, den die Messungen eindeutig stuetzen: Nach einem Kaltstart startet
der P4 sich genau einmal selbst neu, sobald der erste Hochlauf durch ist. Damit passiert
genau das, was bei jedem Versuch zuverlaessig geholfen hat - ohne dass jemand die
Reset-Taste druecken muss.
- Eine Schleife ist ausgeschlossen: Beim zweiten Durchlauf ist der Startgrund kein Kaltstart
mehr, die Bedingung greift nicht erneut. Der Fruehstart-Zaehler der Absturzsicherung wird
vor dem gewollten Neustart zurueckgesetzt, damit dieser nicht als Absturz zaehlt.
- Kostet rund drei Sekunden, und nur beim Einschalten. Schalter WS7_COLD_BOOT_RESTART in
pins_config.h.
- Das ist eine Umgehung, keine Erklaerung: Warum das Panel den ersten Anlauf nach dem
Einschalten nicht annimmt, ist weiterhin offen. Der Hochlauf meldet durchgehend Erfolg.
Version 1.6.21:
- Der Hochlauf lief zuletzt vollstaendig fehlerfrei durch - Bridge zweimal eingestellt,
Panel zweimal geweckt, alle I2C-Bausteine erreichbar - und trotzdem kam beim ersten
@@ -24,6 +24,7 @@
#include "protocol_client.h"
#include "ui.h"
#include "display_hal.h"
#include "pins_config.h"
#include <ArduinoJson.h>
#include <Update.h>
#include <Preferences.h>
@@ -296,6 +297,31 @@ void setup() {
g_client.onOta(onOta);
hal_init(&g_client); // LVGL + Panel/Touch + Dashboard (ruft ui_init intern auf)
// --- Waveshare-Panel: einmaliger Neustart nach dem Einschalten ---
//
// Das Panel kommt nach dem Anlegen der Versorgung im ersten Anlauf nicht zuverlaessig
// hoch: Die Beleuchtung geht an, ein Bild bleibt aus - obwohl jeder Schritt des
// Hochlaufs Erfolg meldet. Ein Reset behebt es zuverlaessig, und zwar nur ein echter
// Chip-Reset; die DSI-Strecke im laufenden Betrieb ab- und wieder aufzubauen genuegt
// nicht (siehe WS7_DSI_RESTART).
//
// Deshalb startet der P4 sich nach einem Kaltstart genau einmal selbst neu, nachdem
// der erste Hochlauf durch ist. Beim zweiten Durchlauf ist der Startgrund kein
// Kaltstart mehr, die Bedingung greift also nicht erneut - eine Schleife ist
// ausgeschlossen. Kostet rund drei Sekunden, aber nur beim Einschalten.
#if (JC_PANEL_TYPE == WS_PANEL_7H) && WS7_COLD_BOOT_RESTART
if (esp_reset_reason() == ESP_RST_POWERON) {
// Der Fruehstart-Zaehler wurde oben bereits erhoeht. Diesen gewollten Neustart
// darf er nicht mitzaehlen, sonst laeuft die Absturzsicherung nach ein paar
// Einschaltvorgaengen in den Update-Modus.
{ Preferences p; p.begin("bootguard", false); p.putUShort("early", 0); p.end(); }
DBG_SERIAL.println(F("[Panel] Kaltstart - einmaliger Neustart fuer das Displaypanel"));
DBG_SERIAL.flush();
delay(50);
esp_restart();
}
#endif
g_client.begin(); // UART starten, hello folgt automatisch in loop()
DBG_SERIAL.println(F("Bereit. Warte auf Verbindung zur Hauptplatine..."));
+1 -1
View File
@@ -50,7 +50,7 @@ Vendor-Pakete: 4,3" im Ordner `JC4880P443C_I_W/`, 7,0" im Repo-Ordner
| Touch-Rohkoordinaten | 480×800 (= Panelraster) | **800×480** → wird auf 1024×600 skaliert | **720×1280** (Hochformat) → X/Y werden getauscht |
| LCD-Reset | GPIO5 | **GPIO27** | kein Reset-Pin (macht die Bridge) |
| Backlight | GPIO23 (LEDC-PWM) | GPIO23 (LEDC-PWM) | **Bridge-Register** auf I²C **0x45** (`AD`/`AB`/`AA`) |
| Framebuffer | 3 × 750 KB ≈ 2,3 MB PSRAM | 3 × 1,2 MB ≈ 3,6 MB PSRAM | 3 × 2,8 MB ≈ 8,3 MB PSRAM |
| Framebuffer | 3 × 750 KB ≈ 2,3 MB PSRAM | 3 × 1,2 MB ≈ 3,6 MB PSRAM | **1 × 2,8 MB** — mehr verträgt das Panel beim Start nicht |
| Freie Expansion-IO | Stiftleiste **JP1**: GPIO 52/51/50/49/35/34/33/32/31/30/29/28 | FPC 1,0 mm 16-pol. **FPC4**: GPIO 34/33/32/31/30/29/28 · **FPC3**: 48/47/46/45/5/4/3/2 | 40-poliger Header im Raspberry-Pi-Pico-Format; belegt sind I²C (7/8), TF-Karte (9/10/11/12/13/53) und Debug-UART0 (37/38) |
| UART zur Hauptplatine | TX GPIO33 / RX GPIO31 | TX GPIO33 / RX GPIO31 | **TX GPIO20 / RX GPIO21** |
+2
View File
@@ -458,6 +458,8 @@ static bool ws7_dsi_bringup(esp_lcd_dsi_bus_handle_t *out_bus,
#else
.pixel_format = LCD_COLOR_PIXEL_FORMAT_RGB565,
#endif
// Anzahl der Bildspeicher. Beim Waveshare-Panel genau einer: mit zweien kam nach
// dem Einschalten kein Bild (siehe WS7_SINGLE_FB in pins_config.h).
.num_fbs = LVGL_PORT_LCD_BUFFER_NUMS,
.video_timing = {
.h_size = BSP_LCD_H_RES,
+40 -1
View File
@@ -32,7 +32,13 @@
// startet der P4 nicht mehr, hier zuerst auf 0 stellen.
// -------------------------------------------------------------------------------------
#define WS7_COLOR_BITS 24
// Ohne Wirkung, solange WS7_SINGLE_FB = 1 ist: Mit nur einem Bildspeicher gibt es keine
// Doppelpufferung, zwischen deren Betriebsarten man waehlen koennte.
#define WS7_PARTIAL_REFRESH 1
// Nur EIN Bildspeicher. Zwei vertraegt die DSI-Ausgabe dieses Panels beim Einschalten
// nicht - siehe die ausfuehrliche Begruendung weiter unten beim Avoid-Tear-Schalter.
// Auf 0 nur, wenn das Startverhalten erneut untersucht wird.
#define WS7_SINGLE_FB 1
#define WS7_PARALLEL_RENDER 1
#define EXAMPLE_LVGL_PORT_TASK_MAX_DELAY_MS 500 //range 2 to 2000
@@ -42,7 +48,32 @@
#define EXAMPLE_LVGL_PORT_TASK_CORE -1 //range -1 to 1
#define EXAMPLE_LVGL_PORT_TICK 2 //ragne 1 to 100
// Ruckelfreie Ausgabe braucht mindestens zwei Bildspeicher, aus denen abwechselnd
// angezeigt und in die gezeichnet wird.
//
// Das Waveshare-Panel vertraegt das nicht: Mit zwei Bildspeichern kam nach dem Einschalten
// kein Bild - der Hochlauf meldete durchgehend Erfolg, das Panel blieb dunkel, und erst ein
// Reset half. Mit genau einem Bildspeicher startet es zuverlaessig; belegt wurde das mit den
// Prueffarbbalken, die der Werks-Testsketch ebenfalls mit einem Speicher anzeigt.
// Deshalb hier ohne Doppelpufferung: LVGL zeichnet in einen kleinen Zwischenpuffer, der
// dann in den einen Bildspeicher uebertragen wird. Bei schnellen Bildwechseln kann dabei
// kurz eine Kante sichtbar werden - ein zuverlaessig startendes Display wiegt das auf.
#if (JC_PANEL_TYPE == WS_PANEL_7H) && WS7_SINGLE_FB
#define EXAMPLE_LVGL_PORT_AVOID_TEAR_ENABLE 0
// Zwischenpuffer fuer das Zeichnen. Volle Bildhoehe, damit ein Bildlauf in EINEM Durchgang
// gezeichnet und uebertragen wird. Mit 120 Zeilen waren es sechs Durchgaenge samt sechs
// Uebertragungen - das war der Grund fuer den zaehen Bildlauf. Kostet 2,8 MB PSRAM.
//
// Bewusst nur EIN Zeichenpuffer: Ein zweiter wuerde LVGL erlauben, schon den naechsten
// Bereich zu zeichnen, waehrend der vorige uebertragen wird. Der Panel-Treiber lehnt eine
// Uebertragung aber ab, solange die vorige laeuft (ESP_ERR_INVALID_STATE) - der betroffene
// Bildbereich wird dann gar nicht geschrieben und behaelt seinen alten Inhalt. Sichtbar
// war das als blaue Zwischenbilder beim Bildlauf.
#define CONFIG_EXAMPLE_LVGL_PORT_BUF_PSRAM 1
#define CONFIG_EXAMPLE_LVGL_PORT_BUF_HEIGHT LCD_V_RES
#else
#define EXAMPLE_LVGL_PORT_AVOID_TEAR_ENABLE 1
#endif
#ifdef EXAMPLE_LVGL_PORT_AVOID_TEAR_ENABLE
// 2 = Triple-Buffer + LVGL Full-Refresh: zeichnet bei jeder Aenderung das komplette
@@ -164,9 +195,17 @@
// Unterschied dabei: Die DSI-Verbindung geht einmal weg und neu auf, waehrend Bridge und
// Panel schon versorgt und eingestellt sind. Genau das holt der zweite Aufbau nach.
// Kostet WS7_DSI_RESTART_MS zusaetzliche Startzeit.
#define WS7_DSI_RESTART 1
#define WS7_DSI_RESTART 0
#define WS7_DSI_RESTART_MS 200
// Nach einem Kaltstart einmal selbst neu starten, sobald der erste Hochlauf durch ist.
// Das Panel kommt beim ersten Anlauf nach dem Einschalten nicht zuverlaessig hoch;
// ein echter Chip-Reset behebt es zuverlaessig, der Ab- und Wiederaufbau der
// DSI-Strecke im Betrieb dagegen nicht. Kostet rund drei Sekunden beim Einschalten.
// Eine Schleife ist ausgeschlossen: Beim zweiten Durchlauf ist der Startgrund kein
// Kaltstart mehr.
#define WS7_COLD_BOOT_RESTART 1
#define WS7_TEST_PATTERN 0
#elif JC_PANEL_TYPE == JC_PANEL_70