通过vmware 来搭建vxworks 的开发环境,然后通过target server 来进行调试程序,网络 下载应用程序,小的应用程序可以顺利download 下去,大的应用程序就不行了。 本文就简要介绍一下如何解决这个问题。
VxWorks 的WDB 通信服务,不支持通信数据的拆包处理,由于网卡的MTU 比较小, 当下载的应用程序比较大的时候,数据会被拆成多个小包,而WDB 不支持拆包,所以导致 target server 在下载的时候抱错,问题的关键在于网卡的MTU,所以可以通过增大网卡的 MTU 来解决这个问题。
下载地址
在VxWorks Image Project的kernel configuration中增加FTP Server组件(INCLUDE_IPFTPS)
将下面的代码copy到usrAppInit.c,放在usrAppInit()前
#include "iprip.h" #include "ipftps.h" int myAuthenticateCallback (Ipftps_session * session,char * password) { return 0; }
如果需要密码验证,可以修改myAuthenticateCallback函数如下
int myAuthenticateCallback (Ipftps_session * session,char * password) { if ( (strcmp (session->username, "abc") == 0)&& (strcmp (password, "123") == 0)) return 0; else return -1; }
操作系统总是基于某个时钟节拍来跑的,这个节拍的得到往往是通过硬件时钟中断得到,一般来说这个中断的优先级就比NMI低一点点,比其他的都高。
这个中断是供给操作系统用的,操作系统用他来进行调度等各种处理。而在VxWorks中的一个重要参数就是SYS_CLK_RATE这个参数,也就是系统时钟率。它的含义是:系统时钟滴嗒在一秒钟之内发生多少次。
比如说,你定义为 60,那么系统时钟在1s中将发生60次中断,两次之间的时间差就是1/60s。发生中断后,操作系统可以进行任务切换。也就是说,如果你有一个任务被挂起,则至少要过1/60s后被激活(其它中断除外)。
又假如你设置为1000,那么系统时钟1秒发生1000次中断,两个时间差就是1ms。而函数sysClkRateGet就是用来获取系统时钟率的,如果你没有调用sysClkRateSet() 函数对系统时钟率进行重新设置的 话,其返回值应该是你在config.h中定义的SYS_CLK_RATE宏的值。而函数taskDelay()是以tick数目为单位的,比如 taskDelay(1) 是指将调用该函数的任务延迟1个tick。那么时间是多少呢,根据你的SYS_CLK_RATE的值,其实际时间不同,但具体 时间是1/SYS_CLK_RATE。假如SYS_CLK_RATE是1000,那么就是1ms。如果是60那么就大约是16.67ms。
通常来讲,VxWorks手册建议不要将时钟率设得太高,否则它就由硬实时变得趋向于软实时了。因为过高的时钟率使得内核调度频繁进入,可能导致一些低优先 级的硬件中断不能得到及时响应。当然,也不要太担心,在x86系统中完全可以设置为1000,这样比较好使,1个tick就是1ms,跟Windows一 样了。
VxWorks下aux clock的使用示例:利用辅助时钟进行对某些函数运行时间进行精确计时。
首先需要在VxWorks映像中包含辅助时钟,包含组件hardware->peripherals->clocks->AUX clock,并将参数 AUX_CLK_RATE_MAX 改大点,默认只有5000的。
然后在程序中的调用,比如要记录某个函数的执行时间,函数假设为为test(),示例如下:
被调用的函数:
int g_aux_clock_tick=0; int myISR(void) { g_aux_clock_tick++; }
进行调用操作:
test(void) { sysAuxClkConnect((FUNCPTR)myISR, 0); sysAuxClkRateSet(100000); // 10us一次 sysAuxClkEnable(); test(); // 要计时的程序 sysAuxClkDisable(); // 然后查看g_aux_clock_tick的计数值是多少就知道了 }
在VxWorks下,使用系统本身提供的接口函数ExcConnect()来进行异常处理只对PowerPC系列处理器有效,对目前使用同样广泛的Intel 80x86系列处理器和ARM系列处理器无法提供有效支持。本文主要针对目前VxWorks异常机制可移植性差的问题,提出一种及时准确并且与具体处理器类型无关的捕捉异常的方法。
在VxWorks下如果使用默认的异常处理机制,处理结束后:产生异常的任务将被悬挂,且该消息将被传送到控制台。可以看出,如果不对异常进行处理,使用默认的异常处理方法,对于一个系统来说往往是致命的。所以我们必须对系统默认的异常处理方法进行修改和完善。
可以将异常处理流程分为以下5个阶段:
本文设计的异常处理模块采用钩子函数的方式接收操作系统传入的异常现场;在内存的保留区保存传入参数,并释放信号量以激活守护任务;守护任务保存未解析的现场信息;采用堆栈回溯和匹配函数序言的方式进行函数调用链分析,将结果保存到内存保留区;若存在外部存储介质,则将解析后的现场和函数调用链分析结果写入文件;对应用层提供钩子函数以实现恢复策略支持。
异常处理模块的整个流程主要由两部分组成:异常处理初始化流程和异常钩子函数流程。初始化流程主要包括初始化全局变量和挂接异常处理钩子函数。异常处理的处理过程设计如图所示:
异常处理过程中的关键是“堆栈分析”,即使用堆栈回溯的方法实现现场分析,该功能的实现也是异常处理的难点。现场分析与处理器类型密切相关,需针对不同系列处理器分别分析异常类型、现场信息、运行栈结构、函数的序言和尾声等内容。下面以x86 处理器为例进行说明。
© 2024 VxWorks Club