Compare commits

...
Author SHA1 Message Date
raw-designsandClaude Opus 5 c58b901f26 diag(P4): Schwarzes Bild eingrenzen - Prüfbild und lückenlose Meldungen (1.6.15)
Kaltstart, kein einziger Fehler im Log, alle I2C-Bausteine da - und trotzdem
keine Anzeige. Zwei Lücken in der Diagnose:

- Die DCS-Weckbefehle (MADCTL, Sleep Out, Display On) liefen ungeprüft
  durch. Jetzt über BSP_STEP gemeldet.
- Nach dem Panel-Start endete die Ausgabe. "Bringup fertig" vor und
  "LVGL laeuft" nach lvgl_port_init() trennen jetzt ein Hängenbleiben in
  LVGL von einem fehlenden Bild.

Neuer Schalter WS7_TEST_PATTERN nutzt esp_lcd_dpi_panel_set_pattern() für
Farbbalken aus dem DSI-Baustein, ohne Framebuffer und ohne LVGL - wie im
funktionierenden Werks-Testsketch. Erscheinen sie, arbeitet die Kette bis
zum Panel und der Fehler liegt weiter oben.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 16:51:04 +02:00
thomas d83619904f Merge pull request 'fix(P4): Touch erst nach Panel-Freigabe initialisieren (1.6.14)' (#42) from fix/touch-nach-panelfreigabe into main 2026-09-01 16:31:55 +02:00
raw-designsandClaude Opus 5 50540179c7 fix(P4): Touch erst nach Panel-Freigabe initialisieren (1.6.14)
Der GT9271 meldete "i2c transaction failed" auch beim Kaltstart, während
alle Panel-Schritte fehlerfrei durchliefen und die Bus-Freitaktung aus 1.6.13
den Bus als frei meldete.

Ursache ist die Reihenfolge: Im funktionierenden Werks-Testsketch steht
initTouch() hinter enableBacklight(). Der GT9271 hängt an derselben
Versorgung wie das Panel und antwortet erst, wenn die Bridge über 0xAD
freigegeben ist. Beim Übertragen in die Firmware war das verloren gegangen -
jc_backlight_set() lief erst nach jc_board_bringup().

- Für WS_PANEL_7H wird die Beleuchtung jetzt innerhalb des Bringups vor der
  Touch-Initialisierung eingeschaltet, mit WS7_TOUCH_POWER_MS Pause.
- Neue Diagnose ws7_i2c_scan() listet die antwortenden I2C-Adressen vor und
  nach dem Panel-Start.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 16:30:31 +02:00
thomas 9bbd7d72aa Merge pull request 'fix(P4): Hängenden I2C-Bus freitakten - Ursache des schwarzen Bildes (1.6.13)' (#41) from fix/i2c-bus-freitakten into main 2026-09-01 16:17:42 +02:00
raw-designsandClaude Opus 5 43c5d5a41a fix(P4): Hängenden I2C-Bus freitakten - Ursache des schwarzen Bildes (1.6.13)
Der Log nach einem Reset zeigte alle Panel-Schritte fehlerfrei, aber
"i2c transaction failed" beim GT911. Bridge und Touch teilen sich den Bus:
Trifft ein Reset des P4 mitten in eine Übertragung, bleibt der Baustein in
seiner Bitausgabe stehen und hält SDA dauerhaft low. Beide hängen an
Dauerstrom, der Zustand überlebt also Reset und Flashen.

- ws7_i2c_bus_recover() taktet SCL vor dem Anlegen des Busses bis zu neunmal
  von Hand, bis SDA freigegeben wird, und erzeugt dann eine Stop-Bedingung.
  Bei freiem Bus läuft die Funktion wirkungslos durch.
- ws7_bridge_write() prüft den Rückgabewert. Bisher liefen fehlgeschlagene
  Schreibzugriffe stillschweigend ins Leere - der eigentliche Grund, warum
  das schwarze Bild keinerlei Spur hinterließ.
- pins_config.h: "#elsealle" statt "#else" seit 1.6.10 korrigiert. Der
  Tippfehler traf nur den JC_PANEL_43-Zweig, der dadurch nicht mehr
  übersetzbar war. Beide Panel-Varianten wieder gegengebaut.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 16:16:09 +02:00
thomas dfd2aaddd1 Merge pull request 'fix(P4): Abschaltfolge zurücknehmen, Startgrund und LDO prüfen (1.6.12)' (#40) from fix/bridge-abschaltfolge-zuruecknehmen into main 2026-09-01 15:45:24 +02:00
raw-designsandClaude Opus 5 6c783c55de fix(P4): Abschaltfolge zurücknehmen, Startgrund und LDO prüfen (1.6.12)
Die Bridge-Abschaltfolge aus 1.6.11 hat den Fehler nicht behoben, sondern
verschlimmert: Nach C0/C2/AC = 0x00 kam das Panel auch direkt nach dem
Flashen nicht mehr hoch. Der Bringup entspricht wieder 1.6.10.

Stattdessen zwei Diagnosen zur Eingrenzung:
- esp_reset_reason() wird beim Hochlauf ausgegeben, um Kalt- von Warmstart
  unterscheiden zu können.
- esp_ldo_acquire_channel() läuft nicht mehr ungeprüft durch, sondern meldet
  einen Fehler über BSP_STEP. Es war der einzige Schritt ohne Prüfung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 15:44:02 +02:00
raw-designs f38ea3045b Revert "Merge pull request 'fix(P4): Schwarzes Bild nach Reset am Waveshare-Panel (1.6.11)' (#39) from fix/schwarzes-bild-nach-reset into main"
This reverts commit 0a6c6ed869, reversing
changes made to edb1e333f0.
2026-09-01 15:37:29 +02:00
thomas 0a6c6ed869 Merge pull request 'fix(P4): Schwarzes Bild nach Reset am Waveshare-Panel (1.6.11)' (#39) from fix/schwarzes-bild-nach-reset into main 2026-09-01 15:23:35 +02:00
raw-designsandClaude Opus 5 e8308a9182 fix(P4): Schwarzes Bild nach Reset am Waveshare-Panel (1.6.11)
Nach einem Reset des P4 blieb das Bild schwarz, die Hintergrundbeleuchtung
brannte; nur direkt nach dem Flashen lief es.

Die Bridge des Panels hat keine Reset-Leitung und hängt an Dauerstrom. Ein
Reset des P4 setzt sie nicht zurück - ihre Register standen noch auf den
Werten der vorigen Sitzung, während der P4 seine DSI-Strecke komplett neu
aufbaut. Beim Flashen wird die Versorgung getrennt, deshalb trat der Fehler
dort nicht auf.

ws7_bridge_pre_init() schaltet die Bridge jetzt zuerst definiert ab
(AB/AA, AD, dann AC/C2/C0), wartet WS7_BRIDGE_RESET_MS und schreibt erst
danach die Grundinitialisierung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 15:22:11 +02:00
thomas edb1e333f0 Merge pull request 'perf(P4): Teil-Neuzeichnen als Vorgabe, Messeinblendung, deckende Seiten (1.6.10)' (#38) from perf/scrollen-messen-und-vorgaben into main 2026-09-01 14:46:56 +02:00
raw-designsandClaude Opus 5 528c8d5500 perf(P4): Teil-Neuzeichnen als Vorgabe, Messeinblendung, deckende Seiten (1.6.10)
- WS7_PARTIAL_REFRESH = 1 auch im Auslieferungsstand. Am Gerät geprüft: kein
  Flackern; von den drei Tempo-Maßnahmen aus 1.6.4 ist es der größte Gewinn.
- make_page() setzt einen deckenden Hintergrund in COL_BG statt LV_OPA_TRANSP.
  Optisch identisch, spart LVGL beim Scrollen aber das Zeichnen und Mischen
  der darunterliegenden Ebenen.
- Neuer Schalter WS7_PERF_MONITOR schaltet LV_USE_SYSMON/LV_USE_PERF_MONITOR
  ein und blendet Bilder je Sekunde und Prozessorlast ein. Vorgabe 0, mit 1
  gegengebaut.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 14:45:33 +02:00
thomas 117715dc3b Merge pull request 'fix(P4): Tipp auf einen Knopf löst nicht mehr mehrfach aus (1.6.9)' (#37) from fix/touch-mehrfachausloesung into main 2026-09-01 14:19:51 +02:00
raw-designsandClaude Opus 5 328dc06983 fix(P4): Tipp auf einen Knopf löst nicht mehr mehrfach aus (1.6.9)
Der GT9271 lässt gelegentlich einen Messzyklus aus oder liefert ein
unplausibles Paket. Der Hersteller-Treiber kann "gerade nichts Neues" nicht
von "Finger weg" unterscheiden und meldet beides als losgelassen. Seit die
Abtastrate mit 1.6.8 von 33 auf 16 ms gestiegen ist, wurde daraus sichtbar
Drücken-Loslassen-Drücken-Loslassen.

Vor den Treiber ist jetzt ein eigener get_xy-Aufsatz gesetzt: Er verwirft
unplausible Rohwerte und hält den letzten gültigen Punkt noch
WS7_TOUCH_HOLD_MS lang (Vorgabe 40 ms). Der Aufsatz wird zur Laufzeit in das
Touch-Handle eingehängt, die Herstellerdateien bleiben unverändert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 14:18:28 +02:00
thomas 480708c992 Merge pull request 'perf(P4): Scrollen am Waveshare-Panel flüssiger (1.6.8)' (#36) from perf/scrollen-taktrate into main 2026-09-01 14:02:46 +02:00
raw-designsandClaude Opus 5 9a0761f6da perf(P4): Scrollen am Waveshare-Panel flüssiger (1.6.8)
LV_DEF_REFR_PERIOD steuert nicht nur die Bildrate, sondern auch die
Abtastrate des Touch und die Schrittweite von Animationen. Mit 33 ms waren
das 30 Schritte je Sekunde - beim Ziehen mit dem Finger sichtbar ruckelig.

Für das Waveshare-Panel jetzt 16 ms, passend zu dessen 60 Hz. Kommt das
Zeichnen nicht hinterher, wird ein Bild später fertig; kaputt geht nichts.
Die JC-Panels bleiben unverändert bei 33 ms.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 14:01:23 +02:00
thomas e6c09b7a9a Merge pull request 'fix(P4): Menü-Knopf fängt Tipps auch knapp daneben ab (1.6.7)' (#35) from fix/menue-knopf-trefferflaeche into main 2026-09-01 13:49:17 +02:00
raw-designsandClaude Opus 5 4fa0c81087 fix(P4): Menü-Knopf fängt Tipps auch knapp daneben ab (1.6.7)
Eine Messung mit WS7_TOUCH_DEBUG hat gezeigt, dass die Touch-Zuordnung stimmt:
Der Tipp auf den Menü-Knopf landete bei X=66/Y=27, der Knopf liegt aber bei
X 8..56. Mit 48x36 Pixeln ist er auf dem 7-Zoll-Panel ein sehr kleines Ziel.

lv_obj_set_ext_click_area vergrößert die Trefferfläche um 20 Pixel, ohne den
Knopf optisch zu ändern. Die Vergrößerung wirkt nur innerhalb der Kopfleiste,
weil diese ihre Kinder beschneidet - dem Seiteninhalt darunter wird nichts
weggenommen, und bei offenem Menü liegt ohnehin der Vorhang darüber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 13:47:54 +02:00
thomas 04eb77fb2d Merge pull request 'feat(P4): Touch-Messausgabe zum Einmessen (1.6.6)' (#34) from diag/touch-einmessen into main 2026-09-01 13:25:39 +02:00
raw-designsandClaude Opus 5 7878f1bafd feat(P4): Touch-Messausgabe zum Einmessen (1.6.6)
Der Menü-Knopf oben links reagiert am Waveshare-Panel nicht. Ob der Touch die
48x36 Pixel grosse Flaeche in der 44 Pixel hohen Kopfleiste ueberhaupt trifft,
liess sich bisher nicht nachsehen.

WS7_TOUCH_DEBUG in pins_config.h gibt jeden Berührpunkt roh und umgerechnet
über esp_rom_printf aus, also auch bei Core-Debug-Level "none". Vorgabe 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 13:24:18 +02:00
thomas 60bb859fc9 Merge pull request 'fix(P4): Menü-Vorhang wieder öffenbar, RGB888 bleibt Vorgabe (1.6.5)' (#33) from fix/waveshare-vollbild-neuzeichnen into main 2026-09-01 13:14:52 +02:00
raw-designsandClaude Opus 5 e8fdc60fea fix(P4): Menü-Vorhang wieder öffenbar, RGB888 bleibt Vorgabe (1.6.5)
Zwei der drei Tempo-Maßnahmen aus 1.6.4 haben sich am Gerät als untauglich
erwiesen und stehen wieder auf ihrem alten Wert:

- WS7_COLOR_BITS = 24: Die Bridge dieses Panels nimmt kein RGB565 an.
- WS7_PARTIAL_REFRESH = 0: Der Menü-Vorhang ist halbtransparent und wird in
  den gerade aktiven Bildpuffer eingemischt. Die nächste Zustandsmeldung der
  S3 zeichnet in den zweiten Puffer, der ihn nie bekommen hat - der Vorhang
  war damit sofort wieder weg und der Knopf schien wirkungslos. Nutzbar wäre
  der Modus erst, wenn der LVGL-Port die geänderten Bereiche zwischen beiden
  Puffern abgleicht.

Beide bleiben als Schalter erhalten, mit Notiz woran sie gescheitert sind.
WS7_PARALLEL_RENDER bleibt eingeschaltet - von den drei Maßnahmen trägt nur
diese.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 13:13:28 +02:00
thomas 8b7978507c Merge pull request 'perf(P4): Darstellung am Waveshare-Panel beschleunigen (1.6.4)' (#32) from perf/waveshare-darstellung-beschleunigen into main 2026-09-01 12:52:55 +02:00
raw-designsandClaude Opus 5 a8ae034911 perf(P4): Darstellung am Waveshare-Panel beschleunigen (1.6.4)
1280x720 sind 2,4-mal so viele Pixel wie beim 4,3-Zöller, und bis 1.6.3 wurde
bei jeder Änderung das komplette Bild in 24 Bit neu gezeichnet. Drei Schalter
in pins_config.h, einzeln zurückstellbar:

- WS7_COLOR_BITS = 16: RGB565 statt RGB888, halbe Datenmenge je Bild.
  lv_conf.h liest den Wert aus pins_config.h, damit Sketch und LVGL-Bibliothek
  dieselbe Farbtiefe benutzen; display_hal.cpp sichert das per static_assert.
- WS7_PARTIAL_REFRESH = 1: Avoid-Tear-Mode 3 (Direct-Mode, zwei Puffer) statt
  Vollbild-Neuzeichnen.
- WS7_PARALLEL_RENDER = 1: LV_USE_OS = FREERTOS und zwei Zeichen-Threads.

Framebuffer-Bedarf sinkt dadurch von rund 8,3 MB auf 3,7 MB PSRAM. Die
JC-Panels sind von allen drei Schaltern nicht betroffen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 12:51:24 +02:00
thomas ee5888ed97 Merge pull request 'fix(P4): UART auf GPIO20/21, Touch oben/unten spiegeln (1.6.3)' (#31) from fix/waveshare-uart-pins-und-touchspiegelung into main 2026-09-01 12:35:54 +02:00
raw-designsandClaude Opus 5 9d9591c26e fix(P4): UART auf GPIO20/21, Touch oben/unten spiegeln (1.6.3)
Nach dem ersten Betrieb am Waveshare ESP32-P4-Pico:

- UART zur Hauptplatine auf TX = GPIO20 / RX = GPIO21 (vorher GPIO17/18).
  Die JC-Panels bleiben bei GPIO33/GPIO31.
- Das Bild steht in der tatsächlichen Einbaulage richtig herum, deshalb ist
  WS7_ROTATE_180 wieder 0. Der Schalter bleibt für den Fall einer anderen
  Montage erhalten.
- Der Touch war oben/unten spiegelverkehrt: Der Digitizer sitzt gegenüber dem
  Bild um die Hochachse gedreht. WS7_TOUCH_MIRROR_RAW_X steht daher auf 1.
  Bild- und Touch-Ausrichtung sind zwei getrennte Schalter, weil sie an diesem
  Panel nicht zusammenfallen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 12:34:27 +02:00
thomas 288aacf1b4 Merge pull request 'fix(P4): Panel-Bringup meldet Fehler im Klartext statt abzustürzen (1.6.2)' (#30) from fix/panel-bringup-diagnose into main 2026-09-01 08:08:39 +02:00
raw-designsandClaude Opus 5 d75708993a fix(P4): Panel-Bringup meldet Fehler im Klartext statt abzustürzen (1.6.2)
Ein fehlgeschlagener Panel-Aufbau endete bisher in einem ESP_ERROR_CHECK
tief im LVGL-Port und damit in einem Speicherauszug ohne erkennbare Ursache.

- Die Schritte des Waveshare-Bringups melden ihren Fehler über esp_rom_printf,
  also auch bei Core-Debug-Level "none". Zusätzlich werden PSRAM-Größe,
  freier PSRAM, größter freier Block und der Framebuffer-Bedarf ausgegeben.
- jc_board_bringup() liefert jetzt einen Status. Kommt das Panel nicht hoch,
  bleibt die Firmware ohne Anzeige lauffähig (UART + OTA), statt beim ersten
  LVGL-Zugriff erneut abzustürzen.
- ui.cpp: alle öffentlichen Funktionen prüfen, ob ui_init gelaufen ist.
- Fehlerbehebung: esp_lcd_touch_new_i2c_gt911 setzt im Fehlerfall einen bereits
  freigegebenen Zeiger. Das Handle wird vorbelegt und der Rückgabewert geprüft.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 08:07:10 +02:00
thomas 146420a0bc Merge pull request 'refactor: Display-Firmware neutral als P4_Display_Firmware führen' (#29) from refactor/p4-display-firmware-umbenennen into main 2026-09-01 03:36:57 +02:00
raw-designsandClaude Opus 5 4f9f686d81 refactor: Display-Firmware neutral als P4_Display_Firmware führen
Der Ordner hieß JC_Display_Firmware, bedient seit 1.6.0 aber auch das
Waveshare 7inch DSI LCD (H) am ESP32-P4-Pico. Der Name führte in die Irre.

- JC_Display_Firmware/ -> P4_Display_Firmware/ (samt Sketch, den Arduino
  gleichnamig zum Ordner verlangt)
- Doku/JC-Display_UART-Protokoll.md -> Doku/P4-Display_UART-Protokoll.md,
  Verweise und Titel angepasst
- Verweise in CLAUDE.md, README und Quelltextköpfen nachgezogen

Nur Namen und Pfade, keine Logikänderung. Der Vendor-Ordner
JC_Display_Firmware_7zoll/ behält seinen Namen, ebenso die Bezeichner
JC_PANEL_TYPE/jc_board_bringup im Quelltext.

Enthält außerdem die bereits im Arbeitsverzeichnis liegende, noch nicht
committete Ergänzung des Git-Workflows in CLAUDE.md (PRs über die Gitea-API
statt der hängenden tea-CLI).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018QoLDQeUh1dCQz7yYZVb4Y
2026-09-01 03:30:42 +02:00
thomas e0c6784ecf Merge pull request 'fix(P4): Waveshare-Panel um 180 Grad gedreht ausgeben (1.6.1)' (#28) from fix/waveshare-einbaulage-180-grad into main 2026-09-01 03:12:31 +02:00
4805 changed files with 617 additions and 79 deletions
+6 -6
View File
@@ -11,17 +11,17 @@ für zwei Mikrocontroller, die per UART (230400 8N1, JSON-Zeilen) verbunden sind
Änderungshistorie: `Changelog.txt` (Root), Version steht in `String version = "…"`.
- **ESP32-P4 UART-Touch-Display (spiegelt den S3-Zustand).**
Ordner: `JC_Display_Firmware/` (Hauptsketch `JC_Display_Firmware.ino`,
Ordner: `P4_Display_Firmware/` (Hauptsketch `P4_Display_Firmware.ino`,
UI in `ui.cpp`/`ui.h`, UART-Protokoll in `protocol_client.*`, LVGL 9.x).
Hat **kein eigenes WLAN** (der ESP32-C6-Co-Prozessor ist ungenutzt); alle Daten
kommen über UART vom S3. Eigene Version `DISPLAY_FW_VERSION` +
`JC_Display_Firmware/Changelog.txt`.
`P4_Display_Firmware/Changelog.txt`.
Wenn ich „S3/Controller/Maschine" sage, ist `Dual_PID_FastHeatUp.ino` gemeint;
„P4/Display" ist der Ordner `JC_Display_Firmware/`.
„P4/Display" ist der Ordner `P4_Display_Firmware/`.
**Nicht anfassen:** Der Ordner `Sicherungen/` enthält nur datierte Versions-Backups
(`.ino`) — niemals dort editieren. Unter `JC_Display_Firmware/JC4880P443C_I_W/` liegen
(`.ino`) — niemals dort editieren. Unter `P4_Display_Firmware/JC4880P443C_I_W/` liegen
reine Hersteller-Demos/Beispiele (Board-Support), ebenfalls nicht als Projektcode behandeln.
# Agent Instructions
@@ -33,8 +33,8 @@ reine Hersteller-Demos/Beispiele (Board-Support), ebenfalls nicht als Projektcod
## Git-Workflow
- Host: Gitea `git.mueller.black`, Repo `thomas/Dual-PID`, User `thomas`, CLI `tea`.
- Aenderungen immer ueber Feature-Branch + Merge-Request (`tea pr create`), nie direkt auf `main` committen oder pushen.
- Pull/Merge-Requests dürfen immer selbstständig gemergt werden (Auto-Merge, kein grünes CI erforderlich, via `tea pr merge` oder Gitea-API); danach den Merge kurz melden.
- Aenderungen immer ueber Feature-Branch + Merge-Request, nie direkt auf `main` committen oder pushen.
- PR anlegen **und** mergen bevorzugt über die **Gitea-REST-API** (PowerShell `Invoke-RestMethod` auf `https://git.mueller.black/api/v1/repos/thomas/Dual-PID/pulls[/<nr>/merge]`, Token aus `C:\Users\Thomas\AppData\Local\tea\config.yml`, nur in Variable, nie ausgeben), da die `tea`-CLI gegen `git.mueller.black` oft hängt und nie zurückkehrt. `tea pr create`/`tea pr merge` nur als Ausweichweg. PRs dürfen selbstständig gemergt werden (Auto-Merge, kein grünes CI erforderlich); danach den Merge kurz melden.
- Kein Force-Push, kein History-Rewrite auf geteilten Branches.
- Commit-Identitaet bleibt `raw-designs` / `Thomas@raw-designs.de` (globale Git-Config, nicht aendern).
- Commit-Messages im Conventional-Commits-Format (feat/fix/docs/refactor/...).
@@ -1,4 +1,4 @@
# JC4880P443C-I-W Touch-Display — UART-Protokoll & Architektur
# P4-Touch-Display — UART-Protokoll & Architektur
Status: Entwurf v1.0 der Doku · Firmware-Protokollversion: **1** (vorhanden, abgeschaltet) ·
Ziel-Protokollversion: **2** (geplante Erweiterungen)
@@ -16,11 +16,11 @@ Bewusste Designentscheidung (siehe Projektbesprechung):
- Das **Webinterface bleibt auf der Hauptplatine** (ESP32-S3). Es bleibt unverändert
die zentrale Steuerungs- und Konnektivitätsinstanz.
- Das **JC-Display ist ein vollwertiges Touch-Bediengerät**, das über UART angebunden
- Das **P4-Display ist ein vollwertiges Touch-Bediengerät**, das über UART angebunden
ist und denselben Funktionsumfang bietet wie das Webinterface — aber **kein** eigenes
WLAN/Webserver betreibt.
- Das **OLED (SH1106G) bleibt optional** und wird wie bisher über ein **Compile-Flag**
gewählt (`ENABLE_DISPLAY`). Es ist unabhängig vom JC-Display.
gewählt (`ENABLE_DISPLAY`). Es ist unabhängig vom P4-Display.
```
+----------------------------+ UART (GPIO43/44) +---------------------------+
@@ -34,13 +34,13 @@ Bewusste Designentscheidung (siehe Projektbesprechung):
| - OLED (optional) | | ST7701 / GT911 / ES8311 |
+----------------------------+ +---------------------------+
* Der ESP32-C6 auf dem JC-Display (WLAN/BT) wird in diesem Projekt NICHT für die
* Der ESP32-C6 auf dem P4-Display (WLAN/BT) wird in diesem Projekt NICHT für die
Maschinensteuerung benötigt. WLAN/Webinterface laufen weiterhin auf der S3.
```
### Rollenverteilung
| Aufgabe | S3 (Hauptplatine) | P4 (JC-Display) |
| Aufgabe | S3 (Hauptplatine) | P4 (P4-Display) |
|---|---|---|
| Echtzeit-Regelung (PID, SSR, Sicherheit) | **ja** | nein |
| Sensoren (NTC, MAX6675, Waage) | **ja** | nein |
@@ -76,7 +76,7 @@ schickt Bedienwünsche als Kommandos. So bleiben Web-UI, OLED und Touch-Display
```
> **Hinweis (bewusst akzeptiert):** GPIO43/44 sind beim ESP32-S3 zugleich die Standard-
> Pins der seriellen Debug-Konsole (UART0). Solange das JC-Display dort angeschlossen ist,
> Pins der seriellen Debug-Konsole (UART0). Solange das P4-Display dort angeschlossen ist,
> steht die klassische serielle Debug-Ausgabe an diesen Pins nicht parallel zur Verfügung.
> Debug/Logging erfolgt dann über USB-CDC bzw. das Webinterface. Diese Pins wurden
> ausdrücklich beibehalten, weil sie auf der Platine herausgeführt sind.
@@ -519,7 +519,7 @@ Für ein vollwertiges 480×800-Touch-UI fehlen v1 noch einige Daten/Funktionen.
## 9. OLED-Koexistenz (Compile-Flag)
- OLED bleibt über `ENABLE_DISPLAY` (Compile-Flag) wählbar — unverändert.
- Das JC-Display wird über `TOUCH_UART_ENABLED` (Compile-Flag) aktiviert.
- Das P4-Display wird über `TOUCH_UART_ENABLED` (Compile-Flag) aktiviert.
- **Geplante Änderung:** beide Flags strikt **unabhängig** halten, damit alle Kombinationen
baubar sind:
@@ -562,7 +562,7 @@ Puffergrößen/Chunking, optionaler CRC + Handshake, `action`-Stringliste dokume
**Löschen:** Nichts.
**Fully-Kiosk bleibt erhalten** (Entscheidung) — als eigenständige, optionale Funktion
neben dem JC-Display. Lastbewertung der S3:
neben dem P4-Display. Lastbewertung der S3:
- Einziger Aufruf `sendFullyKioskLoadUrl()` wird **nur bei Standby-Zustandswechsel**
getriggert (`if (standbyModeActive != lastStandbyModeActive)`), **nicht periodisch**
(wenige Male pro Tag).
@@ -586,10 +586,10 @@ neben dem JC-Display. Lastbewertung der S3:
6. **[offen, optional]** CRC + ggf. Puffer-Feinjustage (§8.3) — bewusst nicht als toter,
ungetesteter Code eingebaut; bei Bedarf später.
7. **[offen, durch dich]** `TOUCH_UART_ENABLED` auf 1 setzen + Build verifizieren, **sobald**
das JC-Display physisch an Serial1 (GPIO43/44) hängt. Bewusst noch **0**, damit die
das P4-Display physisch an Serial1 (GPIO43/44) hängt. Bewusst noch **0**, damit die
serielle Debug-Konsole (GPIO43/44) im aktuellen Betrieb erhalten bleibt.
### Phase B — P4-Seite (JC-Display, Projekt `JC_Display_Firmware/`)
### Phase B — P4-Seite (P4-Display, Projekt `P4_Display_Firmware/`)
Grundgerüst angelegt (Arduino-ESP32 P4 + LVGL 9 + ArduinoJson 7). Aufteilung:
`config.h`, `machine_state.h`, `protocol_client.*`, `ui.*`, `display_hal.*`, `.ino`, `README.md`.
@@ -603,7 +603,7 @@ Grundgerüst angelegt (Arduino-ESP32 P4 + LVGL 9 + ArduinoJson 7). Aufteilung:
(`display_hal.cpp`, Schalter `JC_USE_REAL_PANEL`): MIPI-DSI/ST7701, GT911 (I²C SDA=7/SCL=8),
Backlight GPIO23, LCD-Reset GPIO5; LVGL-Port mit eigenem Task + Lock. Stub-Modus bleibt für
Schreibtisch-Tests. Vendor-BSP-Dateien sind in den Sketch zu kopieren (siehe Projekt-README).
5. **[festgelegt]** UART-Pins am JC-Display: **P4 GPIO50 (TX) / GPIO51 (RX)** vom Expand-IO-Header
5. **[festgelegt]** UART-Pins am P4-Display: **P4 GPIO50 (TX) / GPIO51 (RX)** vom Expand-IO-Header
JP1 (Schaltplan `4_USB&IO.png`). Gegenseite S3 unverändert GPIO43/44.
6. **[offen]** Weitere Screens: Einstellungen (Brew/Service/Sensor), Profil-Auswahl/-Editor,
PID/AutoTune-Bedienung; Ausrichtung Hochformat (Rotation 0 in `pins_config.h`).
@@ -1,3 +1,159 @@
Version 1.6.15:
- Diagnose fuer das schwarze Bild, das der Log bisher nicht erklaeren konnte: Alle Schritte
liefen fehlerfrei durch, trotzdem blieb die Anzeige leer.
- Die drei Weckbefehle an das Panel (MADCTL, Sleep Out, Display On) liefen bislang
ungeprueft durch und sind jetzt in die Fehlerausgabe einbezogen.
- Neuer Schalter WS7_TEST_PATTERN in pins_config.h: zeigt statt der Oberflaeche
Prueffarbbalken an. Sie entstehen im DSI-Baustein selbst und benutzen weder Bildspeicher
noch LVGL. Damit laesst sich in einem Durchgang trennen, ob die Anzeigekette bis zum
Panel arbeitet oder ob der Fehler weiter oben liegt.
- Das Ende des Hochlaufs wird gemeldet ("Bringup fertig" / "LVGL laeuft"). Bisher endete
die Ausgabe nach dem Panel-Start, und ein Haengenbleiben in LVGL war von einem
fehlenden Bild nicht zu unterscheiden.
Version 1.6.14:
- Der Touch-Controller wird jetzt erst angesprochen, nachdem die Bridge freigegeben und die
Hintergrundbeleuchtung eingeschaltet ist. Der GT9271 haengt an derselben Versorgung und
antwortet vorher nicht auf I2C - deshalb schlug seine Initialisierung bisher schon beim
Kaltstart fehl. In der Werks-Testskizze steht die Touch-Initialisierung aus demselben
Grund hinter dem Einschalten der Beleuchtung; beim Uebertragen in die Firmware war diese
Reihenfolge verloren gegangen.
- Die Wartezeit dazwischen steht als WS7_TOUCH_POWER_MS in pins_config.h (Vorgabe 120 ms).
- Neu im Start-Log: eine Liste aller Bausteine am I2C-Bus, einmal vor und einmal nach dem
Panel-Start. Erwartet werden 0x45 (Bridge) und 0x14 (Touch). Damit ist auf einen Blick zu
sehen, ob ein Baustein gar nicht antwortet, statt aus Treiberfehlern raten zu muessen.
Version 1.6.13:
- Ursache des schwarzen Bildes gefunden: ein haengender I2C-Bus. Trifft ein Reset des P4
mitten in eine laufende Uebertragung, bleibt der angesprochene Baustein in seiner
Bitausgabe stehen und haelt die Datenleitung dauerhaft auf Masse. Damit schlaegt jede
weitere Uebertragung fehl. Bridge und Touch-Controller haengen an Dauerstrom, weshalb
dieser Zustand jeden Reset und sogar das Flashen ueberlebt - nur echtes Stromabziehen
loest ihn. Die Folge: Die Bridge wird nie initialisiert, das Bild bleibt schwarz, und
weil sie ihre Register behaelt, brennt die Hintergrundbeleuchtung weiter.
- Vor dem Anlegen des I2C-Busses wird die Taktleitung jetzt von Hand getaktet, bis der
Baustein die Datenleitung freigibt, danach folgt eine Stopp-Bedingung. Das ist der in
der I2C-Spezifikation vorgesehene Weg und laeuft bei freiem Bus wirkungslos durch.
- Fehlerbehebung: Schreibzugriffe auf die Bridge liefen stillschweigend ins Leere. Genau
deshalb war der Fehler so schwer zu finden - das Bild blieb ohne jeden Hinweis schwarz.
Sie melden Fehler jetzt im Klartext.
- Fehlerbehebung: In pins_config.h stand seit 1.6.10 "#elsealle" statt "#else". Der
Tippfehler traf nur den Zweig des 4,3-Zoll-Panels, das damit nicht mehr uebersetzbar war.
Beide Panel-Varianten sind jetzt wieder gegengebaut.
Version 1.6.12:
- Die Abschaltfolge für die Bridge aus 1.6.11 ist zurückgenommen. Sie hat den Fehler nicht
behoben, sondern verschlimmert: Nach dem Nullsetzen von C0/C2/AC kam das Panel auch
direkt nach dem Flashen nicht mehr hoch, die normale Einschaltfolge holt es aus diesem
Zustand nicht zurück. Der Start entspricht damit wieder 1.6.10.
- Stattdessen zwei Diagnosen, um die Ursache des schwarzen Bildes nach einem Reset
einzugrenzen: Der Startgrund wird beim Hochlauf ausgegeben (1 = Kaltstart, alles andere
Warmstart), und das Anfordern der Stromversorgung für die MIPI-Strecke wird jetzt auf
Fehler geprüft - bislang lief dieser Schritt als einziger ungeprüft durch.
Version 1.6.10:
- WS7_PARTIAL_REFRESH ist jetzt auch im Auslieferungsstand 1. Am Gerät geprüft: kein
Flackern, und der Gewinn ist der größte der drei Tempo-Maßnahmen - vor allem während
eines Bezugs, wo die Zeitanzeige zehnmal je Sekunde weiterläuft.
- Der Hintergrund der Seiten ist deckend statt durchsichtig. Sichtbar ändert sich nichts,
die Ebenen darunter haben dieselbe Farbe; LVGL muss sie beim Scrollen aber nicht mehr
mitzeichnen und durchmischen.
- Neuer Schalter WS7_PERF_MONITOR in pins_config.h: blendet unten rechts Bilder je Sekunde
und Prozessorlast ein. Damit lässt sich beantworten, ob weitere Mühe beim Zeichnen
überhaupt noch etwas bringt, statt ins Blaue zu optimieren.
Version 1.6.9:
- Fehlerbehebung: Ein Tipp auf einen Knopf löste oft mehrfach aus. Der GT9271 lässt
gelegentlich einen Messzyklus aus oder liefert ein unplausibles Paket; der
Hersteller-Treiber kann "gerade nichts Neues" nicht von "Finger weg" unterscheiden und
meldet beides als losgelassen. Seit die Oberfläche mit 1.6.8 doppelt so oft abtastet,
wurde daraus sichtbar Drücken-Loslassen-Drücken-Loslassen.
- Vor den Treiber ist deshalb ein Filter gesetzt: Er verwirft unplausible Rohwerte und hält
den letzten gültigen Berührpunkt noch WS7_TOUCH_HOLD_MS lang (Vorgabe 40 ms). Losgelassen
wird erst gemeldet, wenn wirklich nichts mehr kommt. Der Wert steht in pins_config.h;
0 schaltet die Überbrückung ab. Zu groß gewählt verzögert er das Loslassen und dämpft
den Schwung beim Wischen.
- Der Filter hängt sich zur Laufzeit in den Treiber ein, die Herstellerdateien bleiben
unverändert.
Version 1.6.8:
- Scrollen und Wischen laufen am Waveshare-Panel flüssiger: LVGL rechnet dort jetzt im
16-Millisekunden-Takt statt alle 33 ms. Dieser Wert steuert nicht nur die Bildrate,
sondern auch, wie oft der Touch abgetastet und wie fein eine Animation gerechnet wird -
mit 30 Schritten je Sekunde war vor allem das Ziehen mit dem Finger sichtbar ruckelig.
Das Panel läuft mit 60 Hz, mehr als 16 ms bringt also nichts.
- Kommt das Zeichnen einmal nicht hinterher, wird ein Bild später fertig; kaputt geht
dabei nichts. Die JC-Panels bleiben bei 33 ms.
Version 1.6.7:
- Der Menue-Knopf oben links fängt Tipps jetzt auch knapp daneben ab. Mit 48x36 Pixeln war
er auf dem 7-Zoll-Panel ein sehr kleines Ziel; gemessen wurde ein Fehlgriff von rund
10 Pixeln neben der Fläche, weshalb sich das Menü scheinbar nicht öffnen ließ. Optisch
bleibt der Knopf unverändert, die Trefferfläche wächst um 20 Pixel nach allen Seiten.
Sie wirkt nur innerhalb der Kopfleiste - dem Seiteninhalt darunter wird nichts genommen.
- Die Touch-Zuordnung selbst war korrekt: Eine Messung mit WS7_TOUCH_DEBUG hat gezeigt,
dass Achsen und Spiegelung stimmen.
Version 1.6.6:
- Neuer Schalter WS7_TOUCH_DEBUG in pins_config.h: Auf 1 gesetzt, gibt jeder Berührpunkt
seine Rohwerte und die daraus errechnete Bildposition auf der seriellen Konsole aus.
Gedacht zum Einmessen des Touch, wenn Bedienelemente nicht reagieren - insbesondere am
oberen Bildrand, wo die 44 Pixel hohe Kopfleiste sitzt.
Version 1.6.5:
- Zwei der drei Tempo-Maßnahmen aus 1.6.4 haben sich am Gerät als untauglich erwiesen und
stehen wieder auf ihrem alten Wert. Sie bleiben als Schalter erhalten, mit Notiz, woran
sie gescheitert sind.
* WS7_COLOR_BITS wieder 24: Die Bridge dieses Panels nimmt kein RGB565 an, mit 16 Bit
kommt kein brauchbares Bild.
* WS7_PARTIAL_REFRESH wieder 0: Der Menü-Vorhang ließ sich nicht mehr öffnen. Er ist
halbtransparent und wird deshalb in den gerade aktiven Bildpuffer eingemischt; die
nächste Zustandsmeldung der S3 zeichnet aber in den zweiten Puffer, der ihn nie
bekommen hat - der Vorhang war also sofort wieder weg. Nutzbar wäre der Modus erst,
wenn der LVGL-Port die geänderten Bereiche zwischen beiden Puffern abgleicht.
- WS7_PARALLEL_RENDER bleibt eingeschaltet: LVGL zeichnet weiterhin mit zwei Threads auf
beiden Prozessorkernen. Von den drei Maßnahmen trägt nur diese.
Version 1.6.4:
- Waveshare 7" (H): Drei Maßnahmen gegen die träge Bedienung am großen Panel. 1280x720
sind 2,4-mal so viele Pixel wie beim 4,3-Zöller, und bis 1.6.3 wurde bei jeder Änderung
das komplette Bild in 24 Bit neu gezeichnet.
* Farbtiefe RGB565 statt RGB888 (WS7_COLOR_BITS): halbiert die Datenmenge je Bild.
Feinere Farbabstufungen entfallen, sichtbar allenfalls in den dunklen Verläufen der
Rundanzeige - die JC-Panels laufen seit jeher so.
* Nur geänderte Bildbereiche neu zeichnen statt des ganzen Bildes
(WS7_PARTIAL_REFRESH, LVGL-Direct-Mode mit zwei Puffern). Eine sich ändernde
Temperaturanzeige kostet damit ein paar tausend statt 921.600 Pixel.
* LVGL zeichnet mit zwei Threads auf beiden Prozessorkernen (WS7_PARALLEL_RENDER).
- Jeder der drei Schalter steht in pins_config.h und lässt sich einzeln zurückstellen;
die README nennt zu jedem, woran man erkennt, dass er zurück muss. Die JC-Panels sind
von allen dreien nicht betroffen.
- Nebeneffekt: Der Framebuffer-Bedarf sinkt von rund 8,3 MB auf 3,7 MB PSRAM.
Version 1.6.3:
- Waveshare ESP32-P4-Pico: UART zur Hauptplatine liegt jetzt auf TX = GPIO20 und
RX = GPIO21 (vorher GPIO17/GPIO18). Die JC-Panels bleiben bei GPIO33/GPIO31.
- Das Bild steht in der tatsächlichen Einbaulage richtig herum, die 180-Grad-Drehung aus
1.6.1 ist deshalb wieder abgeschaltet (WS7_ROTATE_180 = 0). Sie bleibt als Schalter
erhalten, falls das Panel später anders montiert wird.
- Der Touch war dagegen oben/unten spiegelverkehrt: Der Digitizer sitzt gegenüber dem Bild
um die Hochachse gedreht. WS7_TOUCH_MIRROR_RAW_X steht dafür jetzt auf 1. Bild- und
Touch-Ausrichtung sind damit zwei getrennte Schalter, weil sie an diesem Panel eben
nicht zusammenfallen.
Version 1.6.2:
- Kommt das Panel nicht hoch, stürzt der P4 nicht mehr wortlos ab. Die Bringup-Schritte
melden ihren Fehler jetzt im Klartext auf der seriellen Konsole (auch bei abgeschaltetem
Core-Debug-Level), zusammen mit PSRAM-Größe, freiem PSRAM und dem tatsächlich benötigten
Framebuffer-Bedarf. Vorher endete ein fehlgeschlagener Panel-Aufbau in einem
Speicherauszug, aus dem die Ursache nicht hervorging.
- Schlägt der Panel-Aufbau fehl, läuft die Firmware ohne Anzeige weiter, statt ein zweites
Mal abzustürzen: UART-Verbindung und OTA bleiben offen, die S3 kann also neu flashen.
Alle Oberflächenfunktionen prüfen dafür, ob das Dashboard überhaupt aufgebaut wurde.
- Fehlerbehebung: Findet der Touch-Controller nicht statt, lieferte der Hersteller-Treiber
einen bereits freigegebenen Zeiger zurück, der ungeprüft weiterverwendet wurde. Das
Display läuft in diesem Fall jetzt einfach ohne Bedienung weiter.
Version 1.6.1:
- Waveshare 7" (H): Bild und Touch lassen sich um 180 Grad drehen, wenn das Panel auf dem
Kopf eingebaut ist. Schalter WS7_ROTATE_180 in pins_config.h, Vorgabe ist gedreht.

Some files were not shown because too many files have changed in this diff Show More