LilyGO T-Display-SF32¶

O que é o T-Display-SF32?¶

Xinyuan-LilyGO/T-Display-SF32 é uma plataforma de desenvolvimento baseada no MCU SF32LB52x, com display AMOLED CO5300 de 2,16 polegadas e controlador de toque CST9220. O repositório documenta 16 MB de Flash, 8 MB de PSRAM, IMU BHI260AP, rádio LoRa SX1262, interface microSD, áudio, USB Type-C, suporte a carregamento, pinagem da placa, aplicações de exemplo, arquivos de hardware, um diretório de firmware de fábrica e um relatório de consumo específico da placa.

Essa combinação torna a placa útil para avaliar dispositivos vestíveis centrados no display, controles portáteis, terminais de sensores e interfaces homem-máquina conectadas. Ela é uma referência de plataforma, não um produto acabado: embora o repositório exponha diversos caminhos de hardware, a equipe ainda precisa selecionar os relevantes, reproduzir uma base conhecida e medir o comportamento dos caminhos escolhidos na revisão exata da placa, além de qualificar alimentação, RF, segurança, manutenção do software e recuperação.

A matriz de recursos do repositório distingue a placa T-SF32-Display independente da expansão opcional T-SF32-Keyboard. Wi-Fi (ESP32-C6), GPS (L76K), teclado matricial e LEDs (TCA8418, AW21009 e XL9555), BME280, transmissor infravermelho e motor de vibração (AW86224) exigem essa expansão; não os inclua na base da placa independente.

Por que escolher a implementação com SF32?¶

O T-Display-SF32 reúne os recursos gráficos, Bluetooth, áudio e baixo consumo do SF32LB52x com dispositivos externos de display, toque, movimento, armazenamento e LoRa em uma única placa. A LilyGO também fornece a configuração da placa, drivers específicos, exemplos e um fork do SDK da LilyGO, descrito como derivado do SiFli-SDK 2.4.0. Isso pode simplificar o bring-up inicial (ativação inicial) da placa em comparação com partir de um alvo genérico e sem modificações do SDK.

O contraponto é a responsabilidade de manutenção. O suporte à placa, as alterações nos drivers, as revisões de hardware, o firmware incluído e a relação entre o fork do SDK da LilyGO e o SiFli-SDK upstream são controlados fora da SiFli. Para reproduzir o projeto, fixe os commits dos dois repositórios, preserve uma imagem de fábrica/recuperação funcional e trate qualquer migração para uma versão upstream mais recente do SDK como uma alteração explícita de engenharia.

Resultado, escopo e critérios de entrada¶

Resultado esperado: estabelecer uma base do T-Display-SF32 com versões fixadas; validar display/toque, periféricos selecionados, alimentação e recuperação; reproduzir a compilação a partir do código-fonte; e então fazer uma alteração delimitada na aplicação, acompanhada de evidências de regressão para a revisão do produto.

Esta página não comprova que todas as variantes da placa tenham todos os periféricos montados, que o firmware do fornecedor esteja pronto para produção, que o relatório de consumo se aplique a outra revisão ou carga de trabalho, nem que o uso de LoRa seja permitido em todas as regiões. Ela também não estende o suporte da SiFli ao hardware ou aos drivers específicos da LilyGO.

Antes de começar, tenha:

• A placa T-Display-SF32 exata e sua revisão de hardware, com o esquemático ou mapa de pinos;
• Uma fonte de bancada com limite de corrente ou bateria protegida cuja tensão e condição possam ser monitoradas;
• Um cabo USB de dados conhecido como funcional, a conexão Type-C documentada para gravação e uma imagem de recuperação preservada;
• Commits dos repositórios T-Display-SF32 e do fork do SDK da LilyGO fixados em versões específicas;
• O ambiente Windows/PowerShell documentado pelo fork do SDK da LilyGO para a primeira compilação reproduzível; outros ambientes de host devem ser qualificados separadamente;
• Acessórios de teste somente para as interfaces em escopo, como cartão microSD, fones ou carga de áudio e um dispositivo LoRa que opere em banda permitida;
• Registros de versões do firmware, logs de compilação e serial, fotografias, medições de corrente e resultados de falhas/recuperação.

Especificações de hardware e software¶

Especificação de hardware¶

Especificação de software¶

Escolher uma configuração de referência suportada¶

Atualmente, o repositório upstream usa a branch master e não apresenta uma versão identificada por tag como base universal de software. Registre o commit exato em vez de escrever “mais recente”. O repositório contém o diretório firmware/T-SF32-Factory-V1.2, mas esse nome não substitui o registro da revisão correspondente da placa, do commit do repositório e do procedimento de gravação.

Depois de configurar o ambiente necessário, o README do T-Display-SF32 documenta este fluxo de compilação e gravação no 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

Registre os commits usados do repositório e do SDK, a saída de exportação do ambiente, o log completo da compilação, as imagens geradas e os logs de gravação e inicialização. O número de tarefas executadas em paralelo pode variar; o alvo e as revisões do código-fonte, não.

Etapas do projeto¶

Arquitetura do sistema e dependências¶

flowchart LR
    U["Usuário\ninteração por toque e botões"] --> F["Firmware do T-Display-SF32\nSF32LB52x + RT-Thread"]
    F --> D["AMOLED CO5300\ntoque CST9220"]
    F --> P["Periféricos instalados\nIMU, microSD, áudio, LoRa"]
    B["Bateria / USB Type-C\ncarregador e linhas de alimentação"] --> F
    H["Ferramentas de compilação e gravação no host"] -->|"download UART e logs"| F
    R["Repositório da placa LilyGO"] --> H
    S["Fork do SDK da LilyGO\nderivado do SiFli-SDK"] --> H
    O["Fontes do dispositivo e SDK SiFli"] -. "referência da plataforma base" .-> S

Trate as falhas como áreas distintas: alimentação/carregamento da placa, inicialização e gravação, display/toque, cada periférico selecionado, suporte à placa da LilyGO e SDK subjacente. Por exemplo, uma falha em um exemplo de display pode decorrer da alimentação, revisão da placa, configuração do painel/toque, aplicação ou incompatibilidade entre SDK e driver; dizer apenas “o SDK falhou” não é um diagnóstico suficiente.

Etapa 1 — Estabeleça a base original do fornecedor¶

Objetivo: comprovar o comportamento real da placa recebida e da base do fornecedor antes de alterar o código-fonte.

1. Fotografe os dois lados da placa e registre marcações, periféricos instalados, componentes de display/toque, memória, chaves, conectores e commit do repositório.
2. Verifique a fonte e a polaridade. A LilyGO alerta que a inicialização exige mais de 3,5 V; use uma fonte monitorada e não teste com uma célula profundamente descarregada.
3. Grave somente uma base que corresponda comprovadamente à placa ou execute primeiro o firmware existente, se sua procedência for conhecida. Preserve a imagem original quando as ferramentas permitirem.
4. Teste o menu no próprio dispositivo ou exemplos sem alterações para display/toque e cada periférico selecionado para o produto. Registre funções indisponíveis ou não instaladas, em vez de tratá-las como falhas.
5. Faça duas inicializações a frio e guarde logs de inicialização, fotos da interface, resultados de toque/entrada e uma curva de corrente para uma carga ociosa/ativa claramente definida.

Evidências a preservar: revisão e fotos da placa, identificação do repositório/imagem, dados da fonte e bateria, logs de gravação e inicialização, inventário dos dispositivos instalados, resultados funcionais e condições do teste de corrente.

Critério de saída do ponto de controle 1: duas inicializações a frio reproduzem a base identificada de display/toque, há resultados registrados para cada periférico instalado em escopo e é possível restaurar a imagem original ou uma imagem conhecida como funcional.

Etapa 2 — Valide os periféricos, a alimentação e a recuperação¶

Objetivo: determinar se as falhas podem ser detectadas e se a placa pode ser recuperada sem uso inseguro da bateria nem gravação de firmware fora de um procedimento documentado.

Critério de saída do ponto de controle 2: cada teste aplicável tem resultado reproduzível e caminho de recuperação; qualquer firmware personalizado implementa proteção contra bateria fraca; e nenhuma falha não resolvida pode danificar a bateria ou inutilizar a placa sem um procedimento de recuperação documentado.

Etapa 3 — Crie uma base reproduzível do código-fonte¶

Objetivo: permitir que outro engenheiro gere e grave a mesma base a partir de fontes limpas e com versões fixadas.

1. Faça checkout dos commits fixados do repositório da placa e do fork do SDK da LilyGO; registre qual versão do SDK upstream é indicada como base do fork.
2. Configure o ambiente PowerShell documentado e compile t-display-sf32_hcpu em um diretório limpo.
3. Guarde evidências do ambiente, dependências, configuração, memória/partições, imagem, gravação e logs seriais.
4. Repita em outra máquina ou após excluir todos os artefatos de compilação e execute novamente toda a regressão da Etapa 2.

Critério de saída do ponto de controle 3: nenhuma imagem obsoleta, arquivo de placa não rastreado ou substituição não documentada do SDK é necessária para gerar firmware aprovado na Etapa 2.

Etapa 4 — Adapte um caminho do produto por vez¶

Objetivo: implementar uma alteração útil sem perder as bases funcionais do fornecedor e de recuperação.

Critério de saída do ponto de controle 4: a alteração foi revisada, a imagem original continua recuperável e todos os testes aplicáveis de display, toque, periféricos, alimentação, flash e recuperação foram aprovados.

Etapa 5 — Revise a prontidão do produto¶

Antes de avançar para um teste de campo ou uma PCB própria, responda:

• Quem é responsável pelos arquivos da placa, pelo fork do SDK da LilyGO, correções de drivers, atualizações de segurança e migração para versões posteriores do SiFli-SDK?
• Quais revisões da placa e periféricos instalados compõem a base do produto, e como as unidades recebidas serão identificadas e testadas?
• Quais valores de corrente foram medidos em atividade, repouso, suspensão, inicialização e desligamento, com o brilho do display, o ciclo de trabalho do rádio, o armazenamento e a configuração de sensores previstos?
• Como serão verificados a proteção da bateria, o carregamento, o comportamento térmico, o gabinete, o acesso aos conectores e a recuperação com o dispositivo desligado?
• Quais regiões LoRa, antena, plano de frequências, parâmetros de transmissão e obrigações regulatórias se aplicam?
• Os arquivos de hardware, firmware, fork do SDK, exemplos, recursos e componentes de terceiros têm licenças compatíveis com a distribuição pretendida?
• A equipe aceita a dependência de um protótipo de terceiros ou já qualificou um fork controlado e um plano de suporte?

Critério de saída do ponto de controle 5: cada risco residual tem um responsável, evidências e uma decisão registrada, e a equipe decidiu explicitamente prosseguir, adiar ou parar.

Transição para o projeto do produto¶

Leve adiante o modelo exato do SF32 e os dispositivos de memória, a temporização do display/toque, os periféricos instalados e seus barramentos, a árvore de alimentação, a política do carregador e da bateria, a estratégia de antena/RF, a conexão de boot/gravação, o plano de partições, o acesso aos testes de produção, a responsabilidade pelo fork do software e o caminho de recuperação comprovado. Continue pelo caminho de integração do SF32LB52x, guia de projeto de hardware do SF32LB52x, compilação, gravação e monitoramento do SiFli-SDK e projeto para produção.

Fontes de referência¶

• Repositório Xinyuan-LilyGO/T-Display-SF32
• README do T-Display-SF32 em chinês
• Exemplos do T-Display-SF32
• Arquivos de hardware do T-Display-SF32
• Material de testes de consumo do T-Display-SF32
• Fork do SDK Xinyuan-LilyGO/SlFli-SDK-Lilygo
• OpenSiFli/SiFli-SDK

Última atualização: 2026-10-21