DSP Flash存储器中运行μCOS-II的研究

DSP Flash存储器中运行μCOS-II的研究,第1张

  引言

  在作为国家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文件引用:

  

DSP Flash存储器中运行μCOS-II的研究,第2张

 

  然后在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文件中上面两个数组的上面的初始化定义改为下面两个初始化函数:

  

DSP Flash存储器中运行μCOS-II的研究,第3张

 

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

  

DSP Flash存储器中运行μCOS-II的研究,第4张

 

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

  

DSP Flash存储器中运行μCOS-II的研究,第5张

 

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

  

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/dianzi/2713739.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-08-17
下一篇 2022-08-17

发表评论

登录后才能评论

评论列表(0条)

保存