跳转到主要内容

Cortex-M

最小化ARM Cortex-M CPU功耗的方法与技巧

editor /

<strong>1、理解Thumb-2</strong>
  
首先,让我们从一个看起来并不明显的起点开始讨论节能技术—指令集。所有Cortex-M CPU都使用Thumb-2指令集,它融合了32位ARM指令集和16位Thumb指令集,并且为原始性能和整体代码大小提供了灵活的解决方案。在Cortex-M内核上一个典型的Thumb-2应用程序与完全采用ARM指令完成的相同功能应用程序相比,代码大小减小到25%之内,而执行效率达到90%(当针对运行时间进行优化后)。
  

元器件选择须以应用为依归 8/32位MCU各擅胜场

kelly /

正如汽车代替了马车,电子邮件代替了普通邮件一样,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 Cortex-M系列处理器分类比较

kelly /

<strong> Cortex-M系列 </strong>
 
<strong> M0:</strong>  

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

<strong> M0+: </strong>

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

<strong> M1: </strong>

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

【下载】ARM Cortex-M MCU 应用的标准架构

kelly /

ARM Cortex™-M处理器系列是一系列可向上兼容的高能效、易于使用的处理器,这些处理器旨在帮助开发人员满足将来的嵌入式应用的需要。这些需要包括以更低的成本提供更多功能、不断增加连接、改善代码重用和提高能效。

Cortex-M 系列针对成本和功耗敏感的MCU和终端应用(如智能测量、人机接口设备、汽车和工业控制系统、大型家用电器、消费性产品和医疗器械)的混合信号设备进行过优化。

<span class="download"><a href="http://mm32.eetrend.com/system/files/2016-08/文章/private/100002342-7369-…;

加速Cortex-M MCU调试的五个技巧

editor /

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

<strong><font size="5">技巧1# - 传统的断点调试</font></strong>

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

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

<strong><font size="5">技巧2#- IDE值图</font></strong>