Microcontroller memory limitations [duplicate]

Question

I am really not able to understand why, when our personal computer memory is increasing in terms of gigabytes, the microcontroller memory is not increasing at that speed for both flash and RAM? What limitations are we facing for both kinds of memory?

Answer 1

Several reasons. First, microcontrollers are generally not built with the same bleeding edge processes as the DRAM and Flash for your computer, so they do not take advantage of technological advance to the same extent. These bleeding edge processes do have disadvantages, including I/O pin voltage tolerance (the upper limit for bleeding edge processes might be 1.8 or 1.2 volts, in contrast with 5 or 3.3 volts for many microcontrollers), special core supply voltages (1.0 or even 0.9 volts), higher leakage current, etc. Second, microcontrollers are generally built on one piece of silicon, so the process cannot be optimized for logic, DRAM, and Flash at the same time. Microcontrollers also generally use SRAM instead of DRAM, which takes up a lot more space but consumes less power and does not require refreshing. Also, the flash used in microcontrollers is usually the more robust and less dense NOR flash. This type of flash memory can be read out directly with no post-processing. It also supports more read and write cycles. Most SSDs, flash drives, etc. use NAND flash. This type of flash memory is not as robust as NOR flash, especially when capacity-multiplying tricks such as multilevel cells are used. The raw flash memory is actually prone to error quite often and the cells do not have a particularly long life, so lots of extra processing is required to correct the errors and perform wear-levelling. This requires lots of additional logic and consumes more power.

See also: Why do microcontrollers have so little RAM?

and: Precise differences between DRAM and CMOS processes

Answer 2

Microcontrollers, with a few exceptions, have all of their memory -- both program Flash and RAM -- on the same chip as the CPU. They do this to free up the pins on the chip for on-board peripheral, such as GPIO ports, UARTs, SPI and I2C busses, USB, PWM and others. This allows systems to be built with just a microcontroller and a few other parts. Microcontrollers are very cheap compared to microprocessors, the low end PICs for example start around thirty cents.

To support external memory requires an address bus and data bus, and for a 32-bit microcontroller that uses up 64 pins right there, plus control lines. Even early microprocessors didn't have enough pins to handle that, for example a 68000 in a 64-pin DIP had address lines A1 through A23, and data lines D0-D16. Address and data lines can also be multiplexed, by first latching the address and holding it while the memory access is performed.

Early microprocessors, which were used on the first PC's and were typically housed in 40-pin DIP packages, had very few on-board peripherals if any and thus could afford to use their pins for address and data lines. But that is no longer an issue, as microprocessors now have many more pins than microcontrollers. Microcontrollers may have anywhere from eight pins to over a hundred while some microprocessors such as one variation of the Intel i7 have over 2000 pins. This processor retails for $584 at Newegg, a far cry from 30 cents. Note: that doesn't include any memory cost (see below).

Microprocessors usually don't have any memory built into the chip (except caches). Instead they tend to have lots (GB's) of external dynamic RAM, typically plugged into DIMM sockets. They also usually don't have any internal read-only memory, that is also external. The external ROM is only used for the initial boot code, which reads a second level boot off whatever device is being used (usually a hard drive, but could be a CD, DVD or USB stick).

Answer 3

The main reason, of course, is cost. Even slow standalone RAM costs several dollars per gigabyte, and comes in a rather large package. The process limitations that Alex described in his answer are very real, and would massively increase the cost of on-chip DRAM for a microcontroller. Even if the cost were the same, several dollars is a big price increase for an MCU. You'd need a compelling reason for that kind of upgrade, and embedded control rarely gives you one.

But let me turn this question around -- why on earth does a PC need billions of bytes of storage? The Apollo 11 guidance computer had 4 kB of RAM and 72 kB of ROM. Twenty years ago you could do most tasks with 4 MB of RAM. Fifteen years ago a computer with 64 MB of RAM was sufficient for office use, web browsing, listening to music, etc. Reasonable quantities of text fit into tens of kilobytes, compressed images of good quality are under a megabyte, and 1920x1080 still images are under ten megabytes, and we still mainly deal with that same kind of data. What changed to justify using a thousand times as much storage space?

Multimedia -- higher-resolution displays with more colors, HD video, and high-quality sound, all relying on intensive decoding algorithms to adapt to bandwidth limits. User interfaces went along for the ride. Operating systems started doing more and more work. Games use as much hardware as they can get. And underneath it all, layer upon layer of software frameworks to make high-level programming easier and more reliable. Despite all that, PC sales have stagnated, with users having less and less reason to upgrade their hardware.

But all of that stuff is optional. Strip away the graphics, the interface, and the operating system, and even a 16 MHz CPU becomes a powerful machine for calculation. An MCU is mainly monitoring and responding to events in real-time, so it doesn't take much memory to define the state. You're programming on bare metal (or maybe a minimal RTOS), so software overhead is minimal. There's task-specific hardware to handle most of the high-speed work like timing and communications, which further reduces the CPU and RAM requirements. Now you have a system where you can do quite a lot of work in a few kilobytes of program and data space.

If you need more storage space, you can add off-chip RAM or flash, or even send data to a remote PC. But for most MCU applications, extra capacity on the chip would go unused. So why pay for it? Your end customers will not be impressed by how much RAM is in a motor controller or a power supply module.

For an example of this type of design on a PC, look at MemTest86, which comes on a disc image that's only 10 megabytes, and that includes Linux!