Compare commits
4
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
ee74c700bf | ||
|
|
750a6fb78c | ||
|
|
80b6eb810f | ||
|
|
6a9048411e |
@@ -1,3 +1,28 @@
|
||||
Version 1.6.18:
|
||||
- Ursache des unzuverlässigen Starts gefunden: Der P4 sprach Bridge und Panel sofort nach
|
||||
dem Einschalten an. Das Displaymodul braucht danach aber einen Moment, bis es bereit ist.
|
||||
Kam der Hochlauf zu früh, nahm die Bridge ihre Register nicht an oder das Panel zeigte
|
||||
trotz korrekt gesendeter DSI-Daten nichts - beides ohne Fehlermeldung, weil aus Sicht des
|
||||
P4 jeder Schritt geklappt hatte. Das Ergebnis war ein Display, das mal ansprang und mal
|
||||
nicht, und beim ersten Anstecken meist gar nicht.
|
||||
- Der Hochlauf wartet jetzt WS7_PANEL_WARMUP_MS (Vorgabe 2000 ms), bevor er beginnt. Der
|
||||
Werks-Testsketch wartet aus demselben Grund 2 Sekunden am Anfang.
|
||||
- Damit erklärt sich auch, warum es mit geöffnetem seriellen Monitor fast immer klappte:
|
||||
Dessen USB-Anmeldung verzögert den Start und ersetzte damit unbeabsichtigt die Wartezeit.
|
||||
- Der Wert steht in pins_config.h. Läuft der Start zuverlässig, lässt er sich vorsichtig
|
||||
senken; springt die Anzeige nicht an, ist er der erste Wert zum Erhöhen.
|
||||
|
||||
Version 1.6.17:
|
||||
- Der I2C-Stoerimpulsfilter aus 1.6.16 wirkt: Nach dem Panel-Start melden sich wieder alle
|
||||
drei Bausteine, Bridge und Touch bleiben ansprechbar.
|
||||
- Das Pruefbild aus 1.6.15 war allerdings wirkungslos und damit als Test untauglich: Es
|
||||
wurde zwar gesetzt, doch unmittelbar danach startete LVGL und schrieb in den Bildspeicher,
|
||||
womit das Pruefbild wieder verschwand. Der Test sah deshalb genauso aus wie der Fehler,
|
||||
den er finden sollte.
|
||||
- Mit WS7_TEST_PATTERN = 1 endet der Hochlauf jetzt direkt nach dem Pruefbild: Beleuchtung
|
||||
an, Farbbalken stehen, kein LVGL. Damit ist die Frage eindeutig zu beantworten, ob die
|
||||
Anzeigekette bis zum Panel arbeitet.
|
||||
|
||||
Version 1.6.16:
|
||||
- Ursache des schwarzen Bildes gefunden. Der Start-Log zeigte es eindeutig: Vor dem
|
||||
Panel-Start meldeten sich alle drei I2C-Bausteine (Touch 0x14, Audio 0x18, Bridge 0x45),
|
||||
|
||||
@@ -388,6 +388,20 @@ static void jc_touch_scale(esp_lcd_touch_handle_t tp, uint16_t *x, uint16_t *y,
|
||||
// benutzen, sonst folgt ein zweiter Absturz, der die eigentliche Ursache ueberdeckt.
|
||||
bool jc_board_bringup(void)
|
||||
{
|
||||
#if JC_PANEL_TYPE == WS_PANEL_7H
|
||||
// Anlaufzeit abwarten, BEVOR Bridge und Panel angesprochen werden.
|
||||
//
|
||||
// Das Displaymodul braucht nach dem Anlegen der Versorgung einen Moment, bis Bridge
|
||||
// und Panel bereit sind. Faengt der P4 sofort an, laeuft der Hochlauf ins Leere: Die
|
||||
// Bridge nimmt ihre Register nicht an oder das Panel zeigt trotz korrekt gesendeter
|
||||
// DSI-Daten nichts - beides ohne Fehlermeldung, weil aus Sicht des P4 alles geklappt
|
||||
// hat. Das Ergebnis war ein Display, das mal ansprang und mal nicht.
|
||||
//
|
||||
// Der Werks-Testsketch wartet aus demselben Grund 2 Sekunden am Anfang von setup().
|
||||
// Dass es mit geoeffnetem seriellen Monitor fast immer klappte, hatte dieselbe
|
||||
// Ursache: Dessen USB-Anmeldung verzoegert den Start und ersetzte damit die Wartezeit.
|
||||
vTaskDelay(pdMS_TO_TICKS(WS7_PANEL_WARMUP_MS));
|
||||
#endif
|
||||
jc_backlight_init();
|
||||
|
||||
#if JC_PANEL_TYPE == WS_PANEL_7H
|
||||
@@ -505,14 +519,23 @@ bool jc_board_bringup(void)
|
||||
BSP_STEP(esp_lcd_panel_init(disp_panel), "DPI-Videoausgabe starten");
|
||||
#if WS7_TEST_PATTERN
|
||||
// Prueffarbbalken: Sie entstehen im DSI-Baustein selbst und benutzen weder den
|
||||
// Bildspeicher noch LVGL. Erscheinen sie, arbeitet die gesamte Anzeigekette bis zum
|
||||
// Panel korrekt und der Fehler liegt weiter oben (Bildspeicher, LVGL, Oberflaeche).
|
||||
// Bleibt das Bild schwarz, liegt es an DSI, Zeitbasis oder Panel.
|
||||
// Bildspeicher noch LVGL. Erscheinen sie, arbeitet die Anzeigekette bis zum Panel und
|
||||
// der Fehler liegt weiter oben. Bleibt es schwarz, liegt es an DSI, Zeitbasis oder
|
||||
// Panel.
|
||||
//
|
||||
// Der Hochlauf endet hier bewusst: Wuerde LVGL danach starten, schriebe es sofort in
|
||||
// den Bildspeicher und das Pruefbild waere wieder weg - der Test saehe dann genauso
|
||||
// aus wie der Fehler, den er finden soll.
|
||||
jc_backlight_set(100); // Beleuchtung an, sonst ist nichts zu sehen
|
||||
BSP_STEP(esp_lcd_dpi_panel_set_pattern(disp_panel, MIPI_DSI_PATTERN_BAR_VERTICAL),
|
||||
"Prueffarbbalken");
|
||||
esp_rom_printf("[Panel] Pruefbild aktiv - erwartet werden senkrechte Farbbalken.\n");
|
||||
esp_rom_printf("[Panel] Pruefbild steht - erwartet werden senkrechte Farbbalken.\n");
|
||||
esp_rom_printf("[Panel] Hochlauf endet hier (WS7_TEST_PATTERN = 1, keine Oberflaeche).\n");
|
||||
return false; // ohne LVGL: Anzeige bleibt beim Pruefbild
|
||||
#endif
|
||||
|
||||
|
||||
|
||||
#elif JC_PANEL_TYPE == JC_PANEL_70
|
||||
// ---------------- 7,0" JD9165 (1024x600) ----------------
|
||||
esp_lcd_dsi_bus_config_t bus_config = JD9165_PANEL_BUS_DSI_2CH_CONFIG();
|
||||
|
||||
@@ -148,6 +148,12 @@
|
||||
// Prueffarbbalken statt Oberflaeche anzeigen. Sie entstehen im DSI-Baustein selbst und
|
||||
// benutzen weder Bildspeicher noch LVGL. Damit laesst sich trennen, ob die Anzeigekette
|
||||
// bis zum Panel arbeitet (Balken sichtbar) oder nicht (schwarz). Nur zur Fehlersuche.
|
||||
// Anlaufzeit des Displaymoduls, bevor Bridge und Panel angesprochen werden. Ohne diese
|
||||
// Pause startet die Anzeige nur zufaellig - der Werks-Testsketch wartet aus demselben
|
||||
// Grund 2 Sekunden. Springt das Display beim Einschalten nicht zuverlaessig an, ist das
|
||||
// der erste Wert zum Erhoehen; laeuft es sicher, kann er vorsichtig gesenkt werden.
|
||||
#define WS7_PANEL_WARMUP_MS 2000
|
||||
|
||||
#define WS7_TEST_PATTERN 0
|
||||
|
||||
#elif JC_PANEL_TYPE == JC_PANEL_70
|
||||
|
||||
Reference in New Issue
Block a user