RTOS-F429-HAL-列表创建，写入，读取（2026/8/1）

目录一队列核心概念梳理1、队列是什么2、四个关键特性3、阻塞机制核心4、多个任务挤着等一个队列时谁先醒5、队列操作流程二队列的结构体1结构体分析2联合体分析1含义是2为什么 FreeRTOS 要这么设计3ucQueueType 字段是什么4怎么选择要用哪个三队列的API1、创建队列2、写入队列5 个函数底层都是同一个3、读取队列4 个函数4写入和读取的位置四实验改动清单1freertos_demo.c2main.c五实验总结1、队列概念2、队列结构体3、union队列 ↔ 信号量同一结构体4、核心 API5、阻塞机制6、值拷贝 vs 指针传7、%s 的本质8、工程rtos\10\ 队列实验一队列核心概念梳理1、队列是什么一块有限容量、固定大小的环形缓冲区。队列长度5项目大小10字节 ┌────┬────┬────┬────┬────┐ │ │ │ │ │ │ ← 每个槽 10 字节共 5 个槽 └────┴────┴────┴────┴────┘ ​ 创建时要定两件事能存几个长度、每个多大项目大小字节全局变量容易被胡乱操作2、四个关键特性特性说明FIFO/LIFO默认先进先出可配成后进先出像堆栈值拷贝数据从内存复制进队列不是传指针传大块数据时也可传指针地址节约带宽多任务共享任何任务、中断都可以发/读队列不属于任何一个任务阻塞机制满了写不进去空了读不出来→ 阻塞等3、阻塞机制核心入队队列满了写不进去 ① 任务挂到 pxDelayedTaskList延时列表 ② 任务挂到 xTasksWaitingToSend排队等着写 出队队列空了读不出来 ① 任务挂到 pxDelayedTaskList ② 任务挂到 xTasksWaitingToReceive排队等着读 入队阻塞队列满写不进去 ​ 状态绳(xStateListItem) ReadyList ──摘下来──→ DelayedTaskList 我不跑了等 事件绳(xEventListItem) 空着 ──挂上去──→ Queue.xTasksWaitingToSend 我在等传菜口腾空位 ​ ​ 出队阻塞队列空读不出来 ​ 状态绳(xStateListItem) ReadyList ──摘下来──→ DelayedTaskList 我不跑了等 事件绳(xEventListItem) 空着 ──挂上去──→ Queue.xTasksWaitingToReceive 我在等传菜口出菜 一根绳记录我不跑了另一根绳记录我在等什么。 唤醒时反着来——先把事件绳从 Queue 等待区摘掉再顺着 pvOwner 找到 TCB把状态绳挂回 ReadyList。这就是之前笔记里说的阻塞删 Ready → 插 Waiting唤醒删 Waiting → 插 Ready。阻塞时间三种选择值含义0不等待立刻返回失败1 ~ portMAX_DELAY-1等这么多 tick超时还没戏就返回失败portMAX_DELAY死等等到天荒地老4、多个任务挤着等一个队列时谁先醒优先级高的先拿到优先级相同 →等得最久的先拿到A: xQueueReceive(q, portMAX_DELAY) → 死等等到天荒地老 B: xQueueReceive(q, portMAX_DELAY) → 死等 C: xQueueReceive(q, 100) → 最多等 100 tick ​ 时间轴 → ​ t0 A 先跑到这行xQueueReceive(q, 死等) → A 排在等接收队伍第 1 位 ​ t50 B 才跑到这行xQueueReceive(q, 死等) → B 排在等接收队伍第 2 位 t60 C 才跑到这行xQueueReceive(q, 100) → B 排在等接收队伍第 3 位 ​ SysTick 每 1ms 扫延时列表干活 ​ ​ 第 1msA/B/C 挂进延时列表各自绳上记着到期时间 A/B 到期时间 永远不到期 C 到期时间 当前 100 第 100ms ​ 第 2ms ~ 第 99ms 扫延时列表 → A/B/C 都没到期 → 继续睡 ​ 第 100ms 扫延时列表 → C 到期了 → 把 C 的两根绳都摘掉 → C 拿着超时的结果返回 如果这期间队列一直没来数据 → A 和 B 继续等 下次来数据了 → A 先拿到先来的 就是 SysTick 管着每 1ms 看一眼谁该醒了。 C 等 100 tick 就是 100msSysTick 数到 100 下还没等到数据就把 C 叫醒说你超时了。A/B 填的死等 → 到期时间记成无穷大 → SysTick 扫过去永远不叫醒他们只有数据来了才醒。5、队列操作流程① 创建空队列5 个槽全空 ┌──┬──┬──┬──┬──┐ │ │ │ │ │ │ └──┴──┴──┴──┴──┘ ​ ② taskA 写入 10 ┌──┬──┬──┬──┬────┐ │ │ │ │ │ 10 │ └──┴──┴──┴──┴────┘ 写入指针 → 移到下一个槽 ​ ③ taskA 写入 20 ┌──┬──┬──┬────┬────┐ │ │ │ │ 20 │ 10 │ └──┴──┴──┴────┴────┘ ​ ④ taskB 读取 → 拿走 10先入先出 ┌──┬──┬──┬────┬────┐ │ │ │ │ 20 │ │ └──┴──┴──┴────┴────┘ y 10值拷贝taskA 的x10拷贝进队列taskB 读出来放y。不是传指针是实实在在复制了数据。二队列的结构体typedef struct QueueDefinition { int8_t *pcHead; // 存储区起始地址 int8_t *pcTail; // 存储区结束地址 队列存储区管理 int8_t *pcWriteTo; // 下次写入的位置 ​ union { QueuePointers_t xQueue; SemaphoreData_t xSemaphore; } u; ​ List_t xTasksWaitingToSend; // 等发送的任务排队区 List_t xTasksWaitingToReceive; // 等接收的任务排队区 ​ volatile UBaseType_t uxMessagesWaiting;// 当前队列里有多少条消息 UBaseType_t uxLength; // 队列长度最多存几条 UBaseType_t uxItemSize; // 每条消息的大小字节 ​ volatile int8_t cRxLock; // 接收锁中断安全用 volatile int8_t cTxLock; // 发送锁中断安全用 ​ #if ...条件编译... uint8_t ucStaticallyAllocated; // 是否静态分配 struct QueueDefinition *pxQueueSetContainer; UBaseType_t uxQueueNumber; uint8_t ucQueueType; #endif ​ } xQUEUE; ​ typedef xQUEUE Queue_t;1结构体分析分两拨管数据的 vs 管人排队的管数据的队列缓冲区字段干啥pcHead数据区首地址创建时pvPortMalloc分的pcWriteTo下次往哪写入队时 1 格pcTail数据区末地址判断有没有溢出pcReadFrom上次从哪读的出队时 1 格uxLength最多存几个创建时指定固定不变uxItemSize每个多大创建时指定固定不变uxMessagesWaiting当前排了几个0 ~ uxLength管人排队的任务等待区字段干啥xTasksWaitingToSend满了想写但写不进去的任务挂在这xTasksWaitingToReceive空了想读但读不到的任务挂在这两个都是List_t里面挂的都是任务的xEventListItem那根事件绳。2联合体分析联合体队列 vs 信号量同个结构体两套外套union { QueuePointers_t xQueue; // 当队列用 → 有读写指针 SemaphoreData_t xSemaphore; // 当信号量/互斥锁用 → 有持有者 } u;1含义是u是一个联合体变量xQueue和xSemaphore共用同一段内存同一时刻只能使用其中一个联合体大小 最大成员的大小 也就是说当这个结构表示队列时u.xQueue有意义当这个结构表示信号量时u.xSemaphore有意义二者不会同时存在2为什么 FreeRTOS 要这么设计因为队列和信号量本质上是同一个内核对象只是行为不同类型是否存数据需要的额外字段队列✅ 存数据读指针、写指针互斥信号量❌ 不存数据持有者、递归计数如果不用union就要多占内存用union就可以复用内存。队列 Queue 信号量Semaphore ├── 计数信号量 → 普普通通记数字停车场还有3个位 ├── 二进制信号量 → 计数范围 0~1只有一个位 ├── 互斥锁 → 二进制信号量 记持有者 优先级继承 └── 递归互斥锁 → 互斥锁 同一个人可以锁 N 次所以联合体里只需要两个身份union { QueuePointers_t xQueue; // 队列要存数据 SemaphoreData_t xSemaphore; // 信号量/互斥锁/递归互斥锁不存数据只记持有者 } u;互斥锁需要记录的额外信息持有者、递归次数全都塞在xSemaphore这两个字段里不需要新身份。信号量是爹互斥锁是儿子。3ucQueueType 字段是什么ucQueueType 是 xQUEUE 结构体里的一个 类型标记字段类似“身份证”。靠ucQueueType字段configUSE_TRACE_FACILITY 1时启用从 rtos\7 任务状态查询实验开始我们就设了configUSE_TRACE_FACILITY 1rtos\9 继承了同一个 FreeRTOSConfig.h不用再改。//ucQueueType 这个在结构体中怎么没看到 在列表结构体最下面条件编译包着的typedef struct QueueDefinition { // ... 前面那些你熟悉的字段 ... ​ #if ( configUSE_TRACE_FACILITY 1 ) // ← 开了才存在 UBaseType_t uxQueueNumber; uint8_t ucQueueType; // ← 就在这162 行 #endif ​ } xQUEUE;之前看结构体时被#if包在最底部正点的图里也没画出来。我们configUSE_TRACE_FACILITY 1是开着的所以实际编译时存在不是所有 FreeRTOS 项目都有。4怎么选择要用哪个在你调用创建 API 的那一刻就决定了。✅ 创建队列 QueueHandle_t xQueue xQueueCreate(4, 32); 内部会做这件事简化 pxNewQueue-ucQueueType queueQUEUE_TYPE_BASE; → 说明这是个队列 → 以后只用u.xQueue ✅ 创建互斥信号量 SemaphoreHandle_t xMutex xSemaphoreCreateMutex(); 内部 pxNewQueue-ucQueueType queueQUEUE_TYPE_MUTEX; → 说明这是个互斥量 → 以后只用u.xSemaphore ​ 简单说你调 xQueueCreate 还是 xSemaphoreCreate创建的时候就定了身份ucQueueType 打上标签后面一辈子按标签走对应逻辑三队列的API1、创建队列QueueHandle_t xQueueCreate( UBaseType_t uxQueueLength, UBaseType_t uxItemSize );形参含义uxQueueLength队列长度最多存几条uxItemSize每条消息的大小字节传 0 就是信号量返值成功返回句柄失败返回NULL。// 示例创建一个能存 5 个、每个 32 字节的队列 QueueHandle_t q xQueueCreate(5, 32);静态版本xQueueCreateStatic()需自己提供内存初学不常用用到再说。2、写入队列5 个函数底层都是同一个函数写入位置什么时候用xQueueSend()尾部最常用普通入队xQueueSendToBack()尾部跟上面一模一样xQueueSendToFront()头部插队跳到最前面xQueueOverwrite()覆盖队列长度1 时用直接盖掉旧数据xQueueSendFromISR()尾部中断里专用底层都是调同一个函数只差最后一个参数#define xQueueSend(q, data, wait) xQueueGenericSend(q, data, wait, queueSEND_TO_BACK) #define xQueueSendToBack(q, data, wait) xQueueGenericSend(q, data, wait, queueSEND_TO_BACK) #define xQueueSendToFront(q, data, wait) xQueueGenericSend(q, data, wait, queueSEND_TO_FRONT) #define xQueueOverwrite(q, data) xQueueGenericSend(q, data, 0, queueOVERWRITE)3、读取队列4 个函数函数读了后移除在哪用xQueueReceive()✅ 移除任务中xQueuePeek()❌ 不移除只看不拿任务中xQueueReceiveFromISR()✅ 移除中断里xQueuePeekFromISR()❌ 不移除中断里原型BaseType_t xQueueReceive( QueueHandle_t xQueue, // 从哪读 void * const pvBuffer, // 读到哪输出 TickType_t xTicksToWait ); // 等多久形参含义xQueue队列句柄pvBuffer读出来的数据存到哪xTicksToWait队列空时等多久0不等portMAX_DELAY死等返值pdPASS 拿到了pdFALSE 失败超时/队列空。4写入和读取的位置队列长度5当前有 3 条 读这边 ←←←←←←←←←← 写这边 →→→→→→→→→→ ┌──────┬──────┬──────┬──────┬──────┐ │ 10 │ 20 │ 30 │ │ │ └──────┴──────┴──────┴──────┴──────┘ ↑ ↑ xQueueReceive() xQueueSend() xQueuePeek() xQueueSendToBack() 从头部拿 往尾部放 ​ xQueueSendToFront() → 插到头部挤开别人 xQueueOverwrite() → 只有 1 个槽时直接盖掉明天实验就是用这套 API创建 → 发送 → 接收。四实验改动清单1freertos_demo.c行号内容14新增#include queue.h— 队列 API48-49key_queue(2×1字节) /big_queue(1×4字节) 全局队列句柄69-80freertos_demo()里创建两个队列 打印成功/失败106-134task1扫 KEY1→发 key_queue扫 KEY2→发 big_queue139-158task2xQueueReceive(key_queue, 死等)→ 打印按键值163-177task3xQueueReceive(big_queue, 死等)→ 打印字符串指针传递2main.c行号内容5新增#include ./Key/Key.h17新增Key_Init()26printf 标题 →FreeRTOS Queue Test!五实验总结1、队列概念队列 任务间传数据的管道。先进先出FIFO值拷贝。创建时定好能存几条uxLength和每条多大uxItemSize。2、队列结构体xQUEUE队列结构体 数据缓冲区创建时分配 ┌──────────────────────┐ ┌──────────────────┐ │ pcHead ──────────────┼──────────────→ │ 队列项1 │ 队列项2 │ ... │ │ pcTail │ └──────────────────┘ │ pcWriteTo ───────────┼──→ 下次写到这 │ u.pcReadFrom ────────┼──→ 上次从这读 │ uxLength / uxItemSize│ ← 创建时定死的 │ uxMessagesWaiting │ ← 当前有几条 │ xTasksWaitingToSend │ ← 满了等着写的人的队伍 │ xTasksWaitingToReceive│ ← 空了等着读的人的队伍 └──────────────────────┘3、union队列 ↔ 信号量同一结构体union { 队列用pcReadFrom上次读的位置 互斥锁用xMutexHolder uxRecursiveCallCount谁拿着钥匙 } u;队列有数据区信号量/互斥锁没有uxItemSize 0靠ucQueueType区分身份。4、核心 API操作函数关键点创建xQueueCreate(len, size)返回值是句柄失败返 NULL写入xQueueSend(q, data, wait)值拷贝拷的是指针指向的内容写入插队xQueueSendToFront(q, data, wait)跳到队头覆盖xQueueOverwrite(q, data)长度1 时用读取xQueueReceive(q, buf, wait)值拷贝到 buf同时从队列移除只看不拿xQueuePeek(q, buf, wait)读完数据还在队列里中断版xQueueSendFromISR/ReceiveFromISRISR 里专用5、阻塞机制队列满 → 写入方挂xTasksWaitingToSend事件绳状态绳挂延时列表 队列空 → 读取方挂xTasksWaitingToReceive事件绳状态绳挂延时列表 条件满足 → 顺着pvOwner找回 TCB → 状态绳挂回 ReadyList同优先级排队谁先跑到xQueueReceive谁排前面先到先拿。6、值拷贝 vs 指针传值拷贝指针传递队列大小sizeof(数据类型)sizeof(char *) 4 字节拷进去什么数据本身数据的地址适用场景小数据按键值、传感器值大数据字符串、结构体%s打印—printf(%s, buf)顺着地址找7、%s的本质%s不是打指针值是顺着指针去读内存里的字符串。%p才是打地址值本身。8、工程rtos\10\ 队列实验key_queue存 1 字节按键值值拷贝big_queue存 4 字节指针指针传递指向buff[100]task1 生产者扫 KEY1/KEY2 发队列task2/task3 消费者死等读取读了就打印