LilyGO T-Display-SF32¶

Qu'est-ce que T-Display-SF32 ?¶

Xinyuan-LilyGO/T-Display-SF32 est une plateforme de développement bâtie autour d'un microcontrôleur SF32LB52x, d'un écran AMOLED CO5300 de 2,16 pouces et d'un contrôleur tactile CST9220. Le dépôt documente 16 Mo de Flash, 8 Mo de PSRAM, une IMU BHI260AP, un émetteur-récepteur LoRa SX1262, une interface microSD, l'audio, l'USB Type-C, la prise en charge de la recharge, le brochage de la carte, des exemples, les fichiers matériels, un répertoire de firmware d'usine et un rapport de consommation propre à la carte.

Cette combinaison permet d'évaluer un appareil portable centré sur l'affichage, un contrôleur portatif, un terminal de capteurs portable ou une IHM connectée. Il s'agit d'une référence de plateforme, pas d'un produit fini : le dépôt expose de nombreuses voies matérielles, mais l'équipe produit doit sélectionner celles qui sont pertinentes, reproduire une configuration de référence connue et effectuer les mesures sur la révision exacte de la carte. Elle doit aussi qualifier l'alimentation, la radiofréquence, la sécurité, la maintenance logicielle et la récupération.

La matrice des fonctions du dépôt distingue la carte T-SF32-Display autonome de l'extension optionnelle T-SF32-Keyboard. Le Wi-Fi (ESP32-C6), le GPS (L76K), le clavier matriciel et ses LED (TCA8418, AW21009, XL9555), le BME280, l'émetteur infrarouge et le moteur vibratoire (AW86224) nécessitent cette extension ; ne les incluez pas dans la configuration de base de la carte autonome.

Pourquoi l'implémentation SF32 ?¶

T-Display-SF32 associe les capacités graphiques, Bluetooth, audio et basse consommation du SF32LB52x à des composants externes pour l'affichage, le tactile, la détection de mouvement, le stockage et LoRa. LilyGO fournit aussi la configuration de la carte, des pilotes dédiés, des exemples et un fork distinct du SDK LilyGO, présenté comme dérivé de SiFli-SDK 2.4.0. Celui-ci peut accélérer la première mise en service de la carte par rapport à une cible générique du SDK sans modifications.

Le compromis tient à la propriété : la prise en charge de la carte, les modifications des pilotes, les révisions matérielles, le firmware fourni et la relation entre le fork LilyGO et le SiFli-SDK maintenu en amont sont gérés en dehors de SiFli. Pour garantir la reproductibilité, fixez le commit de chaque dépôt, conservez une image d'usine ou de récupération dont le fonctionnement est vérifié, et traitez toute migration vers une version plus récente du SiFli-SDK amont comme une modification technique explicite à tester.

Résultat, portée et critères d'entrée¶

Résultat : établir une référence T-Display-SF32 aux versions fixées ; valider l'écran/le tactile, les périphériques sélectionnés, le comportement d'alimentation et la récupération ; reproduire une compilation depuis les sources ; puis apporter une modification limitée à l'application, avec des preuves de régression exploitables lors de la revue produit.

Cette page ne prouve pas que tous les périphériques sont montés sur chaque variante de carte, que le firmware du fournisseur est prêt pour la production, que le rapport de consommation s'applique à une autre révision ou charge de travail, ni que l'utilisation de LoRa est autorisée dans toutes les régions. Elle ne transfère pas non plus à SiFli le support du matériel ou des pilotes propres à LilyGO.

Avant de commencer, préparez :

• la carte T-Display-SF32 exacte, sa révision matérielle et son schéma ou brochage ;
• une alimentation de laboratoire limitée en courant ou une batterie protégée, avec surveillance possible de la tension et de l'état ;
• un câble USB de données vérifié, la connexion Type-C documentée pour le flashage et une image de récupération conservée ;
• les commits figés du dépôt T-Display-SF32 et du fork du SDK LilyGO ;
• l'environnement Windows/PowerShell décrit par le fork du SDK LilyGO pour la première compilation reproductible ; valider séparément les autres environnements hôte ;
• uniquement les accessoires correspondant aux interfaces visées, par exemple une carte microSD, un casque ou une charge audio, et un équipement LoRa distant opérant dans une bande autorisée ;
• un relevé des versions de firmware, journaux de compilation et de sortie série, photos, mesures de courant et résultats des essais de panne et de récupération.

Spécifications matérielles et logicielles¶

Spécification matérielle¶

Spécification logicielle¶

Choisir une configuration de référence prise en charge¶

Le dépôt maintenu en amont utilise actuellement la branche master et ne désigne aucun tag comme référence logicielle universelle. Notez le commit exact au lieu d'indiquer « latest ». Le dépôt contient un répertoire firmware/T-SF32-Factory-V1.2, mais son nom ne remplace pas l'enregistrement de la révision de carte correspondante, du commit du dépôt et de la procédure de flashage.

Après configuration de l'environnement requis, le README de T-Display-SF32 documente ce parcours de compilation et de flashage sous 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

Conservez les commits réels des dépôts et du SDK, le résultat d'export de l'environnement, le journal complet de compilation, les images générées ainsi que les journaux de flashage et de démarrage. Le nombre de tâches parallèles peut varier, mais pas la cible ni les révisions des sources.

Étapes du projet¶

Architecture système et dépendances¶

flowchart LR
    U["Utilisateur\ntactile et boutons"] --> F["Firmware T-Display-SF32\nSF32LB52x + RT-Thread"]
    F --> D["AMOLED CO5300\ntactile CST9220"]
    F --> P["Périphériques montés\nIMU, microSD, audio, LoRa"]
    B["Batterie / USB Type-C\nchargeur et rails d'alimentation"] --> F
    H["Outils de compilation et de flashage de l'hôte"] -->|"Flashage UART et journaux"| F
    R["Dépôt de la carte LilyGO"] --> H
    S["Fork SDK LilyGO\ndérivé de SiFli-SDK"] --> H
    O["Sources SiFli du circuit et du SDK"] -. "référence de la plateforme sous-jacente" .-> S

Distinguez les domaines de panne : alimentation/charge de la carte, démarrage et flashage, écran/tactile, chaque périphérique sélectionné, prise en charge de la carte par LilyGO et SDK sous-jacent. Un exemple d'affichage qui échoue peut être lié à l'alimentation, à la révision de carte, à la configuration de la dalle/du tactile, à l'application ou à une incompatibilité entre SDK et pilote ; « le SDK est en panne » ne constitue pas un diagnostic suffisant.

Étape 1 — Établir la référence fournisseur intacte¶

Objectif : établir le comportement réel de la carte reçue et de la référence fournisseur avant toute modification des sources.

1. Photographiez les deux faces de la carte et notez ses références, les périphériques montés, l'écran et le tactile, la mémoire, les commutateurs, les connecteurs et le commit du dépôt.
2. Vérifiez la source d'alimentation et la polarité. LilyGO indique que le démarrage nécessite plus de 3,5 V ; utilisez une alimentation surveillée et ne testez pas avec une cellule profondément déchargée.
3. Ne flashez qu'une référence connue comme compatible avec la carte ou, si sa provenance est connue, commencez par exécuter le firmware présent. Conservez l'image d'origine lorsque les outils le permettent.
4. Testez le menu affiché sur l'appareil ou les exemples intacts pour l'écran/le tactile et chaque périphérique prévu pour le produit. Signalez les fonctions indisponibles ou non montées sans les considérer comme des pannes.
5. Effectuez deux démarrages à froid et conservez les journaux de démarrage, photos de l'interface, résultats tactiles/des entrées et une trace de courant pour un scénario veille/activité clairement défini.

Preuves à conserver : révision de la carte et photos, identité du dépôt/de l'image, détails de l'alimentation et de la batterie, journaux de flash et de démarrage, inventaire des composants montés, résultats fonctionnels et conditions des mesures de courant.

Critère de sortie du point de contrôle 1 : deux démarrages à froid reproduisent la référence d'affichage/tactile identifiée ; le résultat de chaque périphérique monté dans le périmètre est consigné, et l'image d'origine ou une image de référence peut être restaurée.

Étape 2 — Valider les limites des périphériques, de l'alimentation et de la récupération¶

Objectif : déterminer si les pannes peuvent être détectées et récupérées sans utilisation dangereuse de la batterie ni nouveau flashage non documenté.

Critère de sortie du point de contrôle 2 : chaque test applicable possède un résultat répétable et un parcours de récupération ; tout firmware personnalisé protège contre la batterie faible, et aucune panne non résolue ne peut endommager la batterie ou bloquer la carte sans procédure de récupération documentée.

Étape 3 — Établir une base de code reproductible¶

Objectif : permettre à un second ingénieur de reconstruire et flasher la même référence à partir de sources propres et figées.

1. Récupérez les commits figés du dépôt de la carte et du fork du SDK LilyGO ; notez la version de base du SiFli-SDK amont déclarée par le fork.
2. Configurez l'environnement PowerShell documenté et compilez t-display-sf32_hcpu depuis un répertoire propre.
3. Conservez les preuves relatives à l'environnement, aux dépendances, à la configuration, à la mémoire/aux partitions, à l'image, au flashage et aux journaux série.
4. Recommencez sur une autre machine ou après suppression de tous les résultats de compilation, puis exécutez la régression complète de l'étape 2.

Critère de sortie du point de contrôle 3 : aucun ancien fichier image, fichier de carte non suivi ni remplacement SDK non documenté n'est nécessaire pour produire un firmware qui réussit l'étape 2.

Étape 4 — Adapter un chemin produit à la fois¶

Objectif : apporter une modification utile tout en préservant les références fournisseur et de récupération qui fonctionnent.

Critère de sortie du point de contrôle 4 : le changement est relu, l'image d'origine reste restaurable et tous les tests applicables d'affichage, de tactile, de périphériques, d'alimentation, de flash et de récupération réussissent.

Étape 5 — Revue de préparation produit¶

Avant de lancer un essai terrain ou de concevoir un circuit imprimé personnalisé, répondez aux questions suivantes :

• Qui est responsable des fichiers de carte, du fork SDK LilyGO, des correctifs de pilotes, des mises à jour de sécurité et de la migration vers les futures versions de SiFli-SDK ?
• Quelles révisions de carte et quels périphériques montés définissent la référence produit, et comment les unités reçues seront-elles identifiées et testées ?
• Quels sont les courants mesurés en activité, au repos, en veille, au démarrage et à l'arrêt pour la luminosité d'affichage, le rapport cyclique radio, le stockage et la configuration de capteurs prévus ?
• Comment vérifier la protection et la charge de la batterie, le comportement thermique, le boîtier, l'accès aux connecteurs et la récupération lorsque l'appareil est éteint ?
• Quelle région LoRa, antenne, plan de fréquence, paramètres d'émission et obligations réglementaires s'appliquent ?
• Les fichiers matériels, le firmware, le fork SDK, les exemples, les ressources et composants tiers ont-ils des licences compatibles avec la distribution envisagée ?
• L'équipe accepte-t-elle de dépendre d'un prototype tiers, ou a-t-elle qualifié un fork maîtrisé et un plan de support ?

Critère de sortie du point de contrôle 5 : chaque risque résiduel a un responsable, des preuves et une décision de traitement ; l'équipe a explicitement décidé de poursuivre, différer ou arrêter.

Passage à la conception du produit¶

Transmettez à l'étape suivante la référence SF32 exacte et les mémoires, les temporisations de l'écran et du tactile, les périphériques montés et leurs bus, l'arbre d'alimentation, le chargeur et la politique batterie, la stratégie antenne/RF, les connexions de démarrage et de flashage, le plan de partitions, les accès aux tests de production, la responsabilité du fork logiciel et le parcours de récupération validé. Poursuivez avec le parcours d'intégration SF32LB52x, le guide de conception matérielle SF32LB52x, SiFli-SDK : compiler, flasher et surveiller la sortie série et Conception pour la production.

Sources de référence¶

• Dépôt Xinyuan-LilyGO/T-Display-SF32
• README en chinois de T-Display-SF32
• Exemples T-Display-SF32
• Fichiers matériels de T-Display-SF32
• Mesures de consommation de T-Display-SF32
• Dépôt Xinyuan-LilyGO/SlFli-SDK-Lilygo
• OpenSiFli/SiFli-SDK

Dernière mise à jour: 2026-10-21