μC/OS-II在DSP Flash存储器中运行的关键问题

引言

　　在作为国家863计划子项目挖掘机智能化控制系统的开发中，出现了智能化挖掘机轨迹控制系统不按照预先设定好的轨迹运行和嵌入式实时多任务操作系统μC／OS-Ⅱ调度紊乱等失控问题。该智能化系统中采用了μC／OS-Ⅱ，通过位移传感器实时采集挖掘机的铲斗、斗杆和动臂等3路角度信号，通过算法规划路径驱动液压比例阀实现平行推进、铲斗挖掘等典型作业。本文主要针对课题遇到的问题，重点阐述μC／OS-Ⅱ在芯片内Flash存储器运行时关键问题的分析与解决办法。

　　1μC／OS-Ⅱ在Flash存储器中的运行

　　1.1 μC／OS-Ⅱ的特点与功能

　　μC／OS-Ⅱ是一个实时多任务的嵌入式操作系统，它采用可剥夺型内核。所有的任务都有优先级，多任务之间优先级高的可以中断执行中的低优先级任务而优先执行。   

　　它的特点主要有：公开源代码、可移植性、可固化、可裁减、支持多任务、具有可确定性等。μC／OS-Ⅱ是基于优先级抢占式的实时多任务操作系统，包含了实时内核、任务管理、时间管理、任务间通信同步(信号量、邮箱、消息队列)和内存管理等功能。

　　1.2关键问题    

　　在完成了智能控制软件后，就是将之嵌入到μC／OS-Ⅱ系统中。遇到的主要问题是移植好的μC／OS-Ⅱ源代码在闻亭的目标板上在线仿真时，把.out文件下载到RAM中能正常执行，但是用CCS烧写到Flash存储器中就不能正常执行，出现智能化挖掘机轨迹控制系统不按照预先设定好的轨迹运行和μC／OS-Ⅱ实时多任务调度紊乱等失控问题，尤其是在课题的后期验收阶段问题尤为棘手。

　　1.3原因分析

　　程序固化的关键问题是如何在程序存储器中分配存储空间给常量和用const关键字定义的静态、全局变量。经过仔细研究，发现与TI的C编译器功能有关。CCS的编译器按照标准C，没有对Flash ROM中常数数据进行直接访问的功能。所以必须让const段的常量数据在RAM中。

　　实现这一条件的方法有3种：

　　a)方法1：解决μC／OS-Ⅱ在Flash中运行的方法，采用去除const关键字，在程序中赋初值使用，并且需要在.cmd文件中将.cinit段分配到程序区Flash存储空间，然后在编译器的编译选项中选中“-C”，即ROM初始化(C编译器默认就是这样的)。

　　b)方法2：不对定义作修改，.const段保存在Flash存储器中，数据不向数据存储器移动，程序运行时直接在程序存储空间中访问这些量。由于c语言缺乏访问程序区数据的有效手段，因此这些语句只能使用汇编语言编写。由于在每一处访问这些常量时都必须使用这些语句，因此这样编写程序改动量较大。

　　c)方法3：不需要修改常量定义，也不必编写专门的程序，主要的工作是修改.cmd文件并对工程中使用的库文件作简单的修改，修改工作量小而且集中，极大地方便了程序的编写。较之前两种方法，这种方法运用起来要方便得多。

　　2关键问题的解决与实现

　　以下分别介绍方法1和方法3的具体实现。

　　2.1方法1

　　解决μC／OS-Ⅱ在Flash存储器中运行的方法，即去除const关键字，在程序中赋初值使用，以μC／OS-Ⅱ的更改为例：

　　2.1.1问题的发现

　　μC／OS-Ⅱ的程序烧写到Flash中的问题，刚开始怀疑是分配存储器的cmd文件有问题，然后相关的又想到程序的大小问题，特别是在咨询闻亭的技术人员告知大于1 kB的程序要分开烧后，甚至怀疑闻亭的仿真器和开发板。后来实验使用合众达的板子是同样的效果，并且发现不带μC／OS的大小程序都能正常执行，基本排除了程序大小的问题以及硬件问题。后来通过对μC／OS系统任务调度前加LED函数，发现：直到多任务调度前都能正常执行，开始多任务调度后就出了问题。到这里确定问题出在μC／OS-Ⅱ上，但是μC／OS-Ⅱ的移植是其他人员做的，其他本身没有做过严格测试，也没有烧到Flash存储器中运行过，对整个课题产生致命的影响。最后课题组分析了程序在Flash存储器中运行与在RAM中运行的本质区别，提出一个重要的建议：可能有系统需要的常量定义在扩展RAM区了，当掉电后，RAM区的内容没有了，常量也就没有了，影响了系统的运行。

　　通过查看工程的cmd文件和编译输出的map文件，发现确实有系统内核的常量放在8000h以后的扩展RAM区。见下面map文件引用：

　　然后在OS_CORE．C中找到了常量的位置，分别是掩码表：INT8U const OSMapTbl[]和任务优先级判定表：INT8U const OSUnMapTbl[]

　　通过实验发现，烧写程序到Flash存储器中之后，如果不关电源，而直接拔掉USB，从Flash存储器引导，复位后程序能正常执行，但是关电后就不能了。经查看，Flash存储器烧写过程是先将程序装载到RAM，再搬移到Flash存储器中，所以不掉电所有程序都在RAM中有保留，但是程序确能从Flash存储器引导。这样，就确定了确实是这些常量放在RAM中引起的。但是并不像开始想象的那样，把常量直接定义在Flash存储器区就能解决，但可以通过程序赋值来初始化这些常量，而不通过编译来初始化，这是一个不一定最好但很有效的办法。

　　2.1.2修改方法

　　按照上面的思路，对μC／OS作了如下3处修改：

　　a)OS_CORE．C文件中上面两个数组的上面的初始化定义改为下面两个初始化函数：

[p]

　　b)对μC／OS-Ⅱ.H函数进行修改：将外部变量弓用的定义

　　c)在主程序的main()函数中的多任务调度函数执行前调用前面的两个初始化函数，如下：

　　此方法用一句话总结，就是将常量定义成变量，以赋值语句的方式初始化到RAM中。

　　2.2方法3：修改数据段的定位方式和库函数

　　这种方式除了要修改.const段的装载地址和运行地址外，还要对CCS自带的初始化函数进行修改。但是这种方法是一劳永逸的。

　　对.const段的修改如下：

　　即采用了装载地址与运行地址分离的方式，将.const载入ROM段，而运行时在RAM区。为了使程序正常运行，在初始化时，需要将.const段的内容从装载地址拷贝到运行地址内。这段程序可以在编译时由编译器自动生成。这还需要对软件所使用的库文件作简单的修改。该库名称即是rts.lib(表示不同类型的DSP，有2xx、25、50等)。修改该库的方法是将源文件从库中提取出来进行修改，编译后再替代原有的文件。具体操作如下：

　　a)将库函数rts2xx.lib、源文件rts.src、两个工具函数dspar.exe和dspa.exe找到，放在同意个目录下，打开ms_dos命令窗。

　　b)执行DOS命令：

　　这句的功能是从rts.src文件中提取出boot.asm文件。这个rts.src即是rts.lib的源文件。在boot.asm文件中能找到CONST_COPY这个标志量，为了实现所需要的功能，它应被赋值为1。对boot.asm文件的编辑完成之后，就可以将其编译生成目标文件，执行语句：

　　其中对于不同的DSP需要使用不同的参数，对于240xA来说，应该使用2xx来代替“”。语句执行完后会生成boot．obj文件。再执行语句：

　　这时它就替换了库里的同名文件。在编译时编译器就会自动增加拷贝.const段到数据空间的语句。这种方法不必修改程序，代价是牺牲了一定的数据存储空间，时间开销主要出现在初始化中。这应该是最经济实用的方法。

　　3结束语

　　对常量处理的3种方法中，第方法1和方法3相对较容易实现。其中方法1对于自己编写的少量代码修改起来比较方便，但是如果碰到库函数中用到.const的情况，就需要像第方法3一样提取库函数中的代码，来修改这个库函数，在挖掘机轨迹控制程序中用到atan函数就是这种情况。这种做法对每个这样的函数都要执行同样的操作，显然不是最佳解决办法。

　　方法3虽然必须修改cmd文件和库文件，但是它是一劳永逸的。生成相应的库函数和cmd文件以后，对任何带有const的代码都不再需要做任何修改。所以这种方法也是TI推荐的方法，在TI的数据手册TMS320C2x／C2xx／C5x Optimizing C Compiler User’sGuide(SPRU024E)中有对它的说明。

　　本课题已经通过国家863计划专家组的验收，该智能化挖掘机轨迹控制系统已经交付柳工使用。