LilyGO T-Display-SF32¶

¿Qué es T-Display-SF32?¶

Xinyuan-LilyGO/T-Display-SF32 es una plataforma de desarrollo basada en un microcontrolador SF32LB52x, una pantalla AMOLED CO5300 de 2,16 pulgadas y un controlador táctil CST9220. El repositorio documenta 16 MB de flash, 8 MB de PSRAM, una IMU BHI260AP, un transceptor LoRa SX1262, una interfaz microSD, audio, USB Type-C, función de carga, asignaciones de pines de la placa, aplicaciones de ejemplo, archivos de hardware, un directorio de firmware de fábrica y un informe de consumo energético específico de la placa.

Esta combinación resulta útil para evaluar un dispositivo vestible centrado en la pantalla, un controlador portátil, un terminal portátil de sensores o una HMI conectada. Sin embargo, es una referencia de plataforma, no un producto terminado: el repositorio ofrece distintas opciones de hardware, pero el equipo de producto debe seleccionar las que necesita, reproducir una configuración de referencia conocida y medir el comportamiento de los caminos elegidos en la revisión exacta de la placa. También debe validar la alimentación, la RF, la seguridad, el mantenimiento del software y la recuperación.

La matriz de funciones del repositorio distingue la placa T-SF32-Display independiente de la expansión opcional T-SF32-Keyboard. Wi-Fi (ESP32-C6), GPS (L76K), el teclado matricial y sus LED (TCA8418, AW21009 y XL9555), BME280, el emisor infrarrojo y el motor de vibración (AW86224) requieren esa expansión; no deben incluirse en la configuración base de la placa independiente.

¿Por qué esta implementación de SF32?¶

T-Display-SF32 combina las capacidades gráficas, Bluetooth, audio y bajo consumo del SF32LB52x con dispositivos externos para visualización, entrada táctil, detección de movimiento, almacenamiento y LoRa en una misma placa. LilyGO también proporciona la configuración de la placa, controladores específicos, ejemplos y un fork del SDK de LilyGO que, según se indica, parte de SiFli-SDK 2.4.0. Esto puede reducir el tiempo inicial de puesta en marcha de la placa frente a comenzar con un destino genérico del SDK sin modificar.

La contrapartida es la responsabilidad de mantenimiento. El soporte de la placa, los cambios en los controladores, las revisiones de hardware, el firmware incluido y la relación entre el fork de LilyGO y el SiFli-SDK principal se gestionan fuera de SiFli. Por ello, un proyecto reproducible debe fijar los commits de ambos repositorios, conservar una imagen de fábrica/recuperación que funcione y probar cualquier migración a una versión más reciente del SiFli-SDK principal como un cambio de ingeniería explícito.

Resultado, alcance y criterios de entrada¶

Resultado: establecer una configuración de referencia de T-Display-SF32 con versiones fijadas; validar la pantalla y el táctil, los periféricos seleccionados, el comportamiento de alimentación y la recuperación; reproducir una compilación desde el código fuente; y realizar un cambio acotado en la aplicación con evidencias de regresión adecuadas para una revisión de producto.

Esta página no demuestra que todas las variantes de la placa incluyan todos los periféricos, que el firmware del proveedor esté listo para producción, que el informe de consumo se aplique a otra revisión o carga de trabajo, ni que el funcionamiento de LoRa sea legal en todas las regiones. Tampoco implica que SiFli admita el hardware o los controladores específicos de LilyGO.

Antes de empezar, tenga preparado lo siguiente:

• La placa T-Display-SF32 exacta y su revisión de hardware, junto con su esquemático o mapa de pines.
• Una fuente de laboratorio con limitación de corriente o una batería protegida cuya tensión y estado puedan supervisarse.
• Un cable USB de datos que funcione, la conexión Type-C documentada para grabar y una imagen de recuperación guardada.
• Los commits fijados del repositorio T-Display-SF32 y del fork del SDK de LilyGO.
• El entorno Windows/PowerShell que documenta el fork del SDK de LilyGO para la primera compilación reproducible; otros entornos de desarrollo deben validarse por separado.
• Accesorios de prueba solo para las interfaces incluidas en el alcance, como una tarjeta microSD, auriculares o una carga de audio y un equipo LoRa de la banda permitida.
• Un registro de las versiones del firmware, los registros de compilación y consola serie, fotografías, medidas de corriente y resultados de fallos y recuperación.

Especificaciones de hardware y software¶

Especificación de hardware¶

Especificación de software¶

Elegir una configuración de referencia admitida¶

El repositorio de referencia utiliza actualmente la rama master y no presenta una versión etiquetada como configuración de software universal. Registre el commit exacto en lugar de indicar solo «la última versión». El repositorio contiene el directorio firmware/T-SF32-Factory-V1.2, pero su nombre no sustituye al registro de la revisión de la placa, el commit correspondiente y el procedimiento de grabación.

El README de T-Display-SF32 documenta este flujo de compilación y grabación del firmware en Windows, una vez configurado el entorno requerido:

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

Guarde los commits exactos del repositorio y del SDK, el resultado de exportar el entorno, el registro completo de compilación, las imágenes generadas y los registros de grabación y arranque. El número de trabajos en paralelo puede cambiar; el destino y las revisiones del código fuente deben mantenerse fijos.

Etapas del proyecto¶

Arquitectura del sistema y dependencias¶

flowchart LR
    U["Usuario\npantalla táctil y botones"] --> F["Firmware T-Display-SF32\nSF32LB52x + RT-Thread"]
    F --> D["AMOLED CO5300\ntáctil CST9220"]
    F --> P["Periféricos instalados\nIMU, microSD, audio, LoRa"]
    B["Batería / USB Type-C\ncargador y raíles de alimentación"] --> F
    H["Herramientas de compilación y grabación del equipo de desarrollo"] -->|"Grabación por UART y registros"| F
    R["Repositorio de la placa de LilyGO"] --> H
    S["Fork de LilyGO SDK\nderivado de SiFli-SDK"] --> H
    O["Fuentes del dispositivo y SDK de SiFli"] -. "referencia de la plataforma subyacente" .-> S

Analice los fallos por ámbitos: alimentación y carga de la placa, arranque y grabación, pantalla y táctil, cada periférico seleccionado, soporte de LilyGO para la placa y SDK subyacente. Por ejemplo, un fallo en el ejemplo de pantalla puede deberse a la alimentación, a la revisión de la placa, a la configuración del panel o del táctil, a la aplicación o a una discrepancia entre el SDK y el controlador. Decir simplemente «ha fallado el SDK» no es un diagnóstico suficiente.

Etapa 1 — Establecer la configuración intacta del proveedor¶

Objetivo: comprobar el comportamiento real de la placa recibida y de la configuración del proveedor antes de modificar el código fuente.

1. Fotografíe ambas caras de la placa y registre las marcas, los periféricos instalados, los componentes de pantalla y táctil, la memoria, los interruptores, los conectores y el commit del repositorio.
2. Compruebe la fuente de alimentación y su polaridad. LilyGO advierte que el arranque requiere más de 3,5 V; utilice una fuente supervisada y no use una celda muy descargada como método de prueba.
3. Grabe solo una configuración de referencia que se sepa compatible con la placa o ejecute primero el firmware existente si su procedencia es conocida. Conserve la imagen original siempre que las herramientas lo permitan.
4. Utilice el menú del propio dispositivo o los ejemplos sin modificar para probar la pantalla, el táctil y cada periférico seleccionado para el producto. Registre las funciones que no estén disponibles o no estén montadas, en lugar de considerarlas fallos.
5. Realice dos arranques en frío y conserve los registros de arranque, fotografías de la interfaz, resultados de entrada táctil y de otros controles, y una traza de corriente para una carga inactiva/activa definida con claridad.

Evidencias que se deben conservar: revisión y fotografías de la placa, identificación del repositorio y la imagen, datos de la fuente y la batería, registros de grabación y arranque, inventario de dispositivos instalados, resultados funcionales y condiciones de la prueba de corriente.

Criterio de salida del punto de control 1: se reproduce en dos arranques en frío la configuración identificada de pantalla y táctil, hay resultados registrados para todos los periféricos instalados incluidos en el alcance y se puede restaurar la imagen original o una imagen conocida como funcional.

Etapa 2 — Validar los límites de periféricos, alimentación y recuperación¶

Objetivo: determinar si los fallos pueden detectarse y recuperarse sin usar la batería de forma insegura ni depender de una nueva grabación sin documentar.

Criterio de salida del punto de control 2: cada prueba aplicable tiene un resultado repetible y una ruta de recuperación; cualquier firmware personalizado implementa protección por batería baja; y ningún fallo pendiente puede dañar la batería o dejar la placa inutilizable sin una ruta de recuperación documentada.

Etapa 3 — Crear una configuración de referencia reproducible desde el código fuente¶

Objetivo: permitir que otro ingeniero compile y grabe la misma configuración de referencia a partir de fuentes limpias y con versiones fijadas.

1. Obtenga los commits fijados del repositorio de la placa y del fork del SDK de LilyGO; registre la base del SiFli-SDK principal declarada por el fork.
2. Configure el entorno PowerShell documentado y compile t-display-sf32_hcpu desde un directorio limpio.
3. Guarde las evidencias del entorno, las dependencias, la configuración, la memoria/partición, la imagen, la grabación y los registros de consola serie.
4. Repita el proceso en otro equipo o tras borrar todos los resultados de compilación y ejecute de nuevo todas las pruebas de regresión de la Etapa 2.

Criterio de salida del punto de control 3: no se necesita una imagen obsoleta, un archivo de placa sin seguimiento ni una sustitución del SDK no documentada para obtener un firmware que supere la Etapa 2.

Etapa 4 — Adaptar una ruta del producto cada vez¶

Objetivo: realizar un cambio útil preservando la configuración de referencia del proveedor y la de recuperación.

Criterio de salida del punto de control 4: el cambio se ha revisado, la imagen original sigue siendo recuperable y se superan todas las pruebas aplicables de pantalla, táctil, periféricos, alimentación, flash y recuperación.

Etapa 5 — Revisión de preparación del producto¶

Antes de comprometerse con una prueba de campo o una PCB propia, responda a estas preguntas:

• ¿Quién se responsabiliza de los archivos de la placa, el fork del SDK de LilyGO, las correcciones de controladores, las actualizaciones de seguridad y la migración a futuras versiones de SiFli-SDK?
• ¿Qué revisiones de la placa y periféricos instalados forman parte de la configuración del producto y cómo se identificarán y probarán las unidades recibidas?
• ¿Cuáles son las corrientes medidas activa, inactiva, en reposo, de arranque y de apagado para el brillo previsto de la pantalla, el ciclo de trabajo de radio y la configuración de almacenamiento y sensores?
• ¿Cómo se verifican la protección de la batería, la carga, el comportamiento térmico, la carcasa, el acceso a conectores y la recuperación con la placa apagada?
• ¿Qué región LoRa, antena, plan de frecuencias, parámetros de transmisión y obligaciones normativas son aplicables?
• ¿Las licencias de los archivos de hardware, el firmware, el fork del SDK, los ejemplos, los recursos y los componentes de terceros son compatibles con la distribución prevista?
• ¿El equipo acepta depender de un prototipo de terceros o ha validado un fork controlado y un plan de soporte?

Criterio de salida del punto de control 5: todos los riesgos restantes tienen un responsable, evidencias y una resolución, y el equipo ha decidido expresamente continuar, aplazar o detenerse.

Traspaso a la fase de diseño del producto¶

Traslade el número de pieza SF32 exacto y los dispositivos de memoria, los tiempos de pantalla y táctil, los periféricos montados y sus buses, la estructura de alimentación, la política del cargador y la batería, la estrategia de antena/RF, la conexión de arranque y grabación, el plan de particiones, los puntos de acceso para pruebas de producción, quién mantiene el fork de software y la ruta de recuperación demostrada. Continúe con la ruta de integración de SF32LB52x, la guía de diseño de hardware de SF32LB52x, Compilar, grabar y supervisar con SiFli-SDK y Diseño para producción.

Fuentes de referencia¶

• Repositorio Xinyuan-LilyGO/T-Display-SF32
• README en chino de T-Display-SF32
• Ejemplos de T-Display-SF32
• Archivos de hardware de T-Display-SF32
• Material de pruebas de consumo de T-Display-SF32
• Repositorio Xinyuan-LilyGO/SlFli-SDK-Lilygo
• OpenSiFli/SiFli-SDK

Última actualización: 2026-10-21