2026 Sept / By Semir Haddad – Chief Product and Strategy Officer at MicroEJ

DRAM memory used to be the boring part of the bill of materials: cheap, plentiful, and nobody’s problem. That era is over. AI data centers are buying DRAM the way a gold rush buys shovels, and embedded manufacturers are discovering that the chips they budgeted for last year now cost more, ship later, or simply aren’t available.

Deloitte’s July 2026 analysis found that the cost of DRAM used in AI servers roughly doubled in the first quarter of the year, with prices potentially rising fourfold across 2026. New production capacity may not come online until 2029 or 2030.

Before the memory shortage, choosing between an entry-level microprocessor and a high-performance microcontroller was largely a matter of architectural preference; both designs cost roughly the same. Today, an MPU and Linux design costs roughly $6 to $40 more per board, an increase driven almost entirely by the cost and scarcity of external DRAM.

For embedded manufacturers, the shortage is already putting production schedules, margins, and customer commitments under pressure.

The industry has given the situation several memorable names, including “RAMageddon.” The underlying issue is straightforward: artificial intelligence is consuming enormous quantities of memory, and the most profitable parts of the market are receiving priority.

AI Infrastructure Is Reshaping the Memory Supply Chain

AI accelerators require high-bandwidth memory, or HBM, a specialized form of DRAM stacked and placed close to the processor to move very large volumes of data quickly. They also require high-capacity DDR5, enterprise SSDs, advanced packaging, and other supporting components. As Microchip explains in its analysis of the AI hardware shortage, the pressure now extends well beyond GPUs.

IDC expects 2026 growth in DRAM and NAND supply to remain below historical norms, at 16% and 17% year over year respectively. Its analysis also describes a strategic shift in manufacturing capacity from conventional memory toward HBM and other components serving AI data centers.

This creates a difficult situation for manufacturers of connected products. Their devices may have nothing to do with training a large language model, yet they depend on parts coming from the same concentrated semiconductor ecosystem. The memory they rely on, even when not destined for AI servers, shares the very same wafer fabs. Memory makers are now reallocating entire production lines to the juicier AI memory business, pushing other product lines toward end-of-life to clear floor space for the golden goose.

Samsung is the clearest example: it stopped taking new DDR4 orders in mid-2025 to concentrate fab capacity on DDR5, LPDDR5, and HBM; in 2026, it began winding down LPDDR4 and LPDDR4X as well. These legacy parts did not become obsolete overnight; they simply stopped being the most profitable use of silicon. As a result, a smart meter, industrial controller, appliance, medical device, or building automation system can face steep cost increases and stretched lead times simply because hyperscalers got to the front of the line.

The Shortage Sits Around the MPU

The impact on embedded systems requires a technical distinction. A microprocessor, or MPU, typically provides the processing core but relies on external memory and peripherals. A microcontroller, or MCU, integrates the processor, memory, and many peripherals into a single device.

This means that MCU based products are generally spared from the memory situation, while an MPU-based product can be blocked even when the MPU itself remains available. If the associated DDR memory, eMMC storage, or external flash cannot be sourced at the required price and volume, the complete system cannot ship.

For many product teams, there is no easy way out. Qualifying an alternative memory supplier rarely solves the underlying problem: every memory vendor is navigating identical capacity pressures, and allocations promised on paper can vanish overnight. Switching to another MPU brings you right back to square one, because it still demands external RAM from that same constrained supply chain.

The Design Choice That Used to Make Sense

Choosing an MPU and embedded Linux was, for years, entirely rational. When RAM was cheap, a few hundred megabytes of DDR barely registered on the bill of materials, and Linux delivered real value: mature drivers, broad code reuse, and familiar developer tooling.

That arithmetic changes fast when memory prices surge. A companion DRAM chip that once looked like a rounding error can become one of the costliest lines on the schematic, multiplied across every unit shipped. The question quickly shifts from technical to financial: can margins justify a permanent hardware premium just to keep the comfort of a full Linux stack?

To put concrete numbers on that shift, consider two typical edge designs running at comparable clock speeds (~800 MHz to 1 GHz) at volumes of roughly 100,000 units:

• MPU + Linux: An ~800 MHz Cortex-A7 (such as the STM32MP13 or i.MX6ULL) with 256 MB DDR3L and 256 MB SPI-NAND storage.
• MCU + FreeRTOS: A ~1 GHz Cortex-M7 or M85 (such as the i.MX RT1170 or Renesas RA8) with on-chip SRAM, 16 MB QSPI NOR flash, and 8 MB PSRAM.

The processor itself is not the problem: a 1 GHz MCU often costs as much as, or more than, an entry-level MPU. The $10 cost gap comes from everything the MPU requires around it: volatile DRAM, a dedicated PMIC, and a PCB with more routing layers.

Other operational factors tilt the balance even further toward the MCU, even if they are harder to price on a single bill of materials:

• Software maintenance: Keeping a Linux system patched over a 15-to-20-year meter or industrial device life, especially under the EU Cyber Resilience Act, requires continuous kernel and CVE monitoring. FreeRTOS has an inherently smaller attack surface.
• Power budget: An MPU with DDR draws two to four times more power than an MCU, which directly affects power-supply sizing and backup capacitor requirements.
• Boot latency: Linux takes 5 to 20 seconds to boot, versus under a second for an MCU.
• Long-term availability: With major memory vendors phasing out DDR3 and DDR4, an MPU design risks a costly redesign mid-lifecycle just to source memory.

For products that can fit on an MCU, changing the physical board is manageable. The real roadblock is porting the software: rewriting a Linux codebase for an RTOS is slow, expensive, and risks losing the modern platform versatility developers rely on.

Software Containers Bring Supply Chain Agility

For companies that have invested in the right software foundation, that transition looks remarkably different.

By decoupling the application lifecycle from the hardware lifecycle, virtualization and lightweight software containers allow teams to switch silicon platforms on demand. They bring the application sophistication once reserved for multi-gigahertz microprocessors down to low-cost, low-power microcontrollers, all while keeping products upgradable once deployed in the field. MicroEJ’s Software-Defined Everything whitepaper explores this paradigm in detail. MICROEJ VEE provides a virtual execution environment that can run across MCUs, MPUs, and SoCs, as well as operating environments including RTOS platforms, Linux, and bare metal. The application runs above a hardware-specific native layer, which means the product team can preserve a much larger portion of its business logic and user experience when the underlying processor changes.

The NXP and MicroEJ Platform Accelerator illustrates this model across NXP’s MCU and MPU portfolio. It supports application portability across RTOS-based microcontrollers and Linux-based application processors, helping manufacturers reuse software while adapting the hardware platform.

Processors still require hardware-specific work, including board support, peripheral integration, performance validation, power optimization, and regulatory testing. The application can nevertheless move between platforms without being rewritten from the ground up.

Portability Becomes a Supply-Chain Strategy

Manufacturers should build software portability into their sourcing strategy before a crisis begins. Three actions can make a meaningful difference:

1. Define a fallback hardware platform early. A second-source strategy is far more valuable when it has been tested before the first allocation notice arrives.
2. Separate application code from hardware services. The user experience, product logic, and update mechanisms should not depend unnecessarily on vendor-specific registers and drivers.
3. Design for both MPU and MCU-class execution where practical. Today’s microcontrollers handle animated touch interfaces, Matter and BLE connectivity, and on-device intelligence within a few megabytes of integrated memory. With the right software architecture, an MCU can often provide the same experience at a lower cost and with lower power.
4. Treat double sourcing as insurance. In one modeled example, a 30% component shortfall on a product selling one million units at $100 each would put $30 million of revenue at risk, while the avoided cost of the missing $3 components would be only $900,000. The figures are illustrative, but the trade-off is clear: a small component saving can expose the business to a much larger loss.

MicroEJ has guided multiple manufacturers through this exact memory bottleneck. Across smart metering, medical devices, consumer products, and industrial automation, OEMs have successfully migrated production programs from MPU architectures to integrated MCUs without losing their software investment.

MicroEJ’s recent work in smart metering follows the same principle: separating the application lifecycle from the hardware lifecycle allows devices to gain new capabilities over many years in the field. The MicroEJ smart meter software article explores how this model can also support new software-driven business opportunities.

The memory shortage brings the value of this separation into sharper focus.

The current crisis will eventually change shape. Memory prices will move, new fabs will open, and technology priorities will evolve. The companies best prepared for that future will be able to change suppliers, processors, and product configurations without abandoning the software that creates their customer value.

In embedded systems, software agility is becoming a practical form of supply-chain resilience. It can reduce dependence on any single processor family, make MCU alternatives commercially viable, and give product teams room to keep shipping when the hardware market becomes unpredictable.