Help choosing an e‑paper display and architecture for a silent meditation “gong” timer

Hi all,

I’m building a quiet meditation timer that strikes a singing bowl. I want to add a small e‑paper display for low‑power, silent UI. I’d love your advice on the panel choice, interface details, and overall processing architecture.

Context in one paragraph
The device must stay silent until the moment of the strike; it runs from a battery; it will show a simple clock and a few UI states on e‑paper; touch input is via CapSense under acrylic or glass; actuation is either a magnetic latch solenoid with peak‑and‑hold or a voice‑coil; PSoC will manage sensing and timing. I’ve already sourced the mechanical and driver parts; I’m choosing the display path now.

What I need from the display

• Small, low‑power, SPI; black‑white is fine; partial refresh preferred to avoid full screen flashes

• Good readability; minimal ghosting; stable over temperature typical of a quiet room

• Simple connectoring; I will prototype with headers then move to a custom PCB

• Runs happily from 3.3 V logic; plays nicely with capacitive sensing nearby

Architecture questions

1. ESP for UI + separate MCU for real time control
   I’ve seen ESP‑controlled driver boards for e‑paper. Would it make sense to run the UI on an ESP module and keep a dedicated Teensy (or similar) focused on real‑time sensing and actuation; or would you keep everything on one MCU and drive the panel via SPI from PSoC?

2. Timekeeping on ESP
   It is mostly “just a clock” plus strike control. In your experience, does an ESP keep time well enough on battery if I do not use an external RTC; assuming I periodically sync or as long as the battery stays charged; or do you strongly recommend a dedicated RTC for drift and backup?

E‑paper experiences to share

• General experiences with e‑paper in embedded products; any pitfalls around partial updates; ghosting; temperature compensation; display burn‑in over months

• Opinions on Waveshare SPI e‑paper raw panels and their driver boards; any specific controller ICs you recommend avoiding or preferring for partial refresh and clean fonts

• Best practices for update cadence; e.g. redraw once per minute; use windowed partial refresh for small UI elements; tricks to minimize ghosting

Interface and connector questions

• Interface signals I should plan for beyond 4‑wire SPI; typically I see CS, DC, RST, BUSY in addition to SCLK, MOSI, VCC, GND; any others you have found important for smooth partial refresh

• Connectors: I noticed some boards offer “2 × 4‑pin 2.54 mm header” or an “MX1.25‑8P cable‑to‑board” style connector; is that a normal pattern for e‑paper driver boards; or should I expect the raw panels to use fine‑pitch FFC and bring that out myself on the PCB

• Any layout gotchas when placing an e‑paper connector near capacitive electrodes; spacing; ground pours; shielding that you have found necessary

Constraints and nice‑to‑haves

• Power budget matters; e‑paper refresh current spikes are fine; sleep current must be low

• I can accommodate 1.8–3.3 V IO if needed; SPI preferred over parallel

• Size is flexible; I’m open to suggestions that balance clarity with power; common sizes welcome

If you have specific panel + driver combos that worked well for you, please share part numbers or boards. If you think an ESP‑for‑UI + PSoC‑for‑real‑time split is smart, I’d like to hear how you partitioned responsibilities; display updates; touch debouncing; actuator timing. If your experience says keep it all on one MCU and add a proper RTC, I’m all ears.

Thanks in advance for your insights; links to tried‑and‑true modules or reference designs are much appreciated. .