32位MCU已经无敌？8位表示我还活着呢

代码来完成这项工作，最终超过了ARM函数的大校在16位元的情况下，代码大小几乎类似，在执行速度上稍优于32位元核心，因为相同代码通常需要更少周期。还有一点很重要：只有采用最佳化的ARM编译代码时，这种比较才有效。未最佳化的代码需要花费几倍长的时间。

这并不意味着有大量资料移动或32位元运算的应用不应该选择8051核心完成。

在许多情况下，其它方面的考量将超过ARM核心的效率优势，或者说这种优势是无关紧要的。举例来说，考虑使用UART到SPI桥接器时，该应用花费大部分时间在周边之间复制资料，而ARM核心会更高效地完成该任务。然而，这也是一个非常小的应用，可能放入到一个仅有2KB储存容量的晶片就足够了。

尽管8051核心效率较低，但它仍然有足够的处理能力去处理该应用中的高资料速率。对于ARM装置来说，可用的额外周期可能处于空闲回圈或"等待中断"(WFI)，等待下一个可用的资料到来。在这种情况下，8051核心仍然最有意义，因为额外的CPU周期是微不足道的，而较小的Flash封装会节约成本。如果使用者要利用额外的周期去做些有意义的工作，那么额外的效率将是至关重要的，且效率越高越可能越有利于ARM核心。这个例子说明，清楚被开发系统所关注的环境中的各种架构优势是何等重要，而作出这个最佳的决定是简单但却重要的一步。

指标为8051特殊优势

8051装置不像ARM装置般统一的储存映射，而是对存取码(Flash)、IDATA(内部RAM)和XDATA(外部RAM)有不同的指令。为了产生高效的代码，8051代码的指标会说明它指向什么空间。然而，在某些情况下，使用通用指标，可以指向任何空间，但是这种类型的指标是低效的存取。例如，将指标指向缓冲区并将该缓冲区资料输出到UART的函数。如果指标是XDATA指标，那么XDATA阵列能被发送到UART，但在代码空间中的阵列，首先需要被复制到XDATA。通用指标能同时指向代码和XDATA空间，但速度较慢，并且需要更多的代码来存取。

专用区域指标在大多情况下能发挥作用，但是通用指标在编写使用情况未知的可重用代码时非常灵活。如果这种情况在应用中很常见，那么8051就失去了其效率优势。

仔细评估　了解MCU使用优势

本文已经多次注意到，运算倾向于选择ARM，而控制倾向于选择8051，但没有应用仅仅着眼于计算或控制，该怎样才能定义各种应用，并计算出它的合适范围呢？

本文考量一个由10%的32位元计算、25%的控制代码和65%的一般代码构成的假定应用时，其不能明确的归成8或32位元类别。这个应用也更注重代码空间而不是执行速度，因为其并不需要所有可用的运算效能，并且必须为成本进行最佳化。

成本比应用速度更为重要的事实在一般代码情形下将为8051核心带来些微优势。此外，8051核心在控制代码中有中间等级的优势。ARM核心在32位元计算方面占上风，但是这并非是很多应用所重视的。考量到所有这些因素，这个特殊的应用选择8051核心更加合适。

如果做一个细微的改变，假设该应用更关心执行速度而非成本，那么通用代码不会倾向于哪种架构，并且ARM核心在计算代码中全面占有优势。在这种情况下，虽然有比计算更多的控制代码，但是最后结果将相当均衡。 显然，在这个过程中有很多的评估，但是分解应用，然后评估每一元件的技术将能确保使用者了解，在哪种情况下哪种架构有更显着的优势。

功耗影响须多方考量

当查阅资料手册时，很容易根据功耗资料得到哪个MCU更佳的结论。虽然睡眠模式和工作模式电流性能在某些类型MCU上确实更佳，但是这一评估可能会非常容易产生误导。

工作周期(在每个电源模式上分别占用多少时间)始终占据能耗的主导地位。除非两个晶片的工作周期相同，否则资料手册中的电流规格几乎是没有意义的。最适合应用需求的核心架构，通常具备更低的能耗。

假设有一个系统，在装置被唤醒后添加一个16位元ADC样本到转动平均，然后返回到休眠状态，直到获取下一个样本时才又被唤醒。该任务涉及到大量16位元和32位元计算。ARM装置将能够进行计算，并比8051装置更快返回到休眠状态，这会让系统功耗更低，即使8051具备更好的睡眠和工作模式电流。当然，如果进行的任务更适合8051装置，那么MCU能耗由于相同的原因而对系统有利。

周边特性也能够以类似的方式影响功耗。例如，大多数Silicon Labs的EFM32 32位元MCU具备低功耗的UART(LEUART)，能够在低功耗模式下接收资料，而却只有两个EFM8 MCU具备此功能。此周边影响电源的工作周期，且在任何须要等待UART通讯的应用中，具备LEUART的EFM32 MCU都比缺乏LEUART的EFM8有利。遗憾的是