原创 基于ARM的嵌入式程序开发要点三。转

1  ARM还是Thumb

　　在讨论ARM还是Thumb之前,先说明ARM内核型号和ARM体系结构之间的区别和联系。

　　如图1所示,ARM的体系结构主要从版本4开始,发展到了现在的版本6。体系结构的变化,对程序员而言最直接的影响就是指令集的变化。体系结构的演变意味着指令集的不断扩展。值得庆幸的是,ARM体系结构的发展一直保持向上兼容,不会造成老版本程序在新体系结构上的不兼容。

图1  ARM体系结构和处理器家族的演变发展

　　在图1中的横坐标上,显示了每一个体系结构上都含有众多的处理器型号,这是在同一体系结构下根据硬件配置和存储器系统的不同而做的进一步细分。需要注意的是,通常我们用来区分ARM处理器家族的ARM7、ARM9或ARM10,可能跨越不同的体系结构。

　　在ARM的体系结构版本4与5中,还可以再细分出几个小的扩展版本——V4T、V5TE和V5TEJ,其区别如图2所示。这些后缀名也反映在各自拥有的处理器型号上面,可以进行直观的分辨。V6结构体系因为包含了以前版本的所有特性,所以不需要再进行分类。

图2  体系结构特征

　　上面介绍了整个ARM处理器家族的分布,主要是说明在一个特定的平台上编写程序时,一定要先弄清楚目标的特性和一些细微的差别,特别是需要具体优化特征的时候。

　　从ARM体系结构V4T以后,最大的变化是增加了一套16位的指令集——Thumb。在一个具体应用中是否要采用Thumb呢？首先我们来分析一下ARM和Thumb各自的特点和优势。先看如图3所示的性能分析。

　　图3中的纵坐标是测试向量Dhrystone在20MHz频率下运行1s的结果,其值越大表明性能越好;横坐标是系统存储器的数据总线宽度。结果表明：

　　①　当系统具有32位的数据总线宽度时,ARM比Thumb有更好的性能表现;
　　②  当系统的数据总线宽度小于32位时,Thumb比ARM的性能更好。

图3  ARM和Thumb指令集的比较

　　由此可见,并不是32位的ARM指令集性能一定强于16位的Thumb指令集,要具体情况具体分析。考察个中的原因,其实不难发现,当在一个16位存储器系统里面取1条32位指令的时候,需要耗费2个存储器访问周期,比之32位的系统,其速度大概下降一半左右。而16位指令在32位存储器系统或16位存储器系统里的表现基本相同。正是存储器造成的系统瓶颈导致了这个有趣的差别。

　　除了在窄带宽系统里面的性能优势外,Thumb指令的另外一个好处是代码尺寸。同样一段C代码,用Thumb指令编译的结果,其长度大约只占ARM编译结果的65%左右,可以明显地节省存储器空间。在大多数情况下,紧凑的代码和窄带宽的存储器系统,还会带来功耗上的优势。

　　当然,如果在32位的系统上面,并且对系统性能要求很高的情况下,ARM是一个更好的选择。毕竟在这种情况下,只有32位的指令集才能完全发挥32位处理器的优势。

　　因此,选择ARM还是Thumb,需要从存储器开销和性能要求两方面加以权衡考虑。

2  堆栈的分配

　　在图3中,横坐标上还有一种情况：存储器宽度是16位的,但是堆栈空间是32位的。这种情况下无论ARM还是Thumb,其性能表现都比单纯的16位存储器系统情况下要好。这是因为ARM和Thumb其指令集虽然分32位和16位,但是堆栈全部是采用32位的。因此在16位堆栈和32位堆栈的不同环境下,其性能当然都会相差很多。这种差别还跟具体的应用程序密切相关,如果一个程序堆栈的使用频率相当高,则这种性能差异很大;反之则要小一些。

　　在基于ARM的系统中,堆栈不仅仅被用来进行诸如函数调用、中断响应等时候的现场保护,还是程序局部变量和函数参数传递（如果大于4个）的存储空间。所以出于系统整体性能考虑,要给堆栈分配相对访问速度最快、数据宽度最大的存储器空间。

　　一个嵌入式系统通常存在多种多样的存储器类型。设计的时候一定要先清楚每一种存储器的访问速度,地址分配和数据线宽度。然后根据不同程序和目标模块对存储器的不同要求进行合理分配,以期达到最佳配置状态。

3  ROM还是RAM在0地址处

　　显然当系统刚启动的时候,0地址处肯定是某种类型的ROM,里面存储了系统的启动代码。但是,很多灵活的系统设计中,0地址处的存储器类型是可映射的。也就是说,可以通过软件方法,把别的存储器（主要是快速的RAM）分配以0起始的地址。

　　这种做法的最主要目的之一是提高系统对中断的反应速度。因为每一个中断发生的时候,ARM都需要从0地址处的中断向量表开始其中断响应流程,显然把中断向量表放在RAM里,比放在ROM里有更快的访问速度。因此,如果系统提供了这一类的地址重映射功能,软件设计者一定要加以利用。

　　图4是一个典型的经过0地址重映射之后的存储空间分布图。注意：尽可能把速度要求最高的部分放置在系统里面访问速度最快、带宽最宽的RAM里面。

图4  系统存储器分布的实例

4  存储器地址重映射

　　存储器地址重映射（memory remap）是当前很多先进控制器所具有的功能。在上一节中已经提到了0地址处存储器重映射的例子。简而言之,地址重映射就是可以通过软件配置来改变一块存储器物理地址的一种机制或方法。

　　当一段程序对运行自己的存储器进行重映射时,需要特别注意保证程序执行流程在重映射前后的承接关系。图5是一种典型的存储器地址重映射情况。

图5  存储器重映射举例1

　　系统上电后的缺省状态是0地址上放有ROM。这块ROM有两个地址：从0起始和从0x10000起始,里面存储了初始化代码。当进行地址remap以后,从0起始的地址被定向到RAM上,ROM则只保留有唯一的从0x10000起始的地址。

　　如果存储在ROM 里的Reset_Handler一直在0~0x4000的地址上运行,则当执行完remap以后,下面的指令将从RAM里预取,这必然会导致程序执行流程的中断。根据系统特点,可以用下面的办法来解决这个问题。

　　①  上电后系统从0地址开始自动执行,设计跳转指令在remap发生前使PC指针指向0x10000开始的ROM地址中去,因为不同地址指向的是同一块ROM,所以程序能够顺利执行。
　　②  这时候0~0x4000的地址空间空闲,不被程序引用,执行remap后把RAM引进。因为程序一直在0x10000起始的ROM空间里运行,remap对运行流程没有任何影响。
　　③  通过在ROM里运行的程序,对RAM进行相应的代码和数据拷贝,完成应用程序运行的初始化。下面是一段实现上述步骤的例程。

-------------------------------------------------------------------------------
ENTRY ;启动时,从0开始,设法跳转到“真”的ROM地址（0x10000开始的空间里）
　　LDR pc, =start
　　;insert vector table here
Start ;Begin of Reset_Handler
　　; 进行remap
　　设置 LDR r1, =Ctrl_reg ;假定控制remap的寄存器
　　LDR r0, [r1]
　　ORR r0, r0, #Remap_bit ;假定对控制寄存器进行 ;remap设置
　　STR r0, [r1]
;接下去可以进行从ROM到RAM的代码和数据拷贝

　　除此之外,还有另外一种常见的remap方式,如图6所示。

图6  存储器重映射举例2

　　原来RAM和ROM各有自己的地址,进行重映射以后RAM和ROM的地址都发生了变化。这种情况下,可以采用以下的方案。
　　①  上电后,从0地址的ROM开始往下执行。
　　②  根据映射前的地址,对RAM进行必要的代码和 数据拷贝。
　　③  拷贝完成后,进行remap操作。
　　④  因为RAM在remap前准备好了内容,使得PC指 针能继续在RAM里取到正确的指令。

　　不同的系统可能会有多种灵活的remap方案,根据上面提到的两个例子,可以总结出最根本的考虑是：要使程序指针在remap以后能继续往下得到正确的指令。

5  根据目标存储器系统分散加载映像

　　分散加载（Scatterloading）文件是ARM工具链里面的一个特性,作为程序编译过程中给链接器使用的一个参数,用来指定最终生成的目标映像文件运行时的分布状态。如果用户程序映像只是如图7所示的最简状态,所有的可执行代码都集合放置在一起,那么可以不使用Scatterloading文件,直接用链接器的命令行选项就能够完成设置。

图7  简单的映像分布举例

　　RO = 0x00000：表示映像的第一条指令开始地址。
　　RW = 0x10000：表示变量区的起始地址,变量区一定要位于RAM区。

　　但是一个复杂的系统可能会把映像分割成几个部分。如图8所示,系统中存在多种类型的存储器,不同的代码部分根据执行性能优化的考虑分布在不同的地方。

图8  复杂的映像分布举例

　　这时候不能通过简单的RO、RW参数来完成实现上述配置,就要用到scatterloading文件了。在scatterloading文件里,可以给编译出来的各个目标模块指定运行地址,下面的例子是针对图8的。

FLASH 0x20000 0x8000 {
　　FLASH 0x20000 0x8000 {
　　　　init.o (Init, +First)
　　　　* (+RO)
　　}
　　32bitRAM 0x0000 {
　　　　vectors.o (Vect, +First)
　　　　handlers.o (+RO)
　　　　}
　　STACK 0x1000 UNINIT {
　　　　stackheap.o (stack)
　　　　}
:
　　:
　　16bitRAM 0x10000 {
　　　　* (+RW,+ZI)
　　　　}
　　HEAP 0x15000 UNINIT {
　　　　stackheap.o (heap)
　　　　}
}