ucos代码量（ucos 信号量）[20240427更新]

本篇文章给大家谈谈ucos代码量，以及ucos 信号量对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、什么是UCOS操作系统？
• 2、有关uCOS中的汇编代码
• 3、ucos和linux区别，联系。学了ucos再学linux会不会有帮助。。。（嵌入式初学者）
• 4、UCOS临界代码请教 len = OS_StrCopy(pname, pevent->OSEventName);
• 5、ucos 怎样确定任务堆栈大小
• 6、想在STM32上移植UCOSII和UCGUI，需要多大的空间资源

什么是UCOS操作系统？

u C / O S 是一种免费公开源代码、结构小巧、具有可剥夺实时内核的实时操作系统。

μC/OS-II 的前身是μC/OS，最早出自于1992 年美国嵌入式系统专家Jean J.Labrosse 在《嵌入式系统编程》杂志的5 月和6 月刊上刊登的文章连载，并把μC/OS 的源码发布在该杂志的B B S 上。

μC/OS 和μC/OS-II 是专门为计算机的嵌入式应用设计的，绝大部分代码是用C语言编写的。CPU 硬件相关部分是用汇编语言编写的、总量约200行的汇编语言部分被压缩到最低限度，为的是便于移植到任何一种其它的CPU 上。用户只要有标准的ANSI 的C交叉编译器，有汇编器、连接器等软件工具，就可以将μC/OS-II嵌人到开发的产品中。μC/OS-II 具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点， 最小内核可编译至 2KB 。μC/OS-II 已经移植到了几乎所有知名的CPU 上。

严格地说uC/OS-II只是一个实时操作系统内核，它仅仅包含了任务调度，任务管理，时间管理，内存管理和任务间的通信和同步等基本功能。没有提供输入输出管理，文件系统，网络等额外的服务。但由于uC/OS-II良好的可扩展性和源码开放，这些非必须的功能完全可以由用户自己根据需要分别实现。

uC/OS-II目标是实现一个基于优先级调度的抢占式的实时内核，并在这个内核之上提供最基本的系统服务，如信号量，邮箱，消息队列，内存管理，中断管理等。

任务管理

uC/OS-II 中最多可以支持64 个任务，分别对应优先级0～63，其中0 为最高优先级。63为最低级，系统保留了4个最高优先级的任务和4个最低优先级的任务，所有用户可以使用的任务数有56个。

uC/OS-II提供了任务管理的各种函数调用，包括创建任务，删除任务，改变任务的优先级，任务挂起和恢复等。

系统初始化时会自动产生两个任务：一个是空闲任务，它的优先级最低，改任务仅给一个整形变量做累加运算；另一个是系统任务，它的优先级为次低，改任务负责统计当前cpu的利用率。

时间管理

uC/OS-II的时间管理是通过定时中断来实现的，该定时中断一般为10毫秒或100毫秒发生一次，时间频率取决于用户对硬件系统的定时器编程来实现。中断发生的时间间隔是固定不变的，该中断也成为一个时钟节拍。

uC/OS-II要求用户在定时中断的服务程序中，调用系统提供的与时钟节拍相关的系统函数，例如中断级的任务切换函数，系统时间函数。

内存管理

在ANSI C中是使用malloc和free两个函数来动态分配和释放内存。但在嵌入式实时系统中，多次这样的错作会导致内存碎片，且由于内存管理算法的原因，malloc和free的执行时间也是不确定。

uC/OS-II中把连续的大快内存按分区管理。每个分区中包含整数个大小相同的内存块，但不同分区之间的内存快大小可以不同。用户需要动态分配内存时，系统选择一个适当的分区，按块来分配内存。释放内存时将该块放回它以前所属的分区，这样能有效解决碎片问题，同时执行时间也是固定的。

任务间通信与同步

对一个多任务的操作系统来说，任务间的通信和同步是必不可少的。uC/OS-II中提供了4中同步对象，分别是信号量，邮箱，消息队列和事件。所有这些同步对象都有创建，等待，发送，查询的接口用于实现进程间的通信和同步。

任务调度

uC/OS-II 采用的是可剥夺型实时多任务内核。可剥夺型的实时内核在任何时候都运行就绪了的最高优先级的任务。

uC/os-II的任务调度是完全基于任务优先级的抢占式调度，也就是最高优先级的任务一旦处于就绪状态，则立即抢占正在运行的低优先级任务的处理器资源。为了简化系统设计，uC/OS-II规定所有任务的优先级不同，因为任务的优先级也同时唯一标志了该任务本身。

任务调度将在以下情况下发生：

1） 高优先级的任务因为需要某种临界资源，主动请求挂起，让出处理器，此时将调度就绪状态的低优先级任务获得执行，这种调度也称为任务级的上下文切换。

2） 高优先级的任务因为时钟节拍到来，在时钟中断的处理程序中，内核发现高优先级任务获得了执行条件(如休眠的时钟到时)，则在中断态直接切换到高优先级任务执行。这种调度也称为中断级的上下文切换。

这两种调度方式在uC/OS-II的执行过程中非常普遍，一般来说前者发生在系统服务中，后者发生在时钟中断的服务程序中。

调度工作的内容可以分为两部分：最高优先级任务的寻找和任务切换。其最高优先级任务的寻找是通过建立就绪任务表来实现的。u C / O S 中的每一个任务都有独立的堆栈空间，并有一个称为任务控制块TCB(Task Control Block)的数据结构，其中第一个成员变量就是保存的任务堆栈指针。任务调度模块首先用变量OSTCBHighRdy 记录当前最高级就绪任务的TCB 地址，然后调用OS_TASK_SW()函数来进行任务切换。

μC/OS-II的组成部分

μC/OS-II可以大致分成核心、任务处理、时间处理、任务同步与通信，CPU的移植等5个部分。

1) 核心部分(OSCore.c)

是操作系统的处理核心，包括操作系统初始化、操作系统运行、中断进出的前导、时钟节拍、任务调度、事件处理等多部分。能够维持系统基本工作的部分都在这里。

2) 任务处理部分(OSTask.c)

任务处理部分中的内容都是与任务的操作密切相关的。包括任务的建立、删除、挂起、恢复等等。因为μC/OS-II是以任务为基本单位调度的，所以这部分内容也相当重要。

3) 时钟部分(OSTime.c)

μC/OS-II中的最小时钟单位是timetick（时钟节拍）。任务延时等操作是在这里完成的。

4) 任务同步和通信部分

为事件处理部分，包括信号量、邮箱、邮箱队列、事件标志等部分；主要用于任务间的互相联系和对临界资源的访问。

5) 与CPU的接口部分

是指μC/OS-II针对所使用的CPU的移植部分。由于μC/OS-II是一个通用性的操作系统，所以对于关键问题上的实现，还是需要根据具体CPU的具体内容和要求作相应的移植。这部分内容由于牵涉到SP等系统指针，所以通常用汇编语言编写。主要包括中断级任务切换的底层实现、任务级任务切换的底层实现、时钟节拍的产生和处理、中断的相关处理部分等内容。

有关uCOS中的汇编代码

1.这个就不知道了，要你自己去调试，体会之间的区别。

2.PROC表示这是一段子程序，FAR属性表示，它可以被其他代码段中的其他程序用如下方式调用。

CALL FAR 子程序名称

内部操作为，程序下一条指令的段地址、偏移地址入栈（即CS，IP入栈），CS、IP指向子程序的第一条指令的位置。

此外，有的子程序属性为NEAR，表示它只能被同一代码段中的其他子程序调用，调用方式为

CALL NEAR 子程序名称

这里NEAR可省，内部操作为，CS不变，仅偏移地址入栈（IP入栈），IP指向子程序的第一条指令的位置。

3.根据以上的解释，这里的FAR是表示远调用，即被调用子程序跟调用子程序不字同一个代码段。

ucos和linux区别，联系。学了ucos再学linux会不会有帮助。。。（嵌入式初学者）

区别：ucos有执行效率高、占用空间小、实时性和可扩展性强等特点，linux有稳定性、强大网络功能和出色的文件系统等优点。

联系：是两种性能优良源码公开且被广泛应用的的免费嵌入式操作系统，可以作为研究实时操作系统和非实时操作系统的典范。

μC/OS II(Micro-Controller Operating System Two)是一个可以基于ROM运行的、可裁剪的、抢占式、实时多任务内核，具有高度可移植性，特别适合于微处理器和控制器，适合很多商业操作系统性能相当的实时操作系统(RTOS)。

μC/OS II可以简单的视为一个多任务调度器，在这个任务调度器之上完善并添加了和多任务操作系统相关的系统服务，如信号量、邮箱等。其主要特点有公开源代码，代码结构清晰、明了，注释详尽，组织有条理，可移植性好，可裁剪，可固化。

内核属于抢占式，最多可以管理60个任务。从1992年开始，由于高度可靠性、鲁棒性和安全性，μC/OS II已经广泛使用在从照相机到航空电子产品的各种应用中。

Linux是一套免费使用和自由传播的类Unix操作系统，是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的操作系统。它能运行主要的UNIX工具软件、应用程序和网络协议。它支持32位和64位硬件。Linux继承了Unix以网络为核心的设计思想，是一个性能稳定的多用户网络操作系统。

Linux操作系统诞生于1991 年10 月5 日（这是第一次正式向外公布时间）。Linux存在着许多不同的Linux版本，但它们都使用了Linux内核。Linux可安装在各种计算机硬件设备中，比如手机、平板电脑、路由器、视频游戏控制台、台式计算机、大型机和超级计算机。

UCOS临界代码请教 len = OS_StrCopy(pname, pevent->OSEventName);

源代码中OSEventNameGet()的注释：

pevent is a pointer to the event group. 'pevent' can point either to a semaphore, a mutex, a mailbox or a queue.

pevent指向的这些event是全局变量（某些情况下是共享资源），而使用全局变量是要对其进行保护的，这样函数才是可重入的。

否则可能会被 OSEventNameSet()函数 pevent-OSEventName = pname; 更改。

这是我的理解。你看的可真够细致的啊。

ucos 怎样确定任务堆栈大小

1、首先需要知道，μC/OS-II中创建任务的函数有两个: OSTaskCreate()和OSTaskCreateExt()

（1）OSTaskCreate() //创建普通任务

由于重点在下面的创建扩展任务函数，故本函数就不多说了！确实，要想实现检测目标任务栈实际使用情况的功能，是不能使用这个函数来创建目标任务的，必须使用OSTaskCreateExt() 。

（2）OSTaskCreateExt() //创建扩展任务

函数接口原型为：

#if OS_TASK_CREATE_EXT_EN 0

INT8U OSTaskCreateExt

(

void (*task)(void *pd), //建立扩展任务(任务代码指针

void *pdata, //传递参数指针

OS_STK *ptos, //分配任务堆栈栈顶指针

INT8U prio, //分配任务优先级

INT16U id, //(未来的)优先级标识(与优先级相同)

OS_STK *pbos, //分配任务堆栈栈底指针

INT32U stk_size, //指定堆栈的容量(检验用)

void *pext, //指向用户附加的数据域的指针

INT16U opt //建立任务设定选项

)

#endif

2、其次需要知道μC/OS-II中有这么个函数：OSTaskStkChk()

不错，检测任务堆栈实际使用情况正是用的这个函数，下面来本函数的接口原型：

INT8U OSTaskStkChk

(

INT8U prio,  //待测任务的优先级

OS_STK_DATA *pdata //指向一个类型为OS_STK_DATA的结构体

)

3、再次需要知道一个结构体：

#if OS_TASK_CREATE_EXT_EN 0

typedef struct

{

INT32U OSFree; //堆栈中未使用的字节数

INT32U OSUsed; //堆栈中已使用的字节数

} OS_STK_DATA;

#endif

参数: prio 为指定要获取堆栈信息的任务优先级，也可以指定参数OS_PRIO_SELF，获取调用任务本身的

信息。

pdata 指向一个类型为OS_STK_DATA的数据结构，其中包含如下信息：

INT32U OSFree; // 堆栈中未使用的字节数

INT32U OSUsed; // 堆栈中已使用的字节数

4、有了上述三个知识点后就可以啦，具体方法为：

（1）将函数的最后一个参数opt 设置为：OS_TASK_OPT_STK_CHK | OS_TASK_OPT_STK_CLR

（2）定义一个变量：OS_STK_DATA  StackBytes；

（3）调用函数OSTaskStkChk(TestTaskPRIO, StackBytes)

（4）StackBytes.OSFree的值即为被测任务堆栈未使用的字节数，

StackBytes.OSUsed的值即为被测任务堆栈已使用的字节数。

5、需要设置宏：OS_TASK_OPT_STK_CLR为1

6、最后一点建议：

（1）将被测任务经历最坏的堆栈使用状态，测出来的使用率才可靠

（2）堆栈使用率最好在%50~%80之间，太小浪费空间，太大不安全

（3）最好在工程中单独建立一个优先级较低延时较长的任务来测试其它任务的堆栈使用情况，不用时可以挂起该任务

有时候决定任务实际所需的堆栈空间大小是很有必要的。因为这样用户就可以避免为任务分配过多的堆栈空间，从而减少自己的应用程序代码所需的RAM(内存)数量。?C/OS-Ⅱ提供的OSTaskStkChk()函数可以为用户提供这种有价值的信息。

在图4.2中，笔者假定堆栈是从上往下递减的(即OS_STK_GROWTH被置为1)，但以下的讨论也同样适用于从下往上长的堆栈[F4.2(1)]。?C/OS-Ⅱ是通过查看堆栈本身的内容来决定堆栈的方向的。只有内核或是任务发出堆栈检验的命令时，堆栈检验才会被执行，它不会自动地去不断检验任务的堆栈使用情况。在堆栈检验时，?C/OS-Ⅱ要求在任务建立的时候堆栈中存储的必须是0值(即堆栈被清零)[F4.2(2)]。另外，?C/OS-Ⅱ还需要知道堆栈栈底(BOS)的位置和分配给任务的堆栈的大小[F4.2(2)]。在任务建立的时候，BOS的位置及堆栈的这两个值储存在任务的OS_TCB中。

为了使用?C/OS-Ⅱ的堆栈检验功能，用户必须要做以下几件事情：

l  在OS_CFG.H文件中设OS_TASK_CREATE_EXT为1。

l  用OSTaskCreateExt()建立任务，并给予任务比实际需要更多的内存空间。

l  在OSTaskCreateExt()中，将参数opt设置为OS_TASK_OPT_STK_CHK+OS_TASK_OPT_STK_

CLR。注意如果用户的程序启动代码清除了所有的RAM，并且从未删除过已建立了的任务，那么用户就不必设置选项OS_TASK_OPT_STK_CLR了。这样就会减少OSTaskCreateExt()的执行时间。

l  将用户想检验的任务的优先级作为OSTaskStkChk()的参数并调用之。

图 4.2          堆栈检验

OSTaskStkChk()顺着堆栈的栈底开始计算空闲的堆栈空间大小，具体实现方法是统计储存值为0的连续堆栈入口的数目，直到发现储存值不为0的堆栈入口[F4.2(5)]。注意堆栈入口的储存值在进行检验时使用的是堆栈的数据类型(参看OS_CPU.H中的OS_STK)。换句话说，如果堆栈的入口有32位宽，对0值的比较也是按32位完成的。所用的堆栈的空间大小是指从用户在OSTaskCreateExt()中定义的堆栈大小中减去了储存值为0的连续堆栈入口以后的大小。OSTaskStkChk()实际上把空闲堆栈的字节数和已用堆栈的字节数放置在0S_STK_DATA数据结构中(参看?COS_Ⅱ.H)。注意在某个给定的时间，被检验的任务的堆栈指针可能会指向最初的堆栈栈顶(TOS)与堆栈最深处之间的任何位置[F4.2(7)]。每次在调用OSTaskStkChk()的时候，用户也可能会因为任务还没触及堆栈的最深处而得到不同的堆栈的空闲空间数。

用户应该使自己的应用程序运行足够长的时间，并且经历最坏的堆栈使用情况，这样才能得到正确的数。一旦OSTaskStkChk()提供给用户最坏情况下堆栈的需求，用户就可以重新设置堆栈的最后容量了。为了适应系统以后的升级和扩展，用户应该多分配10％－100％的堆栈空间。在堆栈检验中，用户所得到的只是一个大致的堆栈使用情况，并不能说明堆栈使用的全部实际情况。

OSTaskStkChk()函数的代码如程序清单 L4.10所示。0S_STK_DATA(参看?COS_Ⅱ.H)数据结构用来保存有关任务堆栈的信息。笔者打算用一个数据结构来达到两个目的。第一，把OSTaskStkChk()当作是查询类型的函数，并且使所有的查询函数用同样的方法返回，即返回查询数据到某个数据结构中。第二，在数据结构中传递数据使得笔者可以在不改变OSTaskStkChk()的API(应用程序编程接口)的条件下为该数据结构增加其它域，从而扩展OSTaskStkChk()的功能。现在，0S_STK_DATA只包含两个域：OSFree和OSUsed。从代码中用户可看到，通过指定执行堆栈检验的任务的优先级可以调用OSTaskStkChk()。如果用户指定0S_PRIO_SELF[L4.10(1)]，那么就表明用户想知道当前任务的堆栈信息。当然，前提是任务已经存在[L4.10(2)]。要执行堆栈检验，用户必须已用OSTaskCreateExt()建立了任务并且已经传递了选项OS_TASK_OPT_CHK[L4.10(3)]。如果所有的条件都满足了，OSTaskStkChk()就会象前面描述的那样从堆栈栈底开始统计堆栈的空闲空间[L4.10(4)]。最后，储存在0S_STK_DATA中的信息就被确定下来了[L4.10(5)]。注意函数所确定的是堆栈的实际空闲字节数和已被占用的字节数，而不是堆栈的总字节数。当然，堆栈的实际大小(用字节表示)就是该两项之和。

程序清单 L 4.10   堆栈检验函数

INT8U OSTaskStkChk (INT8U prio, OS_STK_DATA *pdata)

{

OS_TCB  *ptcb;

OS_STK  *pchk;

INT32U   free;

INT32U   size;

pdata-OSFree = 0;

pdata-OSUsed = 0;

if (prio OS_LOWEST_PRIO prio != OS_PRIO_SELF) {

return (OS_PRIO_INVALID);

}

OS_ENTER_CRITICAL();

if (prio == OS_PRIO_SELF) {                                              (1)

prio = OSTCBCur-OSTCBPrio;

}

ptcb = OSTCBPrioTbl[prio];

if (ptcb == (OS_TCB *)0) {                                               (2)

OS_EXIT_CRITICAL();

return (OS_TASK_NOT_EXIST);

}

if ((ptcb-OSTCBOpt OS_TASK_OPT_STK_CHK) == 0) {                   (3)

OS_EXIT_CRITICAL();

return (OS_TASK_OPT_ERR);

}

free = 0;                                                                  (4)

size = ptcb-OSTCBStkSize;

pchk = ptcb-OSTCBStkBottom;

OS_EXIT_CRITICAL();

#if OS_STK_GROWTH == 1

while (*pchk++ == 0) {

free++;

}

#else

while (*pchk-- == 0) {

free++;

}

#endif

pdata-OSFree = free * sizeof(OS_STK);                                 (5)

pdata-OSUsed = (size - free) * sizeof(OS_STK);

return (OS_NO_ERR);

}

uCOS-III任务堆栈溢出检测及统计任务堆栈使用量的方法 

1. 在操作系统任务设计的时候，通常会遇到一个比较麻烦的问题，也就是任务 堆 栈大小设定的问题，为此我们我需要知道一些问题 ：

1.1. 任务堆栈一但溢出，意味着系统的崩溃，在有MMU或者MPU的系统中，对堆栈溢出的检测十分简单，因为这是MMU和MPU必备的功能之一。（uCOS-II/uCOS-III中均有针对没有MMU和MPU的处理器对堆栈溢出检测的策略）

1.2. 堆栈的大小取决于该任务的需求。设定堆栈大小时，你就需要考虑：所有可能被堆栈调用的函数及其函数的嵌套层数，相关局部变量的大小，中断服务程序所需要的空间。另外，堆栈还需存入CPU寄存器，如果处理器有浮点数单元FPU寄存器的话还需存入FPU寄存器。（PS：出于这点，所以在嵌入式系统中有个潜规则，避免写递归函数）

1.3. 虽然任务堆栈大小可以通过人工计算出来，但是要考虑的太多，而且不能十分精确的计算。比如逐级嵌套被调用的函数的参数使用，上下文切换时候的CPU寄存器空间的保存，中断时CPU寄存器空间的保存和中断处理函数的堆栈空间等等，未免太过麻烦。特别的，当任务中使用了printf()之类参数可变的函数，那么统计起来就更困难了。所以这种方式怎么看怎么不现实。囧  。

1.4. 建议在不是很精确的确定任务堆栈使用大小(stk_size)的情况下，还是采取stk_size乘以1.5或者2.0的做法，以保证任务的正常运行。

2. uCOS-III任务堆栈溢出检测原理

每个任务都有自己的TCB(Task Control Block 任务控制块)， TCB结构定义在uCOS-III源码(我使用的是V3.03.00版本)中的os.h中。 TCB中有个 StkLimitPtr成员。

假设在切换到任务S前，代码会检测将要被载入CPU堆栈指针的值是否超出该任务S的TCB中StkLimitPtr限制。因为软件不能在溢出时就迅速地做出反应，所以应该设置StkLimitPtr的值尽可能远离MyTaskStk[0]，保证有足够的溢出缓冲。如下图。软件检测不会像硬件检测那样有效，但也可以防止堆栈溢出。 当uC/OS-III从一个任务切换到另一个任务的时候，它会调用一个 hook函数OSTaskSwHook()，它允许用户扩展上下文切换时的功能。 所以，如果处理器没有硬件支持溢出检测功能，就可以在该hook函 数中添加代码软件模拟该能。

不过我个人的做法是，通常设置StkLimitPtr指向任务栈大小的90%处，然后获取任务堆栈使用量，如果栈使用率大于90%时就必须做出警告了！下面就来介绍任务栈使用量的获取。

图1

3. uCOS-III任务堆栈使用量统计的原理和方法

3.1 原理

原理其实很简单，就是统计连续为0的区域的大小就可以知道空闲栈free的大小，而任务在创建时任务栈总量TaskStkSize是确定的，那么使用了的栈大小used =  TaskStkSize  - free。见图2。

图2 

首先，当任务创建时其堆栈被清零。然后，通过一个低优先级任务，计算该任务整个堆栈中值为0的内存大小。如果发现都不为0，那么就需要扩展堆栈的大小。然后，调整堆栈为的相应大小。这是一种非常有效的方法。注意的是，程序需用运行很长的时间以让堆栈达到其需要的最大值。 

3.2 方法 

uC/OS-III提供了一个函数OSTaskStkChk()用于实现这个计算功能。那么就来看看具体怎么做吧。 

3.2.1 首先创建一个任务来运行任务堆栈统计工作，值得注意的是，这个任务的优先级建议设置为系统所有任务中最低的一个！

#define  SystemDatasBroadcast_PRIO            12 // 统计任务优先级最低，我这里是12，已经低于其他任务的优先级了#define  SystemDatasBroadcast_STK_SIZE       100 // 任务的堆栈大小，做统计一般够了，统计结果出来后不够再加..OS_TCB  SystemDatasBroadcast_TCB; // 定义统计任务的TCBCPU_STK SystemDatasBroadcast_STK [SystemDatasBroadcast_STK_SIZE];// 开辟数组作为任务栈给任务使用static  void  AppTaskCreate(void){  // .....

// 这是系统创建任务的函数，还有其他任务创建的代码，这里就不贴出了

// .....

OSTaskCreate( (OS_TCB     *)SystemDatasBroadcast_TCB,

(CPU_CHAR   *)"SystemDatasBroadcast",

(OS_TASK_PTR ) SystemDatasBroadcast,

(void       *) 0,

(OS_PRIO     ) SystemDatasBroadcast_PRIO,

(CPU_STK    *)SystemDatasBroadcast_STK[0],

(CPU_STK_SIZE) SystemDatasBroadcast_STK_SIZE/10,/*栈溢出临界值我设置在栈大小的90%处*/

(CPU_STK_SIZE) SystemDatasBroadcast_STK_SIZE,

(OS_MSG_QTY  ) 0,

(OS_TICK     ) 0,

(void       *) 0,

(OS_OPT      )(OS_OPT_TASK_STK_CHK | OS_OPT_TASK_STK_CLR),

(OS_ERR     *) err);

}

3.2.2 然后在任务函数SystemDatasBroadcast()中开始统计各个任务 (其他任务的代码就不贴了， 跟

SystemDatasBroadcast 创建代码的方法是一模一样的，大家根据自己的需求照葫芦画瓢即可 )的栈使用,代码如下：

void  SystemDatasBroadcast (void *p_arg){

OS_ERR err;

CPU_STK_SIZE free,used;

(void)p_arg;  while(DEF_TRUE)

{

OSTaskStkChk (SystemDatasBroadcast_TCB,free,used,err); printf("SystemDatasBroadcast  used/free:%d/%d  usage:%%%d\r\n",used,free,(used*100)/(used+free));

OSTaskStkChk (Core_Page_TCB,free,used,err); printf("Core_Page             used/free:%d/%d  usage:%%%d\r\n",used,free,(used*100)/(used+free));

OSTaskStkChk (GUIActive_TCB,free,used,err); printf("GUIActive             used/free:%d/%d  usage:%%%d\r\n",used,free,(used*100)/(used+free));

OSTaskStkChk (KeyCheck_Process_TCB,free,used,err); printf("KeyCheck              used/free:%d/%d  usage:%%%d\r\n",used,free,(used*100)/(used+free));

OSTaskStkChk (Light_Adjust_TCB,free,used,err); printf("Light_Adjust          used/free:%d/%d  usage:%%%d\r\n",used,free,(used*100)/(used+free));

OSTaskStkChk (Calibrate_Process_TCB,free,used,err); printf("Calibrate             used/free:%d/%d  usage:%%%d\r\n",used,free,(used*100)/(used+free));

OSTaskStkChk (Data_Process_TCB,free,used,err); printf("Data_Process          used/free:%d/%d  usage:%%%d\r\n",used,free,(used*100)/(used+free));

printf("\r\n\r\n\r\n");

OSTimeDlyHMSM(0,0,5,0,(OS_OPT)OS_OPT_TIME_DLY,(OS_ERR*)err);

}

}

3.2.3实验结果

上述代码的实验结果如下图所示，可以清楚的看到每个任务的堆栈的使用状况。

但是请遵循一个原则：必须让系统运行足够久，比如尽量让系统处于不同的运行状态下，然后观察任务堆栈使用的变化，找到堆栈的最高使用率，然后根据上文所说的原则按需重新分配新的任务堆栈大小。

想在STM32上移植UCOSII和UCGUI，需要多大的空间资源

这看你具体软件多少了，RAM128K肯定够了，UCOS看你需要多少功能和你的代码多少，UCGUI就比较省RAM了，ROM空间也是看代码量。 stm32f103及以上都能移植的。我就是在103上跑的。

如果程序正确并可以通过编译，那么运行结果将是LED_0亮2秒灭2秒的闪烁，LED_1亮5秒灭5秒的闪烁。

不过我觉得这个程序有问题，你的uCOS应该跑不起来，这段程序中，systick_init

在startup_task中初始化，将导致startup_task线程虽然在main中创建了但不能被切换到，因为uCOS的系统滴答时钟都还没有启动。所以应该把systick_init放在main中第一个调用，保证在uCOS启动之前，系统滴答时钟已正常启动。

关于ucos代码量和ucos 信号量的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。