Every embedded design stores something — calibration data, firmware, logs, frames of video — and each job has a memory family that fits it. Choosing wrong shows up as slow boot, worn-out cells, or a BOM that costs more than it should. Here is how the five main families of memory ICs actually differ.
The One-Table Overview
| Family | Volatile? | Endurance | Read Speed | Write Mechanics | Typical Density |
|---|---|---|---|---|---|
| EEPROM | No | 1M erase/write cycles per byte | Fast (random) | Byte-wise | 1 Kbit – 4 Mbit |
| NOR Flash | No | ~100K cycles (blocks) | Very fast random (XIP) | Block erase + page program | 1 – 512 Mbit |
| NAND Flash | No | 10K–100K cycles (blocks) | Fast sequential, slow random | Page program, block erase | 1 – 1,024 Gbit |
| SRAM | Yes | Unlimited | Fastest (ns access) | Direct write | Kbit – 128 Mbit |
| DRAM | Yes | Unlimited (needs refresh) | Fast, burst-oriented | Direct write + refresh | 512 Mbit – 32 Gbit+ |
EEPROM: Small, Tough, Byte-Writable
EEPROM is the default for calibration constants, serial numbers, and configuration that change occasionally but must survive power cycles and be updated byte-by-byte. SPI and I2C EEPROMs from the major manufacturers are cheap, draw almost no standby current, and tolerate a million update cycles per byte. If you find yourself wearing out EEPROMs, the fix is usually wear-leveling in firmware or moving logs to flash.
NOR Flash: Code Storage with Random Access
NOR's superpower is execute-in-place (XIP): random access fast enough that the MCU can run code directly from it. That is why NOR boots virtually every embedded system — the bootloader, and often the whole application, lives in SPI NOR (QSPI/Octal). Density is modest and cost per bit is high, but for 4–128 MB of firmware it is unbeatable. Check the quad/octal interface, the erase granularity, and whether the part offers secure/one-time-programmable regions.
NAND Flash: Gigabytes per Dollar
NAND trades random access for density: sequential reads and writes are fast, but blocks must be erased before rewriting, and bad-block management plus ECC are mandatory. Raw NAND belongs to engineers who want that job; everyone else specifies managed NAND — e.MMC or SD — where the controller does wear-leveling internally. Data loggers, video recorders, and any product storing gigabytes land here.
SRAM and DRAM: Working Memory
SRAM keeps data with no refresh and answers in nanoseconds — perfect for buffers, caches, and battery-backed state, at the highest cost per bit. DRAM (DDR3L, DDR4, LPDDR4) delivers megabytes per dollar for Linux-class processors, at the price of a memory controller, layout constraints, and refresh management. A common embedded pattern: NOR for boot and code, LPDDR for runtime, EEPROM for identity — each doing the job it was built for.
Five Questions That Narrow the Choice
- Must data survive power loss? (eliminates SRAM/DRAM or forces battery backup)
- Does the CPU execute code from it? → NOR.
- How many bytes change per day, and how often? → endurance budget.
- How many megabytes do you really need at boot? → interface and density.
- What does the second source look like? — pin-compatible alternates exist in every family; JTDZ Tech can quote them with date codes and traceability before you commit a layout.
