衡量微控制器不仅取决于总线宽度

自从半导体制造商将产品迁移32位架构到微控制器，一些技术社区中的人们就已经开始预测8位器件的灭亡。现实中，8位器件的使用量确实已经下降，他们可能不再占据主导地位，但8位真的离灭亡不远了吗？答案是否定的，实际上，现在的制造商仍然一直开发和扩展他们的8位器件系列产品，甚至包括那些正在提供32位产品的供应商。

当提及如何在8位和32位MCU之间选择时，或许争论的焦点其实就在于他们的灵活性；毕竟，单个设备就有许许多多应用。但是如果MCU被设计得如此灵活，为什么仍然有如此多的变种呢？对于该问题的多数答案将是外设而非内核，但是实际上内核和它的外设有着千丝万缕的联系。

还有一种看法是—8位架构和相应的32位架构相较之下是过时的，但是实际上的比较结果或许出人意料。虽然他们的指令集可能已经被完好构建，但是大多数8位内核在他们的生命周期中有不止一次的“升级”，同时就像任何其他设备一样，他们也受益于制造工艺的发展。因此，认为这两种架构在某个方面具有可比性，这应当是合理的。

基本差异

除了明显的总线宽度差异之外，8位器件通常比32位器件更加“少”，特别是和内核集成在一起的存储容量，以及相关的平均售价。类似地，如果需要完全集成系统级功能(例如LCD控制器/驱动器)，那么这些功能更可能出现在32位解决方案中。

通常而言，如果系统需要的代码存储容量大于65kbyte，那么需要选择32位解决方案，如果需要的代码存储容量小于8kbyte，那么8位解决方案更可行。当然，就其本质而言，8位器件对于简单操作可能需要更少的代码空间，但是32位指令集的单条指令可以完成更多的工作，因此，在较大和更复杂的应用中，更复杂的指令集实际上可能获得更好的整体代码密度。

对于代码容量在这两个极端之间的应用，或者仅仅需要“标准”MCU外设，选择判断标准不再显而易见，需要基于实际的应用选择。通过花些时间分析应用，工程师能够快速确定哪种架构最适合他们的需求。

基准性能

当然，大多数工程师可能会说8位和32位的主要区别完全在于性能，但这只能根据具体的情况才能这样说，要看具体的要求。“应用性能”才是真正要考虑的问题。

举例来说，对比8051和Cortex-M0+；8051是完全着眼于8位应用领域的架构，这也是大多数工程师可能要进行的对比，因为它要用于嵌入式领域。脱离具体环境直接进行数据手册对比将是没有意义的；在大多数情况下，Cortex-M0+设备可能会“胜出”，但在真实的场景中，结果可能会大相径庭。


图1:Silicon Labs基于8051内核的EFM8 Busy Bee 2亮点及应用领域

较大内核的一个特点是不用太在意它们的资源使用情况；而在嵌入式系统中，这会引发问题，包括8位架构开发人员一直避免的问题。举例来说，考虑图1中的代码。在基于Cortex-M0+的设备上编译和执行代码时，我们发现栈需要48字节，而在8051上编译和执行相同的代码时仅需16字节。尽管区别不是很大，但在RAM有限的系统中，这一点就变得非常重要了。

int main(void){

funcA(0xACED);

while (1);

}

voidfuncA(uint32_t a){

uint8_ti, j=0;

for (i=0; i}

uint16_tfuncB(uint16_t testA, uint16_t testB){

return (testA * testB)/(testA - testB)

}

由于8051最初设计的原因，它一直采用非统一的存储映射。在大多数情况下，这能够提高效率，因为它使用不同的指令指向不同类型的存储区(例如：Flash、内部RAM或外部存储)。不过，指令集还允许通用指针指向任何类型的存储区，这能够提高代码的可重用性，代价是这会稍稍影响执行的效率。ARM架构有统一的存储区管理，这意味着无需使用特殊指针，从而工作可能会变得更简单。

低效是困扰嵌入式开发人员的一大问题，开发人员会想尽一切办法避免这个问题，这凸显了另一个问题—延迟。直觉上，工程师可能会认为Cortex-M0+对中断和函数调用有更快的反应时间，但实际上8051架构更快。ARM内核通过AMBA高性能总线(AHB)在高级外设总线(APB)上 访问外设的事实使得情况变得更糟。

基于此原因，在简单的系统中，8051能够显示出其在中断服务程序进/出时间上的优势，但在更加复杂的系统或执行时间更长的服务程序中，优势变得不再明显。

应用适用性

一般来说，8位和32位内核的另一个重要差异是处理控制任务时各自内在的优势和劣势，尤其是8051和Cortex-M0+。8051指令集在计算比特和字节时表现卓越，而Cortex-M架构的优势在于能够流畅处理较大的数据块，或使用广泛的数学函数执行复杂的逻辑算法。

在判断何种架构最适合应用时，这种“控制vs.处理”的对比尤为有用，但这并不是一成不变的规则；虽然在一个主要实现UART-to-SPI桥接器的应用中，采用ARM器件可能会表现的更高效，但是8位器件也能轻而易举的处理这种情况，而且可能会非常适合仅仅有2kbyte集成存储容量的器件。

举例来说，在一个应用中，它10%的时间用于执行32位数学函数，25%的时间用于处理控制函数，剩余的65%处理时间则用于执行一般目的的活动。如果没有清晰显著的优先考虑的架构，并且如果系统级要求是更小的代码空间而不是执行速度，那么可能更适合选用8位产品。但是，如果要优先考虑执行速度，那可能就要选用32位产品了。

评估整体功耗时，也可做同样的对比，一般情况是整体评估两种选择方案的占空比、活动功耗和休眠电流。现在，许多供应商提供硬件和软件工具来帮助工程师评估这些参数，尤其是那些同时有8位和32位器件产品组合的供应商，比如Silicon Labs。

最后，如果在为某个应用选择8位或32位产品时，如果没有明显优于对方的益处，那么情况很有可能是，即使做出“错误”选择，也真的不会有什么大问题。8位架构在嵌入式开发中仍占有重要位置，这就继续要求工程师们仔细评估其选择，而不是在今后一段时间里默认选择单一的通用架构。

以下我们用一个实例来说明Silicon Labs基于8051的新型EFM8 MCU的应用


图2：EFM8 MCU

比如，Silicon Labs的EFM8SB1系列MCU可以成功应用在智能水杯的方案中。智能水杯主要用来测量液位或者液量，并累计计算一定时间内用户的饮水量，提醒用户适时饮水。传统的智能水杯使用压力传感器测量液位，有的还要加入重力或者加速度传感器检测杯体的倾斜。EFM8SB1的电容感应测量模块可以实现同样的功能。该系列MCU具有多个通道的12位精度高速电容数字转换测量能力，无需外围附加器件，并为用户提供了一系列用户友好的软件库和调试工具。

除了液量测量，EFM8SB1中的其他功能模块也可以实现智能水杯的其他功能。12位的ADC可以测量水温，PCA可以驱动LED或者蜂鸣器提供简单的用户显示界面，而UART或者SPI可以用来连接无线模块，和其他智能设备比如手机交换数据，在功能更强大的设备上提供更丰富的应用和客户体验。