大家好,我是痞子衡,是正经搞技术的痞子。今天痞子衡给大家介绍的是超级下载算法开发笔记(1)之执行在不同 CM 内核下。

 

文接上篇 《RT-UFL - 一个适用全平台 i.MXRT 的超级下载算法设计》,痞子衡开源的这个项目已经正式启动了。痞子衡说过会记录 RT-UFL 项目开发过程所有疑难点及其解决方法,和大家分享下载算法设计背后的奥秘。

 

本篇是开发笔记第一篇,咱们重点聊聊这个项目的立身之本,即如何做到一个 .FLM(其实就是最终的可执行机器码)能在所有 i.MXRT 芯片下均能正常运行。

 

一、从嵌入式程序角度看 i.MXRT 家族差异

因为超级下载算法要运行于所有 i.MXRT 型号下,首先我们得知道 i.MXRT 家族一共有哪些型号、这些不同型号间差异是什么,哪些差异是影响超级下载算法的主要因素。

 

下表是当前 i.MXRT 家族已面世的全部 9 款型号(注:部分型号下不止一款芯片,但仅是内部外设数量差别):

 

 

虽然从芯片本身角度去细看差异会比较多,但我们可以从一个嵌入式程序最根本的三大要素(指令、外设操作、链接空间)来逐一定向分析:

 

从上表我们可以看出 i.MXRT 都是基于 ARM Cortex-M 内核的,这其实是整个项目立项最重要的基础,它们的指令集一脉相承。不过虽然都是 Cortex-M 内核,但是涉及到三个内核处理器版本(M4、M7、M33),因此设计超级下载算法时第一要考虑的就是处理器版本差异。

 

再从外设角度来看,超级下载算法代码可能涉及操作芯片内部的 Clock(时钟)、IOMUXC(引脚)、FlexSPI(Flash 控制器)等外设,这些外设会有差异,但并不重要,我们可以为不同 i.MXRT 型号引入不同代码处理分支。

 

最后从链接空间来看,超级下载算法是要加载到内部 RAM 去执行的,这些 i.MXRT 内部 RAM 大小不一,并且在系统映射地址空间中的地址也略有不同,但也不重要,如果你看过痞子衡之前写的文章 《串行 NOR Flash 下载算法(Keil MDK 工具篇) 》,你应该知道下载算法代码都是位置无关链接,其加载地址可以不固定(由配套 xml 文件或 IDE 工程设置中额外指定),因此 RAM 的差异也不重要。

 

二、解决 Cortex-M 处理器不同版本指令差异

经过上一节的分析,我们知道解决超级下载算法在 i.MXRT 全系列下运行最重要的问题就是处理不同 Cortex-M 内核指令差异。

 

在解决指令差异问题前,有一个重要问题痞子衡不得不澄清,那就是不同 Cortex-M 芯片其中断向量表序列定义并不同,前 16 个是系统向量,这是由 ARM 规定的,但后面的中断向量均是由厂商自定义的。不同芯片型号下,同一类型外设分配的向量号并不一定相同,因此对于一些异构双核下跑的嵌入式程序,需要处理中断向量表差异。但是这对于下载算法来说,不是个问题,因为下载算法不是一般的嵌入式程序,其不含中断向量表,这意味着下载算法中没有使用中断响应函数,不能开启外设中断(这是位置无关链接导致的)。

 

好,我们现在来解决指令差异问题。查看 ARM 官方资料得知,Cortex-M 家族共有 10 款处理器(M0、M0+、M1、M3、M23、M4、M33、M35P、M7、M55),分属四个架构规范(ARMv6-M、ARMv7-M、ARMv8-M、ARMv8.1-M),架构主要和指令集息息相关。

 

 

再来看两张 Cortex-M 指令集关系图,从图里我们可以看出 Cortex-M0/M0+/M1 处理器基于 ARMv6-M 架构,这是一个只支持 56 条指令的小指令集(蓝色粗框标出),所有 Cortex-M 处理器都支持这个 56 条指令的指令集。

 

 

看到这你是不是有所领悟?ARM 公司其实为了能让 Cortex-M 用户的软件能重用,特地在设计 Cortex-M 处理器时为其赋予了处理器向下兼容、软件二进制向上兼容特性。通俗地说就是在较低版本 Cortex-M 处理器上编译出来的机器码可以在较高版本 Cortex-M 处理器上直接执行。

 

因此为了实现超级下载算法在 i.MXRT 全系列上(M4、M7、M33)运行,我们只需要做一件事,那就是编译生成算法文件的源 MDK 工程设置里选择 Cortex-M0 处理器就行,是不是超级简单?如果你下载了 CMSIS_5 包,里面的下载算法模板工程默认处理器就是 ARMCM0,这并不只是个偶然!

 

 

至此,超级下载算法开发笔记(1)之执行在不同 CM 内核下痞子衡便介绍完毕了,掌声在哪里~~~