博客首页 | 排行榜 |

马建辉

没有版权,欢迎转载, 功德无量。

个人档案
博文分类
【设计作品展示】uCOS-Ⅱ平台电动汽车仪表盘的设计与实现  2012-12-25 16:34
分享到:

1 引言:

随着人们对汽车功能日益增长的需求,汽车电子得到了日益广泛的应用,应用的复杂性使得基于嵌入式技术的汽车电子产品的设计核心日益转向软件设计。从软件设计的开发过程来看,包括不带操作系统的裸机程序和采用操作系统的多任务应用程序两种不同的实现方式。由于裸机程序难以保证汽车电子产品的实时性要求[3],而且在遵守汽车行业的特定标准规范上有很大的实现难度,而采用实时操作系统不仅可以满足实时性的要求,还可以很容易得集成汽车行业标准规范解决方案。操作系统提供的多任务划分及其调度机制,可以更好地反映应用的不同组成部分和应用实现的不同侧面,使得程序逻辑更加清晰、模块独立性更强、维护更加方便,可靠性也更高,因此实时操作系统在汽车电子产品中得到了广泛的应用。在笔者为某电动汽车设计一款仪表盘的过程中,采用实时操作系统uCOS-II进行应用程序设计,改进了系统实时性,提高了软件质量。本文系统介绍下仪表盘的结构及软硬设计技术,以及uCOS-II的应用经验。

2 仪表盘系统结构

仪表盘是一个多方位的信息显示平台[2],信息来源包括开关量、模拟量和车速转速脉冲信号,也有来自各个汽车电子零部件的相关信息通过CAN总线获取,从而降低了直接采集的复杂度。信息的显示是仪表盘功能的核心,显示接口包括步进电机及其指针、LEDLCD和蜂鸣器,其系统结构如图1所示。

1 仪表盘系统结构图

3 硬件设计:

       仪表盘的电路设计包括开关去抖及分压电路、脉冲整形滤波电路、CAN总线通讯电路、LED驱动电路、模拟量AD采集电路、步进电机控制电路等,下面以LED驱动电路为例介绍下仪表盘的硬件设计。

3.1 LED驱动

通过LED进行信息的指示和警示是仪表盘信息显示功能的重要实现手段,部分LED的控制通过外部驱动和仪表盘内部电路自动实现,不用经过MCU程序的处理,如转向指示,其电路如图2所示。

2:右转向指示

对于需要仪表盘采集相关信息后通过一定的逻辑运算来控制的LED,由于MCU管脚驱动能力有限,而仪表盘用LED的亮度高消耗电流大,所以需要设计相应的LED驱动电路。如空挡指示功能,仪表盘采集前进档位开关和倒档开关,当前进挡和倒档同时无效时,点亮空挡指示LED,其电路如图3所示:

 

3 空挡指示

 

4 软件设计

       下面从uCOS-II的移植配置过程和应用程序两个方面介绍下仪表盘的应用程序设计。

4.1 uCOS-II移植及配置

uCOS-II的移植工作是针对处理器进行的,主要在OS_CPU.H OS_CPU_C.C OS_CPU_A.ASM这三个文件中进行[3],重点关注处理器位数决定的数据类型、不同处理器内核决定的堆栈位宽及增长方向、不同处理器决定的任务切换触发机制和上下文切换函数,由于uCOS-II针对各种通用处理器都有官方移植例程,具体移植过程在此不再赘述。

移植针对平台进行,或者说针对不同的处理器内核,相对而言是通用的,而配置则针对具体应用,不同的应用程序有不同的配置方式。配置工作主要在os_cfg.h中进行,涉及ucos-ii的裁剪和与应用密切相关的宏定义,比如不用uCOS-II中的mail box,可以通过以下条件编译语句裁剪掉这一部分,以节省有限的RAMROM资源。

#define OS_MBOX_EN                0

比如应用中只用到8个任务,那么定义OS_LOWEST_PRIO10,定义OS_MAX_TASKS8,这样便可以最大程度节省处理器资源。仪表盘应用的部分配置修改如下所示:

#define OS_LOWEST_PRIO           12    

#define OS_MAX_EVENTS           10   

#define OS_MAX_QS                 8   

#define OS_MAX_TASKS             (OS_LOWEST_PRIO-2)   

#define OS_SCHED_LOCK_EN        0   

#define OS_TICK_STEP_EN           0   

#define OS_TICKS_PER_SEC        1000   

4.2 应用程序设计

基于uCOS-II的多任务并发编程模式与裸机程序基于超级循环的前后台编程方法有很大不同[4]uCOS-II是抢占式实时多任务操作系统,以任务的形式来划分和实现应用程序的不同组成部分,不仅需要根据系统结构和特性在上层应用层面合理划分任务,根据不同任务的实时性要求合理设置任务优先级,还需要考虑任务间通信、中断与任务间的通信及数据共享。

任务通信机制是uCOS-II应用程序的核心,如何合理地使用这些通信机制,是系统能够长期高效、可靠、安全运行的关键[5]。消息队列是任务通信机制的核心,任务与消息队列一一对应,不同的任务有不同的消息队列,同一个事件在不同的任务中对应不同消息队列中的消息。消息队列及消息内容队列的设计和管理是应用程序的重心所在,下面以仪表盘应用中行车安全信息警示任务为例,介绍下uCOS-II任务的通信和调度。行车安全信息警示任务的代码如下所示:

static void IndicatorTask(void *pdata)

{

  INT8U err;

  s_MsgQ* indicatormsg;

  pdata=pdata;

  Event_Indicator=OSQCreate(&EventQ_Indicator[0],EVENT_Q_INDICATOR_SIZE);

  while(TRUE){ 

    indicatormsg=OSQPend(Event_Indicator,0,&err);   

    Indicator(indicatormsg->msg_id);     

  } 

}

首先,根据任务的复杂程度、消息产生和消费的速度,通过OSQCreate建立特定长度的消息队列,同时建立同等长度的消息内容队列,定义如下所示:

void         *EventQ_Indicator[EVENT_Q_INDICATOR_SIZE];

s_MsgQ       IndicatorMsgQ[EVENT_Q_INDICATOR_SIZE];

行车安全信息警示任务等待消息队列EventQ_Indicator中的消息,当行车安全检测任务检测到行车状况的变化时,向行车安全信息警示任务的消息队列EventQ_Indicator中发送消息,触发系统调度,行车安全信息警示任务得到CPU执行权,消化相应的消息后再次进入等待消息的状态,向行车安全信息警示任务发送消息的函数设计如下:

void PostIndicatorTaskMsg(e_Signal signal)

{

  IndicatorMsgQ[IndicatorMsg_index].msg_id=signal;

  OSQPost(Event_Indicator,&IndicatorMsgQ[IndicatorMsg_index]);

  MsgIndexUpdate(INDICATOR_TASK_PRIO);  

}

首先填充消息内容队列,然后调用OSQPost将消息内容发入Event_Indicator所表征的消息队列EventQ_Indicator,然后按照与消息队列指针更新管理相同的方式更新消息内容队列指针。

结语

本文分析了仪表盘的系统结构,介绍了其硬件设计,分析了基于uCOS-II的软件设计方式,描述了uCOS-II的移植要点和配置实例,介绍了任务间基于消息队列的通信机制和具体应用。仪表盘经装车试验,运行良好,功能稳定,有很高的实用价值。

类别:拙作 |
上一篇:一种通用的汽车仪表信号转换器设计 | 下一篇:【技术人生】读《人月神话》有感
以下网友评论只代表其个人观点,不代表本网站的观点或立场