Compare commits

..
Author SHA1 Message Date
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
5 changed files with 70 additions and 10 deletions
+30
View File
@@ -1,3 +1,33 @@
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,
+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 -7
View File
@@ -458,14 +458,9 @@ static bool ws7_dsi_bringup(esp_lcd_dsi_bus_handle_t *out_bus,
#else
.pixel_format = LCD_COLOR_PIXEL_FORMAT_RGB565,
#endif
#if WS7_TEST_PATTERN
// Im Pruefbild-Modus genau ein Bildspeicher - wie im funktionierenden
// Werks-Testsketch. Nur so ist der Test wirklich ein Nachbau davon: Bisher lief er
// mit zwei Speichern und wich damit an genau der Stelle ab, die noch offen ist.
.num_fbs = 1,
#else
// 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,
#endif
.video_timing = {
.h_size = BSP_LCD_H_RES,
.v_size = BSP_LCD_V_RES,
+8 -2
View File
@@ -492,9 +492,15 @@ static lv_display_t *display_init(esp_lcd_panel_handle_t panel_handle)
// Normmaly, for RGB LCD, we just use one buffer for LVGL rendering
buffer_size = LVGL_PORT_H_RES * LVGL_PORT_BUFFER_HEIGHT;
buf1 = heap_caps_malloc(buffer_size * sizeof(lv_color_t), LVGL_PORT_BUFFER_MALLOC_CAPS);
// buffer_size = LVGL_PORT_H_RES * LVGL_PORT_BUFFER_HEIGHT;
// buf1 = heap_caps_malloc(buffer_size * sizeof(lv_color_t), MALLOC_CAP_DMA);
assert(buf1);
#ifdef LVGL_PORT_SECOND_DRAW_BUFFER
// PROJEKTAENDERUNG gegenueber der Hersteller-Portierung: ein zweiter Zeichenpuffer.
// Mit nur einem Puffer steht das Zeichnen still, solange der fertige Inhalt in den
// Bildspeicher uebertragen wird. Mit zwei Puffern zeichnet LVGL bereits den naechsten
// Bereich, waehrend der vorige noch uebertragen wird - beim Bildlauf deutlich spuerbar.
buf2 = heap_caps_malloc(buffer_size * sizeof(lv_color_t), LVGL_PORT_BUFFER_MALLOC_CAPS);
assert(buf2);
#endif
ESP_LOGI(TAG, "LVGL buffer size: %dKB", buffer_size * sizeof(lv_color_t) / 1024);
#endif /* LVGL_PORT_AVOID_TEAR_ENABLE */
+29
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,30 @@
#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.
// Dazu ein zweiter Puffer: LVGL zeichnet damit schon den naechsten Bereich, waehrend der
// vorige noch in den Bildspeicher uebertragen wird.
// Kosten: 2 x 2,8 MB PSRAM. Bei 32 MB unkritisch. Der interne Speicher waere zu knapp.
#define CONFIG_EXAMPLE_LVGL_PORT_BUF_PSRAM 1
#define CONFIG_EXAMPLE_LVGL_PORT_BUF_HEIGHT LCD_V_RES
#define LVGL_PORT_SECOND_DRAW_BUFFER 1
#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