38
\$\begingroup\$

Maybe this is more of a perceptional problem, but it seems like microcontrollers have advanced by leaps and bounds in the last 20 years, in almost all regards, higher clock speed, more peripherals, easier debugging, 32-bit cores, etc...

It is still common to see RAM in the 10's of KB (16/32 KB).

It doesn't seem like it could be an issue of cost or size directly. Is it an issue of complexity with the RAM controller above some threshold?

Or is it just that it isn't generally required?

Looking over a parts matrix at a popular Internet supplier, I see one Cortex M4 with 256 KB for less than US$8, and then for a few dollars more you can find a few more that are ROMless, but it seems pretty sparse...

I don't exactly have a need for a microcontroller with a MB of volatile storage, but it seems like somebody might...

\$\endgroup\$
  • 8
    \$\begingroup\$ Perhaps there is a more technical reason, but to me it seems like it may be a question of markets. You use microcontrollers when you have applications that use them, when you need something more power you usually move to a more complete embedded system. \$\endgroup\$ – Jarrod Christman Oct 15 '14 at 19:52
  • 14
    \$\begingroup\$ 10s of kB. That's huge. My go-to microcontroller to use in prototyping stuff has 68 bytes of RAM: en.wikipedia.org/wiki/PIC16x84 \$\endgroup\$ – slebetman Oct 16 '14 at 0:16
  • 2
    \$\begingroup\$ I once wrote a 3D software rasterizer in 86B on an Arduino with 2KB RAM. It made me upset because if I'd had even 10KB or 50KB I could have actually started fitting real models in memory and done something interesting.¶ I actually had exactly this same question at the time, and I don't think the current answers address it well enough. Yes SRAM is expensive--but CPUs have megabytes of cache made out of SRAM, and yet they're still quite cheap. It feels like a lame excuse. \$\endgroup\$ – imallett Oct 16 '14 at 0:53
  • 2
    \$\begingroup\$ @slebetman any reason you like a 20-year old micro when much better devices are more widely available and cheaper? \$\endgroup\$ – markrages Oct 16 '14 at 17:32
  • 3
    \$\begingroup\$ it seems like somebody might is the catch here, most people don't. You're not exactly going to stream Netflix on that chip, and the 64K is usually more than enough for everything you need to do with a microcontroller. If you want to go higher, get a full blown comp, e.g., a raspberry. \$\endgroup\$ – TC1 Oct 16 '14 at 20:56
44
\$\begingroup\$

There are several reasons for this.

First of all, memory takes up a lot of silicon area. This means that increasing the amount of RAM directly increases the silicon area of the chip and hence the cost. Larger silicon area has a 'double whammy' effect on price: larger chips mean less chips per wafer, especially around the edge, and larger chips means each chip is more likely to get a defect.

Second is the issue of process. RAM arrays should be optimized in different ways than logic, and it is not possible to send different parts of the same chip through different processes - the whole chip must be manufactured with the same process. There are semiconductor foundaries that are more or less dedicated to producing DRAM. Not CPUs or other logic, just straight up DRAM. DRAM requires area-efficient capacitors and very low leakage transistors. Making the capacitors requires special processing. Making low leakage transistors results in slower transistors, which is a fine trade-off for DRAM readout electronics, but would not be so good for building high performance logic. Producing DRAM on a microcontroller die would mean you would need to trade off the process optimization somehow. Large RAM arrays are also more likely to develop faults simply due to their large area, decreasing yield and increasing costs. Testing large RAM arrays is also time consuming and so including large arrays will increase testing costs. Additionally, economies of scale drive down the cost of separate RAM chips more so than more specialized microcontrollers.

Power consumption is another reason. Many embedded applications are power constrained, and as a result many microcontrollers are built so that they can be put into a very low power sleep state. To enable very low power sleep, SRAM is used due to its ability to maintain its contents with extremely low power consumption. Battery backed SRAM can hold its state for years off of a single 3V button battery. DRAM, on the other hand, cannot hold its state for more than a fraction of a second. The capacitors are so small that the handful of electrons tunnel out and into the substrate, or leak through the cell transistors. To combat this, DRAM must be continuously read out and written back. As a result, DRAM consumes significantly more power than SRAM at idle.

On the flip side, SRAM bit cells are much larger than DRAM bit cells, so if a lot of memory is required, DRAM is generally a better option. This is why it's quite common to use a small amount of SRAM (kB to MB) as on-chip cache memory coupled with a larger amount of off-chip DRAM (MB to GB).

There have been some very cool design techniques used to increase the amount of RAM available in an embedded system for low cost. Some of these are multi chip packages which contain separate dies for the processor and RAM. Other solutions involve producing pads on the top of the CPU package so a RAM chip can be stacked on top. This solution is very clever as different RAM chips can be soldered on top of the CPU depending on the required amount of memory, with no additional board-level routing required (memory busses are very wide and take up a lot of board area). Note that these systems are usually not considered to be microcontrollers.

Many very small embedded systems do not require very much RAM anyway. If you need a lot of RAM, then you're probably going to want to use a higher-end processor that has external DRAM instead of onboard SRAM.

\$\endgroup\$
  • \$\begingroup\$ I have seen actual RAM ICs with legs and everything glued/placed on top of processors (which are BGA packages) and routed into them! The things we do for board space!! As the Russians point out with their TRIZ methodology of design, if you run out space in X and Y, go to Z :) \$\endgroup\$ – KyranF Oct 15 '14 at 20:31
  • 2
    \$\begingroup\$ +1 For the important distinction between SRAM and DRAM. SRAM is both faster and more energy efficient particularly when idle, but as you note, considerably more expensive and requires more space. \$\endgroup\$ – fizzle Oct 15 '14 at 20:32
  • \$\begingroup\$ I don't think SRAM is the most expensive sort of RAM. A combination of flip flops and multiplexers can be used as a random access memory which will offer better performance than SRAM, but at a much greater silicon cost. Such memories don't usually get much bigger than about 32 words, but such a memory can accommodate simultaneous reads and writes in ways that an SRAM cannot. \$\endgroup\$ – supercat Oct 16 '14 at 17:36
  • 1
    \$\begingroup\$ True, register files and full flip-flops are more expensive than SRAM, but they aren't used for general purpose system memory. \$\endgroup\$ – alex.forencich Oct 16 '14 at 22:22
  • 1
    \$\begingroup\$ I've seen a working HTTP server on an MCU with 160kB of SRAM and no external DRAM. It couldnt't handle many parallel connections but it worked. \$\endgroup\$ – Jan Dorniak Jan 11 '18 at 14:21
15
\$\begingroup\$

Memory probably takes up the most silicon space, and RAM being very fast to use is volatile - and uses power constantly to keep its state. Unless you need lots of RAM, it's not useful for many other applications. If an embedded system designer needs more RAM, they merely get an external RAM chip and use peripheral memory interfaces that microcontrollers often have these days for very easy plug and play memory extension. That is the reason I see as why microcontrollers in general still have reasonable low onboard RAM, because reasonable application code and use-case scenarios normally do not need much.

When you start getting up to the larger architectures that need to run full on operating systems, then RAM becomes extremely important, however this gets out of the realm of microcontrollers and into embedded computers more like those you see in the Beaglebone and Raspberri Pi boards these days. And even at this stage, the processors are so complex and so full of features that they have no room for the amount of RAM needed for their task so external memory is pretty much required for them to operate at all.

EDIT:

As a personal anecdote, I recently made a small autonomous robot control board with the aim of using it for low resolution computer vision like motion detection and object tracking and following. I chose a low pin-count ARM Cortex M3 for this task and while looking at Atmel's selection of their SAM3 series processors, I indeed went for the highest RAM I could find - because in this case I did not want to buy an external RAM IC due to board space and not wanting the complexity of a high speed RAM memory bus on the PCB. In this case for my particular application, I would have very much liked to have the option of many 100's of KB more RAM if possible. I ended up only having 48KB SRAM but further designs I will get a higher pin count package and make use of the parallel data capture peripheral to rout 8-bit camera pixel data straight into an external RAM chip.

\$\endgroup\$
  • \$\begingroup\$ good point I didn't even think about power consumption... \$\endgroup\$ – Grady Player Oct 15 '14 at 20:26
  • 4
    \$\begingroup\$ "and RAM being volatile but very fast to use, uses power constantly to keep it's state" barely. CMOS logic, SRAM included, uses extremely little power when not changing state. Notice that most microcontrollers retain their RAM contents even when in extremely low consumption power down modes. \$\endgroup\$ – Chris Stratton Oct 15 '14 at 22:07
  • \$\begingroup\$ @ChrisStratton: I've seen a number of microcontrollers, from a couple different manufacturers, with modes that shut down some of their RAM to save power, although somewhat annoyingly the ones I've seen don't allow the RAM to be powered up without a system reset. Not sure what the purpose of that latter restriction is; if I need a big chunk of RAM for temporary storage during certain operations, but not otherwise, I don't see why I shouldn't be able to power it on when needed and off when not, but I've not seen such a feature. \$\endgroup\$ – supercat Oct 16 '14 at 17:30
14
\$\begingroup\$

Besides the excellent points brought up in the other answers, another reason for limited RAM is the architecture of the microcontroller. For example, take the the Microchip PIC10LF320, which has only 448 bytes of program (flash) memory and 64 bytes of RAM. But it probably costs only 25ȼ (or less) in large quantities. The limited size of the PIC10 instruction word (12 bits) allows it to only address 128 bytes of RAM directly.

I am sure there are other microcontrollers out there that only have an 8-bit address bus, limiting them to 256 bytes of RAM.

But most mid-range microcontrollers (even those with 8-bit data paths), have a 16-bit address bus. A major architectural consideration for these chips is whether the chip uses Harvard or Von Neumann architecture.

Most microcontrollers uses Harvard architecture, which has separate 16-bit address spaces for program memory, RAM, and memory-mapped I/O addresses. So for these, the 16-bit address bus can access up to 64K (65,536) bytes of RAM. There is still a 64K limit placed by the architecture, and if one wants to go above that some sort of paging must be used. It is much more common to have paging for program space rather than RAM space.

Microcontrollers using Von Neumann architecture, such as the Freescale HCS08 line, have just one address space divided up between the program memory, RAM and memory-mapped I/O. In order to have a reasonable amount of program space, this limits the amount of RAM to typically 4K or 8K. Again, one can use paging to increase the available program or RAM space.

\$\endgroup\$
  • 1
    \$\begingroup\$ You have to keep in mind though, that the PIC core is so utterly code ineffective, that it will consume lots of extra flash for nothing. And one reason it doesn't need a lot of RAM, is because it has severe restrictions on for example call stack depth. \$\endgroup\$ – Lundin Oct 28 '14 at 12:01
  • \$\begingroup\$ @Lundin Agreed, you pretty much have to program the original PIC10 and PIC12 in assembly language, very carefully. The newer PIC12F and PIC16F devices now have a 16-level hardware stack and 14 new instructions. some added just for C, so they are a lot more usable. \$\endgroup\$ – tcrosley Oct 28 '14 at 16:25
  • \$\begingroup\$ @Lundin: The PIC chips with 12- and 14-bit instruction lengths were pretty decent for code density I thought. The PIC18F is were code density really tended to fall off when using the HiTech compiler due to the excessive amount of bank switching which was typically required. \$\endgroup\$ – supercat Sep 30 '15 at 20:57
7
\$\begingroup\$

Having worked with microcontrollers and small systems for a good while now, I'd like to point out that quite often very little RAM is needed. Remember that even though an MCU may be capable of accomplishing a great deal, the trend these days is to use many more MCUs then ever before, and to use more of them to distribute many tasks in larger systems. This combined with the fact that unlike bloated development systems needed to program in Windows, MCU development often uses very well optimized compilers, most often with very efficient C and C++ source code, sometimes with little to no OS overhead at all. While you could scarcely write a Windows program to display your name on any device without consuming at least hundreds of kilobytes including OS resources, you usually can accomplish the same on an LCD display with an MCU in way less than 256 bytes, including library and low level BIOS support!

For sure, there are cost and space issues as others have pointed out. But the history at hand here is that what is considered a small amount of RAM by newcomers these days is really quite a bit more than ever before, and all the while the components and devices the MCU will need to interface with are themselves getting smarter. Honestly, my largest use of RAM in many MCU applications lately has been for interrupt driven communication buffers, to free up the MCU for other tasks without fear of losing data. But believe it or not, for ordinary logic and computational functionality, MCUs are pretty well matched to their limited built in RAM and flash resources, and you really can do a lot with very little.

Keep in mind that once upon a time, famous Video games with crude graphics but complex game logic like "PAC Man" and "Space Invaders" were typically done within 8K ROMS, on machines that barely had 8 or 16 KB of RAM!

\$\endgroup\$
  • \$\begingroup\$ What about SD cards? Don't SDHC cards require a buffer of 256 or 512 bytes (the standard/old SD cards are no longer produced)? \$\endgroup\$ – Peter Mortensen Oct 16 '14 at 15:27
  • \$\begingroup\$ The version of Pac Man for the Atari 2600 Video Computer System was 4K ROM, and the VCS itself had 128 bytes of RAM. Many arcade machines had a fairly decent chunk of ROM and RAM, however, compared with home computers of the era. I think Defender, for example, had 32K or ROM and 64K of RAM, though 32K of RAM was "write-only" from the CPU's point of view (the processor would put data there which the display hardware would clock out to the monitor). \$\endgroup\$ – supercat Oct 16 '14 at 17:27
  • \$\begingroup\$ @PeterMortensen Many SD cards have an integrated CPU of some sort to manage the flash. Some cards have a full 32 bit ARM core that likely has 16 or 32K of RAM attached to it. \$\endgroup\$ – alex.forencich Oct 16 '14 at 22:28
  • \$\begingroup\$ @alex.forencich: Yes, but don't the SPI interface for operating an SDHC SD card require a buffer on the host side (embedded system/microcontroller) - in contrast to the older cards? That is, bit addressing is no longer possible for the newer (SDHC) cards? Or is it only dependent on the file system (bit addressing still possible)? Don't the newer cards require block transfers (and thus requiring a buffer of 256 or 512 bytes)? \$\endgroup\$ – Peter Mortensen Oct 17 '14 at 8:09
  • \$\begingroup\$ Yes, 512B, if I recall. You could just write an unefficient SD card driver, to discard first X bytes of data -> no "large" buffer needed. \$\endgroup\$ – domen Oct 17 '14 at 8:41
3
\$\begingroup\$

Besides the excellent points about cost and manufacturing, there is surprisingly little demand for a lot of on-chip RAM.

I often work with microcontrollers with flash in the tens of kB (16kB, 32kB) and RAMs in the kB range (1kB, 2kB). I very often run out of flash, and almost never run out of RAM. In most of my projects I get pretty close to the flash limit, but usually need much less than 20% of the RAM.

Most very small microcontrollers have two different kinds of roles:

  • regulation and control: they have to control a piece of machinery. Even in case of a complicated controller algorithm, which can take up tens of kB of code space, very little RAM is required. You are in the control of a physical process, and have variables containing a few physical units, and maybe a few variables as loop counters. No need for more.

  • data processing: in the rare case you need to store a large amount of data the same time, you can use external RAM. Pretty much all modern microcontrollers have native support for it. If you need a simple program using a lot of memory, it will be both cheaper and smaller to use a small microcontroller and external RAM, rather than a high-level microcontroller. Nobody produces controllers with few ports, small flash and large RAM, because there is so little demand for them.

\$\endgroup\$
2
\$\begingroup\$

All of the already mentioned reasons are, of course, technically valid and accurate. However, do not forget electronics is a business and MCUs is one of the most competitive niche markets within the electronics industry.

I dare to say the actual reasons for linking the price tag of an MCU to the amount of embedded SRAM are mainly marketing reasons, not cost reasons:

  • In most designs, maximum attainable clock frequency is not the limiting factor. Instead, the amount of available SRAM is. Don't get me wrong, CPU frequency is hugely important, however, within a certain MCU family segment, you don't usually get offered different device models at different prices based on the maximum CPU frequency. Also, Flash program storage is the other key limiting factor, however, I won't focus too much on Flash (the question is directed specifically to SRAM).

  • The amount of available SRAM is directly related to the level of complexity you will be able to embed in your MCU, be it with third party libraries or with your own rolled out code. So it is a "natural" metric to segment on base your MCU prices on. It is understandable for a technical customer to accept that a MCU capable of more complex tasks (more SRAM, more Flash storage) should cost more. Price, here, is a reflexion of the underlying value (delivering capabilities) of the MCU. Flash storage is usually offered in an amount proportional to the SRAM.

  • On the contrary, if you take the desktop and mobile CPU market, you don't usually can source an specific MCU/CPU with many different SRAM sizes. Instead, the pricing schema is usually built on top of the execution/performance capabilities of the MCU/CPU: frequency, number of cores, power efficiency...

\$\endgroup\$
  • \$\begingroup\$ I think this is probably accurate, but is there evidence? Like scratching out traces to sell chip a as chip b? \$\endgroup\$ – Grady Player Oct 28 '14 at 13:16
  • \$\begingroup\$ Uhm... interesting thought. I do not have evidence of such practices. However, it brings an interesting question about the underlying manufacturing costs. Would it be more expensive the wasted real estate of the silicon chip (wafer) in case there was a higher SRAM size chip scratched out to a less SRAM size? Or the increased manufacturing and inventory costs associated to manufacture not a single device but two? I am afraid the whole electronics industry is very picky about openly discussing their costs. We may never know it. \$\endgroup\$ – jose.angel.jimenez Oct 28 '14 at 14:03
  • 1
    \$\begingroup\$ For evidence: the MT6250 is a multi-die chip,used for single chip feature phones, costs less than $2 in volume and is much more complex than an mcu, and include a 8MB sram die.It would be trivial to build, using similar technology an SRAM rich mcu. \$\endgroup\$ – hulkingtickets Nov 28 '14 at 13:54
  • \$\begingroup\$ This would be a good answer to "why is the price tag of the MCU linked to the amount of embedded SRAM?". But it doesn't seem to answer the original question. Why are there so few microcontrollers available with more than 512 KB SRAM on-chip, at any price? Why are there so many microcontrollers with "weird" non-power-of-2 sizes of SRAM, when dedicated SRAM chip manufacturers seem to think that the reduced inventory costs make it worth only producing dedicated SRAM chips in powers-of-2 sizes? \$\endgroup\$ – davidcary Jul 12 '16 at 16:00
1
\$\begingroup\$

So first you have to consider that 16 KB or 32 KB are an enormous amount of memory and most microcontrollers sold today do not have such large amounts of RAM.

Many microcontroller programs need 10 or 50 Bytes of memory. Even more complex stuff needs mostly in the hundreds of Bytes.

Basically there are three use cases where you need RAM in the order of KBytes: a) When your microcontroller does graphics b) when you use microcontroller for large arbitrary calculations c) when you interface with PC interfaces

Second please note that if you talk about microcontroller RAM you talk about Level 0 / Level 1 cache. If you consider that an Intel Haswell has "only" 64 KByte of Level 1 cache you will reconsider the RAM size of a microcontroller.

Third you can attach any amount of external RAM to a microcontroller, especially even more than you can attach to a CPU.

Personally I am developing many microcontroller applications and I never needed 1 KB of memory nor even more. I also never used external RAM.

Things are different if we come to ROM (today Flash), as your program and data is in the ROM. There are really many applications where you attach external ROM to your microcontroller, because you have many data.

Let's examine an example: Let's analyze a microcontroller application and we take a portable MP3 player with display and 4 Gigabytes of Flash.

For this application you need maybe 1 KB RAM. That is enough to do the job. However you could use some more RAM for larger buffers to speed up USB to Flash writing.

You see the difference now: A typical PC holds all programs and data in RAM. Therefore it needs lots of RAM. For microcontroller this is all in Flash/ROM.

\$\endgroup\$
  • 2
    \$\begingroup\$ You underestimate the RAM usage in many applications. Not by a huge amount, but maybe by a factor of 10-100 depending on the instance. MP3 players have to do digital signal processing. \$\endgroup\$ – Jason S Feb 6 '15 at 14:52
  • \$\begingroup\$ I'd like to know why either of you are saying these things. What kinds of C commands require RAM. Rather than saying "these applications require more RAM," I'd prefer "these operations require more RAM, because..." \$\endgroup\$ – Frederick Apr 15 '15 at 20:12
-1
\$\begingroup\$

While designing an MCU, you have to face conditions which are not that important on PCs.

  1. Durability

    To choose the components, you don't neccessarily take the best or/and most high performance parts, but those that have proven to run proper after several years of usage, will be available for several years and are capable to running 24/7 for years. Due to this circumstance, if a controller is on market for several years, doing its job fine, it seems to have poor RAM, compared with the PC standard today. But anyway, it does its job fine, and there should be no need for replacement, if the engineering was well.

  2. Space

    Microprocessor units literally are micros. You have to cut down the needed space to the absolute minimum. Of course, you can get a 256 MB at the same space as 10-years-old 64 KB chips. This is where #1 comes to point.

  3. Price

    Not only the purchase price, but also the power consumption. You don't want to design an MCU that has control over an entry-system, that needs 1000 W, if your rival in business has one that only needs 25 W. And of course, cheaper purchase price (at the same quality) is always better.

\$\endgroup\$
  • 1
    \$\begingroup\$ that is a really high power microprocessor! \$\endgroup\$ – KyranF Oct 16 '14 at 13:18
  • 2
    \$\begingroup\$ I'm guessing a 1kW MCU wouldn't stay in a solid state very long. \$\endgroup\$ – Dan Bryant Oct 17 '14 at 16:52
  • 1
    \$\begingroup\$ All three points are extremely important in PC design nowadays. \$\endgroup\$ – Keelan Oct 19 '14 at 6:34
  • \$\begingroup\$ @KyranF: Yes, divide both numbers by 100. But if anything, he's understated the relative power difference between high performance processor and low power microcontrollers for battery applications. \$\endgroup\$ – Ben Voigt Oct 28 '14 at 12:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.