让STM32F103学会-一心多用-：uCOS-II任务调度的奇妙世界

于 2025-07-11 17:16:59 发布
阅读量247 收藏 10
点赞数 4
CC 4.0 BY-SA版权
文章标签： stm32 前端 javascript
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/SlientICE/article/details/149279013

文章总结（帮你们节约时间）

  • uCOS-II是一个基于优先级的抢占式实时操作系统，任务调度采用最高优先级优先算法，确保高优先级任务能够及时响应
  • 任务创建通过OSTaskCreate()函数实现，需要指定任务函数、堆栈、优先级等关键参数，每个任务都有独立的堆栈空间和任务控制块
  • STM32F103作为Cortex-M3内核MCU，天然支持uCOS-II的PendSV异常和SysTick定时器机制，为实时系统提供了硬件基础
  • Keil5开发环境提供了完整的uCOS-II移植包，简化了系统集成和调试过程，让开发者能够快速上手实时系统开发

uCOS-II：嵌入式世界的"交通指挥官"

你有没有想过，在一个繁忙的十字路口，如果没有交通信号灯会发生什么？车辆会横冲直撞，行人无所适从，整个交通系统将陷入混乱。而在嵌入式系统的世界里，uCOS-II就像是那个智能的交通指挥官，它有条不紊地协调着各个任务的执行，确保每个任务都能在合适的时间得到CPU的关注。

uCOS-II（Micro Controller Operating System Version II）是由Jean Labrosse开发的一款源码公开的实时多任务操作系统内核。为什么说它是"micro"呢？这可不是因为它功能简陋，而是因为它专门为微控制器量身定制，就像是为小户型房子设计的多功能家具一样，麻雀虽小五脏俱全！

这个系统最大的特点就是采用了基于优先级的抢占式调度算法。什么叫抢占式？想象一下你正在排队买奶茶，突然来了一个VIP客户，店员会立即为VIP服务，而让你暂时等待。在uCOS-II中，高优先级的任务就是这样的VIP，它们可以随时"插队"，抢占CPU资源。

uCOS-II支持最多64个不同的优先级（0-63），其中0级是最高优先级，通常保留给系统使用。每个优先级只能分配给一个任务，这就像是每个VIP等级只能有一个持有者一样。这种设计保证了系统的确定性 - 你永远知道在任何给定时刻，哪个任务会被执行。

在STM32F103这样的ARM Cortex-M3架构上，uCOS-II展现出了极佳的适配性。Cortex-M3的异常处理机制、嵌套向量中断控制器（NVIC）、以及SysTick定时器等硬件特性，都为uCOS-II的运行提供了强有力的支撑。就像是为F1赛车配备了专业的赛道一样，硬件和软件的完美结合让整个系统的性能得到了最大化的发挥。

任务调度的艺术：谁说了算？

如果说uCOS-II是交通指挥官，那么任务调度就是它的核心技能。但是，这个调度器是如何决定下一个该执行哪个任务的呢？这里面的学问可大了！

uCOS-II的调度器基于一个简单而强大的原则：最高优先级优先。听起来很简单对吧？但是实现起来却需要考虑很多细节。调度器需要维护一个就绪任务表（Ready Table），这张表记录了所有处于就绪状态的任务。

// uCOS-II中的就绪任务表结构
INT8U  OSRdyTbl[OS_RDY_TBL_SIZE];  // 就绪任务表
INT8U  OSRdyGrp;                   // 就绪组

这个就绪任务表的设计非常巧妙，它使用了位图的方式来记录任务状态。OSRdyGrp记录了哪些优先级组有就绪的任务，而OSRdyTbl数组则记录了每个组内具体哪些任务是就绪的。这种设计的好处是什么呢？查找最高优先级就绪任务的时间复杂度是O(1)O(1)O(1)，也就是说无论系统中有多少个任务，找到下一个要执行的任务的时间都是固定的！

寻找最高优先级就绪任务的算法使用了一个查表的技巧：

// 查找最高优先级就绪任务
y = OSUnMapTbl[OSRdyGrp];           // 找到最高优先级组
x = OSUnMapTbl[OSRdyTbl[y]];        // 找到组内最高优先级任务
prio = (y << 3) + x;                // 计算优先级

这里的OSUnMapTbl是一个预先计算好的查找表，它能够快速找到一个字节中最高位的1在哪里。这种算法的精妙之处在于，它将一个可能需要循环查找的过程转换成了简单的查表操作。

但是调度器什么时候会被调用呢？这就涉及到调度的触发时机了。在uCOS-II中，调度器可能在以下几种情况下被调用：

  1. 时钟中断：SysTick定时器产生的周期性中断，这是系统的"心跳"
  2. 任务主动让出CPU：任务调用了OSTimeDly()、OSSemPend()等阻塞函数
  3. 中断服务程序结束时：当中断处理完成后，可能有更高优先级的任务被唤醒
  4. 任务被删除或挂起时：当前运行任务的状态发生改变

任务调度的过程实际上就是一个上下文切换（Context Switch）的过程。什么是上下文？简单来说，就是CPU在执行一个任务时的"现场"，包括各种寄存器的值、程序计数器、堆栈指针等等。当调度器决定切换任务时，它需要：

  1. 保存当前任务的上下文到该任务的堆栈中
  2. 从新任务的堆栈中恢复其上下文
  3. 跳转到新任务继续执行

在ARM Cortex-M3架构上，这个过程得到了硬件的支持。处理器提供了PendSV异常，专门用于执行上下文切换。PendSV的优先级可以设置为最低，这样可以确保所有其他中断都处理完毕后再进行任务切换，避免了复杂的嵌套问题。

任务创建的魔法：从无到有的过程

创建一个任务就像是招聘一个新员工 - 你需要为他分配办公位置（堆栈空间），给他一个工号（优先级），告诉他要做什么工作（任务函数），还要为他建立人事档案（任务控制块）。在uCOS-II中，这个"招聘"过程通过OSTaskCreate()函数来完成。

让我们看看这个函数的"面试要求"：

参数类型意义
taskvoid (*task)(void *pd)指向任务函数的指针，这是任务的"职责描述"
pdatavoid *传递给任务函数的参数，就像是给员工的"工作指导书"
ptosOS_STK *指向任务堆栈顶部的指针，这是任务的"办公室地址"
prioINT8U任务优先级，就是员工的"职级"
INT8U OSTaskCreate(void (*task)(void *pd),
                   void *pdata,
                   OS_STK *ptos,
                   INT8U prio)
{
    OS_STK    *psp;
    INT8U      err;
    
    // 检查优先级是否有效
    if (prio > OS_LOWEST_PRIO) {
        return (OS_PRIO_INVALID);
    }
    
    // 检查该优先级是否已被使用
    OS_ENTER_CRITICAL();
    if (OSTCBPrioTbl[prio] == (OS_TCB *)0) {
        // 优先级可用，继续创建任务
        OSTCBPrioTbl[prio] = (OS_TCB *)1;  // 先标记为已使用
        OS_EXIT_CRITICAL();
        
        // 初始化任务堆栈
        psp = OSTaskStkInit(task, pdata, ptos, 0);
        
        // 创建任务控制块
        err = OSTCBInit(prio, psp, (OS_STK *)0, 0, 0, (void *)0, 0);
        
        if (err == OS_NO_ERR) {
            // 任务创建成功，加入就绪队列
            OSRdyGrp |= OSMapTbl[prio >> 3];
            OSRdyTbl[prio >> 3] |= OSMapTbl[prio & 0x07];
            OSTaskCtr++;  // 任务计数器加1
        }
    } else {
        // 优先级已被使用
        OS_EXIT_CRITICAL();
        err = OS_PRIO_EXIST;
    }
    
    return (err);
}

这个函数看起来很简单，但是每一步都有它的深意。首先，系统会检查传入的优先级是否有效，这就像是HR检查应聘者的资格一样。然后，系统会查看这个优先级是否已经被其他任务占用了 - 毕竟在uCOS-II的世界里，每个优先级都是独一无二的VIP席位！

如果一切检查都通过了，系统就开始真正的"入职手续"。首先是初始化任务堆栈。这个步骤非常关键，因为堆栈不仅仅是存储临时数据的地方，更是任务上下文的载体。

OSTaskStkInit()函数会在堆栈中构造一个假的"中断现场"，就好像这个任务之前正在运行，然后被中断打断了一样。这样当调度器第一次切换到这个任务时，就可以使用统一的上下文恢复机制来启动任务。

OS_STK *OSTaskStkInit(void (*task)(void *pd),
                      void *pdata,
                      OS_STK *ptos,
                      INT16U opt)
{
    OS_STK *stk;
    
    stk = ptos;  // 从堆栈顶部开始
    
    // 构造初始的堆栈帧，模拟中断现场
    *(stk)    = (INT32U)0x01000000L;           // xPSR
    *(--stk)  = (INT32U)task;                  // PC - 任务入口地址
    *(--stk)  = (INT32U)0xFFFFFFFEL;           // LR
    *(--stk)  = (INT32U)0x12121212L;           // R12
    *(--stk)  = (INT32U)0x03030303L;           // R3
    *(--stk)  = (INT32U)0x02020202L;           // R2
    *(--stk)  = (INT32U)0x01010101L;           // R1
    *(--stk)  = (INT32U)pdata;                 // R0 - 任务参数
    
    // 剩余的寄存器R4-R11
    *(--stk)  = (INT32U)0x11111111L;           // R11
    *(--stk)  = (INT32U)0x10101010L;           // R10
    *(--stk)  = (INT32U)0x09090909L;           // R9
    *(--stk)  = (INT32U)0x08080808L;           // R8
    *(--stk)  = (INT32U)0x07070707L;           // R7
    *(--stk)  = (INT32U)0x06060606L;           // R6
    *(--stk)  = (INT32U)0x05050505L;           // R5
    *(--stk)  = (INT32U)0x04040404L;           // R4
    
    return (stk);
}

看到这些魔法数字了吗？0x01010101、0x02020202…这些不是随便填的，它们可以帮助调试。当你在调试器中看到这些特殊的值时，就知道这些寄存器还没有被任务真正使用过，这对于跟踪任务的执行状态非常有用。

接下来是创建任务控制块（TCB - Task Control Block）。如果说堆栈是任务的"工作台"，那么TCB就是任务的"身份证"。每个任务都有一个唯一的TCB，里面记录了任务的所有重要信息：

typedef struct os_tcb {
    OS_STK          *OSTCBStkPtr;      // 指向当前堆栈指针
    
    struct os_tcb   *OSTCBNext;       // 指向下一个TCB
    struct os_tcb   *OSTCBPrev;       // 指向前一个TCB
    
    OS_EVENT        *OSTCBEventPtr;   // 指向任务等待的事件
    
    INT16U          OSTCBDly;         // 延时计数
    INT8U           OSTCBStat;        // 任务状态
    INT8U           OSTCBPrio;        // 任务优先级
    
    INT8U           OSTCBX;           // 优先级位图X坐标
    INT8U           OSTCBY;           // 优先级位图Y坐标
    INT8U           OSTCBBitX;        // X坐标对应的位掩码
    INT8U           OSTCBBitY;        // Y坐标对应的位掩码
    
#if OS_TASK_DEL_EN > 0
    BOOLEAN         OSTCBDelReq;      // 删除请求标志
#endif

#if OS_TASK_NAME_SIZE > 1
    INT8U           OSTCBTaskName[OS_TASK_NAME_SIZE]; // 任务名称
#endif

#if OS_TASK_PROFILE_EN > 0
    INT32U          OSTCBCtxSwCtr;    // 上下文切换计数
    INT32U          OSTCBCyclesTot;   // 总周期数
    INT32U          OSTCBCyclesStart; // 开始时间戳
    OS_STK          *OSTCBStkBase;    // 堆栈基址
    INT32U          OSTCBStkUsed;     // 已使用堆栈大小
#endif
} OS_TCB;

这个数据结构设计得非常精巧。OSTCBX、OSTCBY、OSTCBBitX、OSTCBBitY这几个字段是优化的关键所在。它们预先计算并存储了任务优先级在位图中的位置信息，这样在进行任务调度时就不需要重复计算了。这种以空间换时间的策略在实时系统中非常重要，因为每一个CPU周期都很宝贵。

STM32F103：uCOS-II的理想舞台

为什么说STM32F103是运行uCOS-II的理想平台呢？这就得从ARM Cortex-M3的架构说起了。如果把uCOS-II比作一出精彩的话剧，那么STM32F103就是为这出戏量身定制的舞台，每一个硬件特性都为操作系统的运行提供了完美的支持。

首先，让我们来看看Cortex-M3的异常处理机制。在传统的ARM7/ARM9架构中，中断处理需要手动保存和恢复寄存器，这个过程既繁琐又容易出错。而Cortex-M3的硬件会自动保存R0-R3、R12、LR、PC和xPSR这8个寄存器，这种硬件级别的支持大大简化了操作系统的实现。

// Cortex-M3异常入口时硬件自动保存的寄存器
// 高地址 +--------+
//        |  xPSR  |
//        |   PC   |
//        |   LR   |
//        |   R12  |
//        |   R3   |
//        |   R2   |
//        |   R1   |
// 低地址 |   R0   | <- SP指向这里
//        +--------+

这种硬件自动保存的机制有什么好处呢？首先是速度快，硬件保存比软件保存效率更高；其次是一致性好，无论是哪种异常，保存的寄存器都是一样的，这为操作系统的设计提供了统一的接口。

SysTick定时器是另一个重要的硬件特性。这个定时器被设计为操作系统的"心脏"，它能够产生周期性的中断，为任务调度提供时间基准。SysTick的配置非常简单：

// SysTick定时器初始化
void SysTick_Init(void)
{
    SysTick->LOAD = SystemCoreClock / OS_TICKS_PER_SEC - 1;  // 设置重载值
    SysTick->VAL  = 0;                                       // 清空当前值
    SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk |            // 使用处理器时钟
                    SysTick_CTRL_TICKINT_Msk   |            // 开启中断
                    SysTick_CTRL_ENABLE_Msk;                // 启动定时器
}

在STM32F103上，系统时钟通常是72MHz，如果我们希望OS的时钟节拍是1000Hz（即每1ms产生一次中断），那么LOAD寄存器应该设置为72000-1。这个公式很简单：

LOAD=SystemCoreClockOS_TICKS_PER_SEC−1LOAD = \frac{SystemCoreClock}{OS\_TICKS\_PER\_SEC} - 1LOAD=OS_TICKS_PER_SECSystemCoreClock​−1

PendSV异常是Cortex-M3为操作系统专门设计的另一个特性。这个异常的特殊之处在于它的优先级可以设置为最低，并且可以通过软件触发。当系统需要进行任务切换时，只需要设置PendSV的挂起位，处理器就会在所有高优先级异常处理完毕后自动进入PendSV处理程序：

// 触发PendSV异常进行任务切换
#define OS_TASK_SW()  SCB->ICSR |= SCB_ICSR_PENDSVSET_Msk

这种设计的妙处在于，任务切换总是在最合适的时机进行，不会干扰其他重要的中断处理。想象一下，如果高优先级中断正在处理紧急事务，这时候进行任务切换岂不是很不合适？PendSV的设计就避免了这种情况。

STM32F103的内存架构也很适合运行uCOS-II。它采用了哈佛架构，指令和数据分别有独立的总线，这样可以同时进行指令取指和数据访问，提高了系统的效率。而且STM32F103的Flash和SRAM都是连续映射的，这为操作系统的内存管理提供了便利。

STM32F103内存映射：
0x08000000 - 0x0807FFFF  Flash存储器 (512KB)
0x20000000 - 0x2000FFFF  SRAM (64KB)
0x40000000 - 0x5FFFFFFF  外设区域
0xE0000000 - 0xE00FFFFF  Cortex-M3私有外设

在Flash中存储程序代码，在SRAM中分配任务堆栈和全局变量，这种简单清晰的内存布局让开发者可以很容易地规划内存使用。

Keil5环境搭建：工欲善其事必先利其器

选择一个好的开发环境就像选择一把趁手的工具，能够事半功倍。Keil5（现在叫MDK-ARM）对uCOS-II的支持可以说是天衣无缝，它不仅提供了完整的uCOS-II源码包，还集成了强大的调试功能，让你能够深入观察操作系统的运行状态。

首先，我们需要在Keil5中创建一个新的项目。选择STM32F103系列的芯片后，Keil5会弹出一个组件选择界面，这里你可以看到uCOS-II的选项：

CMSIS -> CORE
CMSIS -> RTOS (API) -> Keil RTX 或者 uCOS-II
Device -> Startup

选择uCOS-II后，Keil会自动添加相关的源文件到项目中。这些文件包括：

  • uCOS-II的核心源码（ucos_ii.c）
  • 移植层文件（os_cpu_c.c, os_cpu_a.s）
  • 配置文件（os_cfg.h, app_cfg.h）

但是，我更建议你手动添加uCOS-II的源码，这样你可以更好地理解系统的结构。下载官方的uCOS-II源码包后，你会看到这样的目录结构：

uCOS-II/
├── Source/
│   ├── ucos_ii.c          // 核心源码
│   └── ucos_ii.h          // 核心头文件
├── Ports/
│   └── ARM-Cortex-M3/
│       ├── Generic/
│       │   ├── os_cpu_c.c  // C语言移植文件
│       │   ├── os_cpu_a.s  // 汇编移植文件
│       │   └── os_cpu.h    // 移植相关定义
│       └── Keil/
└── Config/
    ├── os_cfg.h           // uCOS-II配置文件
    └── app_cfg.h          // 应用配置文件

将这些文件添加到Keil项目中后，还需要设置包含路径，让编译器能够找到头文件：

Project -> Options for Target -> C/C++ -> Include Paths:
./uCOS-II/Source
./uCOS-II/Ports/ARM-Cortex-M3/Generic
./uCOS-II/Config

配置文件是uCOS-II的"控制面板"，通过修改os_cfg.h中的宏定义，你可以定制操作系统的功能。比如：

// os_cfg.h 中的重要配置选项
#define OS_MAX_TASKS          10    // 最大任务数量
#define OS_TASK_IDLE_STK_SIZE 128   // 空闲任务堆栈大小
#define OS_TICKS_PER_SEC      1000  // 每秒时钟节拍数

// 可选功能开关
#define OS_SEM_EN             1     // 启用信号量
#define OS_MBOX_EN            1     // 启用消息邮箱
#define OS_Q_EN               1     // 启用消息队列
#define OS_MEM_EN             1     // 启用内存管理
#define OS_TASK_STAT_EN       1     // 启用统计任务

这些配置选项就像是积木块，你可以根据项目的需要来组合。如果你的项目不需要消息队列，就可以把OS_Q_EN设置为0，这样编译器就不会包含相关的代码，从而节省存储空间。

Keil5的调试功能对于学习uCOS-II来说简直是神器。它提供了专门的RTOS调试视图，可以实时显示所有任务的状态、堆栈使用情况、优先级等信息。在调试时，你可以：

  1. 任务窗口：查看所有任务的当前状态、优先级、堆栈指针等
  2. 事件窗口：观察信号量、邮箱、队列的状态
  3. 内存窗口：检查任务堆栈的使用情况
  4. 反汇编窗口：查看上下文切换的汇编代码

特别是任务窗口，它能够让你直观地看到整个系统的运行状态。想象一下，你可以像上帝视角一样俯瞰整个系统，看到每个任务在做什么，这种感觉是不是很棒？

深入任务控制块：任务的"身份证"

如果把uCOS-II比作一个大公司，那么任务控制块（TCB）就是每个员工的详细档案。这份档案记录了员工的所有重要信息：姓名、工号、职位、工作状态、工资水平（优先级）、办公室地址（堆栈位置）等等。操作系统正是通过这些"档案"来管理成千上万个任务的。

让我们再次深入观察TCB的结构，但这次我们从实际应用的角度来理解每个字段的作用：

typedef struct os_tcb {
    OS_STK    *OSTCBStkPtr;      // 这是任务的"当前位置"
    
    // 双向链表指针 - 任务的"人际关系"
    struct os_tcb *OSTCBNext;    
    struct os_tcb *OSTCBPrev;    
    
    // 等待事件指针 - 任务在"等什么"
    OS_EVENT  *OSTCBEventPtr;    
    
    // 延时计数 - 任务的"休假时间"
    INT16U    OSTCBDly;          
    
    // 任务状态 - 任务的"工作状态"
    INT8U     OSTCBStat;         
    
    // 任务优先级 - 任务的"职级"
    INT8U     OSTCBPrio;         
    
    // 位图坐标 - 快速查找的"索引"
    INT8U     OSTCBX, OSTCBY;    
    INT8U     OSTCBBitX, OSTCBBitY;  
} OS_TCB;

OSTCBStkPtr是TCB中最重要的字段之一，它指向任务当前的堆栈指针位置。为什么说"当前"呢？因为当任务正在运行时，实际的堆栈指针在CPU的SP寄存器中；只有当任务被挂起时，系统才会将SP的值保存到OSTCBStkPtr中。这就像是你离开办公室时要在登记表上标记你的去向一样。

任务状态（OSTCBStat）是一个非常有趣的字段，它使用位掩码的方式来表示任务的各种状态：

// 任务状态定义
#define OS_STAT_RDY         0x00    // 就绪状态
#define OS_STAT_SEM         0x01    // 等待信号量
#define OS_STAT_MBOX        0x02    // 等待消息邮箱
#define OS_STAT_Q           0x04    // 等待消息队列
#define OS_STAT_SUSPEND     0x08    // 挂起状态
#define OS_STAT_MUTEX       0x10    // 等待互斥信号量
#define OS_STAT_FLAG        0x20    // 等待事件标志组

// 组合状态示例
task_stat = OS_STAT_SUSPEND | OS_STAT_SEM;  // 既挂起又等待信号量

这种位掩码的设计非常巧妙，一个字节就能表示多种状态的组合。比如一个任务可能既处于挂起状态，又在等待某个信号量，通过位操作可以很容易地检查和设置这些状态。

双向链表指针（OSTCBNext和OSTCBPrev）用于将相同状态的任务串联起来。比如所有等待同一个信号量的任务会形成一个等待链表，这样当信号量可用时，系统就能快速找到所有等待的任务。这种设计就像是医院的排队系统，等待同一个医生的病人排成一队，医生空闲时就叫下一个病人。

位图坐标字段（OSTCBX、OSTCBY、OSTCBBitX、OSTCBBitY）是uCOS-II性能优化的精华所在。还记得我们之前提到的就绪任务表吗？为了快速查找最高优先级任务，系统需要在这个表中进行位操作。但是每次都计算位置会很慢，所以TCB中预先存储了这些位置信息：

// 优先级到位图坐标的转换
prio = 25;  // 假设任务优先级是25
y = prio >> 3;      // y = 25/8 = 3 (组号)
x = prio & 0x07;    // x = 25%8 = 1 (组内位置)

// 对应的位掩码
bit_y = OSMapTbl[y];    // OSMapTbl[3] = 0x08
bit_x = OSMapTbl[x];    // OSMapTbl[1] = 0x02

这样，当需要将任务设置为就绪状态时，只需要简单的位操作：

OSRdyGrp |= bit_y;           // 设置组就绪位
OSRdyTbl[y] |= bit_x;        // 设置任务就绪位

而将任务从就绪状态移除也同样简单：

OSRdyTbl[y] &= ~bit_x;       // 清除任务就绪位
if (OSRdyTbl[y] == 0) {      // 如果该组没有就绪任务了
    OSRdyGrp &= ~bit_y;      // 清除组就绪位
}

这种设计的时间复杂度是O(1)O(1)O(1)，无论系统中有多少个任务，操作时间都是固定的。这对于实时系统来说非常重要，因为任务切换的时间必须是可预测的。

TCB的分配和管理也有讲究。uCOS-II使用了一个TCB池：

OS_TCB    OSTCBTbl[OS_MAX_TASKS + OS_N_SYS_TASKS];  // TCB表
OS_TCB   *OSTCBList;                                 // 空闲TCB链表
OS_TCB   *OSTCBFreeList;                            // 已分配TCB链表

当创建新任务时，系统从空闲链表中取出一个TCB；当任务被删除时，TCB被归还到空闲链表中。这种预先分配的策略避免了动态内存分配的不确定性，保证了系统的实时性。

任务状态转换：生命的轮回

任务的生命就像是一出戏，有着不同的场景和状态转换。在uCOS-II中，每个任务都会在不同的状态之间流转，就像演员在不同的舞台上表演一样。理解这些状态转换对于掌握uCOS-II的精髓至关重要。

让我们从一个任务的"出生"开始讲起。当OSTaskCreate()被调用时，一个新的任务就诞生了，它立即进入就绪状态（Ready）。就绪状态意味着任务已经准备好运行了，只是在等待CPU的关注。这就像是演员已经化好妆、背好台词，站在后台等待上场的信号。

// 任务状态枚举
typedef enum {
    TASK_STATE_READY = 0,      // 就绪状态
    TASK_STATE_RUNNING,        // 运行状态  
    TASK_STATE_WAITING,        // 等待状态
    TASK_STATE_SUSPENDED,      // 挂起状态
    TASK_STATE_DORMANT         // 休眠状态
} task_state_t;

当调度器选中了这个任务时，它就从就绪状态转换到运行状态（Running）。在单核系统中，同一时刻只能有一个任务处于运行状态，这个任务就是系统的"主角"，拥有CPU的全部注意力。

但是，没有任务能够永远占据舞台。运行中的任务可能会因为各种原因离开运行状态：

  1. 主动让出：任务调用了OSTimeDly()、OSSemPend()等函数，主动进入等待状态
  2. 被抢占：更高优先级的任务变为就绪，当前任务被强制切换到就绪状态
  3. 时间片用完：如果启用了时间片轮转，任务用完时间片后回到就绪状态
  4. 被挂起：其他任务调用OSTaskSuspend()将当前任务挂起

让我们看一个具体的状态转换例子：

void LED_Task(void *pdata)
{
    while(1) {
        // 任务处于运行状态
        LED_Toggle();
        
        // 调用延时函数，任务主动进入等待状态
        OSTimeDly(1000);  // 等待1000个时钟节拍
        
        // 延时到期后，任务重新进入就绪状态
        // 当被调度器选中时，又进入运行状态
    }
}

等待状态（Waiting）是任务生命中的"休息时间"。处于等待状态的任务不会被调度器考虑，它们可能在等待：

  • 时间的流逝（OSTimeDly()）
  • 信号量的释放（OSSemPend()）
  • 消息的到达（OSMboxPend()）
  • 事件的发生（OSFlagPend()）

等待状态的任务会被放入相应的等待链表中。比如等待信号量的任务会被链接到信号量的等待链表上，当信号量可用时，系统会从这个链表中选择合适的任务唤醒。

挂起状态（Suspended）是一种特殊的状态，处于挂起状态的任务就像是被"冻结"了一样，无论发生什么事情都不会被唤醒，除非其他任务显式地恢复它。一个任务可以同时处于挂起状态和等待状态，这种组合状态意味着即使等待的事件发生了，任务也不会被唤醒，直到挂起状态被清除。

// 挂起任务
OSTaskSuspend(TASK_PRIO);

// 恢复任务  
OSTaskResume(TASK_PRIO);

状态转换不仅仅是概念上的，它们在代码中有着具体的实现。每次状态转换都涉及到就绪表的更新：

// 将任务从就绪状态移除
void OS_TASK_REMOVE_FROM_READY_LIST(INT8U prio)
{
    INT8U y, x;
    
    y = prio >> 3;
    x = prio & 0x07;
    
    OSRdyTbl[y] &= ~OSMapTbl[x];   // 清除任务就绪位
    if (OSRdyTbl[y] == 0) {        // 如果该组没有就绪任务
        OSRdyGrp &= ~OSMapTbl[y];  // 清除组就绪位
    }
}

// 将任务加入就绪状态
void OS_TASK_ADD_TO_READY_LIST(INT8U prio)
{
    INT8U y, x;
    
    y = prio >> 3;
    x = prio & 0x07;
    
    OSRdyGrp |= OSMapTbl[y];       // 设置组就绪位
    OSRdyTbl[y] |= OSMapTbl[x];    // 设置任务就绪位
}

理解任务状态转换对于调试和优化系统性能非常重要。当你发现某个任务响应很慢时，你需要分析它在各个状态上花费的时间：

  • 如果任务经常处于就绪状态但得不到执行机会，说明有太多高优先级任务在抢占CPU
  • 如果任务长时间处于等待状态，说明它等待的资源可能有问题
  • 如果任务频繁在就绪和运行状态之间切换，说明系统的任务切换开销可能很大

优先级管理：等级森严的嵌入式社会

在uCOS-II的世界里，优先级就是绝对的权力。就像古代的等级制度一样，高优先级的任务享有绝对的特权，可以随时打断低优先级任务的执行。这种看似"不公平"的制度实际上是实时系统的核心保证 - 重要的事情必须立即处理！

uCOS-II支持64个不同的优先级，编号从0到63，其中0是最高优先级。为什么是64个呢？这不是随便选的，而是有深刻的技术原因。64正好是262^626，这意味着可以用6个bit来表示所有的优先级，同时64个优先级可以完美地分组管理 - 8个组，每组8个优先级。

// 优先级的位图表示
#define OS_LOWEST_PRIO   63   // 最低优先级
#define OS_PRIO_SELF     0xFF // 表示当前任务自己

// 优先级映射表 - 快速查找的秘密武器
INT8U const OSMapTbl[] = {
    0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
};

// 反向映射表 - 找到最高位1的位置
INT8U const OSUnMapTbl[] = {
    0, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
    4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
    // ... 更多映射值
};

这个OSUnMapTbl表格是uCOS-II的一个巧妙设计。它能够快速找到一个字节中最高位的1在哪个位置。比如，对于数值0x48（二进制01001000），OSUnMapTbl[0x48]会返回6，表示最高位的1在第6位（从0开始计数）。

优先级分配是一门艺术，需要根据任务的重要性和时间要求来决定。一般来说：

超高优先级（0-7）：系统关键任务

  • 中断服务任务的后半部分
  • 安全关键功能
  • 硬实时任务

高优先级（8-15）：重要应用任务

  • 通信协议栈
  • 关键控制算法
  • 用户交互响应

中等优先级（16-31）：一般应用任务

  • 数据处理任务
  • 文件系统操作
  • 普通控制逻辑

低优先级（32-63）：后台任务

  • 统计和监控
  • 日志记录
  • 空闲时处理

但是，优先级分配也不是越高越好。如果高优先级任务运行时间过长，会导致低优先级任务"饿死"。这就像是如果老板总是开会，员工就永远得不到指导一样。因此，高优先级任务应该遵循"快进快出"的原则：

void HighPriorityTask(void *pdata)
{
    while(1) {
        // 等待紧急事件
        OSSemPend(EmergencySem, 0, &err);
        
        // 快速处理紧急事件
        HandleEmergency();  // 这个函数执行时间要短！
        
        // 处理完立即释放CPU给其他任务
        OSTimeDly(1);  // 给其他任务一个机会
    }
}

uCOS-II还提供了动态改变任务优先级的功能：

// 改变任务优先级
INT8U OSTaskChangePrio(INT8U oldprio, INT8U newprio)
{
    OS_TCB *ptcb;
    INT8U   x, y;
    
    // 检查新优先级是否有效
    if (newprio > OS_LOWEST_PRIO) {
        return OS_PRIO_INVALID;
    }
    
    // 检查新优先级是否已被占用
    if (OSTCBPrioTbl[newprio] != (OS_TCB *)0) {
        return OS_PRIO_EXIST;
    }
    
    // 找到要改变优先级的任务
    ptcb = OSTCBPrioTbl[oldprio];
    if (ptcb == (OS_TCB *)0) {
        return OS_PRIO_ERR;
    }
    
    // 更新优先级映射表
    OSTCBPrioTbl[newprio] = ptcb;
    OSTCBPrioTbl[oldprio] = (OS_TCB *)0;
    
    // 更新TCB中的优先级信息
    ptcb->OSTCBPrio = newprio;
    
    // 重新计算位图坐标
    y = newprio >> 3;
    x = newprio & 0x07;
    ptcb->OSTCBY = y;
    ptcb->OSTCBX = x;
    ptcb->OSTCBBitY = OSMapTbl[y];
    ptcb->OSTCBBitX = OSMapTbl[x];
    
    // 如果任务处于就绪状态，需要更新就绪表
    if (ptcb->OSTCBStat == OS_STAT_RDY) {
        // 从旧位置移除
        OSRdyTbl[oldprio >> 3] &= ~OSMapTbl[oldprio & 0x07];
        if (OSRdyTbl[oldprio >> 3] == 0) {
            OSRdyGrp &= ~OSMapTbl[oldprio >> 3];
        }
        
        // 添加到新位置
        OSRdyGrp |= OSMapTbl[y];
        OSRdyTbl[y] |= OSMapTbl[x];
    }
    
    return OS_NO_ERR;
}

优先级继承是解决优先级反转问题的重要机制。什么是优先级反转呢？想象这样一个场景：高优先级任务A需要等待低优先级任务C释放的资源，但是中等优先级任务B一直在运行，导致任务C得不到执行机会，间接地阻塞了高优先级任务A。这就是优先级反转，高优先级任务反而被低优先级任务阻塞了！

// 优先级反转的经典例子
任务A（高优先级）：等待互斥信号量
任务B（中等优先级）：一直在运行
任务C（低优先级）：持有互斥信号量，但被B抢占

结果：A等待C，但C被B阻塞，A间接被B阻塞

优先级继承的解决方案是：当高优先级任务等待低优先级任务释放资源时，临时将低优先级任务的优先级提升到高优先级任务的水平，这样它就能够抢占中等优先级任务，尽快释放资源。

堆栈管理：任务的私人空间

如果说优先级是任务的"身份地位"，那么堆栈就是任务的"私人办公室"。每个任务都有自己独立的堆栈空间，就像每个员工都有自己的工位一样。堆栈不仅存储任务的局部变量，更重要的是保存任务的上下文信息。

在ARM Cortex-M3架构中，堆栈是向下生长的，也就是说堆栈指针会随着数据的压入而递减。这种设计有其历史原因，但对于理解代码执行流程非常重要：

// 堆栈布局示例（向下生长）
// 高地址 +----------+
//        |  堆栈顶  |  <- 堆栈基址
//        |   ...    |
//        | 局部变量 |
//        | 函数参数 |
//        | 返回地址 |
//        | 寄存器   |
// 低地址 +----------+  <- 当前堆栈指针

在uCOS-II中，堆栈大小的计算是一个需要仔细考虑的问题。太小的堆栈会导致堆栈溢出，而太大的堆栈又会浪费宝贵的内存资源。怎么确定合适的堆栈大小呢？

// 堆栈大小的经验公式
Stack_Size = Context_Size + Local_Variables + Function_Call_Depth * Call_Frame_Size + Safety_Margin

其中：

  • Context_Size：上下文保存需要的空间（ARM Cortex-M3约为64字节）
  • Local_Variables：任务中局部变量占用的最大空间
  • Function_Call_Depth：最大函数调用深度
  • Call_Frame_Size：每次函数调用的栈帧大小
  • Safety_Margin：安全裕量（建议至少10%）

让我们看一个具体的例子：

// 定义任务堆栈
#define LED_TASK_STK_SIZE    128
OS_STK LED_TaskStk[LED_TASK_STK_SIZE];

// LED任务函数
void LED_Task(void *pdata)
{
    INT8U err;
    char buffer[64];  // 局部变量，占用64字节
    
    while(1) {
        // 调用多层函数
        ProcessLED();     // 可能调用其他函数
        
        // 等待信号量
        OSSemPend(LEDSem, 0, &err);
        
        sprintf(buffer, "LED Task running...");  // 使用局部变量
        
        OSTimeDly(100);
    }
}

对于这个任务，堆栈大小的计算可能是：

  • 上下文保存：64字节
  • 局部变量buffer：64字节
  • 函数调用深度：假设3层，每层16字节 = 48字节
  • 安全裕量：20%
  • 总计：(64 + 64 + 48) × 1.2 = 211字节

所以128字节的堆栈对于这个任务来说可能不够，建议设置为256字节。

uCOS-II提供了堆栈检查功能来帮助开发者发现堆栈问题：

// 启用堆栈检查
#define OS_TASK_STAT_STK_CHK_EN  1

// 检查任务堆栈使用情况
INT8U OSTaskStkChk(INT8U prio, OS_STK_DATA *pdata)
{
    OS_TCB *ptcb;
    OS_STK *pchk;
    INT32U  free;
    INT32U  size;
    
    // 找到任务控制块
    ptcb = OSTCBPrioTbl[prio];
    if (ptcb == (OS_TCB *)0) {
        return OS_PRIO_ERR;
    }
    
    // 检查堆栈使用情况
    pchk = ptcb->OSTCBStkBottom;
    size = ptcb->OSTCBStkSize;
    
    // 从堆栈底部开始检查
    free = 0;
    while ((*pchk++ == (OS_STK)0) && (free < size)) {
        free++;
    }
    
    pdata->OSFree = free * sizeof(OS_STK);  // 空闲字节数
    pdata->OSUsed = (size - free) * sizeof(OS_STK);  // 已使用字节数
    
    return OS_NO_ERR;
}

这个函数的原理是在任务创建时将堆栈初始化为0，然后通过检查从堆栈底部开始有多少个0来判断堆栈的使用情况。这种方法虽然不是100%准确（因为任务可能会将某些位置重新设置为0），但在大多数情况下是有效的。

堆栈溢出是嵌入式系统中最常见也是最危险的问题之一。当任务的堆栈空间不够时，数据会被写入到其他内存区域，可能破坏其他任务的堆栈或全局变量，导致系统崩溃。

// 堆栈溢出检测的常用方法
#define STACK_CANARY  0xDEADBEEF

// 在堆栈底部放置"金丝雀"值
void SetupStackCanary(OS_STK *stack_bottom)
{
    *stack_bottom = STACK_CANARY;
}

// 定期检查"金丝雀"值是否被修改
BOOLEAN CheckStackOverflow(OS_STK *stack_bottom)
{
    return (*stack_bottom != STACK_CANARY);
}

这种"金丝雀"（Canary）检测方法借鉴了矿工用金丝雀检测有毒气体的概念。如果堆栈溢出，就会修改金丝雀值，系统就能检测到问题。

时间片轮转：公平与效率的平衡

虽然uCOS-II主要采用基于优先级的调度算法，但它也支持时间片轮转（Round-Robin）调度来处理相同优先级的任务。这就像是在同一个会议室里，如果有多个同级别的经理需要汇报工作，那么每个人都应该有相等的发言时间。

时间片轮转的核心思想是：相同优先级的任务按照时间片轮流使用CPU，每个任务运行一个时间片后就切换到下一个任务。这种机制保证了公平性，避免了某个任务长时间占用CPU而导致其他同级任务"饿死"。

// 时间片轮转相关的全局变量
#if OS_TIME_SLICE_EN > 0
INT8U OSTimeSliceState;    // 时间片状态
INT8U OSTimeSliceCtr;      // 时间片计数器
#endif

// 时间片轮转的实现
void OSTimeTick(void)
{
    OS_TCB *ptcb;
    
    // 增加系统时钟节拍
    OSTime++;
    
    // 处理延时任务
    // ...
    
#if OS_TIME_SLICE_EN > 0
    // 时间片处理
    if (OSTimeSliceState == OS_TRUE) {
        if (OSTimeSliceCtr > 0) {
            OSTimeSliceCtr--;
        }
        
        // 时间片用完，检查是否需要切换任务
        if (OSTimeSliceCtr == 0) {
            OSTimeSliceState = OS_FALSE;
            
            // 找到下一个相同优先级的任务
            ptcb = OSTCBCur;
            if (ptcb->OSTCBNext != ptcb) {  // 有其他相同优先级任务
                // 将当前任务移到队列末尾
                OSTCBCur = ptcb->OSTCBNext;
                
                // 重新设置时间片
                OSTimeSliceCtr = OS_TIME_SLICE;
                OSTimeSliceState = OS_TRUE;
                
                // 触发任务切换
                OS_TASK_SW();
            }
        }
    }
#endif
}

时间片的长度是一个需要仔细调整的参数。太短的时间片会导致频繁的任务切换，系统开销增大；太长的时间片又会影响响应性。一般来说，时间片长度应该是任务平均执行时间的数倍：

TimeSlice=k×AverageTaskTimeTimeSlice = k \times AverageTaskTimeTimeSlice=k×AverageTaskTime

其中k通常取值在2-10之间，具体数值需要根据系统的实际情况来调整。

让我们看一个时间片轮转的实际应用例子：

// 三个相同优先级的数据处理任务
void DataProcess1(void *pdata)
{
    while(1) {
        // 处理数据类型1
        ProcessDataType1();
        
        // 主动让出CPU，避免长时间占用
        OSTimeDly(1);
    }
}

void DataProcess2(void *pdata)
{
    while(1) {
        // 处理数据类型2
        ProcessDataType2();
        OSTimeDly(1);
    }
}

void DataProcess3(void *pdata)
{
    while(1) {
        // 处理数据类型3
        ProcessDataType3();
        OSTimeDly(1);
    }
}

// 在主函数中创建这三个任务，使用相同优先级
void main(void)
{
    OSInit();
    
    // 创建三个相同优先级的任务
    OSTaskCreate(DataProcess1, (void *)0, &Task1Stk[TASK_STK_SIZE-1], 10);
    OSTaskCreate(DataProcess2, (void *)0, &Task2Stk[TASK_STK_SIZE-1], 10);
    OSTaskCreate(DataProcess3, (void *)0, &Task3Stk[TASK_STK_SIZE-1], 10);
    
    // 启用时间片轮转
    OSTimeSliceInit(OS_TIME_SLICE);
    
    OSStart();
}

时间片轮转特别适合于处理批处理类型的任务，比如数据处理、文件操作、网络传输等。这些任务通常没有严格的实时要求，但需要公平地分享CPU资源。

任务间通信：建立沟通桥梁

在一个复杂的嵌入式系统中，任务之间需要协作完成复杂的功能。就像一个交响乐团，每个乐手都有自己的任务，但只有协调一致才能演奏出美妙的乐章。uCOS-II提供了多种任务间通信机制，包括信号量、消息邮箱、消息队列和事件标志组。

**信号量（Semaphore）**是最基本的同步机制，它就像是一个计数器，用来控制对共享资源的访问。想象一个停车场，信号量就是停车位的数量指示器：

// 创建信号量
OS_EVENT *ParkingSem;

void CreateParkingSemaphore(void)
{
    // 创建一个有10个停车位的信号量
    ParkingSem = OSSemCreate(10);
}

// 获取停车位（P操作）
void ParkCar(void)
{
    INT8U err;
    
    // 等待停车位可用
    OSSemPend(ParkingSem, 0, &err);  // 0表示无限等待
    
    if (err == OS_NO_ERR) {
        // 成功获得停车位，可以停车了
        printf("Car parked successfully!\n");
        
        // 模拟停车时间
        OSTimeDly(100);
        
        // 离开停车场，释放停车位
        OSSemPost(ParkingSem);
        printf("Car left the parking lot.\n");
    }
}

信号量的实现原理很简单，但效果强大：

函数参数类型意义
OSSemCreateINT16U cnt创建信号量，cnt是初始计数值
OSSemPendOS_EVENT *pevent, INT16U timeout, INT8U *err等待信号量，timeout是超时时间
OSSemPostOS_EVENT *pevent释放信号量，计数值加1
OSSemDelOS_EVENT *pevent, INT8U opt, INT8U *err删除信号量

**消息邮箱（Message Mailbox）**就像是任务间的邮政系统，一个任务可以给另一个任务发送一条消息：

// 创建消息邮箱
OS_EVENT *CommandMbox;

void CreateCommandMailbox(void)
{
    CommandMbox = OSMboxCreate((void *)0);  // 创建空邮箱
}

// 发送者任务
void CommandSender(void *pdata)
{
    char *command;
    
    while(1) {
        // 等待用户输入
        command = GetUserCommand();
        
        // 发送命令到邮箱
        OSMboxPost(CommandMbox, (void *)command);
        
        OSTimeDly(100);
    }
}

// 接收者任务
void CommandProcessor(void *pdata)
{
    char *command;
    INT8U err;
    
    while(1) {
        // 等待命令到达
        command = (char *)OSMboxPend(CommandMbox, 0, &err);
        
        if (err == OS_NO_ERR) {
            // 处理收到的命令
            ProcessCommand(command);
        }
    }
}

消息邮箱的特点是只能存储一条消息，如果邮箱已满，新的消息会覆盖旧的消息。这种机制适合于状态更新类的通信，比如传感器数据、系统状态等。

**消息队列（Message Queue）**是邮箱的扩展版本，它可以存储多条消息，就像是一个消息缓冲区：

// 创建消息队列
#define QUEUE_SIZE 10
OS_EVENT *DataQueue;
void *QueueStorage[QUEUE_SIZE];

void CreateDataQueue(void)
{
    DataQueue = OSQCreate(&QueueStorage[0], QUEUE_SIZE);
}

// 数据生产者
void DataProducer(void *pdata)
{
    SensorData *data;
    
    while(1) {
        // 读取传感器数据
        data = ReadSensorData();
        
        // 发送数据到队列
        if (OSQPost(DataQueue, (void *)data) != OS_NO_ERR) {
            // 队列满了，数据丢失
            printf("Queue full, data lost!\n");
        }
        
        OSTimeDly(10);  // 100Hz采样率
    }
}

// 数据消费者
void DataConsumer(void *pdata)
{
    SensorData *data;
    INT8U err;
    
    while(1) {
        // 从队列中获取数据
        data = (SensorData *)OSQPend(DataQueue, 0, &err);
        
        if (err == OS_NO_ERR) {
            // 处理数据
            ProcessSensorData(data);
        }
    }
}

消息队列特别适合于生产者-消费者模式，可以有效地解耦数据生产和消费的速度差异。

**事件标志组（Event Flag Group）**是一种更灵活的同步机制，它允许任务等待多个事件的组合：

// 创建事件标志组
OS_FLAG_GRP *SystemFlags;

#define FLAG_SENSOR_READY    0x01
#define FLAG_COMM_READY      0x02  
#define FLAG_STORAGE_READY   0x04
#define FLAG_ALL_READY       (FLAG_SENSOR_READY | FLAG_COMM_READY | FLAG_STORAGE_READY)

void CreateSystemFlags(void)
{
    SystemFlags = OSFlagCreate(0, &err);  // 初始值为0
}

// 系统初始化任务
void SystemInit(void *pdata)
{
    // 初始化传感器
    InitSensor();
    OSFlagPost(SystemFlags, FLAG_SENSOR_READY, OS_FLAG_SET, &err);
    
    // 初始化通信
    InitComm();
    OSFlagPost(SystemFlags, FLAG_COMM_READY, OS_FLAG_SET, &err);
    
    // 初始化存储
    InitStorage();  
    OSFlagPost(SystemFlags, FLAG_STORAGE_READY, OS_FLAG_SET, &err);
}

// 主应用任务
void MainApp(void *pdata)
{
    INT8U err;
    
    // 等待所有子系统就绪
    OSFlagPend(SystemFlags, FLAG_ALL_READY, OS_FLAG_WAIT_SET_ALL, 0, &err);
    
    if (err == OS_NO_ERR) {
        // 所有子系统都就绪了，开始主要功能
        printf("System fully initialized, starting main application...\n");
        
        while(1) {
            // 主应用逻辑
            RunMainApplication();
            OSTimeDly(100);
        }
    }
}

事件标志组的强大之处在于它支持复杂的等待条件：

  • 等待任意一个事件发生（OR操作）
  • 等待所有事件都发生（AND操作）
  • 等待事件被设置或清除

这些通信机制可以组合使用，构建复杂的系统架构。选择哪种机制取决于具体的应用需求：

  • 简单的资源保护：使用信号量
  • 状态通知：使用消息邮箱
  • 数据传输：使用消息队列
  • 复杂的同步条件：使用事件标志组

实战演练：点亮LED的华丽变身

理论说得再多，不如动手实践一个项目。让我们从最简单的LED控制开始，逐步构建一个完整的uCOS-II应用。这个项目将展示如何在STM32F103上使用Keil5开发环境创建和管理多个任务。

首先，我们需要创建一个基本的项目框架：

// main.c - 主程序文件
#include "includes.h"

// 任务优先级定义
#define LED_TASK_PRIO        10
#define KEY_TASK_PRIO        11
#define DISPLAY_TASK_PRIO    12

// 任务堆栈大小
#define TASK_STK_SIZE        128

// 任务堆栈定义
OS_STK LED_TaskStk[TASK_STK_SIZE];
OS_STK KEY_TaskStk[TASK_STK_SIZE];
OS_STK DISPLAY_TaskStk[TASK_STK_SIZE];

// 全局变量
OS_EVENT *LEDSem;        // LED控制信号量
OS_EVENT *KeyMbox;       // 按键消息邮箱
OS_FLAG_GRP *SystemFlags; // 系统状态标志组

int main(void)
{
    OSInit();                    // 初始化uCOS-II
    
    SystemInit();               // 系统硬件初始化
    CreateSyncObjects();        // 创建同步对象
    CreateTasks();              // 创建任务
    
    OSStart();                  // 启动多任务系统
    
    return 0;  // 永远不会执行到这里
}

接下来是硬件初始化部分：

// system.c - 系统初始化
void SystemInit(void)
{
    // 时钟初始化
    RCC_DeInit();
    RCC_HSEConfig(RCC_HSE_ON);
    while(RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET);
    
    // 配置系统时钟为72MHz
    RCC_PLLConfig(RCC_PLLSource_HSE_Div1, RCC_PLLMul_9);
    RCC_PLLCmd(ENABLE);
    while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET);
    
    RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);
    
    // GPIO初始化
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB, ENABLE);
    
    // LED引脚配置（假设使用PA0-PA3）
    GPIO_InitTypeDef GPIO_InitStructure;
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(GPIOA, &GPIO_InitStructure);
    
    // 按键引脚配置（假设使用PB0-PB3）
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPU;  // 上拉输入
    GPIO_Init(GPIOB, &GPIO_InitStructure);
    
    // SysTick定时器初始化
    SysTick_Config(SystemCoreClock / OS_TICKS_PER_SEC);
}

创建同步对象和任务：

// 创建同步对象
void CreateSyncObjects(void)
{
    INT8U err;
    
    // 创建LED控制信号量
    LEDSem = OSSemCreate(1);
    
    // 创建按键消息邮箱
    KeyMbox = OSMboxCreate((void *)0);
    
    // 创建系统状态标志组
    SystemFlags = OSFlagCreate(0, &err);
}

// 创建任务
void CreateTasks(void)
{
    // 创建LED任务
    OSTaskCreate(LED_Task, 
                 (void *)0, 
                 &LED_TaskStk[TASK_STK_SIZE-1], 
                 LED_TASK_PRIO);
    
    // 创建按键任务
    OSTaskCreate(KEY_Task, 
                 (void *)0, 
                 &KEY_TaskStk[TASK_STK_SIZE-1], 
                 KEY_TASK_PRIO);
    
    // 创建显示任务
    OSTaskCreate(DISPLAY_Task, 
                 (void *)0, 
                 &DISPLAY_TaskStk[TASK_STK_SIZE-1], 
                 DISPLAY_TASK_PRIO);
}

现在让我们实现各个任务的功能。LED任务负责根据接收到的命令控制LED：

// LED任务 - 负责LED控制
void LED_Task(void *pdata)
{
    INT8U err;
    INT8U *command;
    static INT8U led_pattern = 0;
    
    while(1) {
        // 等待LED控制信号量
        OSSemPend(LEDSem, 0, &err);
        
        if (err == OS_NO_ERR) {
            // 检查是否有新的控制命令
            command = (INT8U *)OSMboxAccept(KeyMbox);
            
            if (command != (void *)0) {
                // 根据命令更新LED模式
                switch(*command) {
                    case 1:  // 流水灯模式
                        led_pattern = 1;
                        break;
                    case 2:  // 闪烁模式
                        led_pattern = 2;
                        break;
                    case 3:  // 呼吸灯模式
                        led_pattern = 3;
                        break;
                    default:
                        led_pattern = 0;  // 关闭
                        break;
                }
            }
            
            // 执行LED控制
            ExecuteLEDPattern(led_pattern);
        }
        
        OSTimeDly(50);  // 50ms更新一次
    }
}

// LED模式执行函数
void ExecuteLEDPattern(INT8U pattern)
{
    static INT8U step = 0;
    
    switch(pattern) {
        case 1:  // 流水灯
            GPIO_Write(GPIOA, (1 << (step % 4)));
            step++;
            break;
            
        case 2:  // 闪烁
            if (step % 2 == 0) {
                GPIO_Write(GPIOA, 0x0F);  // 全亮
            } else {
                GPIO_Write(GPIOA, 0x00);  // 全灭
            }
            step++;
            break;
            
        case 3:  // 呼吸灯（简化版）
            // 这里需要PWM控制，简化为渐变效果
            BreathingLight(step);
            step++;
            break;
            
        default:
            GPIO_Write(GPIOA, 0x00);  // 关闭所有LED
            break;
    }
}

按键任务负责检测按键状态并发送控制命令：

// 按键任务 - 负责按键检测和命令发送
void KEY_Task(void *pdata)
{
    INT8U key_value;
    INT8U last_key = 0;
    static INT8U command = 0;
    
    while(1) {
        // 读取按键状态
        key_value = ReadKeys();
        
        // 检测按键按下（边沿检测）
        if (key_value != last_key && key_value != 0) {
            // 有按键按下，确定命令
            switch(key_value) {
                case 0x01:  // 按键1
                    command = 1;
                    break;
                case 0x02:  // 按键2
                    command = 2;
                    break;
                case 0x04:  // 按键3
                    command = 3;
                    break;
                case 0x08:  // 按键4
                    command = 0;
                    break;
            }
            
            // 发送命令到邮箱
            OSMboxPost(KeyMbox, (void *)&command);
            
            // 释放LED控制信号量，通知LED任务
            OSSemPost(LEDSem);
            
            // 设置按键事件标志
            OSFlagPost(SystemFlags, FLAG_KEY_PRESSED, OS_FLAG_SET, &err);
        }
        
        last_key = key_value;
        OSTimeDly(20);  // 按键扫描间隔20ms
    }
}

// 读取按键状态
INT8U ReadKeys(void)
{
    INT8U key_state = 0;
    
    // 读取4个按键状态（低电平有效）
    if (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_0) == Bit_RESET) {
        key_state |= 0x01;
    }
    if (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_1) == Bit_RESET) {
        key_state |= 0x02;
    }
    if (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_2) == Bit_RESET) {
        key_state |= 0x04;
    }
    if (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_3) == Bit_RESET) {
        key_state |= 0x08;
    }
    
    return key_state;
}

显示任务负责系统状态的显示和监控：

// 显示任务 - 负责状态显示和系统监控
void DISPLAY_Task(void *pdata)
{
    INT8U err;
    OS_STK_DATA stk_data;
    char display_buffer[64];
    
    while(1) {
        // 等待按键事件
        OSFlagPend(SystemFlags, FLAG_KEY_PRESSED, 
                   OS_FLAG_WAIT_SET_ANY | OS_FLAG_CONSUME, 1000, &err);
        
        if (err == OS_NO_ERR) {
            // 有按键事件，更新显示
            sprintf(display_buffer, "Key pressed, LED mode changed\n");
            
            // 这里可以通过串口或LCD显示
            printf(display_buffer);
        }
        
        // 定期显示系统状态
        static INT8U counter = 0;
        if (++counter >= 100) {  // 每5秒显示一次
            counter = 0;
            
            // 显示任务堆栈使用情况
            OSTaskStkChk(LED_TASK_PRIO, &stk_data);
            printf("LED Task Stack: Used=%d, Free=%d\n", 
                   stk_data.OSUsed, stk_data.OSFree);
            
            OSTaskStkChk(KEY_TASK_PRIO, &stk_data);
            printf("Key Task Stack: Used=%d, Free=%d\n", 
                   stk_data.OSUsed, stk_data.OSFree);
            
            // 显示系统运行时间
            printf("System running time: %d seconds\n", OSTimeGet()/OS_TICKS_PER_SEC);
        }
        
        OSTimeDly(50);
    }
}

为了支持printf输出，我们需要重定向标准输出到串口：

// 重定向printf到串口
int fputc(int ch, FILE *f)
{
    // 等待串口发送完成
    while(!(USART1->SR & USART_FLAG_TXE));
    USART1->DR = (u8) ch;
    
    return ch;
}

// 串口初始化
void USART_Init(void)
{
    GPIO_InitTypeDef GPIO_InitStructure;
    USART_InitTypeDef USART_InitStructure;
    
    // 时钟使能
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1 | RCC_APB2Periph_GPIOA, ENABLE);
    
    // GPIO配置
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;  // TX
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(GPIOA, &GPIO_InitStructure);
    
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10; // RX
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
    GPIO_Init(GPIOA, &GPIO_InitStructure);
    
    // USART配置
    USART_InitStructure.USART_BaudRate = 115200;
    USART_InitStructure.USART_WordLength = USART_WordLength_8b;
    USART_InitStructure.USART_StopBits = USART_StopBits_1;
    USART_InitStructure.USART_Parity = USART_Parity_No;
    USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
    USART_InitStructure.USART_Mode = USART_Mode_Tx | USART_Mode_Rx;
    
    USART_Init(USART1, &USART_InitStructure);
    USART_Cmd(USART1, ENABLE);
}

性能优化：让系统飞起来

性能优化是嵌入式系统开发中永恒的话题。一个设计良好的系统不仅要功能正确，还要运行高效。在uCOS-II中，有许多技巧可以提升系统性能，让你的项目从"能跑"变成"飞跑"！

中断延迟优化是第一个要考虑的问题。中断响应时间直接影响系统的实时性能。在uCOS-II中，中断延迟主要由以下几个因素决定：

Tinterrupt_latency=Thardware+TOS_overhead+Tcritical_sectionT_{interrupt\_latency} = T_{hardware} + T_{OS\_overhead} + T_{critical\_section}Tinterrupt_latency​=Thardware​+TOS_overhead​+Tcritical_section​

其中：

  • ThardwareT_{hardware}Thardware​：硬件中断响应时间（通常是固定值）
  • TOS_overheadT_{OS\_overhead}TOS_overhead​：操作系统开销（包括上下文保存等）
  • Tcritical_sectionT_{critical\_section}Tcritical_section​：关键段执行时间（可优化）

关键段是指OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()之间的代码，在这段时间内中断是被禁止的。因此，减少关键段的执行时间是优化中断延迟的关键：

// 不好的做法：关键段太长
void BadExample(void)
{
    OS_ENTER_CRITICAL();
    
    // 长时间操作
    ProcessLargeData();      // 可能需要几毫秒
    UpdateComplexStructure(); // 复杂的数据结构更新
    PerformCalculation();    // 复杂计算
    
    OS_EXIT_CRITICAL();
}

// 好的做法：缩短关键段
void GoodExample(void)
{
    // 先在关键段外做准备工作
    ProcessLargeData();
    
    // 只在必要时进入关键段
    OS_ENTER_CRITICAL();
    UpdateSharedVariable();  // 只更新共享变量
    OS_EXIT_CRITICAL();
    
    // 其他操作在关键段外进行
    PerformCalculation();
}

任务切换开销优化是另一个重要方面。虽然uCOS-II的任务切换已经很高效，但仍然可以通过一些技巧来优化：

// 减少不必要的任务切换
void OptimizedTask(void *pdata)
{
    INT8U err;
    
    while(1) {
        // 批量处理多个事件，减少切换次数
        while(OSMboxAccept(EventMbox) != (void *)0) {
            ProcessEvent();
        }
        
        // 使用较大的延时值，减少周期性唤醒
        OSTimeDly(100);  // 而不是OSTimeDly(1)
    }
}

内存访问优化也很重要。在STM32F103这样的ARM Cortex-M3处理器上，内存访问效率对系统性能有显著影响：

// 数据对齐优化
typedef struct {
    INT8U  flag;        // 1字节
    INT8U  padding[3];  // 填充到4字节边界
    INT32U counter;     // 4字节，现在是对齐的
    INT16U status;      // 2字节
    INT16U padding2;    // 填充到4字节边界
} OptimizedStruct;

// 不好的数据结构（未对齐）
typedef struct {
    INT8U  flag;        // 1字节
    INT32U counter;     // 4字节，但不对齐！
    INT16U status;      // 2字节
} UnalignedStruct;    // 编译器可能会自动填充，但不可预测

为什么数据对齐这么重要？因为ARM Cortex-M3处理器访问未对齐的32位数据时，需要额外的处理周期。想象一下，如果你要搬一个大箱子，但箱子被放在了两个台阶之间，你是不是需要更多的力气和时间？

算法优化同样不容忽视。uCOS-II内部使用了很多巧妙的算法来提高效率，我们也可以借鉴这些思路：

// 快速计算2的幂次方（位操作比乘法快）
#define IS_POWER_OF_2(x)    (((x) & ((x) - 1)) == 0)
#define NEXT_POWER_OF_2(x)  (1 << (32 - __builtin_clz((x) - 1)))

// 快速模运算（当除数是2的幂时）
#define FAST_MOD_POWER_OF_2(val, mod)  ((val) & ((mod) - 1))

// 示例：快速的循环缓冲区实现
typedef struct {
    INT8U  buffer[256];  // 大小必须是2的幂
    INT8U  head;
    INT8U  tail;
} FastRingBuffer;

void FastRingBufferPut(FastRingBuffer *rb, INT8U data)
{
    rb->buffer[rb->head] = data;
    rb->head = (rb->head + 1) & 0xFF;  // 相当于 % 256，但更快
}

INT8U FastRingBufferGet(FastRingBuffer *rb)
{
    INT8U data = rb->buffer[rb->tail];
    rb->tail = (rb->tail + 1) & 0xFF;
    return data;
}

编译器优化也是性能提升的重要手段。Keil5提供了丰富的优化选项：

// 使用内联函数减少函数调用开销
__INLINE void GPIO_SetBit(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
{
    GPIOx->BSRR = GPIO_Pin;
}

// 使用寄存器变量提示编译器优化
void HighFrequencyTask(void *pdata)
{
    register INT32U counter = 0;  // 提示编译器使用寄存器
    
    while(1) {
        // 高频操作
        counter++;
        
        if (counter >= 1000000) {
            counter = 0;
            // 每100万次循环做一次操作
            DoPeriodicWork();
        }
    }
}

在Keil5中，你可以通过以下设置来优化性能：

Project -> Options for Target -> C/C++:
- Optimization Level: -O2 或 -O3
- One ELF Section per Function: 启用（有助于链接器优化）
- Use ARM Compiler 6: 启用（更新的编译器通常有更好的优化）

内存池优化是另一个值得关注的方面。频繁的动态内存分配会导致内存碎片化，影响系统稳定性。uCOS-II提供了内存池机制来解决这个问题：

// 创建内存池
#define BLOCK_SIZE      64
#define BLOCK_COUNT     20
#define POOL_SIZE       (BLOCK_SIZE * BLOCK_COUNT)

INT8U MemoryPool[POOL_SIZE];
OS_MEM *DataMemPool;

void CreateMemoryPool(void)
{
    INT8U err;
    
    DataMemPool = OSMemCreate(MemoryPool, BLOCK_COUNT, BLOCK_SIZE, &err);
    if (err != OS_NO_ERR) {
        // 内存池创建失败
        printf("Memory pool creation failed!\n");
    }
}

// 使用内存池
void UseMemoryPool(void)
{
    INT8U err;
    void *ptr;
    
    // 从内存池获取内存块
    ptr = OSMemGet(DataMemPool, &err);
    if (err == OS_NO_ERR) {
        // 使用内存块
        ProcessData(ptr);
        
        // 释放内存块
        OSMemPut(DataMemPool, ptr);
    }
}

这种内存池的设计就像是停车场的固定车位，每个车位大小相同，不会产生碎片，分配和释放都很快。

调试技巧：火眼金睛找Bug

调试是嵌入式开发中最具挑战性的环节，特别是在多任务系统中。Bug可能隐藏在任务间的复杂交互中，就像在迷宫中寻找出口一样。但是，掌握了正确的调试技巧，你就能像侦探一样，从蛛丝马迹中找出问题的根源。

使用Keil5的RTOS调试功能是最直接的方法。在调试会话中，你可以实时观察系统状态：

// 在代码中添加断点和观察点
void DebugTask(void *pdata)
{
    INT8U err;
    static INT32U debug_counter = 0;
    
    while(1) {
        debug_counter++;  // 在这里设置断点
        
        // 观察任务状态
        OSTimeDly(100);
        
        // 检查堆栈使用情况
        if (debug_counter % 100 == 0) {
            // 每10秒检查一次
            CheckStackUsage();
        }
    }
}

void CheckStackUsage(void)
{
    OS_STK_DATA stk_data;
    INT8U err;
    
    // 检查各个任务的堆栈使用情况
    OSTaskStkChk(LED_TASK_PRIO, &stk_data);
    if (stk_data.OSUsed > stk_data.OSFree) {
        // 堆栈使用超过50%，发出警告
        printf("WARNING: LED Task stack usage high: %d%%\n", 
               (stk_data.OSUsed * 100) / (stk_data.OSUsed + stk_data.OSFree));
    }
}

任务死锁检测是多任务系统中的常见问题。死锁就像是几个人在狭窄的走廊里互相堵住了去路，谁也动不了：

// 死锁检测机制
#define DEADLOCK_TIMEOUT    5000  // 5秒超时

typedef struct {
    OS_EVENT *sem;
    INT32U    timestamp;
    INT8U     task_prio;
} DeadlockMonitor;

DeadlockMonitor deadlock_monitors[OS_MAX_TASKS];

void DeadlockDetectionTask(void *pdata)
{
    INT8U i;
    INT32U current_time;
    
    while(1) {
        current_time = OSTimeGet();
        
        for (i = 0; i < OS_MAX_TASKS; i++) {
            if (deadlock_monitors[i].sem != (OS_EVENT *)0) {
                // 检查是否超时
                if ((current_time - deadlock_monitors[i].timestamp) > DEADLOCK_TIMEOUT) {
                    // 可能发生死锁
                    printf("DEADLOCK DETECTED: Task %d waiting for semaphore too long!\n", 
                           deadlock_monitors[i].task_prio);
                    
                    // 这里可以采取恢复措施
                    HandleDeadlock(i);
                }
            }
        }
        
        OSTimeDly(1000);  // 每秒检查一次
    }
}

// 包装信号量等待函数，添加死锁检测
INT8U SafeOSSemPend(OS_EVENT *pevent, INT16U timeout, INT8U *err)
{
    INT8U task_prio = OSPrioCur;
    INT8U i;
    
    // 记录等待开始时间
    for (i = 0; i < OS_MAX_TASKS; i++) {
        if (deadlock_monitors[i].sem == (OS_EVENT *)0) {
            deadlock_monitors[i].sem = pevent;
            deadlock_monitors[i].timestamp = OSTimeGet();
            deadlock_monitors[i].task_prio = task_prio;
            break;
        }
    }
    
    // 调用原始函数
    OSSemPend(pevent, timeout, err);
    
    // 清除监控记录
    if (i < OS_MAX_TASKS) {
        deadlock_monitors[i].sem = (OS_EVENT *)0;
    }
    
    return *err;
}

堆栈溢出检测是另一个重要的调试技巧。堆栈溢出往往会导致系统崩溃，而且问题现象可能出现在与真正原因相距很远的地方：

// 增强型堆栈溢出检测
#define STACK_CANARY_SIZE   4
#define STACK_CANARY_VALUE  0xDEADBEEF

typedef struct {
    OS_STK *stack_base;
    INT32U  stack_size;
    INT32U  canary_value;
} StackGuard;

StackGuard stack_guards[OS_MAX_TASKS];

void InitStackGuard(INT8U task_prio, OS_STK *stack_base, INT32U stack_size)
{
    INT8U i;
    
    // 找到空闲的监控槽
    for (i = 0; i < OS_MAX_TASKS; i++) {
        if (stack_guards[i].stack_base == (OS_STK *)0) {
            stack_guards[i].stack_base = stack_base;
            stack_guards[i].stack_size = stack_size;
            stack_guards[i].canary_value = STACK_CANARY_VALUE;
            
            // 在堆栈底部放置金丝雀值
            *(stack_base) = STACK_CANARY_VALUE;
            *(stack_base + 1) = STACK_CANARY_VALUE;
            *(stack_base + 2) = STACK_CANARY_VALUE;
            *(stack_base + 3) = STACK_CANARY_VALUE;
            
            break;
        }
    }
}

void CheckStackOverflow(void)
{
    INT8U i;
    
    for (i = 0; i < OS_MAX_TASKS; i++) {
        if (stack_guards[i].stack_base != (OS_STK *)0) {
            // 检查金丝雀值是否被修改
            if (*(stack_guards[i].stack_base) != STACK_CANARY_VALUE ||
                *(stack_guards[i].stack_base + 1) != STACK_CANARY_VALUE ||
                *(stack_guards[i].stack_base + 2) != STACK_CANARY_VALUE ||
                *(stack_guards[i].stack_base + 3) != STACK_CANARY_VALUE) {
                
                printf("STACK OVERFLOW DETECTED in slot %d!\n", i);
                
                // 触发断言或采取恢复措施
                __BKPT(0);  // 触发断点
            }
        }
    }
}

任务执行时间分析可以帮助你找出性能瓶颈：

// 任务执行时间统计
typedef struct {
    INT8U   task_prio;
    INT32U  total_time;
    INT32U  call_count;
    INT32U  max_time;
    INT32U  start_time;
} TaskProfiler;

TaskProfiler task_profilers[OS_MAX_TASKS];

void StartTaskProfiling(INT8U task_prio)
{
    INT8U i;
    
    for (i = 0; i < OS_MAX_TASKS; i++) {
        if (task_profilers[i].task_prio == task_prio) {
            task_profilers[i].start_time = OSTimeGet();
            break;
        }
    }
}

void EndTaskProfiling(INT8U task_prio)
{
    INT8U i;
    INT32U execution_time;
    
    for (i = 0; i < OS_MAX_TASKS; i++) {
        if (task_profilers[i].task_prio == task_prio) {
            execution_time = OSTimeGet() - task_profilers[i].start_time;
            
            task_profilers[i].total_time += execution_time;
            task_profilers[i].call_count++;
            
            if (execution_time > task_profilers[i].max_time) {
                task_profilers[i].max_time = execution_time;
            }
            
            break;
        }
    }
}

// 在任务中使用性能分析
void ProfiledTask(void *pdata)
{
    INT8U task_prio = OSPrioCur;
    
    while(1) {
        StartTaskProfiling(task_prio);
        
        // 执行任务工作
        DoTaskWork();
        
        EndTaskProfiling(task_prio);
        
        OSTimeDly(100);
    }
}

内存泄漏检测虽然在uCOS-II中不如在Windows或Linux系统中常见，但仍然可能发生：

// 简单的内存使用监控
typedef struct {
    void   *ptr;
    INT32U  size;
    INT32U  timestamp;
    INT8U   task_prio;
} MemAllocRecord;

#define MAX_ALLOC_RECORDS  100
MemAllocRecord alloc_records[MAX_ALLOC_RECORDS];

void* DebugMalloc(INT32U size)
{
    void *ptr;
    INT8U i;
    
    // 从内存池分配
    ptr = OSMemGet(DataMemPool, &err);
    
    if (ptr != (void *)0) {
        // 记录分配信息
        for (i = 0; i < MAX_ALLOC_RECORDS; i++) {
            if (alloc_records[i].ptr == (void *)0) {
                alloc_records[i].ptr = ptr;
                alloc_records[i].size = size;
                alloc_records[i].timestamp = OSTimeGet();
                alloc_records[i].task_prio = OSPrioCur;
                break;
            }
        }
    }
    
    return ptr;
}

void DebugFree(void *ptr)
{
    INT8U i;
    
    // 释放内存
    OSMemPut(DataMemPool, ptr);
    
    // 清除记录
    for (i = 0; i < MAX_ALLOC_RECORDS; i++) {
        if (alloc_records[i].ptr == ptr) {
            alloc_records[i].ptr = (void *)0;
            break;
        }
    }
}

// 检查内存泄漏
void CheckMemoryLeaks(void)
{
    INT8U i;
    INT32U current_time = OSTimeGet();
    
    printf("Memory leak check:\n");
    for (i = 0; i < MAX_ALLOC_RECORDS; i++) {
        if (alloc_records[i].ptr != (void *)0) {
            printf("Leak: Task %d, Size %d, Age %d ticks\n",
                   alloc_records[i].task_prio,
                   alloc_records[i].size,
                   current_time - alloc_records[i].timestamp);
        }
    }
}

调试输出技巧也很重要。合理的调试输出可以帮助你快速定位问题：

// 带时间戳的调试输出
#define DEBUG_PRINT(fmt, ...) \
    printf("[%08d] %s:%d " fmt "\n", OSTimeGet(), __FILE__, __LINE__, ##__VA_ARGS__)

// 条件编译的调试输出
#ifdef DEBUG_ENABLED
    #define DBG_PRINT(fmt, ...)  DEBUG_PRINT(fmt, ##__VA_ARGS__)
#else
    #define DBG_PRINT(fmt, ...)  // 空操作
#endif

// 使用示例
void ExampleTask(void *pdata)
{
    while(1) {
        DBG_PRINT("Task executing, counter = %d", counter);
        
        // 任务逻辑
        counter++;
        
        OSTimeDly(100);
    }
}

记住，调试是一门艺术，需要耐心和技巧。就像医生诊断病情一样，要从现象推测原因，从局部看到整体。不要急于求成，要系统地分析问题，逐步缩小范围，最终找到问题的根源。

通过这些调试技巧，你就能像拥有"火眼金睛"一样，快速发现和解决系统中的各种问题。记住，每一个Bug都是学习的机会，每一次调试都是技能的提升！

SlientICE
关注
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值