LightInk

Qu’est-ce que LightInk ?

LightInk est un projet de montre solaire e-ink à base d’ESP32 conçu pour imiter les montres solaires numériques des années 1990 tout en utilisant des composants modernes (eInk, WiFi/Bluetooth, LoRa, GPS sont mentionnés parmi les capacités prévues/disponibles). Son objectif principal est une consommation ultra-faible pour que l’appareil reste éteint sauf quand nécessaire — en particulier en minimisant le temps d’éveil de l’ESP32 lors des mises à jour e-ink.

Un défi central décrit par l’auteur est de réduire le temps « allumé » de l’ESP32 à des niveaux sub-milliseconde pendant le rafraîchissement de l’affichage. Le projet y parvient en réimplémentant le comportement SPI dans le code du wake stub de l’ESP32, permettant de contourner les chemins de boot flash normaux et d’exécuter uniquement le code placé en mémoire RTC lors de l’éveil.

Fonctionnalités clés

• Concept de montre e-ink solaire : Vise une longue autonomie grâce à l’énergie solaire et une batterie, avec l’e-ink pour les mises à jour d’affichage.
• Approche wake-stub ESP32 pour réduire la consommation au boot : Utilise un wake-stub ESP32 stocké en mémoire RTC (pointeur de fonction) pour que le cœur démarre immédiatement en microsecondes plutôt que d’attendre le démarrage complet du flash/firmware.
• Réimplémentation SPI dans le contexte wake-stub : Comme le code RTC-only ne peut pas s’appuyer sur les routines flash normales, la communication d’affichage (SPI) est réimplémentée pour mettre à jour l’e-ink pendant la brève fenêtre d’éveil.
• Capacité de power gating (prévue/requise) : Le projet insiste sur la nécessité que le système puisse être mis en power gating et éteint quand non nécessaire.
• Matériel d’alimentation personnalisé : L’auteur a développé une carte autour d’un convertisseur DC-DC buck-boost à faible courant quiescent (TPS63900, 1,8 V à 5,5 V, 75 nA IQ mentionné) pour supporter un fonctionnement à basses tensions.

Comment utiliser LightInk

• Consultez le code source et les matériaux de construction : L’auteur fournit le code et les matériaux via le dépôt GitHub et s’attend à ce que les utilisateurs partent de cette documentation plutôt que d’un produit packagé.
• Suivez la structure du firmware pour le deep sleep/éveil : Le mécanisme wake-stub est central au design, et les chemins de code pertinents sont référencés (ex. : deep sleep et fichiers uspi-related dans le dépôt).
• Calibrez le matériel à votre configuration : Le projet décrit de nombreuses révisions et tests de carte pour une opération fiable avec solaire, touch, RTC/affichage et comportement basse tension.
• Utilisez un workflow de mise à jour e-ink typique : En pratique, l’appareil est conçu pour s’éveiller, communiquer avec l’affichage e-ink, puis retourner en mode basse consommation — plutôt que de rester actif en continu.

Cas d’usage

• Affichage solaire longue durée : Une cible pratique est un affichage de type montre qui continue de fonctionner avec l’apport solaire au lieu de recharges fréquentes.
• Badge IoT ou nœud capteur basse consommation : La même approche wake-stub + activité courte peut supporter de petites mises à jour de statut sur un affichage e-ink quand l’énergie doit être préservée.
• Concept d’affichage heure/localisation connecté LoRa : Le projet a commencé avec l’idée d’utiliser des paquets LoRa pour communiquer vers un récepteur à domicile, et l’auteur continue vers une montre utilisant la communication sans fil tout en restant basse consommation.
• Développement embarqué optimisé énergie : Les développeurs intéressés par la réduction de l’énergie d’éveil/boot ESP32 peuvent étudier la stratégie wake-stub en mémoire RTC et les implications des pilotes matériels dans cet environnement contraint.
• Appareil compact à contrôle tactile : L’auteur a choisi la fonctionnalité tactile de l’ESP32 (plutôt que des boutons watchy), avec l’approche tactile notée comme adaptée aux contraintes du boîtier.

FAQ

Q : LightInk est-il un produit grand public prêt à l’achat ?
Non. La page décrit un projet matériel/firmware en cours, avec code et matériaux hébergés sur GitHub.

Q : Qu’est-ce qui rend la stratégie d’alimentation de LightInk différente ?
Le projet se concentre sur la minimisation du temps d’éveil de l’ESP32 lors des mises à jour d’affichage, en utilisant le wake stub ESP32 stocké en RTC memory et en exécutant le code nécessaire (y compris une approche SPI) dans ce contexte d’éveil.

Q : Pourquoi l’approche wake-stub nécessite-t-elle un travail supplémentaire ?
L’auteur explique que pendant l’exécution du wake-stub, seul le code en RTC memory peut s’exécuter et les fonctionnalités basées sur flash sont contournées. Cela force la réimplémentation des routines de communication matérielle.

Q : Quelles options de connectivité sont prises en charge ?
La description mentionne WiFi, Bluetooth, LoRa et GPS parmi les technologies visées par le projet. L’extrait de page ne précise pas lesquelles sont pleinement implémentées dans la version actuelle, vérifiez les détails dans le dépôt.

Q : Où trouver les informations sur le firmware et le matériel ?
Le projet renvoie à un dépôt GitHub contenant tout le code et les matériaux.

Alternatives

• Conceptions de montres solaires e-ink style Watchy : Watchy est explicitement mentionné comme point de départ. Par rapport à LightInk, les approches basées sur Watchy peuvent utiliser un workflow d’alimentation/mise à jour différent et ne pas employer la même approche SPI wake-stub ESP32.
• Autres projets d’affichages e-ink basse consommation avec deep sleep standard : Au lieu de l’exécution wake-stub, certaines conceptions utilisent le deep sleep avec réveil/démarrage firmware normal. Elles sont généralement plus simples mais peuvent consommer plus d’énergie en raison de chemins de démarrage plus longs.
• Architectures microcontrôleur ULP/toujours actif : Certains projets embarqués atteignent une faible énergie d’éveil grâce à des coprocesseurs ultra-basse consommation ou périphériques, plutôt que des wake stubs basés sur pointeurs de fonction RTC.
• Approches avec contrôleur d’affichage e-ink dédié : Une catégorie alternative concerne les conceptions où l’affichage est mis à jour par un contrôleur spécialisé, réduisant le temps actif du MCU principal. Cela change le workflow de « mises à jour pilotées par MCU » vers « mises à jour pilotées par contrôleur ».