探索IoT应用中对于8位、32位MCU的选择

　　延时

　　两种架构的中断和函数调用延时存在很大差异，8051比ARM Cortex-M内核更快。此外，高级外设总线(APB)配备的外设也会影响延时，这是因为数据必须通过APB和AMBA高性能总线(AHB)传输。最后，当使用高频内核时钟时，许多基于Cortex-M的MCU需要分配APB时钟，这也增加了外设延时。

　　我做了个简单的实验，实验中的中断是通过I/O引脚触发的。该中断对引脚发出一些信号，并根据引发中断的引脚更新标志。然后我测量了一些参数，如下表所示。这里的列表显示了32位的实现。

　　8051内核在中断服务程序(ISR)进入和退出时显示出优势。但是，随着中断服务程序(ISR)越来越大和执行时间的增加，这些延迟将变得微不足道。和已有原则一致，系统越大，8051的优势越小。此外，如果中断服务程序(ISR)涉及到大量数据迁移或大于8位的整数数据运算，中断服务程序(ISR)执行时间的优势将转向ARM内核。例如，一个采用新样本更新16位或32位移动平均的ADC ISR可能在ARM设备上执行的更快。

　　控制vs.处理

　　8051内核的基本功能是控制代码，其中对于变量的访问是分散的，并且使用了许多控制逻辑(if、case等)。8051内核在处理8位数据时也是非常有效的，而ARM Cortex-M内核擅长数据处理和32位运算。此外，32位数据通道使得ARM MCU复制大包的数据更加有效，因为它每次可以移动4个字节，而8051每次仅能够移动1个字节。因此，那些主要把数据从一个地方移动到另一个地方(例如UART到CRC或者到USB)的流数据处理的应用更适合选择基于ARM处理器的系统。

　　来做个简单的实验。我们编译以下两种架构的函数，变量大小为uint8_t、uint16_t和uint32_t。

　　uint32_t funcB(uint32_t testA, uint32_t testB){

　　return (testA * testB)/(testA—testB)

　　}

　　|data type | 32bit(-o3) | 8bit |

　　| uint8_t | 20 | 13 | bytes

　　| uint16_t | 20 | 20 | bytes

　　| uint32_t | 16 | 52 | bytes

　　随着数据量的增加，8051内核需要越来越多的代码来完成这项工作，最终超过了ARM函数的大小。16位的情况下在代码大小上几乎类似，在执行速度上稍好于32位内核，因为相同代码通常需要更少周期。还有一点很重要，那就是要注意到，只有采用优化的ARM编译代码时，这种比较才有效。未优化的代码需要花费几倍长的时间。

　　这并不意味着有大量数据移动或32位运算的应用不应该选择8051内核完成。在许多情况下，其它方面的考虑将超过ARM内核的效率优势，或者说这种优势是不相关的。考虑使用UART到SPI桥接器。该应用花费大部分时间在外设之间复制数据，而ARM内核会更高效地完成该任务。然而，这也是一个非常小的应用，可能小到足以放入一个仅有2KB存储容量的器件就足够合适。

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

　　指针

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

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

　　通过选择完成工作

　　我已经注意到多次，运算倾向于选择ARM，而控制倾向于选择8051，但没有应用仅仅着眼于计算或控制。我们怎样才能表征广义上的应用，并计算出它的合适范围呢?

　　让我们考虑一个由10%的32位计算、25%的控制代码和65%的一般代码构成的假定的应用时，它不能明确的归于8或32位类别。这个应用也更注重代码空间而不是执行速度，因为它并不需要所有可用MIPS，并且必须为成本进行优化。成本比应用速度更为重要的事实在一般代码情形下将给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的EFM8在很大程度上有利于EFM32 MCU。遗憾的是，除了让MCU供应商的本地应用工程师利用EFM8来解决问题，没有简单的指南来评估这些外设因素。系统设计人员还应了解各种MCU能耗模式下可完成的处理任务。

　　8位或32位?我仍然不能决定!

　　如果考虑到所有这些变量后，仍然不清楚哪些MCU架构是最好的选择，会怎样?那好吧!这说明，它们都是很好的选择，你使用哪种体系结构并不是紧要的事情。如果没有明确的技术优势，那么过去的经验和个人喜好在你的MCU架构决定中也起到了很大的作用。此外，你也可以利用这个机会去评估可能的未来项目。如果大多数未来项目更适合ARM设备，那么选择ARM，如果未来项目更侧重于降低成本和尺寸，那么就选择8051。

　　这到底意味着什么呢?

　　8位MCU仍然可以为嵌入式开发人员提供许多功能，并且越来越关注物联网。当开发人员开始设计时，重要的是确保从工具箱中获得合适的工具。虽然我还是很乐意把8051出售给可能更适合选择32位设备的客户，但是我不禁要想象如果开发人员仅仅花费1个小时思考就作出决定，那么他们的工作将会如何更加容易、最终产品将会有多好。

　　实际上的难题是，不能仅仅依赖于PowerPoint演示文稿中的一两个要点就得出选择MCU架构的结论。然而，一旦你有正确的信息，并愿意花一点时间应用它，就不难作出最佳选择。

　　关于作者

　　Josh Norem是Silicon Labs微控制器和无线产品系统工程师。他于2006年加入Silicon Labs公司，任职产品和测试工程师，担任过包括测试和应用方面的多个技术职位，最近担任系统工程师。在加入Silicon Labs公司之前，Josh就职于AMD公司，负责AMD的x86微处理器的系统级速度调试工作。此前，他就职于TI，负责TI的DSP产品的开发和存储测试。Josh拥有伊利诺斯大学(University of Illinois)Urbana-Champaign分校电气工程科学学士学位。