Cortex-M

正如汽车代替了马车,电子邮件代替了普通邮件一样,32位微控制器(MCU)让8位MCU变得黯然失色。尽管未来8位MCU朝向32位MCU发展将会成为现实,但目前还没那么容易实现。事实证明8位MCU和32位MCU仍是互补的技术,在一些方面各有千秋,而在其它方面的表现却同样出色。这其中的窍门在于厘清何种应用适合哪种MCU架构。

本文比较了8位MCU和32位MCU的使用案例,可作为如何选择这两种MCU架构的指南使用。

本文大部分32位范例将关注于ARM Cortex-M装置,Cortex-M在不同MCU供货商产品组合中表现非常相似。由于8位MCU有很多种架构,所以很难对8位供货商之间进行类似的产品比较。为了进行比较,本文将使用广泛应用、易于理解的8051 8位架构。

事实上,“ARM Cortex和8051哪个比较好”不是个逻辑问题,反而像是在问“吉他和钢琴哪个好”?真正要解决的问题是“哪种MCU最能帮助解决目前面临的问题?”。

不同的任务须使用不同的工具,使用者目的是要了解“如何才能善用所拥有的工具”,包括8位和32位装置。

对不同的装置进行比较,须要对其进行测量。有很多建构工具可供选择,本文尽量选择一些认为能够进行最公平的比较,且最能代表开发人员真实体验的情境。

以下ARM数据是透过GCC+ nanoCLibrary和-03优化选项所生成。

此一比较试验并不为任何一种装置的代码优化,只是简单实现90%开发人员都会使用的常见代码,并呈现普通开发人员所见到的结果,而不是理想状态下的结果。当然,花费诸多时间、精力和财力去调整8051代码使其表现胜过ARM是可能的,反之亦然,但一开始就选择适合该项工作的最佳工具比费尽心力做优化简单多了。

8位MCU功效持续精进

在开始对架构进行比较前,要注意到并非所有的MCU都是一样,这一点非常重要。

如果将基于ARM Cortex-M0+处理器的现代MCU与30年前的8051 MCU做对比,8051 MCU在性能上当然不会胜出。幸运的是,许多供货商一直对8位处理器持续投资。

例如芯科实验室(Silicon Labs)正持续更新基于8051核心的EFM8 MCU产品线,其效能比原始的8051架构更高,而且开发过程也已实现现代化。所以在许多应用中,8位核心能够容易弥补比M0+或M3核心不利的地方,甚至在一些方面性能更佳。

开发工具也很重要。现代嵌入式韧体开发需要全功能IDE、现成的韧体库、丰富的范例、完整的评估和入门套件,以及助手应用,以简化硬件配置、数据库管理和量产编程之类的工作。当MCU有了现代化的8位核心和开发环境时,在很多情况下,这样的MCU将超越基于ARM-Cortex的类似MCU。

以系统规模选择MCU

第一个一般性原则是:ARM Cortex-M核心更适用于较大的系统规模(>64KB代码),而8051装置适用于较小的系统规模(<8KB代码)。中等规模的系统可以选择两种方式,这取决于系统要执行的任务。须要注意的是,在大多数情况下,周边组合将会发挥重要作用。如果需要三个UART、一个LCD控制器、四个频率和两个ADC,用户可能不会在8位MCU上找到所有的周边。

易用性与成本/尺寸之比较

对于中等规模的系统来说,使用任何一种架构都可以完成工作。但主要须考虑是选择ARM核心带来的易用性,还是8051装置带来的成本和物理尺寸优势。

ARM Cortex-M架构具备统一的储存模式,并在所有常见编译程序中支持完整的C99,这使得该架构非常易于写韧体。此外,还可得到一系列数据库和第三方代码。

当然,这种易用性的代价就是成本。对于高复杂性、上市时间较短的应用或缺乏经验的韧体开发人员来说,易用性是个重要因素。

比起32位MCU,8位MCU的成本颇具优势。使用者经常会发现内建2KB/512B(Flash/RAM)的小容量8位MCU,而却很难找到低于8KB/2KB的32位MCU。在不需要很多资源的系统中,储存容量小的MCU能够让系统开发人员获得显著的成本降低。因此,对成本极为敏感或仅需较小储存容量的应用,会更倾向于选择8051解决方案。

8位芯片通常也具备物理尺寸上的优势。例如Silicon Labs提供的最小32位QFN封装为4mm×4mm,而基于8051的8位芯片的QFN封装可小至2mm×2mm。

芯片级封装(CSP)的8位和32位架构之间的差异较小,但却使成本增加,且组装较难。对于空间严格受限的应用来说,通常须要选择8051装置来满足限制要求。

通用代码/RAM效率易影响MCU成本

8051 MCU成本较低的主要原因之一是其使用Flash和RAM的效率通常比ARM Cortex-M核心更高,这允许系统采用更少资源实现。系统越大,这种影响就越小。

然而,这种8位储存资源的优势并不总是如此,这一点很重要。在某些情况下,ARM核心会像8051核心一样高效或比其更高效。例如32位运算在ARM MCU上仅需要一条指令,而在8051 MCU上则需要多条8位指令。显然,这种代码在ARM架构上有更高的执行效率。

ARM架构在Flash/RAM尺寸较小时的两个主要缺点是代码空间效率和RAM使用的可预测性。首要也是最明显的问题是通用代码空间效率。8051核心使用1字节、2字节或3字节指令,而ARM核心使用2字节或4字节指令。

通常情况下,8051指令更小,但这一优势因实际上花费许多时间而受到削弱,ARM核心比8051在一条指令下能做更多工作。32位运算就是这样一个范例。以实践来说,指令宽度是能在8051上产生适度的更密集代码。

代码空间效率

在含有分布式存取变量的系统中,ARM架构的加载/储存架构通常比指令宽度更为重要。试想讯号量的实现,一个变量需要在代码周围的多个不同位置进行减量(分配)或者增量(释放)。ARM核心必须将变量加载到缓存器,对其进行操作并重新储存,这需要三条指令。另一方面,8051核心可以直接在内存位置上进行操作,且仅需一条指令。随着每次对变量完成工作量的增大,由加载/储存而产生的消耗就变得微不足道。但对于每次仅完成一点工作的情况来说,加载/储存能产生重要影响,让8051获得明显的效率优势。

尽管讯号量在嵌入式软件中并非常见结构,但简单的计数器和标志却广泛应用于控制导向的应用中并发挥相同的作用。许多常见的MCU代码都属于这一类型。

另一个原因是ARM处理器比8051核心具有更多的自由使用堆栈。通常情况下,8051装置针对每次函数调用仅在堆栈上储存返回地址(2字节),透过通常分配给堆栈的静态变量处理大量的任务。在某些情况下,这会产生问题,因为这会造成函数默认不可重入。然而,这也意味着必须保留的堆栈空间很小,且完全可预测,这在RAM容量有限的MCU中至关重要。

举个简单的例子,试验者设计了以下程序,然后测量funcB内部的堆栈深度(图1),发现M0+核心的堆栈用了四十八个字节,而8051核心的堆栈仅用了十六个字节。当然,8051核心还静态分配了八个字节的RAM,总共用了二十四个字节。在较大的系统中,这个差异显得微不足道,但是在仅有256字节的ARM的系统中,这就变得很重要。

图1 测量funcB内部堆栈程序示意图。

架构细节之考虑

假设有基于ARM和基于8051的MCU各一个,配有所需的周边,那么对于较大的系统或需要重点考虑易用性的应用来说,ARM装置是更好的选择。如果首要考虑的是低成本/小尺寸,那么8051装置将是更好的选择。本文以下对于每种架构更擅长的应用进行更详细的分析,同时也划分出一般原则。

影响延时因素

两种架构的中断和函数调用延时存在很大差异,8051比ARM Cortex-M核心更快。

此外,高阶周边总线(APB)配备的周边也会影响延时,这是因为数据必须透过APB和AMBA高性能总线(AHB)传输。最后,当使用高频核心频率时,许多基于Cortex-M的MCU需要分配APB频率,这也增加了周边延时。

试验者做了个简单的实验,实验中的中断是透过I/O引脚触发的。该中断对引脚发出一些讯号,并根据引发中断的引脚更新标志,之后再量测其部分参数的变化。图2为此次32位Cortex-M与8051对照实验的程序代码与参数比较。

图2 测试程序代码与所得结果参数

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

文章来源 : 新电子

围观 505

Cortex-M系列 
 
M0:  

Cortex-M0是目前最小的ARM处理器,该处理器的芯片面积非常小,能耗极低,且编程所需的代码占用量很少,这就使得开发人员可以直接跳过16位系统,以 接近8 位系统的成本开销获取 32 位系统的性能。Cortex-M0 处理器超低的门数开销,使得它可以用在仿真和数模混合设备中。  

M0+: 

以Cortex-M0 处理器为基础,保留了全部指令集和数据兼容性,同时进一步降低了能耗,提高了性能。2级流水线,性能效率可达1.08 DMIPS/MHz。  

M1: 

第一个专为 FPGA 中的实现设计的 ARM 处理器。Cortex-M1 处理器面向所有主要 FPGA 设备并包括对领先的 FPGA 综合工具的支持,允许设计者为每个项目选择最佳实现。
  
M3:  

适用于具有较高确定性的实时应用,它经过专门开发,可使合作伙伴针对广泛的设备(包括微控制器、汽车车身系统、工业控制系统以及无线网络和传感器)开发高性能低成本平台。此处理器具有出色的计算性能以及对事件的优异系统响应能力,同时可应实际中对低动态和静态功率需求的挑战。  

M4:
 
由 ARM 专门开发的最新嵌入式处理器,用以满足需要有效且易于使用的控制和信号处理功能混合的数字信号控制市场。  

M7:  

在 ARM Cortex-M 处理器系列中,Cortex-M7 的性能最为出色。它拥有六级超标量流水线、灵活的系统和内存接口(包括 AXI 和 AHB)、缓存(Cache)以及高度耦合内存(TCM),为MCU 提供出色的整数、浮点和 DSP 性能。 

互联:64位 AMBA4 AXI, AHB外设端口 (64MB 到 512MB) 指令缓存:0 到 64kB,双路组相联,带有可选 ECC 数据缓存:0 到 64kB,四路组相联,带有可选 ECC 指令TCM:0 到 16MB,带有可选 ECC 数据TCM:0 到 16MB,带有可选 ECC

Cortex-M系列规格对比

围观 534

调试嵌入式软件是我最不喜欢的行为,不幸地是,它却是必要的。值得庆幸地是,技术和工具链创新的进步衍生出大量的新技术,从而大大地加快了调试过程。下面让我们来看看其中一些方法,从传统的断点调试出发到更先进的仪器跟踪技术。

技巧1# - 传统的断点调试

每个开发人员都熟悉传统的调试技术,设置断点、执行代码,然后单步调试代码进行监视,同时监视寄存器和变量值。断点调试是我看到的使用最多的技术。然而,结果却不甚乐观,因为断点调试的效率较低,通常会产生次优的结果。

既然如此,为什么大家还如此频繁地使用断点调试呢?主要原因似乎是断点调试便于使用,易于理解,并且开发人员都乐观地认为,对于工作而言,断点是正确的工具。这种乐观需要校验。断点有可能破坏系统的实时性能,同时会将开发者吸进一个黑洞,使其无休止地去单步执行代码,盲目地寻找问题的一种解决方法。

技巧2#- IDE值图

如今,几乎所有的现代调试器和IDE都允许开发者监视存储在内存中的变量值。开发人员可以选择内存位置以及值刷新率,然后启动调试会话。一些IDE自身就有能力监视内置到IDE的值,而另外一些IDE则需要依靠外部软件。

值监测非常有用,如果将监测到的数据与图形化表示关联到一起,其带来的价值则更大。对实时的数据绘制值图对于发现意想不到的变化和验证特定波形的生成极其有用。例如,一个三相无刷直流电机(BLDC motor)。开发人员如果想要监测每个电机支架的电流和电压,则需要驱动电机所形成的非常具体的波形。绘制每个电机支架电流和电压能够让开发人员实时看到发生的事情。

技巧3#-从printf到SWO

在高端的ARM Cortex-M系列配件中,如M3/M4,它为开发人员提供了额外的调试能力,即串行线查看器(Serial Wire Viewer,SWV)。SWV还包括除串行线输出(SWO)以外的标准串行线调试。SWO可以用来做很酷的东西,如程序检索计数器,事件计数器,及数据追踪等。开发者还可以对它们进行自定义,设置自己想要在SWO中传送的信息。

许多开发者为了从他们的嵌入式系统中获取调试信息通常会设置printf。实际上则并不是在单片机中使用串口引脚,而是开发人员可以使用SWO通过调试器重新路由printf信息。以这种方式使用调试器可以保存专用串行接口的需要,同时消除了开发UART和USB设备的时间,效率更高。现在通过SWO和调试硬件将最初被应用程序所使用的开销卸去,缩减了那些有可能被应用程序代码使用的宝贵的时钟周期。

技巧4#-RTOS跟踪

试图透过表像看清一个实时操作系统中(RTOS)的本质可以说是相当具有挑战性。开发者并不想扰乱实时系统的性能,但仍然需要一些方法来了解系统的行为。这也是Blinky LED经常使用的把戏,但最近开发者的工具箱中增加了更多惊人的跟踪工具。例如免费的商用RTOS工具,如TraceX、SystemView和tracealyzer等等。

当RTOS闲置,或是有任务进入和退出时,跟踪工具允许开发者进行追踪分析。开发人员可以监控系统的异常,响应时间,执行时间,以及正确开发一个嵌入式系统所需的许多其他关键细节。RTOS跟踪工具最酷的功能是它们能够展示系统内部发生了什么。实时地或是在日志文件中进行审查和时序图监视,能够让开发者确定一个置信水平,用以估量系统是否能够按预期正常运行,或者帮助他们发现一些小问题,否则将花费大量的时间去寻找。

技巧5 #- 使用指令追踪技术(ETM / ETB / ETM)

有时开发人员面临的调试问题,只是在处理器中所能想象到的最低层面的问题。跟踪技术的存在,可以监视处理器执行的单个指令。在测试和验证软件时这种低水平跟踪对于监测分支覆盖非常有用。用于指令跟踪的调试工具不同于那些开发人员使用的串行线查看,而且成本略高。

结束语

调试工具和技术在过去几年里迅速发展,特别是高端微控制器。一般来讲,工程师都是视觉型生物,工具供应商正在寻找方法以刺激视觉的方式来揭示一个实时系统究竟发生什么。配置调试工具可能需要做一些前期工作,但是在设计上多花一点时间可以换来更少的调试时间,确实是一笔非常值得的时间投资。开发人员至少应该熟悉不同的调试工具和可用的功能,以便在出现问题,系统需要调试时,他们可以选择合适的工具完成任务。你有用过其它可以帮助工程师更快、更有效率地调试他们系统的技术么?

原文链接:Debugging the Cortex-M MCU

作者:Jacob Beningo

译者:刘帝伟 审校:刘翔宇

责编:周建丁(zhoujd@csdn.net

文章来源: 极客头条

围观 407

页面

订阅 RSS - Cortex-M