标签: m0+

关于 CORTEX-M0+ 架构随笔   修改历史 08.30, 完成初稿. 09.01, 修改文中错误, 全部的 ARMv7 架构都实现了 Thumb-2 技术. 而作为 ARMv7M 子集 的 ARMv6M, 实现了绝大部分 Thumb, 以及少数几个的 Thumb-2, 因此不能直接称 ARMv6M 实现了 Thumb-2.  并且为了系统概括, 在最后的部分, 增加了来自 ARM info 的构架与产品线对应框图. ARM Architecture 诚如 ARM 帮助文档所言, 确定所研 uController 的体系构架是第一重要的事情. "因为 ARM 指令集架构被第一个研发出来, 并且会在未来持续被研发". 那么今天(这里指2013年8月间), ARM 架构的版本号从 v1 排到 v8(这是确认无疑的, 因为此刻我们正在注视着, ARM Information Center 的 documentation 部分的 "ARM 体系结构"章节的下拉框).  *o*   幸运的事情是, 我们不必再关注 ARM 诞生伊始的 v1, v2, v3. 在 arm A-RM document 中, 注明因过时而废止的 ARM架构包括: ARMv1, ARMv2, ARMv2a, ARMv3, ARMv3G, ARMv3M, ARMv4xM, ARMv4TxM, ARMv5, ARMv5xM, and ARMv5TxM 我们想知道的就是, v1 为啥是 26-bit 的架构, ARM 设计之初面临着一个怎样资源稀缺的生产工艺? 而 ARMv3 作为第一个引入 32-bit 架构设计的时代背景又是如何? -- 但是 anyway, 这些个 story 都以远去, 我猜她们的剧情都至少超过了 10 years. 对比作为有效的现存架构是: ARMv4, ARMv4T, ARMv5T, (ARMv5TExP), ARMv5TE, ARMv5TEJ, and ARMv6 ARM7TDMI-S 而 ARM7, 作为 ARM 世界在基础应用中的, 小心翼翼的第一步, 这样进入了我们的视野. 我们最初接触到的 ARM7, 比方以 NXP 的 LPC21XX series 为例, 注意到其ARM core是 ARM7TDMI-S, 其ARM 架构为 ARMv4T(参考源于 ARM7TDMI-S 之 A-RM). 这也是一颗 Von Neumann 架构的 32-bit 的 RISC. 话说 Von Neumann 架构似乎总是为简单或者基础的型号而准备? 因为, 我们往往不稀奇地在 M3 或者 M4(我们把这些比做更高级的应用), 里面发现定义的是哈佛结构. 这可能从另一方面说明了, 这里的 ARM v4T 或者我们后面提到的 Cortex M0/M0+ (v6M) 在 ARM 的设计理念中, 是面向低端市场的存在, 且生产工艺更简单(或者生产成本更低廉). Thumb v4T 的这个变量 T, 在 A-RM document 中, 被当作 Thumb 指令集的标志. 关于 Thumb mode, 我想已经可能为我们熟知了, 正是因为其 16-bit 的宽度, 会显著地降低我们 firmware 的 size, 而据说性能同 arm mode 比较没有太大的损失. 但是应该注意的是, Thumb 指令集, 仍然是 ARM 指令集的一个子集, 只是其每条指令, 都被编码为 16-bit. 另外, 虽然没有看见类似的说法, 但我个人是有怀疑, 是否 Thumb 指令集被第一次引入, 就是在 ARMv4T 架构之上呢? ARM7/ARM9/ARM11 ARM7 series 的 CPU core 包括: ARM7TDMI、ARM7TDMI-S、ARM7EJ-S 和 ARM720T. ARM9/ARM9E series 的 CPU core 包括: ARM926EJ-S、ARM946E-S、ARM966E-S、ARM968E-S、ARM996HS、ARM920T 和 ARM922T ARM11 series 的 CPU core 包括: ARM1136JF-S 和 ARM1126J-S、ARM1156T2-S、ARM1156T2F-S、ARM1176JZF、ARM1176JZ-S、ARM1176JZF-S 以及 ARM11 MPCore 尽管没有明言, 我们敏感地感觉到, 上述过去年代中, 被我们熟知的 ARM7, ARM9, ARM11, 其体系架构可能均属于前面提到的, ARM 架构中的有效部分, 它们是: ARMv4, ARMv4T, ARMv5T, (ARMv5TExP), ARMv5TE, ARMv5TEJ, and ARMv6 (如果我有错请告诉我). 并且令人精神振作且注意力集中的是: ARM documentation 称呼上述 ARMv4 ~ v6, 通称为: ARMv5 架构. 似乎可以简单认为, 超过 v4~v6, 比方说凡是 v7 就是进入 ARM 新时代, 就可以当作 ARM 新系列 cortex 之后的实现架构? 答案并非如此, 因为我们知道, 至少 ARMv6M 还属于新出现的 cortex series. 我想这是不是说, 将对应的产品与架构进行比对才能定论, 比方说, 与上述 ARMv4 ~ v6(通称v5架构) 进行比对, 观察是新时代 cortex 产品, 还是过去的 ARM7/9/11. ARM 新时代 - CORTEX 不管是从技术引领市场, 还是市场推动技术的哪个观点来看, ARM 的架构进步都让人屏住呼吸. 我很想代表多位工程师, 呼喊出我们的心声, "喂喂, 老兄, 节奏请放慢点儿, 这才2,3年, v4T 我们还熟悉的不够捏!```" 但沉默的工程师, 总是被动于势不可挡的科技进步与市场需求... 观察 ARM 版权所有声明的年限, 我们注意到在 2008 年, cortex 已经进入设计进度或者说可能设计成熟阶段/计划市场推广了. Anyway, ARM7/9/11 的年代迅速成为记忆中的口号, 我们现在不得不在 ARM 的教育下, 言必称 Cortex. 正如我们近年来熟知的, Cortex 分成 A, R, M 三个 series, 或者我们理解, 这可能勉强对应着, 高端 - 中端 - 低端的应用需求. 再来回到我们的思路核心: 以 ARM 处理器架构为核心区分 ARM 产品类型. 那么伴随 cortex 产品系列的出现, 伴随而来的, 新的架构 ARMv7 浮出水面. P.S, ARM7/9/11 is dead? 似乎不能完全确认, 尽管今天我们称呼 ARM7/9/11 为陈旧概念, 但是在 ARMv7-AR 架构中, 还特别给出章节, 讲解 ARM11 中较新的 ARMv6 的版本. 我们大胆猜测, 这或许是尊重已经投放市场的产品线的继续延续? 还是说, ARMv6 (通常 ARM11 实现的是v6 架构) 处于研发历史阶层的上下衔接阶段? 因为 ARMv6 在通称的 ARMv5 文档中, 以及在 ARMv7-AR 文档中, 都被提及. ARMv7 Cortex A 与 cortex R 似乎被 ARM 统一对待, 它们两者的指令集架构被放在了一个文档中, ARMv7-AR RM. 我们可以合理想见其架构的相似性. 还有就是, 我们这里重视的基础类型的 application 中常用的 Cortex M 系列实现的架构: ARMv7-M. 而 ARMv7-M 指令集架构一般由 Cortex-M3 实现. ARMv7-M 仅支持 Thumb-2 任何阅读过 ARMv7-M A-RM document 的同行诸君, 都会如我们般, 立即注意到 ARM 指令集章节消失, 只存在 Thumb 指令集章节. 显然的, ARMv7-M 只支持 Thumb instruction set. 因为全部的 ARMv7 都支持 Thumb-2(包括大量32-bit 指令), 故 ARMv7-M 仅仅支持 Thumb-2 ISA, 而不支持 ARM ISA. ARMv7类型特点 A, 具备内存管理模块的虚拟地址 -- 我们毫不犹豫将它与影音应用化等号. R, 有一个实时的 profile -- 我们似乎感觉到路由器转发器之类的应用在招手. 而且我们似乎也对 R 的来由知道了些什么``` M, 至于M -- 我们想忠实翻译出 M 的介绍, "仅仅支持 Thumb, 这里整个儿的 size 和实现操作的确认性, 比纯粹的能力表现来得更重要"... 与闪闪发光 AR 比较, 这个推广似乎有点让人垂头丧气,``` 不过似乎也非常符合 cortex M 的市场策略```  ^^ 对于我们感兴趣的 ARMv7-M 的特性之一是: 异常句柄仅仅用 c/c+ funcitons 就可以实现, 标准调用即可. 我们猜测这可能说明, 类似处理中断之类的 job, 我们或者说 compiler 不需要汇编的代码的参与. 什么是"高度确定性的操作"(Highly deteerministic operation)? 在 ARMv7M A-TM 中, ARM 试图向我们解释, Cotex M series(比如实现 v7M 的 cortex M3), 一个强调的优点就是高度确定性操作, 这可能包括下列优点: (1) single or low cycle count execution (2) minimal interrupt latency, with short pipeline (3) cacheless operation ARMv7E-M 如果在 ARMv7-M 架构中, 加入 ARM DSP 指令, 可以实现 ARMv7E-M. Cortex M4 实现该架构而为我们所知. v5 与 v7M Registers 如果要在通称 ARMv5 与 ARMv7M 的 Register 进行一番比较, 我们能够发现一些显著的不同: ARM registers(通称 v5) 共 37pcs, 包括: 16pcs 通用registers + 15 pcs(异常加速处理专用 registers) + 6pcs 状态 registers(CPSR, 5-SPSR) 这 16pcs 通用 registers 中有 3pcs 是特殊的, 它们是: R13(SP), R14(LP), R15(PC) ARMv7-M core registers (我们没有提及 v7M 新的 SCS registers 与 CPUID registers, 它们属于 memory mapped system registers) 在 application level 上, (16 + 1)pcs core register, 包括: 13pcs 通用registers + 3pcs specail registers(SP, LR, PC) 以及 application statue register APSR. 在 system level 上, 则增加了 xPCR, MASK, CONTROL registers   如果说 ARMv7-M 的不同特性, 它们或许暗示着: (1) SP, LP, PC currently is specail register for v7M instead of using as general purpose registers sometimes under v5 Architecture. (2) xPCR only manage APSR, IRSP and EPSR, which is different from v5 (it will save any PSR with every proess mode). (3) Add MASK and CONTROL registers. About Control register, we found it should be specail for us to know the privilege mode, sp mode and fp extension. 尽管有这两者我们总结出的上述不同, 但是也让我们感觉到了 arm architecture 的继承性. 另外, 我们隐约意识到, 因为 SCS 与 CPUID registers 的存在, 我们很可能对 ARMv7-M 的实现者(我指 M0 ~ M4) 将有一个更加清晰的了解与支配手段``` Cortex M0/M0+ 实现的架构 Cortex M0/M0+ 实现的架构是 ARMv6-M ARMv6-M 架构 ARMv6-M 是 ARMv7-M 的一个子集(subset) ARMv6-M 架构仅支持 Thumb 指令集 ARMv7-M 架构支持Thumb-2(该指令集在 v6T2中引入). 作为 ARMv7-M 的 subset,  v6M 支持全部的来自 ARMv7-M 的 16-bit Thumb instructions(不包括 CBZ, CBNZ, and IT). 此外还支持 32-bit 的 Thumb Instraction 中的 BL, DMB, DSB, ISB, MRS, MSR. 要提及的就是, 作为 v7-M的 subset, 也同样的, 并不支持 ARM 指令集 因此, 在上述角度下, Cortex-M0+ 应该称为 Thumb 支持更合适(实际上, 后面的 ARM info 的 Architecture 框图也说明了此点). 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* 这种感觉, 我们喜欢.   Allen Zhan 2013.08.30 于深圳 Release On EETC