Cortext-M3系列:M3的底层编程(7)

1、概览

        在CM3上编程,既可以使用C也可以使用汇编,keil也支持C++,但是大多数人还是会在C与汇编。C与汇编都“尺有所短,寸有所长”,不能互相取代。使用C能开发大型程序,而汇编则用于执行特种任务。

1.1 使用汇编

        如果工程比较小,使用纯汇编常常是可行的,而且能使我们随心所欲地优化和控制程序。不过,这么一来的开发周期会变长。尤其是当工程变大,需要处理比较复杂的数据结构,以及要管理函数库时,汇编那狰狞的真面目就会渐显出来:各种地址和间接引用千头万绪;bug劈头盖脸;甚至好几天都改不完,工作量激增,简直就是自虐。(汇编狗都不用,有时候,我们连狗都不如)

        不论如何,时间宝贵。我们应该以C来实现程序的大框架,而本着好钢用在刀刃上的原则来使用汇编,因为只有在不多的特殊场合是适合使用汇编,甚至是非使用汇编语言不可的,它们包括:

        无法用C写成的函数,如操作特殊功能寄存器,以及实施互斥访问。

        在危急关头执行处理的子程序(如,NMI服务例程)。 ​

        存储器极度受限,只有使用汇编才可能把程序或数据挤进去。 ​

        执行频率非常高的子程序,如操作系统的调度程序。 ​

        与处理器体系结构相关的子程序,如上下文切换。 ​

        对性能要求极高的应用,如防空炮的火控系统。

1.2 使用C

        用C写的程序可以移植,并且操作复杂数据结构时远远比汇编方便。但因为C是一种通用语言——至少是低等高级语言,它并不指定如何初始化具体的处理器(用于在main执行前准备好执行环境)。解决这个问题时,不同的工具链都有自己的一套方法。

        尽管在使用了C后,大大加速了开发,但是底层的系统控制往往还需要汇编代码。很多编译器都允许我们直接在C代码中插汇编,称为“内联汇编”;另外还允许我们写独立的汇编模块,与编译后的C模块一起连接。以往,使用内联汇编的作法比较多,但是在ARM编译器中,不支持对Thumb-2指令的内联汇编。取而代之的,是从RealView C编译器的3.0版开始,新增了所谓“嵌入式汇编”的功能,它支持Thumb-2指令。它让我们可以在C程序中插入使用汇编语言编写的函数,例如:

_asm  void SetFaultMask(unsigned int new_value)
{
		//在这里使用汇编代码实现本函数
		MSR FAULTMASK, new_value //把new_value写入FAULTMASK中BX LR //返回主程序(不可省略)
}

        RealView C编译器对嵌入式汇编的详细论述,在《RVCT 3.0 Compiler and LibraryGuide(Ref6)》中给出。在CM3中,嵌入式汇编还是比较需要的,因为常常会有访问特殊功能寄存器的时候。比如,在设置堆栈时,就要使用MRS/MSR指令。对于其它不能由编译器产生的指令,比如WFI/WFE、互斥访问、存储器隔离等指令,也必须用汇编显式给出。

        在以前的ARM处理器中,因为支持ARM/Thumb双重状态,往往需要所谓的“interworking”,且不同的源文件可能需要编译成不同状态下的代码。在CM3中不再有此需求,因为只使用了Thumb状态,从而工程管理方便多了。

        当使用C开发程序时,推荐开启CM3的双字对齐管理机制(在NVIC配置与控制寄存器中,把STKALIGN置位),这是用于确保系统能严格遵守AAPCS过程调用标准,代码形如:

#define	NVIC_CCR ((volatile unsigned long  *)(0xE000ED14))
*NVIC_CCR = *NVIC_CCR  |  0x200;     //设置STKALIGN位

2、汇编与C的接口

        在很多情况下,都需要让C程序模块与汇编程序模块互相交互,它们包括:

        在C代码中使用了嵌入式汇编(或者是在GNU工具下,使用了内联汇编)

        C程序呼叫了汇编程序,这些汇编程序是在独立的汇编源文件中实现的

        汇编程序调用了C程序

        在这些情况下,必须知晓参数是如何传递的,以及值是如何返回的,才能在主调函数与子程序之间协同工作。这些交互的机制在ARM中有明确的规定,由文档《ARM Architecture ProcedureCall Standard(AAPCS, Ref5)》给出。

                不过,在大多数场合下的情况都比较简单:当主调函数需要传递参数(实参)时,它们使用R0-R3。其中R0传递第一个,R1传递第2个……在返回时,把返回值写到R0中。在子程序中,可以随心所欲地使用R0-R3,以及R12。但若使用R4-R11,则必须在使用之前先PUSH它们,使用后POP回来。

        可见,汇编程序使用R0-R3, R12时会很舒服。但是如果换个立场——汇编要呼叫C函数,则考虑问题的方式就有所不同:必须意识到子程序可以随心所欲地改写R0-R3, R12,却决不会改变R4-R11。因此,如果在调用后还需要使用R0-R3,R12,则在调用之前,必须先PUSH,从C函数返回后再POP它们,对R4-R11则不用操心。

3、典型的开发流程

        在开发基于CM3的应用程序时,常常有多种源程序和库,有些是自己写的,有些是别人已经写好的(尤其是底层的软件)。上述这些开发工具生成代码的流程都差不离。对于最基本的应用,也至少需要C编译器,连接器以及二进制文件处理工具。如果使用的是ARM的工具,如RVDS或RealView编译器工具(RVCT),则它们的流程如图所示。其中的“分散加载脚本”是可选的,但是当存储器映射变得比较复杂时,则需要它。

Cortext-M3系列:M3的底层编程(7)_第1张图片

4、使用互斥访问实现信号量操作

        专门用于信号量的操作中。最常见的用途,就是确保需要互斥使用的共享资源只被一个任务拥有。互斥锁本身的操作是原子访问的。

        在单处理机系统中,互斥访问主要用在ISR与主程序之间,用以保护它们共享的,并且需要互斥访问的资源(如,一块内存,一个外设)。此时,引起互斥写失败的唯一原因,就是在读写期间曾响应过中断。如果代码在特权级下运行,还可以通过设置PRIMASK,在“测试——置位”期间暂时把中断给掐了。 ​

         在多处理机系统中,情况会变得更复杂。此时,除了本机的中断,其它处理机对同一块内存的访问也可以使互斥写操作失败。为了检测到其它处理机对内存的访问,总线系统中必须加入一个“互斥访问监视”的硬件基础设施。它负责检测在互斥读写期间,总线上是否有其它主机访问了互斥锁及其临近的“高危地带”。事实上,在绝大多数低成本的CM3单片机中,都只包含了一个核,因此无需此监视器。 ​

         有了这个机制,我们就可以确信共享资源一定能互斥地使用,不会发生紊乱危象。如果一个共享资源在多次尝试时依然无法获取,则可能必须放弃对此资源的请求,有可能先前锁住该资源的任务已经崩溃了。

5、使用位带实现互斥锁操作

        如果存储器系统支持“锁定传送”(locked transfers),或者总线上只有一个主机,还可以使用CM3的位带功能来实现互斥锁的操作。通过使用位带,则可以在C程序中实现互斥锁,但是操作过程与互斥访问是不同的。在使用位带来做资源分配的控制机制时,需要使用位带存储区的内存单元(比如,一个字),该内存单元的每个位表示资源正被特定的任务使用。 ​

        在位带别名区的读写实质上是锁定的“读-改-写”(在传送期间总线不能被其它主机占有)。因此,只要每个任务都仅修改分配给它们自己的锁定位,其它任务锁定位的值就不会丢失,即使是两个任务同时写自己的锁定位也不怕。

        对于“测试并设置”这种互斥锁的简单操作,也可以使用“关中临界区”来保护——也就是在操作前关中断,操作后开中断。这种关中的时间是很短的,因为其它原因导致的关中通常都比这个长得多。只是有时为了无限追求实时性,有一丝希望也会尽最大的努力,就像这两种互斥锁操作那样。

6、使用位段提取与查表跳转

        位段提取指令(UBFX)和查表跳转指令(TBB/TBH)。这两条指令可以配合工作,以构建一个非常强大的“跳转树”。这对于电表及数据通信应用程序非常有意义,常使这类程序得到戏剧般地优化。这类程序在工作时,经常要判断各种各样的情况,并且“分类讨论”。有时,还需要进一步细化,作二级甚至多级的比较判断。

你可能感兴趣的:(ARM体系,嵌入式硬件,单片机,arm,mcu,stm32)