UStackUStack
LightInk icon

LightInk

LightInk é um projeto de relógio solar e-ink com ESP32, focado em uso ultrabaixo de energia com wake stub para atualizar o display em pouco tempo.

LightInk

O que é LightInk?

LightInk é um projeto de relógio solar e-ink baseado em ESP32, projetado para imitar relógios digitais solares dos anos 1990 usando componentes modernos (eInk, WiFi/Bluetooth, LoRa, GPS estão entre as capacidades planejadas/disponíveis). Seu principal objetivo é operação de ultrabaixo consumo, para que o dispositivo permaneça desligado exceto quando necessário — especialmente minimizando o tempo de ativação do ESP32 durante atualizações do e-ink.

Um desafio central de design descrito pelo autor do projeto é reduzir o tempo “ligado” do ESP32 para níveis submilissegundo durante a atualização da tela. O projeto consegue isso reimplementando o comportamento SPI no código do wake stub do ESP32, permitindo que o ESP32 evite os caminhos normais de boot do flash e execute apenas o código colocado na memória RTC durante o wake.

Principais Recursos

  • Conceito de relógio e-ink alimentado a solar: Visa longa autonomia dependendo de energia solar e bateria, com e-ink usado para atualizações da tela.
  • Abordagem wake-stub do ESP32 para reduzir consumo no boot: Usa um wake stub do ESP32 armazenado na memória RTC (um ponteiro de função) para que o core inicialize imediatamente em microssegundos, em vez de aguardar o startup completo do flash/firmware.
  • Reimplementação SPI no contexto wake-stub: Como o código apenas em RTC não pode depender de rotinas normais baseadas em flash, a comunicação com a tela (SPI) é reimplementada para atualizar o e-ink durante a breve janela de wake.
  • Capacidade de power gating (planejado/necessário): O projeto destaca explicitamente a exigência de que o sistema possa ser isolado de energia e desligado quando não necessário.
  • Hardware de energia personalizado: O autor desenvolveu uma placa em torno de um conversor DC-DC buck-boost de baixa corrente quiescente (TPS63900, 1,8 V a 5,5 V, 75 nA IQ mencionado) para suportar operação em baixas tensões.

Como Usar LightInk

  • Revise o código-fonte e materiais de construção: O autor fornece código e materiais via repositório GitHub e espera que os usuários comecem pela documentação, não por um produto pronto.
  • Siga a estrutura do firmware para deep sleep/wake: O mecanismo wake-stub é central no design, com referências aos caminhos de código relevantes (ex.: arquivos de deep sleep e uspi no repositório).
  • Calibre o hardware para sua configuração: O projeto descreve revisões extensas de placa e testes para operação confiável com solar, toque, componentes RTC/tela e comportamento em baixa tensão.
  • Use um fluxo de trabalho típico de atualização e-ink: Na prática, o dispositivo é projetado para acordar, comunicar com a tela e-ink e retornar à operação de baixo consumo — em vez de ficar continuamente ativo.

Casos de Uso

  • Dispositivo de exibição solar de longa duração: Um alvo prático é uma tela estilo relógio que continua funcionando com entrada solar em vez de recargas frequentes.
  • Badge ou nó de sensor IoT de baixo consumo: A mesma abordagem wake-stub + atividade curta pode suportar atualizações pequenas de status em tela e-ink quando o dispositivo precisa economizar energia.
  • Conceito de exibição de localização/tempo via LoRa: O projeto começou com a ideia de usar pacotes LoRa para comunicar com um receptor em casa, e o autor continua trabalhando em um relógio que usa comunicação sem fio mantendo baixo consumo.
  • Desenvolvimento embarcado otimizado para energia: Desenvolvedores interessados em reduzir o consumo de wake/boot do ESP32 podem estudar a estratégia wake-stub em memória RTC e as implicações de drivers de hardware disponíveis nesse ambiente restrito.
  • Dispositivo compacto controlado por toque: O autor optou pela funcionalidade de toque do ESP32 (em vez de botões como no Watchy), com a abordagem de toque adequada às restrições do enclosure.

FAQ

P: O LightInk é um produto de consumo pronto para compra?
Não. A página descreve um projeto em andamento de hardware/firmware com código e materiais hospedados no GitHub.

P: O que diferencia a estratégia de energia do LightInk?
O projeto foca em minimizar o tempo do ESP32 acordado durante atualizações do display, usando o wake stub do ESP32 armazenado na memória RTC e executando o código necessário (incluindo uma abordagem SPI) nesse contexto de wake.

P: Por que a abordagem wake-stub exige trabalho extra?
O autor explica que, durante a execução do wake-stub, apenas código na memória RTC pode rodar e funcionalidades baseadas em flash são ignoradas. Isso força a reimplementação de rotinas de comunicação com hardware.

P: Quais opções de conectividade são suportadas?
A descrição menciona WiFi, Bluetooth, LoRa e GPS entre as tecnologias que o projeto visa usar. O trecho da página não especifica quais estão totalmente implementadas na build atual, então detalhes devem ser verificados no repositório.

P: Onde encontro o firmware e informações de hardware?
O projeto linka para um repositório no GitHub contendo todo o código e materiais.

Alternativas

  • Designs de relógio solar e-ink estilo Watchy: Watchy é mencionado explicitamente como ponto de partida. Comparado ao LightInk, abordagens baseadas em Watchy podem usar um fluxo de energia/atualização diferente e não usar a mesma abordagem wake-stub SPI do ESP32.
  • Outros projetos de display e-ink de baixo consumo usando deep sleep padrão: Em vez de execução wake-stub, alguns designs usam deep sleep com wake/boot de firmware normal. Esses são tipicamente mais simples, mas podem consumir mais energia devido a caminhos de boot mais longos.
  • Arquiteturas de microcontrolador ULP/sempre ligado: Alguns projetos embarcados alcançam baixa energia de wake usando coprocessadores ultra-low-power ou periféricos, em vez de wake stubs por ponteiro de função RTC.
  • Abordagens com controlador dedicado de display e-ink: Uma categoria alternativa são designs onde o display é atualizado por um controlador especializado, reduzindo o tempo ativo do MCU principal. Isso muda o fluxo de “atualizações impulsionadas por MCU” para “atualizações impulsionadas por controlador”.