关于 CORTEX-M0+ 架构随笔

ARMv6-M 只支持特权模式(除非加入拓展)

与 ARMv7-M 不同, v6-M 只支持特权模式.

但是如果增加 Unprivileged/Privileged Extension, v6-M 也可以在这样低的门数上支持特权模式.

解惑1: 为何在开发 Cortex-M0+ uController 开发中无法选择 arm mode?

- 根据上述分析, 我们已知 Cortex M0/M0+ 实现的是 ARMv6-M 指令集, 它是 ARMv7-M 的一个子集, 同样的 v6M 不支持 ARM 指令集(事实上 M0+ 支持的是 Thumb).

因此, 我们在 build new project 时, 一旦使用了 IDE 选择了 M0+ uController, 我们很可能发现, IDE 的 config page 不再提供 arm or thumb 的选择项给我们, 往往表现为 Thumb 默认必选.

解惑2: 何为 M0+ uController 喜欢宣称自己与 M0 兼容并且可向上升级为 M3/M4?

- 根据上述分析, M0+ 与 M0 拥有同样的 ARMv6-M 指令集架构, 因此在此意义上, 是兼容的.

并且, M3 实现了 ARMv7M, M4 实现了 ARMv7E-M. 而 v6-M 为 v7-M 子集, v7E-M 为 V7 加上 DSP 指令. 均存在子集关系, 从上述角度理解, 这就是为何使用 M0+ 开发的系统, 可以向上移植到 M0, M3, M4.

解惑3: 为何强调 M0+ 的节能特性的最大贡献为 pipeline?

- 严格来说, ARMv6M/AMRv7M/ARMv5 的 A-TM 中没有对 pipeline stage 的定义(更重要的它们定义了指令集架构).

我们不清楚在哪里可以找到, M0/M0+ 约定 2-stage pipeline 的定义, 同行读者们或可告诉我...

但是返回到 uController 的 datasheet, 我们确知,

以 NXP lpc21xx 为例的 ARM7TDMI-S(实现 ARMv4T 架构) 的 pipeline 为 3-stage pipeline.
以 FSL kinetis L KL25Z 为例的 Cortex-M0+(实现 ARMv6M 架构) 的 pipeline 为 2-stage pipeline.

"通过转移到 2-stage pipeline, branch shadow 减少. 作为结果, 访问 flash memory 的次数也降低. 而 flash momery power 常常是一颗 uController 中能耗的大部分, 访问 flash 次数的降低, 将直接影响总体能耗".

回顾

在这份随笔中, 我们在对 cortex-M0+ 了解过程中, 不由得对 ARM uController story 进行了一个简单的追溯.

我们并且非常坚持地使用 ARM Architecture 作为核心判断标准, 从 ARMv4 -> ARMv7-M(与其 subset ARMv6-M) 的架构发展过程进行解读, 并作为 ARM uController 发展的阶段性产品区分标准.

并且根据指令集架构的回溯过程, 我们又对现今流行的 Cortex-M0+ 的标准特性, 如仅仅支持 Thumb 指令集进行了对照理解, 并加深了对所谓 M0+ 为何向 M4 一路顺利迁移的意义的理解.

ARM Architecture 产品类型框图(From ARM Info)

在泛泛随笔, 谈及了 architecture 后, 加上 ARM info 整理的框图, 这篇随笔就几乎完美了, 不是吗?



感想

ARM 架构的延续性, 以及目前市场上对 ARM 的服从性, 似乎第一次使我们工程师直起腰杆... 那在开始的每一份新的 MCU system 设计任务时, 也许我们似乎不用再表现的像个新人?...

*O*
这种感觉, 我们喜欢.