为什么微控制器的RAM这么少?


39

也许这更多是一个感知问题,但是在过去的20年中,微控制器似乎在飞跃发展,几乎在所有方面,更高的时钟速度,更多的外设,更容易的调试,32位内核等。

看到RAM以10的KB(16/32 KB)为单位仍然很常见。

看来这可能不是直接影响成本或规模的问题。RAM控制器超过某个阈值是否会带来复杂性问题?

还是只是通常不需要它?

在一个受欢迎的互联网供应商的零件矩阵上,我看到一个256 KB的Cortex M4不到8美元,然后再花几美元,您可以找到更多没有ROM的东西,但是看起来很稀疏...

我完全不需要具有MB易失性存储的微控制器,但似乎有人可能会...


8
也许还有更多的技术原因,但在我看来,这可能是市场问题。当您拥有使用微控制器的应用程序时,就需要使用微控制器;当您需要更多功能时,通常会转向更完整的嵌入式系统。
Jarrod Christman 2014年

15
10s的kB。好大 我在原型制作中使用的微控制器具有68 个字节的RAM:en.wikipedia.org/wiki/PIC16x84
slebetman 2014年

2
我曾经在带有2KB RAM的Arduino上用86B编写了3D软件光栅化器。这让我很沮丧,因为如果我只有10KB或50KB,我本可以开始在内存中拟合真实模型并做一些有趣的事情。¶当时我确实有同样的问题,我不认为当前的答案解决得足够好。 是的, SRAM很昂贵-但是CPU具有以SRAM制成的兆字节缓存,但它们仍然很便宜。感觉就像是me脚的借口。
imallett 2014年

2
@slebetman是什么原因让您喜欢拥有20年历史的微型设备,而更便宜的设备更广泛,更便宜?
2014年

3
it seems like somebody might是这里的问题,大多数人没有。您并不是要在该芯片上流式传输Netflix,而64K通常足以满足您使用控制器进行的所有操作。如果您想走得更高,请拿一个完整的小玩意儿,例如覆盆子。
TC1 2014年

Answers:


44

有几个原因。

首先,内存占用大量的硅面积。这意味着增加RAM的数量会直接增加芯片的硅面积,从而增加成本。更大的硅面积对价格产生“双重打击”:更大的芯片意味着每个晶圆的芯片数量减少,尤其是在边缘附近,而更大的芯片则意味着每个芯片更容易出现缺陷。

第二是过程问题。RAM阵列应该以不同于逻辑的不同方式进行优化,并且不可能通过不同的过程发送同一芯片的不同部分-整个芯片必须以相同的过程制造。有些半导体公司或多或少致力于生产DRAM。不使用CPU或其他逻辑,仅使用DRAM。DRAM需要面积高效的电容器和极低泄漏的晶体管。制作电容器需要特殊处理。制造低漏电晶体管会导致晶体管变慢,这对于DRAM读出电子设备来说是一个很好的权衡,但是对于构建高性能逻辑来说却不是那么好。在微控制器芯片上生产DRAM意味着您将需要以某种方式权衡工艺优化。大型RAM阵列也很可能仅由于其面积大,产量下降和成本增加而出现故障。测试大型RAM阵列也很耗时,因此包含大型阵列将增加测试成本。此外,与更专业的微控制器相比,规模经济进一步降低了独立RAM芯片的成本。

功耗是另一个原因。许多嵌入式应用受功率限制,因此,许多微控制器被构建为可以置于非常低功率的睡眠状态。为了实现非常低的功耗睡眠,使用SRAM的原因在于它能够以极低的功耗保持其内容。电池供电的SRAM可以保持状态,即使是3V纽扣电池也可以使用多年。另一方面,DRAM不能保持其状态超过一秒钟的时间。电容器是如此之小,以至于少数电子会隧穿并进入基板,或者通过单元晶体管泄漏。为了解决这个问题,必须连续读出并回写DRAM。结果,在空闲状态下,DRAM比SRAM消耗更多的功率。

另一方面,SRAM位单元比DRAM位单元大得多,因此,如果需要大量内存,则DRAM通常是更好的选择。这就是为什么使用少量SRAM(kB到MB)作为片上高速缓存存储器以及大量的片外DRAM(MB到GB)的原因。

已经有一些非常酷的设计技术用于以低成本增加嵌入式系统中可用的RAM数量。其中一些是多芯片封装,其中包含用于处理器和RAM的单独管芯。其他解决方案包括在CPU封装的顶部生产焊盘,以便将RAM芯片堆叠在顶部。该解决方案非常聪明,因为可以根据所需的内存量将不同的RAM芯片焊接到CPU顶部,而无需其他板级路由(内存总线非常宽,占用了很多板面积)。请注意,这些系统通常不被视为微控制器。

无论如何,许多非常小的嵌入式系统都不需要太多的RAM。如果需要大量RAM,则可能需要使用具有外部DRAM而不是板载SRAM的高端处理器。


我已经看到了实际的带脚的RAM IC,并将所有东西粘贴/放置在处理器(它们是BGA封装)的顶部,并路由到其中!我们为板空间做的事情!正如俄罗斯人使用TRIZ设计方法所指出的那样,如果您
用不完

2
+1对于SRAM和DRAM之间的重要区别。SRAM不仅速度更快,而且能源效率更高,尤其是在空闲时,但正如您所指出的那样,其价格昂贵得多,并且需要更多空间。
2014年

我认为SRAM不是最昂贵的RAM。触发器和多路复用器的组合可以用作随机存取存储器,它将提供比SRAM更好的性能,但是硅成本要高得多。这样的存储器通常不会超过约32个字,但是可以以SRAM无法实现的方式容纳同时读写。
2014年

1
的确,寄存器文件和完整触发器比SRAM贵,但它们不用于通用系统存储器。
alex.forencich 2014年

1
我已经看到在具有160kB SRAM且没有外部DRAM的MCU上可以正常工作的HTTP服务器。它无法处理许多并行连接,但可以正常工作。
Jan Dorniak '18年

15

内存可能会占用最大的硅空间,而使用速度非常快的RAM易失性-并不断使用电源来保持其状态。除非您需要大量的RAM,否则它对许多其他应用程序都没有用。如果嵌入式系统设计人员需要更多的RAM,则只需获得一个外部RAM芯片,并使用微控制器通常具有的即插即用内存扩展的外围存储器接口即可。这就是我认为微控制器通常仍具有合理的板载RAM的原因,因为合理的应用程序代码和用例场景通常不需要太多。

当您开始需要在操作系统上完全运行的更大的体系结构时,RAM变得非常重要,但是这已经脱离了微控制器的领域,进入了嵌入式计算机,就像在Beaglebone和Raspberri Pi板上看到的那样。天。即使在此阶段,处理器也是如此复杂且功能如此丰富,以至于它们没有足够的空间容纳执行任务所需的RAM量,因此,运行它们几乎需要外部存储器。

编辑:

作为个人轶事,我最近制作了一个小型自主机器人控制板,旨在将其用于低分辨率计算机视觉,例如运动检测,对象跟踪和跟踪。我选择了一个低引脚数的ARM Cortex M3来完成此任务,在查看Atmel选择的SAM3系列处理器时,我的确选择了我能找到的最大RAM-因为在这种情况下,我不想购买外部RAM IC由于电路板空间大,并且不希望PCB上具有高速RAM存储器总线的复杂性。在这种情况下,对于我的特定应用程序,如果可以的话,我非常希望可以选择多100 KB的RAM。


好点,我什至没有考虑功耗...
Grady Player

4
“ RAM易失但使用非常快,不断使用电源来保持其状态”。不更改状态时,包括SRAM在内的CMOS逻辑仅消耗极少的功率。注意,即使在极低功耗的掉电模式下,大多数微控制器仍保留其RAM内容。
克里斯·斯特拉顿

@ChrisStratton:我已经看到了一些来自不同制造商的微控制器,这些微控制器具有关闭其某些 RAM的模式以节省功率,尽管有些令人讨厌的是我不允许的RAM不能上电无需系统重置。不确定后一个限制的目的是什么;如果在某些操作期间我需要大量的RAM来临时存储,但不是这样,我不明白为什么我不应该在需要时打开电源,而在不需要时关闭电源,但是我没有看到特征。
2014年

14

除了其他答案中提到的优点之外,RAM受限的另一个原因是微控制器的体系结构。例如,以Microchip PIC10LF320为例,它只有448 字节的程序(闪存)存储器和64 字节的RAM。但是,它的成本可能仅为25英镑(或更少)。PIC10指令字的有限大小(12位)使其只能直接寻址128个字节的RAM。

我敢肯定,还有其他只有8位地址总线的微控制器,将它们限制为256字节的RAM。

但是大多数中端微控制器(甚至那些具有8位数据路径的微控制器)都具有16位地址总线。这些芯片的主要架构考虑因素是该芯片是采用哈佛架构还是冯·诺依曼架构。

大多数微控制器使用哈佛架构,该架构具有用于程序存储器,RAM和存储器映射的I / O地址的单独的16位地址空间。因此,对于这些,16位地址总线可以访问多达64K(65,536)字节的RAM。该体系结构仍然存在64K的限制,如果要超过该限制,则必须使用某种分页。使用分页来存储程序空间而不是使用RAM空间更为常见。

使用Von Neumann架构的微控制器(例如Freescale HCS08系列)仅在程序存储器,RAM和存储器映射的I / O之间分配了一个地址空间。为了拥有合理的程序空间,这会将RAM的数量通常限制为4K或8K。同样,可以使用分页来增加可用程序或RAM空间。


1
不过,您必须牢记,PIC内核代码完全无效,以至于它会浪费大量额外的闪存。它不需要大量RAM的原因之一是因为它对例如调用堆栈深度有严格的限制。
伦丁2014年

@Lundin Agreed,您几乎必须非常小心地用汇编语言对原始PIC10和PIC12进行编程。现在,较新的PIC12F和PIC16F器件具有16级硬件堆栈和14条新指令。有些只是为C添加的,因此它们的可用性更高。
tcrosley14年

@Lundin:我认为12位和14位指令长度的PIC芯片在代码密度方面相当不错。PIC18F是在使用HiTech编译器时,由于通常需要过多的存储体切换,因此代码密度确实趋于下降。
supercat

7

我已经在微控制器和小型系统上工作了一段时间,我想指出的是,通常只需要很少的RAM。请记住,即使MCU可以完成很多工作,但如今的趋势是使用比以前更多的MCU,并使用更多的MCU在更大的系统中分配许多任务。这与以下事实结合在一起:与在Windows中编程所需的肿的开发系统不同,MCU开发通常使用经过很好优化的编译器,大多数情况下使用非常高效的C和C ++源代码,有时甚至很少甚至没有OS开销。尽管您几乎无需编写Windows程序即可在任何设备上显示您的名字,而不会占用至少数百千字节(包括操作系统资源),

当然,还有其他人指出的成本和空间问题。但是这里的历史是,如今新手认为少量的RAM确实比以往任何时候都多了很多,而且MCU需要与之交互的组件和设备一直在变得越来越智能。老实说,最近我在许多MCU应用程序中最大的使用RAM是用于中断驱动的通信缓冲区,以便将MCU释放给其他任务而不必担心丢失数据。但是,不管您相信与否,对于普通的逻辑和计算功能,MCU与其有限的内置RAM和闪存资源都可以很好地匹配,并且您实际上可以做很少的事情

请记住,曾有一段时间,著名的视频游戏具有粗糙的图形,但是复杂的游戏逻辑(如“ PAC Man”和“ Space Invaders”)通常是在8K ROMS内完成的,而这些机器的RAM几乎只有8 KB或16 KB!


SD卡呢?SDHC卡是否不需要256或512字节的缓冲区(不再生产标准/旧SD卡)?
彼得·莫滕森

Atari 2600视频计算机系统的Pac Man版本是4K ROM,而VCS本身具有128字节的RAM。但是,与当时的家用计算机相比,许多街机都具有相当不错的ROM和RAM。我认为Defender例如具有32K或ROM和64K的RAM,尽管从CPU的角度来看32K的RAM是“只写的”(处理器会将数据放置在那里,显示硬件会将其输出到监视器) 。
超级猫

@PeterMortensen许多SD卡都有某种集成的CPU来管理闪存。某些卡具有完整的32位ARM内核,可能已连接16或32K RAM。
alex.forencich 2014年

@ alex.forencich:是的,但是与旧卡相比,用于操作SDHC SD卡的SPI接口在主机侧(嵌入式系统/微控制器)是否不需要缓冲区?也就是说,对于较新的(SDHC)卡,不再可以使用位寻址?还是仅取决于文件系统(仍然可以进行位寻址)?较新的卡是否不需要块传输(因此需要256或512字节的缓冲区)?
彼得·莫滕森

是的,我记得是512B。您可能只编写了效率低下的SD卡驱动程序,以丢弃前X个字节的数据->无需“大”缓冲区。
domen 2014年

3

除了在成本和制造方面的优势外,对片上RAM的需求也很少。

我经常使用具有数十kB(16kB,32kB)闪存和kB范围(1kB,2kB)RAM的微控制器。我经常用光闪存,而几乎用不完RAM。在我的大多数项目中,我都非常接近闪存限制,但是通常只需要少于20%的RAM。

大多数非常小的微控制器都有两种不同的作用:

  • 调控:他们必须控制一台机器。即使在复杂的控制器算法(可能占用数十kB的代码空间)的情况下,也只需要很少的RAM。您处于物理过程的控制之下,并且具有包含一些物理单元的变量,并且可能包含一些作为循环计数器的变量。不需要更多。

  • 数据处理:在极少数情况下,您需要同时存储大量数据,可以使用外部RAM。几乎所有现代微控制器都对此提供原生支持。如果您需要一个使用大量内存的简单程序,则使用小型微控制器和外部RAM而不是高级微控制器将既便宜又小。没有人生产具有很少端口,小闪存和大RAM的控制器,因为对它们的需求很小。


2

当然,所有上述原因在技术上都是有效和准确的。但是,请不要忘记电子产品是一家企业,MCU是电子产品行业中竞争最激烈的利基市场之一。

我敢说将MCU的价格标签与嵌入式SRAM数量链接的实际原因主要是营销原因,而不是成本原因:

  • 在大多数设计中,最大可达到的时钟频率不是限制因素。而是,可用SRAM的数量为。别误会,CPU频率非常重要,但是,在某些MCU系列细分市场中,通常不会基于最大CPU频率以不同的价格提供不同的设备型号。同样,闪存程序存储是另一个关键限制因素,但是,我不会过多地关注闪存(问题专门针对SRAM)。

  • 可用SRAM的数量与您将能够嵌入到MCU中的复杂程度直接相关,无论是与第三方库还是与您自己推出的代码。因此,根据您的MCU价格进行细分是一个“自然”的指标。对于技术客户而言,可以接受的是,能够执行更多复杂任务(更多SRAM,更多闪存)的MCU的成本更高,这是可以理解的。价格在这里反映了MCU的潜在价值(交付能力)。闪存的存储量通常与SRAM成比例。

  • 相反,如果您进入台式机和移动CPU市场,通常无法采购具有许多不同SRAM大小的特定MCU / CPU。相反,定价模式通常建立在MCU / CPU的执行/性能能力之上:频率,内核数,电源效率...


我认为这可能是正确的,但是有证据吗?像划痕一样将芯片a出售为芯片b?
Grady Player

嗯...有趣的想法。我没有这种做法的证据。但是,它带来了有关基础制造成本的有趣问题。如果有更大的SRAM尺寸的芯片被划为较小的SRAM尺寸,浪费硅芯片(晶圆)的空间会更昂贵吗?还是与制造一个设备而不是两个设备相关的增加的制造和库存成本?恐怕整个电子行业对公开讨论其成本非常挑剔。我们可能永远不会知道。
jose.angel.jimenez 2014年

1
举个例子,MT6250是一种多芯片芯片,用于单芯片功能手机,体积不到2美元,比MCU复杂得多,并带有8MB SRAM芯片。 SRAM丰富的MCU技术
hulkingtickets 2014年

这将很好地回答“为什么MCU的价格与嵌入式SRAM的数量有关?”。但这似乎无法回答最初的问题。为什么有这么少的微控制器以任何价格提供超过512 KB的片上SRAM ?当专用SRAM芯片制造商似乎认为减少的存货成本使其仅值得生产2乘幂尺寸的专用SRAM芯片时,为什么有这么多微控制器具有“怪异”的非2幂尺寸的SRAM?
davidcary

1

因此,首先您必须考虑16 KB或32 KB是巨大的内存,并且当今出售的大多数微控制器都没有这么大的RAM。

许多微控制器程序需要10或50字节的内存。甚至更复杂的内容大多需要数百个字节。

基本上,在三种使用情况下,您需要按KB量级的RAM:a)当您的微控制器执行图形操作时b)当您使用微控制器进行大型任意计算时c)当您与PC接口连接时

其次,请注意,如果您谈论微控制器RAM,则是谈论0级/ 1级缓存。如果您认为Intel Haswell仅“拥有” 64 KB 1级缓存,那么您将重新考虑微控制器的RAM大小。

第三,您可以将任意数量的外部RAM连接到微控制器,尤其是可以连接到CPU的外部RAM。

我个人正在开发许多微控制器应用程序,而我从来不需要1 KB的内存,甚至不需要更多的内存。我也从未使用过外部RAM。

如果我们使用ROM(今天的闪存),情况会有所不同,因为您的程序和数据都在ROM中。实际上,在许多应用程序中,您需要将外部ROM连接到微控制器,因为您有许多数据。

让我们看一个例子:让我们分析一个微控制器应用程序,然后我们拿一个带有显示屏和4 GB闪存的便携式MP3播放器。

对于此应用程序,您可能需要1 KB RAM。这足以胜任这项工作。但是,您可以为更大的缓冲区使用更多的RAM,以加快USB到Flash的写入速度。

您现在看到的区别是:典型的PC将所有程序和数据保存在RAM中。因此,它需要大量RAM。对于微控制器,这全部在Flash / ROM中。


2
您低估了许多应用程序中的RAM使用率。不会很大,但可能取决于实例,大约是10到100。MP3播放器必须执行数字信号处理。
杰森S

我想知道你们两个为什么都这么说。哪种C命令需要RAM。与其说“这些应用程序需要更多的RAM”,不如说“这些操作需要更多的RAM,因为...”
Frederick

-1

在设计MCU时,您必须面对在PC上不那么重要的条件。

  1. 耐用性

    选择这些组件时,您不一定需要使用最好的或/和最高性能的零件,但已证明在使用数年后可以正常运行的零件将可以使用数年,并且能够以24/7的速度运行年份。由于这种情况,如果控制器在市场上已经销售了好几年,并且表现良好,那么与今天的PC标准相比,它似乎具有较差的RAM。但是无论如何,它做得很好,如果工程状况良好,则无需更换。

  2. 空间

    微处理器单元实际上是微米。您必须将所需的空间减少到最小。当然,您可以在拥有10年历史的64 KB芯片的相同空间中获得256 MB。这就是第一点。

  3. 价钱

    不仅是购买价格,而且是功耗。如果您的竞争对手仅需要25 W,那么您就不想设计一种可以控制入门系统的MCU,而该MCU则需要1000W。如果您的竞争对手仅需要25W。总是更好。


1
那是一个真正的大功率微处理器!
KyranF 2014年

2
我猜一个1kW的MCU不会在固态中保持很长时间。
丹·布莱恩特

1
这三点在当今的PC设计中都极为重要。

@KyranF:是的,将两个数字除以100。但是,如果有的话,他低估了电池应用的高性能处理器和低功耗微控制器之间的相对功率差异。
Ben Voigt 2014年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.