LPC1768嵌入式uCOS-II+UDP移植应用手册

基于LPC1768硬件平台移植uC/OS-II记录文档

孟范涛：2013-4-19 2013-4-19一移植准备工作

一、系统内核

在Micrium官网下载基于LPC1768的评估系统框架代码Micrium_LPC1768-SK_uCOS-II，其代码结构如下：

二、标准固件库

目前有两个版本，其一down自NXP官网的ware支持站点，版本2012年中，60M左右，有DSP，filter等丰富的代码支持及相关设计工具，但该死的是NXP对源代码进行了封装，所以调用起来非常不方便，所以选择了其二，即谢云鹏版本，虽然版本较老（2011），但其源码开源，便于移植和引用。最后的固件库目录结构如下：

三、硬件测试平台

苗林的M3-Transport板，板级资源包括以太网、232串口、422串口、485串口、USB串口、JTAG调试接口；

四、开发平台

KEIL MDK470

五、测试目标：在ucosii系统下开发以太网、ADC、文件系统，应用的BC中视频项目。

2013-4-19一系统内核移植及测试

一、整理代码架构

由于官方的测试代码是多平台、多CPU支持的，所以文件目录结构混乱、启动文件位置不合理、头文件包含不清晰，非常不便于对系统的深入理解，也不利于后期备份与共享，遂必须去除无用文件，删除多级目录，构建一个清晰的文件管理目录，基本的步骤如下：

1.删除IAR平台支持文件

2.删除无效启动文件

3.去除三级以上目录，提取平台相关文件

工程版本LPC1768_uCOSII经典，且编译通过，最后的目录结构如下：

提示：全部文件位置小于二级，并增加了app文件夹，存放高层应用文件app.c、app_cfg.c，以后自定义的高层用户文件也放置在此，便于管理。

二、潜入NXP固件库

UC官方代码的BSP、CSP对LPC1768的支持有限，并且进行了转义表示，非常不符合前后台方式（裸跑）工程师的开发习惯，所以要淡化原BSP、CSP的过度功能，只留有时钟系统初始化、系统定时器初始化、堆栈初始化、任务切换（汇编）的关联代码，其他如gpio、spi、i2c的代码全部删除，转而采用nxp标准固件库来替代BSP/CSP，有两点非常重要：

1.有选择的潜入固件库设备驱动文件

2.不引入固件库提供的系统启动文件，否则会与uc提供的启动文件发生冲突。

3.不调用固件库中的系统初始化函数，保持uc/bsp中的初始化方式。

4.systick中断也由uc初始化。

带固件库的工程版本LPC17xx_FwLib_uCOS-II，最后的目录结构如下：

三、核心代码整改

由于原测试代码是基于其官方评估板的，且苗林板没有数码管接口，所以无法测试，所以只能用串口来检验系统，具体工作如下：

1.删除bsp、csp中的led、key的相关代码级宏定义

2.删除app.c中启动任务的led功能代码

3.增加固件库的管理头文件fw_driver.h，并加入到includes.h中，这样完全不影响原os文

件结构，实现固件库和BSP的自然衔接。

4.增加bsp_uart.h/bsp_uart.c文件，并加入带includes.h中，这两个文件完全采用固件库函

数实现，具体实现见源代码。

5.增加usr_app.c文件，把用户应用级任务完全放倒这个文件里，类似前后台程序的main.c,

而app.c只用作系统初始化、系统启动。

最后的代码结构如下：

五、用DB9串口（uart3）进行系统测试，在task1中初始化uart3，并且循环向上位机发送

字符串“laomeng”，测试成功：

总结：

1.文件组织无误

2.固件移植无误

3.启动文件选择无误

4.启动初始化、启动正常

5.固件驱动加载、调用正确，系统任务执行正常

2013-4-20一串口中断系统测试一

一、中断使能及注册

#if(UART3_INT_EN > 0)

/* Enable UART Rx interrupt */

UART_IntConfig((LPC_UART_TypeDef *)LPC_UART3, UART_INTCFG_RBR, ENABLE);

/* Enable UART line status interrupt */

UART_IntConfig((LPC_UART_TypeDef *)LPC_UART3, UART_INTCFG_RLS, ENABLE);

/* ?òOS?μí3×￠2áUART3?D?? */

//CSP_IntVectReg(CSP_INT_CTRL_NBR_MAIN, CSP_INT_SRC_NBR_UART_03, (CPU_FNCT_PTR)Uart3Int_Handler, (void *)0);

CSP_IntVectSet((CSP_INT_VECT *)CSP_INT_SRC_NBR_UART_03,

(CPU_FNCT_PTR )Uart3Int_Handler,

(void *)0);

CSP_IntEn(CSP_INT_CTRL_NBR_MAIN, CSP_INT_SRC_NBR_UART_03);

#endif

仔细看了固件和CSP的代码，中断的注册机使能没有太大问题，但是依然不能进入中断，于是问题回到了启动文件，发现自己定义的中断服务程序与系统启动文件预订的预订的服务程序不符，于是按照startup_LPC17xx.s修改cstartup.s中的外部中断向量表。

2013-4-25一串口中断系统测试二

结果：测试通过，版本LPC17xx_FwLib_uCOS-II_20130425

“串口中断测试一”失败原因：串口三引脚配置错误，即串口三的RXD复用引脚配置成TXD 的了，所以直接导致查询、中断两种方式都无法接受到数据，正确配置之后问题得以解决。

一、关于OS环境下使用中断服务的总结，大致五个步骤：

（1）利用固件库函数配置外围设备的基本工作模式

（2）利用固件库提供的中断配置函数，设定目标中断标志

（3）自定义、编写中断服务程序

（4）利用CSP提供的系统级中断服务注册函数（如下）向系统注册对应的中断向量，及中断服务程序的执行函数入口地址（ISR函数名）

CPU_BOOLEAN CSP_IntV ectReg (CSP_DEV_NBR int_ctrl,

CSP_DEV_NBR src_nbr,

CPU_FNCT_PTR isr_fnct,

void *p_arg)

（5）使用CSP提供的中断源使能函数（如下），在系统级使能对应的中断服务；

void CSP_IntEn (CSP_DEV_NBR int_ctrl,

CSP_DEV_NBR src_nbr);

至此中断的实现过程结束！

二、深入理解uC/OS-II系统中断处理思想

（1）硬件触发中断，根据系统启动文件cstartup.s定义，程序跳转到对应的中断服务的入口地址执行对应的中断服务程序。

（2）然，所有外部中断共用一个中断服务程序OS_CPU_IntHandler，大概流程如下：函数名称定义位置说明

调用

顺序

1 OS_CPU_IntHandler Os_csp.c 1.临界代码区保护，OSIntNesting++，

2.调用CSP_IntHandler();

2 CSP_IntHandler() Csp_int.c 1.判断中断是否有效

2.加载p_int_vect = &CSP_MainVectTbl[src_nbr];

3.调用CSP_IntVectDeref(p_int_vect)

3 CSP_IntV ectDeref（）Csp.c 调用用户自定义中断服务函数：

(*int_isr_fnct)(p_int_arg)

4 Usr_ISR 应用层用户自定义中断服务程序

5 中断返回---------- OSIntNesting++

三、提示

（1）OS系统对所有硬件中断进行了统一封装，交由OS_CPU_IntHandler函数来处理所有的中断响应，也就是说不能再cstartup.s修改中断入口的中断服务程序的名称，致使外部中断发生时，不经过系统层，而直接执行自定义的中断服务程序。

（2）OS对中断的封装（加壳）处理过程中，进行了必要的系统管理工作，比如OS系统嵌套标志OSIntNesting++，所以忽略这个必须的系统开销，必然会导致系统不稳定甚至崩溃。（3）这里的中断与进程间通信是采用全局标志实现的，也可以用信号量的方式更为稳定。2013-5-6一系统瘦身

编译“版本LPC17xx_FwLib_uCOS-II_20130425”的代码量如下：

根据编译数据显示：

1．蓝色标注为Flash占用量，由于LPC1768的rom为512k，所以本工程的31k代码量还可以接受。

2．红色标注为RAM代码量，为32k。因为LPC1768的RAM为（32k+32k）的方式，

如下图：其中IRAM1为默认设

置，用户常规代码区，IRAM2为

以太网描述符映射地址空间，一

般不能占用

由以上分析，很明显，目前的系统本身代码量过大，已经接近32k的边缘，无法继续开发其他应用。所以从以下几个方便，来缩减系统对ram的占用：

1．系统级：os_cfg.h

os_cfg.h文件，它是系统配置文件，系统初始化主要依靠这个文件来注册、管理各个功能模块的开关和使能，有如下几个方便，可以减少ram占用量：

#define OS_MAX_EVENTS 20u

#define OS_MAX_FLAGS 20u

#define OS_MAX_MEM_PART 5u

#define OS_MAX_QS 10u

#define OS_MAX_TASKS 10u

跟据实际情况来规划系统各个信号量的注册数量，可以减少RAM的占用。其中最大任务数量，可以明显减少系统ram的占用量，原始值20，这里把它改为10，足够用！

#define OS_APP_HOOKS_EN 0u /* 应用程序回调函数，可关掉，禁止回调*/ #define OS_ARG_CHK_EN 0u /* 应用参数检查功能，可关掉，禁止检查*/ 以上两点可以减少code占用，也可以提高用户任务的执行效率。

#define OS_TMR_EN 1u /*使能软件定时器，不建议关掉*/

#define OS_TMR_CFG_MAX 4u /*定时器的最大数量，默认值16，修改为4，

可以减少ram占用，并且不影响系统功能*/ 2．应用级app_cfg.h

（1）禁止os系统对标准库资源的内存分配及管理，如下图的红色标注，可大大节约RAM

（2）任务数量级任务堆栈，合理分配用户任务的数量和任务堆栈的大小

当前除了OS必要的三个任务外，启动了五个用户任务，任务堆栈定义如下：

其实5个用户任务其实已经足够，任务堆栈的大小，跟经验值应该设定在128和512之间。3．经过上述优化之后的RAM使用量如下：

可以明显看出，ram的使用量减少了21K，加入开设三个用户任务的话，ram的占用量可以控制在8K左右，这将是一个非常轻量级的系统框架。

4．另外，为了提高中断响应速度，也可以屏蔽掉csp.c中CSP_IntVectDeref的ts = CPU_TS_Get32() – ts，它是中断执行时间统计函数。

5．提示，为了构建一个健壮的系统架构，处了上述配置外，不要轻易尝试修改其他os和app配置，更不要修改core内核配置，否则会造成uc系统的不稳定甚至崩溃。

关于以太网，有两种常用的通信方式，即TCP、UDP，两种方式下MCU均作为服务器，而上位机则作为客户端，对m3进行控制和数据请求。

一、程序说明：

1、系统环境，用20130428的代码。

2、测试方式，上位机通过网口给M3发送一帧数据，M3收到后立即返回数据帧，要求响

应速度快，数据不丢帧。

3、测试软件，TCP&UDP测试工具。

4、协议栈，在网上下载的一些样例代码，综合各个版本的代码结构，最后的程序目录如下：

二、TCP服务器结构

1．emac中断服务，工作在物理层，当有数据到来，并且已经存储在数据缓冲区（emac描述符区），则释放发送中断标志信号量RecPackedFlag，

2．主任务App_TaskStart，等待中断标志信号量RecPackedFlag，执行数据链路层的数据接收任务。

3．Task_tcp，工作在IP层(网络层)，负责ip层的协议判断和数据解析任务。

4．Task_TcpServer，工作在TCP（运输层），属于高层协议，这里主要是处理上位机客户端的连接、断开、数据等请求。

注：由于老唐项目用UDP协议，所以TCP协议没有系统测试，并且速度有限，后续再优化！

一、UDP

现在测试过的版本有uCOSII_FwLib_UDP_BETTER1、2，uCOSII_FwLib_UDP_基本成型、uCOSII_FwLib_UDP_BEST1，其中uCOSII_FwLib_UDP_BEST1为定型版本，测试稳定，测试结果如下：

1.任务数量：3个系统任务，5个用户任务，共8个任务

2.任务功能：

（1）App_TaskStart：第一功能，负责初始化用户任务、初始化系统信号量；第二功能是服务于mac层，等待mac中断信号量EmacIntFlag，无效则挂起自身任务；如果有效则接受缓存区中的数据包，并把数据包传递到IP层，并发送RecUdpQFlag信号量，只是数据已经到达IP层（网际层）。

（2）Task_IPService：等待相邻底层(物理层)的数据有效信号，如果该信号无效则挂起，信号有效执行运输层处理函数Udp_Process，处理IP层提供的服务，当数据处理结束后，发送UdpSemRec信号量，指示IP层数据处理完成，并且数据有效；

简言之：网际IP层工作进程，向下层（物理层）交付服务，上层（运输层TCP/IP）提供服务。

（3）Task_UdpServer()，运输层（TCP/IP）服务进程，一方面想下层（运输层）交付服务，另一方面向上层（APP应用层）提供数据服务；

注：本任务的优先级比较高，主要是为实现优先处理客户端（上位机）请求，因此任务中的两个注释掉的OSTimeDly（1）只是测试以太网数据响应、数据吞吐量是所用，在真正的项目开发的时候完全可以使用，这样的话高优先级适当挂起，避免阻塞用户任务进程的有效执行，也可以大大提高系统的任务管理效率；

（4）AppTask1()和AppTask2()，用户级任务，当进行项目应用的扩展开发是，其他的功能如LED/LCD显示、键盘扫描、串口数据处理、ADC数据采集等任务可以放在这两个任务中实现；

目前功能：

1> AppTask1()每个20个系统延时（100ms）通过串口向上位机发送字符串"_______1___"。

2> AppTask2()，等待串口3中断标志信号量Uart3IntFlag，当串口3收到上位机数据的时候，在中断服务函数中发送信号OSSemPost(Uart3IntFlag)，任务中调用OSSemPend(Uart3IntFlag)等待信号，如果信号有效则向上位机发送发送字符串"_______2___"；

2013-5-14一以太网系统测试三

二、测试方法

1．上位机每个1ms想M3发送400字节的以太网数据包，M3接受到数据包后，立刻返回这400字节的UDP数据包，并显示；任务1、任务2同时执行；

（1）打开串口调试助手，系统启动后会不断显示_______1___，表示任务1在运行；

（2）通过助手向上位机发送几个字符数据，间隔5毫秒；然后串口助手中会显示_______2___，表示系统正常的响应了串口3中断，并且任务2也开始运行；

（3）打开上位机网络设置界面，设置如下：

注：M3作为服务器，地址为192.168.1.101，电脑作为客户端，地址设为是192.168.1.103，红圈位置应该为102、103等大于101的数；

（4）打开TCP/UDP调试软件

新建一个UDP客户端连接，设置如下：

注：（1）红圈位置是指定要连接的服务器IP地址，即为M3的IP地址，见主函数；

（2）蓝圈，发送间隔1ms

（3）发送数据包400Byte，建议数据包不要大于420，其实对于控制而言已经足够；

（4）绿圈，因为本软件开辟的接受缓存有限，未来更快的响应、测试网口速度，需要不断的点击“清空”按钮，否则数据速率会越来越慢；

（5）可以打开接受和发送的选项，增大缓冲区大小，来提高本软件的速度；

测试思想及目的：

1．实时性：4个任务同时运行；

2．中断响应：5ms一次串口中断、5毫秒一次系统定时器中断、1毫秒一次网口中断；3．网口响应速度、数据传输速率：每隔1ms发送400byte数据包，并立刻回传400byte数据包；

4．稳定性：连续测试

2013-5-16一以太网系统测试四

三、测试结果

1．代码量

2．以太网数据率

（1）响应时间1ms，其实可以更快，只是调试软件已经工作在极限，无法更快；

（2）数据包400字节；

（3）每秒钟发送240000字节、接收240000字节，简单计算一下，就是一秒内以太网传输了480000个字节，那么480000*8 = 3680000bit/S，即3.68bps的比特率。

3．连续测试时间2小时，数据无丢包现象，并且系统运行稳定；

4．四个任务、三个中断同时运行，互不干扰；

5．台式机的网口速度高于笔记本电脑，所以尽量采用台式机；

6．其实网口的速率可以更高，一方面不了解算法，另一方面上位机找不到更好的测试软件；测试版本：uCOSII_FwLib_UDP_BEST

2013-5-20一以太网系统测试五

一、框架代码中附有相信的注释，请认真阅读，下面对各个Group简要说明：

1．APP用户代码文件；

2．BSP板级支持包，负责定义、声明、管理

外部设备；建议具体的项目应用接口定义也

放在这个文件夹中。

3．CSP处理器支持包，负责管理时钟系统、

中断系统、AHB总线pwr开关等，实现ucos

软件最小系统的初始化代码；

4．CPU是CSP和APP的接口文件，为systick、

中断管理提供过度代码，看似多余，无需修

改；

5．LIB是系统库文件，用处不大，勿删勿改；

6．Ports，平台相关，是uC内核和所有上层

的接口文件，采用C语言嵌套汇编的方式，

实现systick定时器中断服务、任务切换、任

务查询、任务优先级table管理等最核心的代

码，无需修改；

7．Source系统内核文件，有Micrium维护，

任何时候都无需修改；

8．Ethernet，以太网协议栈，已经调试ok，

无需改动；

9．FwDrivers固件库，来自NXP官网

https://www.360docs.net/doc/b02882564.html,，较新版本，只需在fw.h中

引用，源码无需修改；

二、扩展应用开发说明

1．框架代码中已经把无需修改的文件设定为只读属性（加锁），目的是避免无意的错误改动，致使uCOS最小软件系统无法工作。但如果要使用SourceInsight查看源码，去除这些文件的只读属性即可。

2．两个用户任务已经足够，如果不够清参考AppTask1、2增加。

3．App_cfg.h中关于任务堆栈大小、任务优先级的定义，已经是优化，无需修改，也不建议修改；

4．Os_cfg中关于系统使用的app回调函数、cpu回调函数、任务个数、信号量个数及开关、时钟管理已经优化，遂不建议修改；

5．为了提高中断执行效率，在csp.c中屏蔽了CSP_IntVectDeref的ts = CPU_TS_Get32() – ts，它是中断执行时间统计函数。如果需要此功能，可以还原此段代码；

6．UdpServer_Process()、UserTask1_Process()、UserTask2_Process()分别是以太网服务响应处理函数、用户应用执行函数，目前都是空实现，见app_usr.c，为了保持代码的独立性、可移植性，建议用这三个函数进行扩展开发；

7．尽量使用OSTimeDly函数，避免使用前后台(裸跑、while（1）+中断)方式的软件延时习惯，因为它本质上是迫使CPU对时钟进行指令周期计数，将会阻塞其他函数执行，进而降低系统效率；

8．可能涉及三个潜在问题：（1）当代码量足够大的时候，需要在app_cfg.h中把用户任务堆栈增加到512。（2）注释掉sendto(*us, RecvBuff, RecvCnt, 0, (struct sockaddr *)&clientaddr, al);（3）可以把UdpServer_Process()中定义为一个带指针形参的函数，把接受缓冲区的数据传递到app_usr.c中执行、解析、处理；

9．建议：扩展开发的板级实现在BSP.C中开发，并新建对应的头文件，然后统一加入include.h中。

评估说明：扩展开发的可实现性，无论从任务个数、中断源个数、多中断源高频率嵌套响应、网口数据率等角度，目前的测试手段都应该可以满足多种项目应用的扩展开发功能！

特别解释：

关于：OS_TICKS_PER_SEC 200u，目前赋值200，及系统节拍定时器的频率为200Hz，亦及定时5ms。关于它要权衡取值，没有固定约束，处理复位中断，它中断优先级最高，所以OS_TICKS_PER_SEC大了会加快任务切换时间、提高系统调度效率，但是会增加系统负荷，相对多的占用了CPU资源；相反OS_TICKS_PER_SEC小了，会减少cpu资源占用，降低系统负荷，但是却降低了任务切换、调度的效率，降低了实时性。

对于uCOSII_FwLib_UDP_BEST，测试取值100、200、250都OK；

建议的取值范围：100~200，严格而言100或者200，这样系统稳定，且系统延时比较清楚，及10ms或5ms，方便后续扩展开发；

测控事业部 硬件组

2013-5-20