LilyGO T-Display-SF32¶

Was ist T-Display-SF32?¶

Xinyuan-LilyGO/T-Display-SF32 ist eine Entwicklungsplattform mit SF32LB52x-MCU und einem 2,16-Zoll-AMOLED-Display CO5300 mit Touchcontroller CST9220. Das Repository dokumentiert 16 MB Flash, 8 MB PSRAM, eine BHI260AP-IMU, LoRa mit SX1262, eine microSD-Schnittstelle, Audio, USB Type-C, Ladeunterstützung, Board-Pinbelegungen, Beispielanwendungen, Hardwaredateien, ein Verzeichnis mit Werksfirmware und einen boardspezifischen Stromverbrauchsbericht.

Damit eignet sich das Board zur Bewertung eines displayorientierten Wearables, eines Handheld-Controllers, eines mobilen Sensorterminals oder einer vernetzten HMI. Es ist eine Plattformreferenz, kein fertiges Produkt: Das Repository stellt zahlreiche Hardwarepfade bereit, doch das Produktteam muss die relevanten Pfade auswählen, eine bekannte Basis reproduzieren, sie auf genau seiner Board-Revision messen und Stromversorgung, RF, Sicherheit, Softwarepflege und Wiederherstellung qualifizieren.

Die Funktionsmatrix des Repositorys unterscheidet das eigenständige T-SF32-Display-Board von der optionalen T-SF32-Keyboard-Erweiterung. WLAN (ESP32-C6), GPS (L76K), Matrix-Tastatur und LEDs (TCA8418, AW21009, XL9555), BME280, Infrarotsender und Vibrationsmotor (AW86224) setzen diese Erweiterung voraus und gehören nicht zur Ausgangsbasis des eigenständigen Boards.

Warum eine Umsetzung auf SF32-Basis?¶

T-Display-SF32 vereint Grafik-, Bluetooth-, Audio- und Energiesparfunktionen des SF32LB52x mit externen Display-, Touch-, Bewegungs-, Speicher- und LoRa-Bausteinen auf einem Board. LilyGO stellt außerdem Board-Konfiguration, dedizierte Gerätetreiber, Beispiele und einen separaten LilyGO-SDK-Fork bereit, der laut Dokumentation auf SiFli-SDK 2.4.0 basiert. Das kann die anfängliche Inbetriebnahme gegenüber einem unveränderten generischen SDK-Ziel verkürzen.

Der Preis dafür liegt in der Zuständigkeit. Board-Unterstützung, Treiberänderungen, Hardware-Revisionen, mitgelieferte Firmware und das Verhältnis zwischen LilyGOs SDK-Fork und dem SiFli-SDK-Upstream werden außerhalb von SiFli kontrolliert. Ein reproduzierbares Projekt muss daher beide Repositories auf Commits fixieren, ein funktionsfähiges Werks- bzw. Wiederherstellungsimage aufbewahren und jede Migration auf ein neueres Upstream-SDK als ausdrückliche technische Änderung testen.

Ergebnis, Umfang und Eintrittskriterien¶

Ergebnis: eine versionsfixierte T-Display-SF32-Basis herstellen, Display/Touch, ausgewählte Peripherie, Stromverhalten und Wiederherstellung prüfen, einen Build aus dem Quellcode reproduzieren und anschließend eine klar begrenzte Anwendungsänderung mit Regressionsnachweisen umsetzen, die sich für eine Produktbewertung eignen.

Diese Seite belegt weder, dass jede Peripherie auf jeder Board-Variante bestückt ist, noch dass die Herstellerfirmware serienreif ist, noch dass der Stromverbrauchsbericht für andere Revisionen oder Arbeitslasten gilt, noch dass LoRa-Betrieb in jeder Region zulässig ist. Sie überträgt auch keine SiFli-Unterstützung auf LilyGO-spezifische Hardware oder Treiber.

Vor dem Start benötigen Sie:

• das konkrete T-Display-SF32-Board samt Hardware-Revision und Schaltplan oder Pinbelegung;
• ein strombegrenztes Labornetzteil oder einen geschützten Akku, dessen Spannung und Zustand überwacht werden können;
• ein geprüftes USB-Datenkabel, die dokumentierte Type-C-Flashverbindung und ein aufbewahrtes Recovery-Image;
• fixierte Commits des T-Display-SF32-Repositories und des LilyGO-SDK-Forks;
• die vom LilyGO-SDK-Fork dokumentierte Windows-/PowerShell-Umgebung für den ersten reproduzierbaren Build; andere Hostumgebungen müssen separat qualifiziert werden;
• Testzubehör nur für relevante Schnittstellen, zum Beispiel eine microSD-Karte, Kopfhörer oder eine Audiolast sowie einen LoRa-Gegenpart für ein zulässiges Frequenzband;
• eine Dokumentation von Firmwareversionen, Build-Protokollen, serieller Ausgabe, Fotos, Strommessungen sowie Fehler- und Wiederherstellungstests.

Hardware- und Software-Spezifikationen¶

Hardware-Spezifikation¶

Software-Spezifikation¶

Unterstützte Referenzkonfiguration auswählen¶

Das Upstream-Repository verwendet derzeit den Branch master und weist kein getaggtes Release als allgemeingültige Softwarebasis aus. Dokumentieren Sie den genauen Commit, statt „latest“ zu notieren. Das Repository enthält das Verzeichnis firmware/T-SF32-Factory-V1.2; dessen Name ersetzt jedoch nicht die Dokumentation der passenden Board-Revision, des Repository-Commits und des Flash-Verfahrens.

Die T-Display-SF32-README beschreibt nach Einrichtung der erforderlichen Umgebung folgenden Build- und Flashablauf unter Windows:

cd T-Display-SF32\examples\rt_os\rt_driver\project
scons --board=t-display-sf32_hcpu -j8
build_t-display-sf32_hcpu\uart_download.bat

Dokumentieren Sie die tatsächlichen Repository- und SDK-Commits, das Ergebnis des Umgebungsexports, das vollständige Build-Protokoll, erzeugte Images sowie Flash- und Bootprotokoll. Die Zahl paralleler Jobs darf variieren, Buildziel und Quellrevisionen nicht.

Projektphasen und Entscheidungspunkte¶

Systemarchitektur und Abhängigkeiten¶

flowchart LR
    U["Nutzer\nTouch und Tasten"] --> F["T-Display-SF32-Firmware\nSF32LB52x + RT-Thread"]
    F --> D["CO5300-AMOLED\nTouch CST9220"]
    F --> P["Bestückte Peripherie\nIMU, microSD, Audio, LoRa"]
    B["Akku / USB Type-C\nLadegerät und Stromschienen"] --> F
    H["Build- und Flashwerkzeuge des Entwicklungsrechners"] -->|"UART-Flashen und Protokolle"| F
    R["LilyGO-Board-Repository"] --> H
    S["LilyGO-SDK-Fork\nauf Basis des SiFli-SDK"] --> H
    O["SiFli-Geräte- und SDK-Quellen"] -. "Referenz der Plattformbasis" .-> S

Betrachten Sie Fehler als getrennte Bereiche: Stromversorgung/Laden des Boards, Start und Flashen, Display/Touch, jede ausgewählte Peripherie, LilyGO-Board-Unterstützung und das zugrunde liegende SDK. Ein fehlgeschlagenes Displaybeispiel kann etwa auf Stromversorgung, Board-Revision, Panel-/Touchkonfiguration, Anwendung oder eine Unvereinbarkeit von SDK und Treiber zurückgehen. „Das SDK ist fehlgeschlagen“ ist keine ausreichende Diagnose.

Phase 1 — Die unveränderte Herstellerbasis einrichten¶

Ziel: vor jeder Quellcodeänderung nachweisen, wie sich das gelieferte Board und die Herstellerbasis tatsächlich verhalten.

1. Fotografieren Sie beide Platinenseiten und dokumentieren Sie Kennzeichnungen, bestückte Peripherie, Display-/Touchbauteile, Speicher, Schalter, Anschlüsse und Repository-Commit.
2. Prüfen Sie Stromquelle und Polarität. LilyGO weist darauf hin, dass zum Start mehr als 3,5 V erforderlich sind. Verwenden Sie eine überwachte Stromquelle und keinen tiefentladenen Akku als Testmethode.
3. Flashen Sie nur eine nachweislich zum Board passende Basis oder führen Sie zunächst die vorhandene Firmware aus, sofern ihre Herkunft bekannt ist. Sichern Sie das Originalimage nach Möglichkeit.
4. Testen Sie das Menü auf dem Gerät oder unveränderte Beispiele für Display/Touch und jede für das Produkt ausgewählte Peripherie. Dokumentieren Sie nicht verfügbare oder nicht bestückte Funktionen, statt sie als Fehler zu werten.
5. Starten Sie zweimal kalt und sichern Sie Bootprotokolle, UI-Fotos, Touch-/Eingabeergebnisse sowie einen Stromverlauf für eine klar definierte Leerlauf-/Aktivitätslast.

Aufzubewahrende Nachweise: Board-Revision und Fotos, Repository-/Image-Identität, Angaben zu Versorgung und Akku, Flash- und Bootprotokolle, Inventar der bestückten Bauteile, Funktionsergebnisse und Bedingungen der Strommessung.

Abnahmekriterium für Kontrollpunkt 1: Zwei Kaltstarts reproduzieren die identifizierte Display-/Touch-Basis. Für jede relevante bestückte Peripherie liegt ein Ergebnis vor, und das Original- oder ein bekannt gutes Image lässt sich wiederherstellen.

Phase 2 — Peripherie-, Strom- und Wiederherstellungsgrenzen validieren¶

Ziel: feststellen, ob Fehler ohne unsicheren Akkubetrieb oder undokumentiertes erneutes Flashen erkannt und behoben werden können.

Abnahmekriterium für Kontrollpunkt 2: Jeder relevante Test hat ein reproduzierbares Ergebnis und einen Wiederherstellungsweg. Für jede eigene Firmware ist ein Schutz bei niedrigem Akkustand implementiert; kein ungelöster Fehler kann den Akku beschädigen oder das Board ohne dokumentierten Recovery-Pfad unbrauchbar machen.

Phase 3 — Eine reproduzierbare Quellbasis erstellen¶

Ziel: einem zweiten Entwickler ermöglichen, dieselbe Basis aus sauberen, versionsfixierten Quellen zu bauen und zu flashen.

1. Checken Sie fixierte Commits des Board-Repositories und des LilyGO-SDK-Forks aus und dokumentieren Sie die angegebene Upstream-SDK-Basis des Forks.
2. Richten Sie die dokumentierte PowerShell-Umgebung ein und bauen Sie t-display-sf32_hcpu aus einem sauberen Verzeichnis.
3. Sichern Sie Nachweise zu Umgebung, Abhängigkeiten, Konfiguration, Speicher/Partitionen, Image, Flashvorgang und seriellen Protokollen.
4. Wiederholen Sie den Vorgang auf einem anderen Rechner oder nach Löschen sämtlicher Build-Ausgaben und führen Sie anschließend die vollständige Regression aus Phase 2 durch.

Abnahmekriterium für Kontrollpunkt 3: Um eine Firmware zu erzeugen, die Phase 2 besteht, sind weder veraltete Images noch nicht versionierte Board-Dateien noch undokumentierte SDK-Ersetzungen erforderlich.

Phase 4 — Jeweils einen Produktpfad anpassen¶

Ziel: eine nützliche Änderung umsetzen und dabei die funktionierende Hersteller- und Wiederherstellungsbasis erhalten.

Abnahmekriterium für Kontrollpunkt 4: Die Änderung ist geprüft, das Originalimage wiederherstellbar und alle relevanten Tests für Display, Touch, Peripherie, Stromversorgung, Flashen und Wiederherstellung sind bestanden.

Phase 5 — Produktreife-Überprüfung¶

Vor einem Feldversuch oder einer eigenen Leiterplatte sind folgende Fragen zu beantworten:

• Wer verantwortet Board-Dateien, LilyGO-SDK-Fork, Treiberkorrekturen, Sicherheitsupdates und die Migration auf spätere SiFli-SDK-Versionen?
• Welche Board-Revisionen und bestückten Peripheriebausteine gehören zur Produktbasis, und wie werden eingehende Geräte identifiziert und geprüft?
• Wie hoch sind die gemessenen Ströme im Aktiv-, Leerlauf-, Schlaf-, Start- und Abschaltzustand bei vorgesehener Displayhelligkeit, Funk-Tastverhältnis, Speicher- und Sensorkonfiguration?
• Wie werden Akkuschutz, Laden, Temperaturverhalten, Gehäuse, Anschlusszugang und Wiederherstellung im ausgeschalteten Zustand verifiziert?
• Welche LoRa-Region, Antenne, Frequenzplanung, Sendeparameter und regulatorischen Pflichten gelten?
• Sind Hardwaredateien, Firmware, SDK-Fork, Beispiele, Assets und Drittanbieterkomponenten mit den Lizenzen für die geplante Verteilung vereinbar?
• Akzeptiert das Team die Abhängigkeit von einem Drittanbieterprototyp, oder hat es einen kontrollierten Fork und Supportplan qualifiziert?

Abnahmekriterium für Kontrollpunkt 5: Für jedes Restrisiko gibt es Verantwortliche, Nachweise und eine Behandlung. Das Team hat ausdrücklich entschieden, fortzufahren, zurückzustellen oder abzubrechen.

Übergabe an das Produktdesign¶

In die nächste Entwicklungsphase gehören die genaue SF32-Variante und Speicherbausteine, Display-/Touch-Timing, bestückte Peripherie und Busse, Stromversorgungsbaum, Ladegerät und Akkurichtlinie, Antennen-/RF-Konzept, Boot-/Flashanschluss, Partitionsplan, Zugriff für Produktionstests, Zuständigkeit für den Software-Fork und der nachgewiesene Wiederherstellungsweg. Weiter geht es mit dem Integrationspfad für SF32LB52x, dem SF32LB52x Hardware-Design-Leitfaden, SiFli-SDK: Bauen, Flashen und Überwachen und Design für die Produktion.

Maßgebliche Quellen¶

• Repository Xinyuan-LilyGO/T-Display-SF32
• Chinesische README zu T-Display-SF32
• Beispiele für T-Display-SF32
• Hardwaredateien für T-Display-SF32
• Material zu Stromverbrauchstests für T-Display-SF32
• Repository Xinyuan-LilyGO/SlFli-SDK-Lilygo
• OpenSiFli/SiFli-SDK

Zuletzt aktualisiert: 2026-10-21