A smartwatch, a color-screen TWS charging case, or a health band runs its GUI from a few hundred kilobytes of on-chip SRAM. A full-screen frame buffer alone needs megabytes, and the voice algorithm and the wireless stack each want their own space. Once the display refreshes every second, the heart-rate curve scrolls, and a voice prompt fires at the same time, that on-chip pool is gone. Adding external memory is not a luxury in this class of product, it is the first decision every wearable team has to make.
Most teams end up with PSRAM: a DRAM core wrapped in an SRAM-style interface. Not SRAM, not NOR Flash, not eMMC. The reasons are specific, and they repeat across projects.
Start with area and cost. SRAM at the same density costs an order of magnitude more, and an 8MB SRAM needs dozens of parallel address and data lines. Neither the package nor the board area works inside a watch case. Then look at access behavior. eMMC is managed in blocks, so every frame refresh pays block-protocol latency, and a display redrawing dozens of times per second cannot absorb that. NOR Flash cannot carry megabyte-class buffers at a wearable price either.
For the same external 8MB, PSRAM is the only one of the three that holds cost, pin count, and access model together:
A QSPI interface with four data lines gives 8MB in an 8-pin package.
The CPU reads and writes by address, so software treats it as SRAM with no block overhead.
Data retention comes from the chip's internal self-refresh, so no software maintenance is involved.
| Option | Density at wearable cost | Pins | Access model | Fit for a frame buffer |
|---|---|---|---|---|
| SRAM | Up to a few MB, expensive per bit | Parallel, dozens of lines | Byte random access | Poor, cost and pin count |
| PSRAM | 64Mb and up, 8-pin QSPI | 4 data lines plus control | Byte random access | Good |
| NOR Flash | 64Mb to 1Gb, but per-bit cost rises | SPI/QSPI | Byte read, slow write, erase blocks | Poor, writes are the problem |
| eMMC | 4GB and up | 8-bit bus plus command lines | Block protocol | Poor, random latency |
That table is why the external buffer slot in a wearable is almost always PSRAM.
The buffer is sized from the display, not from the part. Take an 800 x 480 panel in RGB565: one frame is 800 x 480 x 2 bytes, about 750KB. A double buffer to prevent tearing doubles that, and a watch face, a scrolling chart, and a voice prompt each want their own region. 8MB covers all three with room for the GUI framework and its assets, which is why 64Mb is the common density in this class and 32Mb is where designs start to compromise.
Under-sizing shows up as specific symptoms rather than as a clean failure. The GUI drops frames while audio plays, the watch face stutters when a notification arrives, and a voice prompt truncates at the end. Teams often blame the display driver or the audio stack, when the real answer is that the buffer and the audio working set are competing for the same few hundred kilobytes. Sizing from the frame arithmetic first avoids that debugging loop.
The APS6404L-SQH-ZR runs from 1.62
Telephone: +86-150-1290-5940
Mobile phone: +86-150-1290-5940
Mailbox: sales@manduic.com
Address: Room 1115, R&D Building, DAFU Technology, Fenghuang Sub‑district, Guangming District, Shenzhen City