From 8064e2649708be9425ea8d778703c47622784eaf Mon Sep 17 00:00:00 2001
From: kylehe233-ui <kylehe233@gmail.com>
Date: Mon, 17 Aug 2026 16:02:28 +0800
Subject: [PATCH 1/7] =?UTF-8?q?=E4=B8=AA=E4=BA=BA=E6=A8=A1=E6=9D=BFCOMMIT?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...47\254\254\344\270\200\345\244\251\344\275\234\344\270\232.md" | 0
 ...47\254\254\344\270\200\345\244\251\347\254\224\350\256\260.md" | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\200\345\244\251\344\275\234\344\270\232.md"
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\200\345\244\251\347\254\224\350\256\260.md"

diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\200\345\244\251\344\275\234\344\270\232.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\200\345\244\251\344\275\234\344\270\232.md"
new file mode 100644
index 0000000..e69de29
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\200\345\244\251\347\254\224\350\256\260.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\200\345\244\251\347\254\224\350\256\260.md"
new file mode 100644
index 0000000..e69de29
-- 
Gitee


From d07af8db7c79c3b0fa4c758f5e3935c435bdac22 Mon Sep 17 00:00:00 2001
From: kylehe233-ui <kylehe233@gmail.com>
Date: Tue, 18 Aug 2026 10:59:13 +0800
Subject: [PATCH 2/7] day1 commit

---
 ...00\345\244\251\344\275\234\344\270\232.md" |    1 +
 ...00\345\244\251\347\254\224\350\256\260.md" | 2113 +++++++++++++++++
 2 files changed, 2114 insertions(+)

diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\200\345\244\251\344\275\234\344\270\232.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\200\345\244\251\344\275\234\344\270\232.md"
index e69de29..5e681e6 100644
--- "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\200\345\244\251\344\275\234\344\270\232.md"
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\200\345\244\251\344\275\234\344\270\232.md"
@@ -0,0 +1 @@
+已完成
\ No newline at end of file
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\200\345\244\251\347\254\224\350\256\260.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\200\345\244\251\347\254\224\350\256\260.md"
index e69de29..d5877d3 100644
--- "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\200\345\244\251\347\254\224\350\256\260.md"
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\200\345\244\251\347\254\224\350\256\260.md"
@@ -0,0 +1,2113 @@
+# Day 1
+
+## Task 1 开始 RT-Thread
+
+### 1. RT-Thread 简介
+
+RT-Thread 是一款面向嵌入式设备的实时操作系统（RTOS）。在 RT-Thread 的学习和开发过程中，一个基本的程序开发流程可以分为：
+
+**编码 → 编译 → 烧录 → 运行 → 调试**
+
+### 2. 编码
+
+首先根据实验要求编写程序代码。
+
+在 RT-Thread 中，可以通过创建线程、使用延时函数以及调用系统提供的 API 来实现不同的功能。
+
+例如，一个简单的线程程序可以按照以下结构编写：
+
+```c
+#include <rtthread.h>
+
+int main(void)
+{
+    rt_kprintf("Hello RT-Thread!\n");
+
+    while (1)
+    {
+        rt_thread_mdelay(1000);
+    }
+
+    return 0;
+}
+```
+
+其中：
+
+- `rt_kprintf()`：用于向 Console 输出调试信息。
+- `rt_thread_mdelay()`：使当前线程延时指定的毫秒数。
+- `while (1)`：使程序持续运行。
+
+### 3. 编译
+
+完成代码编写后，需要对工程进行编译。
+
+编译的主要作用是将编写的 C/C++ 源代码转换为 MCU 可以运行的机器代码。
+
+基本过程为：
+
+```text
+源代码
+  ↓
+预处理
+  ↓
+编译
+  ↓
+汇编
+  ↓
+链接
+  ↓
+生成可执行文件
+```
+
+编译成功后，一般会生成用于烧录的程序文件，例如：
+
+```text
+.elf
+.bin
+.hex
+```
+
+如果编译过程中出现 Error，需要根据控制台中的错误信息检查代码、头文件、驱动以及工程配置。
+
+### 4. 烧录
+
+编译成功后，将生成的程序下载到开发板 MCU 的 Flash 中。
+
+常见烧录方式包括：
+
+- ST-Link
+- J-Link
+- USB
+- 串口 Bootloader
+- STM32CubeProgrammer
+
+烧录完成后，对开发板重新上电或复位，MCU 就会开始运行 Flash 中的程序。
+
+### 5. 运行与 Console
+
+程序烧录成功后，可以通过串口 Console 查看 RT-Thread 的运行信息。
+
+例如：
+
+```text
+ \ | /
+- RT -     Thread Operating System
+ / | \
+
+Hello RT-Thread!
+```
+
+Console 是嵌入式开发过程中非常重要的调试工具，可以通过打印信息判断：
+
+- 程序是否正常启动
+- 线程是否正常运行
+- 函数是否被执行
+- 变量值是否正确
+- 程序运行到了哪个位置
+
+### 6. 调试与修改
+
+如果程序运行结果与预期不一致，需要重新检查程序并进行修改。
+
+因此，RT-Thread 实际开发通常是一个不断循环的过程：
+
+```text
+编码
+ ↓
+编译
+ ↓
+烧录
+ ↓
+运行
+ ↓
+观察 Console
+ ↓
+发现问题
+ ↓
+修改代码
+ ↓
+重新编译
+```
+
+通过不断重复这一过程，最终完成程序功能。
+
+------
+
+## Task 2 MD 文档编写
+
+Markdown（`.md`）是一种轻量级标记语言，可以使用简单的符号完成标题、代码、表格以及文字格式的编写。
+
+### 1. 标题
+
+Markdown 使用 `#` 表示标题，不同数量的 `#` 代表不同级别的标题。
+
+```text
+# 一级标题
+
+## 二级标题
+
+### 三级标题
+
+#### 四级标题
+
+##### 五级标题
+
+###### 六级标题
+```
+
+标题级别越高，使用的 `#` 数量越少。
+
+------
+
+### 2. 代码段
+
+Markdown 可以使用三个反引号创建代码块。
+
+例如 C 语言代码：
+
+```c
+#include <stdio.h>
+
+int main()
+{
+    return 0;
+}
+```
+
+在三个反引号后添加语言名称，例如 `c`、`cpp`、`python`、`java` 等，可以让 Markdown 编辑器自动进行代码语法高亮。
+
+例如：
+
+~~~text
+```c
+#include <stdio.h>
+
+int main()
+{
+    return 0;
+}
+```
+~~~
+
+------
+
+### 3. 表格
+
+Markdown 可以通过 `|` 和 `-` 创建表格。
+
+例如：
+
+| t1   | t2   |
+| ---- | ---- |
+| 1    | 2    |
+
+对应的 Markdown 语法为：
+
+```text
+|   t1   |   t2   |
+| ---- | ---- |
+|   1   |   2   |
+```
+
+表格可以用于记录实验参数、测试结果和不同配置之间的对比。
+
+------
+
+### 4. 行内代码与高亮
+
+使用一对反引号可以标记代码、变量名、命令或者需要特别强调的内容。
+
+例如：
+
+```
+高亮语法
+```
+
+还可以用于表示函数名：
+
+```
+rt_kprintf()
+```
+
+文件名：
+
+```
+main.c
+```
+
+或者命令：
+
+```
+make
+```
+
+这种方式非常适合在技术文档中标记代码相关内容。
+
+------
+
+### 5. 加粗字体
+
+使用两个星号包围文字可以实现加粗：
+
+**加粗字体**
+
+对应语法：
+
+```text
+**加粗字体**
+```
+
+加粗通常用于强调：
+
+**重要步骤**
+
+**注意事项**
+
+**关键参数**
+
+------
+
+## Task 3 开始 Spark1 最小示例
+
+### 1. 创建 Project
+
+开始创建 Spark1 最小示例工程。
+
+Project 名称：
+
+```text
+01_hello
+```
+
+### 2. Project 参数选择
+
+具体选择：
+
+![image-20260817133918955](figures/image-20260817133918955.png)
+
+### 3. 编写最小示例
+
+程序代码：
+
+```c
+#include <rtthread.h>
+
+#define DBG_TAG "main"
+#define DBG_LVL DBG_LOG
+#include <rtdbg.h>
+
+int main(void)
+{
+    int count = 1;
+
+    rt_kprintf("hello RSOC2026!\n");
+
+    while (count++)
+    {
+        LOG_D("Hello RT-Thread!");
+        rt_thread_mdelay(1000);
+    }
+
+    return RT_EOK;
+}
+```
+
+### 4. 编译
+
+编译操作：
+
+```text
+点击编译按钮开始编译
+```
+
+编译结果：
+
+```text
+Build Finished. 0 errors, 0 warnings. (took 657ms)
+```
+
+### 5. 烧录
+
+烧录方式：
+
+```text
+点击下载按钮
+```
+
+烧录结果：
+
+```text
+Download in Progress:
+Progress: 100%
+File download complete
+Time elapsed during download operation: 00:00:01.683
+Hard reset is performed
+RUNNING Program ... 
+  Address:      : 0x8000000
+Application is running, Please Hold on...
+Start operation achieved successfully
+执行完毕, 耗时：1904ms.
+```
+
+### 6.连接串口
+
+连接配置：
+
+![image-20260817134312360](figures/image-20260817134312360.png)
+
+### 7. 运行结果
+
+程序烧录完成后的 Console 输出：
+
+```text
+ \ |
+ \ | /
+- RT -     Thread Operating System
+ / | \     4.1.1 build Aug 17 2026 10:47:44
+ 2006 - 2022 Copyright by RT-Thread team
+hello RSOC2026!
+```
+
+### 7. 遇到的问题
+
+问题描述：
+
+```text
+debug无法通过
+```
+
+问题原因：
+
+```text
+st-link的版本过低
+```
+
+解决方法：
+
+```text
+找到stm32官方升级程序升级st-link的版本
+```
+
+### 8. Task 3 总结
+
+通过 Spark1 最小示例，完成了从 **Project 创建 → 参数配置 → 编码 → 编译 → 烧录 → 运行** 的基本开发流程。
+
+## Git 入门
+
+本文以 **Gitee + Git Bash + Windows** 为例，记录从创建仓库、拉取代码、配置 Git、配置 SSH，到日常开发、分支管理以及最终提交 Pull Request（PR）的完整流程。
+
+示例仓库：
+
+```text
+https://gitee.com/kylehe233/rt-thread2026.git
+```
+
+SSH 地址：
+
+```text
+git@gitee.com:kylehe233/rt-thread2026.git
+```
+
+------
+
+### 1. 在 Gitee 创建仓库
+
+首先登录 Gitee，新建一个仓库，例如：
+
+```text
+rt-thread2026
+```
+
+创建完成后，可以看到两种常用的仓库地址。
+
+HTTPS：
+
+```text
+https://gitee.com/kylehe233/rt-thread2026.git
+```
+
+SSH：
+
+```text
+git@gitee.com:kylehe233/rt-thread2026.git
+```
+
+两种方式都可以用于 `clone / pull / push`。
+
+推荐后续使用 **SSH**，配置完成之后不需要频繁输入账号密码。
+
+------
+
+### 2. 将远程仓库拉取到本地
+
+进入希望存放项目的目录：
+
+```bash
+cd /d/rt_thread2026/git
+```
+
+使用 HTTPS 克隆：
+
+```bash
+git clone https://gitee.com/kylehe233/rt-thread2026.git
+```
+
+例如：
+
+```text
+28431@KyleHe MINGW64 /d/rt_thread2026/git
+$ git clone https://gitee.com/kylehe233/rt-thread2026.git
+
+Cloning into 'rt-thread2026'...
+remote: Enumerating objects: 4, done.
+remote: Counting objects: 100% (4/4), done.
+remote: Compressing objects: 100% (4/4), done.
+remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
+Receiving objects: 100% (4/4), done.
+```
+
+克隆完成后进入仓库：
+
+```bash
+cd rt-thread2026
+```
+
+也可以直接使用 SSH：
+
+```bash
+git clone git@gitee.com:kylehe233/rt-thread2026.git
+```
+
+前提是已经完成 SSH Key 配置。
+
+------
+
+### 3. 配置 Git 用户信息
+
+第一次使用 Git 时，需要配置用户名和邮箱。
+
+```bash
+git config --global user.name "kylehe233-ui"
+git config --global user.email "kylehe233@gmail.com"
+```
+
+其中：
+
+```text
+--global
+```
+
+表示该配置应用于当前电脑上的所有 Git 仓库。
+
+查看当前 Git 配置：
+
+```bash
+git config --list
+```
+
+例如：
+
+```text
+user.name=kylehe233-ui
+user.email=kylehe233@gmail.com
+```
+
+也可以分别查看：
+
+```bash
+git config user.name
+git config user.email
+```
+
+------
+
+### 4. 配置 Gitee SSH Key
+
+为了避免每次 Push 都进行 HTTPS 身份验证，可以配置 SSH。
+
+#### 4.1 生成 SSH Key
+
+执行：
+
+```bash
+ssh-keygen -t rsa -b 4096 -C "kylehe@gmail.com"
+```
+
+例如：
+
+```text
+Generating public/private rsa key pair.
+
+Enter file in which to save the key (/c/Users/28431/.ssh/id_rsa):
+Enter passphrase for "/c/Users/28431/.ssh/id_rsa" (empty for no passphrase):
+Enter same passphrase again:
+```
+
+如果不需要额外密码，可以直接连续按 Enter。
+
+生成完成：
+
+```text
+Your identification has been saved in /c/Users/28431/.ssh/id_rsa
+Your public key has been saved in /c/Users/28431/.ssh/id_rsa.pub
+```
+
+会生成两个文件：
+
+```text
+id_rsa
+id_rsa.pub
+```
+
+其中：
+
+```text
+id_rsa
+```
+
+是 **私钥**，不要发送给任何人。
+
+```text
+id_rsa.pub
+```
+
+是 **公钥**，需要添加到 Gitee。
+
+------
+
+#### 4.2 查看 SSH 公钥
+
+Git Bash 中执行：
+
+```bash
+cat ~/.ssh/id_rsa.pub
+```
+
+复制完整内容。
+
+一般类似：
+
+```text
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ... kylehe@gmail.com
+```
+
+------
+
+#### 4.3 将公钥添加到 Gitee
+
+进入：
+
+```text
+Gitee
+→ 设置
+→ SSH 公钥
+→ 添加公钥
+```
+
+将刚才 `id_rsa.pub` 中的内容粘贴进去并保存。
+
+------
+
+#### 4.4 测试 SSH
+
+执行：
+
+```bash
+ssh -T git@gitee.com
+```
+
+第一次连接可能出现：
+
+```text
+The authenticity of host 'gitee.com (...)' can't be established.
+Are you sure you want to continue connecting (yes/no/[fingerprint])?
+```
+
+输入：
+
+```text
+yes
+```
+
+如果出现：
+
+```text
+Hi kylehe233-ui(@kylehe233)! You've successfully authenticated, but GITEE.COM does not provide shell access.
+```
+
+说明：
+
+```text
+SSH 配置成功
+```
+
+其中：
+
+```text
+GITEE.COM does not provide shell access
+```
+
+不是报错，只是表示 Gitee 不提供 SSH Shell 登录。
+
+Git 的：
+
+```text
+clone
+pull
+fetch
+push
+```
+
+都可以正常使用。
+
+------
+
+### 5. Git 仓库初始化
+
+如果项目已经通过：
+
+```bash
+git clone
+```
+
+拉取下来，**不需要再执行 `git init`**。
+
+如果是一个本地已有项目，需要自己创建 Git 仓库，则进入项目目录执行：
+
+```bash
+git init
+```
+
+例如：
+
+```bash
+cd /d/rt_thread2026/my_project
+git init
+```
+
+此时当前目录会生成：
+
+```text
+.git
+```
+
+目录，表示当前文件夹已经成为 Git 仓库。
+
+------
+
+### 6. 添加远程仓库
+
+如果是通过 `git clone` 获取的项目，通常已经自动配置了：
+
+```text
+origin
+```
+
+如果是自己执行：
+
+```bash
+git init
+```
+
+创建的本地仓库，需要手动添加远程仓库：
+
+```bash
+git remote add origin git@gitee.com:kylehe233/rt-thread2026.git
+```
+
+查看远程仓库：
+
+```bash
+git remote -v
+```
+
+例如：
+
+```text
+origin  git@gitee.com:kylehe233/rt-thread2026.git (fetch)
+origin  git@gitee.com:kylehe233/rt-thread2026.git (push)
+```
+
+------
+
+### 7. 修改远程仓库 URL
+
+如果最开始使用的是 HTTPS：
+
+```text
+https://gitee.com/kylehe233/rt-thread2026.git
+```
+
+后来希望改为 SSH，可以执行：
+
+```bash
+git remote set-url origin git@gitee.com:kylehe233/rt-thread2026.git
+```
+
+再次检查：
+
+```bash
+git remote -v
+```
+
+这个命令的作用可以理解为：
+
+```text
+设置当前 Git 仓库的远程仓库地址
+```
+
+以后：
+
+```bash
+git pull
+git fetch
+git push
+```
+
+都会使用新的地址。
+
+------
+
+## Git 基本操作
+
+### 8. 查看仓库状态
+
+这是日常使用频率最高的命令之一：
+
+```bash
+git status
+```
+
+可以查看：
+
+- 哪些文件被修改
+- 哪些文件还没有加入暂存区
+- 哪些文件已经加入暂存区
+- 当前所在分支
+
+建议每次：
+
+```text
+add
+commit
+push
+```
+
+之前都可以执行一次：
+
+```bash
+git status
+```
+
+------
+
+### 9. 拉取远程代码
+
+在开始修改代码之前，建议先同步远程仓库。
+
+```bash
+git pull origin master
+```
+
+含义：
+
+```text
+从 origin 远程仓库
+拉取 master 分支
+并合并到当前本地分支
+```
+
+如果当前分支已经和远程分支建立关联，也可以直接：
+
+```bash
+git pull
+```
+
+------
+
+### 10. 添加修改到暂存区
+
+添加指定文件：
+
+```bash
+git add 文件路径
+```
+
+例如：
+
+```bash
+git add README.md
+```
+
+或者：
+
+```bash
+git add src/main.c
+```
+
+添加整个目录：
+
+```bash
+git add src/
+```
+
+添加当前目录下全部修改：
+
+```bash
+git add .
+```
+
+检查：
+
+```bash
+git status
+```
+
+------
+
+### 11. 提交修改
+
+提交到本地 Git 仓库：
+
+```bash
+git commit -m "message"
+```
+
+例如：
+
+```bash
+git commit -m "add uart driver"
+```
+
+或者：
+
+```bash
+git commit -m "fix serial configuration"
+```
+
+一个比较推荐的提交信息格式是：
+
+```text
+add: 新增功能
+fix: 修复问题
+update: 更新功能
+docs: 修改文档
+refactor: 重构代码
+test: 测试相关修改
+```
+
+例如：
+
+```bash
+git commit -m "fix: repair uart initialization"
+```
+
+------
+
+### 12. 推送到 Gitee
+
+推送当前提交到远程 `master`：
+
+```bash
+git push origin master
+```
+
+![0e2c3d99-08de-41e0-b846-3c7a02cdf538](figures/0e2c3d99-08de-41e0-b846-3c7a02cdf538.png)
+
+如果本地分支第一次推送，可以使用：
+
+```bash
+git push -u origin master
+```
+
+其中：
+
+```text
+-u
+```
+
+会建立：
+
+```text
+本地 master → origin/master
+```
+
+的跟踪关系。
+
+以后可以直接：
+
+```bash
+git push
+```
+
+------
+
+## Git 远程同步
+
+### 13. fetch 获取远程更新
+
+执行：
+
+```bash
+git fetch origin master
+```
+
+作用是：
+
+```text
+获取远程 master 分支的最新信息
+```
+
+但 **不会自动把代码合并到当前工作分支**。
+
+因此：
+
+```bash
+git fetch
+```
+
+和：
+
+```bash
+git pull
+```
+
+并不完全一样。
+
+可以简单理解为：
+
+```text
+git fetch = 下载远程更新，但暂时不合并
+git pull  = 下载远程更新 + 合并
+```
+
+实际上：
+
+```bash
+git pull
+```
+
+通常相当于：
+
+```text
+git fetch
++
+git merge
+```
+
+------
+
+### 14. 查看远程仓库
+
+执行：
+
+```bash
+git remote -v
+```
+
+用于查看当前仓库配置的远程地址。
+
+例如：
+
+```text
+origin  git@gitee.com:kylehe233/rt-thread2026.git (fetch)
+origin  git@gitee.com:kylehe233/rt-thread2026.git (push)
+```
+
+其中：
+
+```text
+origin
+```
+
+只是远程仓库的默认名字。
+
+------
+
+## Git 分支
+
+### 15. 查看当前分支
+
+执行：
+
+```bash
+git branch
+```
+
+例如：
+
+```text
+* master
+```
+
+`*` 表示当前所在分支。
+
+查看所有本地和远程分支：
+
+```bash
+git branch -a
+```
+
+------
+
+### 16. 创建新的开发分支
+
+例如需要创建：
+
+```text
+test
+```
+
+分支。
+
+执行：
+
+```bash
+git checkout -b test
+```
+
+![image-20260817153038429](figures/image-20260817153038429.png)
+
+这个命令相当于：
+
+```bash
+git branch test
+git checkout test
+```
+
+即：
+
+```text
+创建 test 分支
++
+切换到 test 分支
+```
+
+再次查看：
+
+```bash
+git branch
+```
+
+应该看到：
+
+```text
+master
+* test
+```
+
+------
+
+### 17. 切换分支
+
+切换回：
+
+```text
+master
+```
+
+执行：
+
+```bash
+git checkout master
+```
+
+切换到：
+
+```text
+test
+```
+
+执行：
+
+```bash
+git checkout test
+```
+
+新版 Git 也可以使用：
+
+```bash
+git switch master
+```
+
+以及：
+
+```bash
+git switch test
+```
+
+创建并切换：
+
+```bash
+git switch -c test
+```
+
+------
+
+## 推荐的实际开发流程
+
+假设：
+
+```text
+master = 稳定主分支
+test   = 开发测试分支
+```
+
+开发时不要直接在：
+
+```text
+master
+```
+
+中大量修改代码。
+
+推荐：
+
+```text
+master
+   │
+   └── test
+         │
+         ├── 修改代码
+         ├── commit
+         ├── push
+         │
+         └── PR
+               │
+               ▼
+             master
+```
+
+------
+
+### 18. 第一次创建 test 分支
+
+首先确保当前 `master` 是最新状态：
+
+```bash
+git checkout master
+```
+
+然后：
+
+```bash
+git pull origin master
+```
+
+创建：
+
+```text
+test
+```
+
+分支：
+
+```bash
+git checkout -b test
+```
+
+将 `test` 推送到 Gitee：
+
+```bash
+git push -u origin test
+```
+
+此时 Gitee 上就会同时存在：
+
+```text
+master
+test
+```
+
+两个分支。
+
+------
+
+### 19. 在 test 分支开发
+
+确认当前分支：
+
+```bash
+git branch
+```
+
+应该显示：
+
+```text
+master
+* test
+```
+
+然后正常修改代码。
+
+查看修改：
+
+```bash
+git status
+```
+
+加入暂存区：
+
+```bash
+git add .
+```
+
+提交：
+
+```bash
+git commit -m "add: implement new feature"
+```
+
+上传到远程 `test`：
+
+```bash
+git push origin test
+```
+
+![2e9a5471-cfdf-4477-bdc8-cc09204a69db](figures/2e9a5471-cfdf-4477-bdc8-cc09204a69db.png)
+
+如果已经建立 upstream：
+
+```bash
+git push
+```
+
+即可。
+
+------
+
+## Gitee PR 流程
+
+### 20. 将 test 合并到 master
+
+当：
+
+```text
+test
+```
+
+分支中的代码已经开发、编译、测试完成之后，不建议直接在本地强行修改 `master`。
+
+推荐通过 Gitee：
+
+```text
+Pull Request
+```
+
+进行合并。
+
+完整关系：
+
+```text
+test
+  │
+  │ push
+  ▼
+origin/test
+  │
+  │ Pull Request
+  ▼
+origin/master
+```
+
+------
+
+### 21. 创建 Pull Request
+
+首先确保最新代码已经提交：
+
+```bash
+git status
+```
+
+然后：
+
+```bash
+git add .
+```
+
+提交：
+
+```bash
+git commit -m "test: complete feature validation"
+```
+
+推送：
+
+```bash
+git push origin test
+```
+
+然后进入 Gitee 仓库页面。
+
+进入：
+
+```text
+Pull Requests
+```
+
+创建新的 Pull Request。
+
+选择：
+
+```text
+源分支：test
+
+目标分支：master
+```
+
+也就是：
+
+```text
+test
+  ↓
+master
+```
+
+填写 PR 标题，例如：
+
+```text
+Merge test branch into master
+```
+
+![image-20260817153225643](figures/image-20260817153225643.png)
+
+PR 描述可以说明：
+
+```text
+1. 新增了哪些功能
+2. 修改了哪些文件
+3. 修复了哪些问题
+4. 是否已经编译通过
+5. 是否已经在开发板上测试
+```
+
+确认无误后创建 Pull Request。
+
+------
+
+### 22. 检查并合并 PR
+
+在 Gitee 上检查：
+
+```text
+代码差异
+提交记录
+文件修改
+是否存在冲突
+```
+
+确认代码没有问题后：
+
+```text
+Merge
+```
+
+将：
+
+```text
+test
+```
+
+合并到：
+
+```text
+master
+```
+
+最终：
+
+```text
+test
+   │
+   │ Pull Request
+   ▼
+master
+```
+
+合并完成。
+
+------
+
+### 23. PR 合并后同步本地 master
+
+Gitee 上完成合并之后，本地的：
+
+```text
+master
+```
+
+并不会自动更新。
+
+首先切换：
+
+```bash
+git checkout master
+```
+
+然后：
+
+```bash
+git pull origin master
+```
+
+此时本地：
+
+```text
+master
+```
+
+就和 Gitee 上最新的：
+
+```text
+master
+```
+
+保持一致。
+
+------
+
+### 24. 继续下一轮开发
+
+如果继续使用：
+
+```text
+test
+```
+
+分支进行开发，建议先让它同步最新的：
+
+```text
+master
+```
+
+切换到：
+
+```bash
+git checkout test
+```
+
+然后：
+
+```bash
+git merge master
+```
+
+此时：
+
+```text
+test
+```
+
+就包含最新：
+
+```text
+master
+```
+
+代码。
+
+之后继续开发：
+
+```bash
+git add .
+git commit -m "add: next feature"
+git push origin test
+```
+
+开发完成后再次：
+
+```text
+test → PR → master
+```
+
+------
+
+## 常用 Git 命令速查
+
+| 作用           | 命令                                                      |
+| -------------- | --------------------------------------------------------- |
+| 初始化仓库     | `git init`                                                |
+| HTTPS 克隆仓库 | `git clone https://gitee.com/kylehe233/rt-thread2026.git` |
+| SSH 克隆仓库   | `git clone git@gitee.com:kylehe233/rt-thread2026.git`     |
+| 查看状态       | `git status`                                              |
+| 查看分支       | `git branch`                                              |
+| 查看所有分支   | `git branch -a`                                           |
+| 创建并切换分支 | `git checkout -b test`                                    |
+| 切换分支       | `git checkout test`                                       |
+| 拉取远程代码   | `git pull origin master`                                  |
+| 获取远程信息   | `git fetch origin master`                                 |
+| 添加单个文件   | `git add file`                                            |
+| 添加所有修改   | `git add .`                                               |
+| 提交修改       | `git commit -m "message"`                                 |
+| 推送 master    | `git push origin master`                                  |
+| 推送 test      | `git push origin test`                                    |
+| 查看远程仓库   | `git remote -v`                                           |
+| 添加远程仓库   | `git remote add origin URL`                               |
+| 修改远程 URL   | `git remote set-url origin URL`                           |
+| 测试 Gitee SSH | `ssh -T git@gitee.com`                                    |
+| 查看提交历史   | `git log`                                                 |
+| 简洁查看提交   | `git log --oneline`                                       |
+| 查看代码修改   | `git diff`                                                |
+
+------
+
+## 日常开发最简流程
+
+如果当前已经在：
+
+```text
+test
+```
+
+分支开发，一般每天最常用的就是：
+
+```bash
+git pull
+```
+
+修改代码后：
+
+```bash
+git status
+```
+
+然后：
+
+```bash
+git add .
+```
+
+提交：
+
+```bash
+git commit -m "fix: description"
+```
+
+最后：
+
+```bash
+git push
+```
+
+也就是：
+
+```text
+拉取最新代码
+    ↓
+修改代码
+    ↓
+git status
+    ↓
+git add .
+    ↓
+git commit
+    ↓
+git push
+```
+
+------
+
+## 一个完整示例
+
+第一次获取项目：
+
+```bash
+git clone git@gitee.com:kylehe233/rt-thread2026.git
+```
+
+进入项目：
+
+```bash
+cd rt-thread2026
+```
+
+拉取最新主分支：
+
+```bash
+git checkout master
+git pull origin master
+```
+
+创建测试分支：
+
+```bash
+git checkout -b test
+```
+
+上传分支：
+
+```bash
+git push -u origin test
+```
+
+开发完成：
+
+```bash
+git status
+git add .
+git commit -m "add: complete uart demo"
+git push origin test
+```
+
+然后在 Gitee：
+
+```text
+test
+→ Pull Request
+→ master
+→ Merge
+```
+
+PR 合并完成之后：
+
+```bash
+git checkout master
+git pull origin master
+```
+
+此时整个开发闭环完成。
+
+## RT-Thread 的启动流程
+
+RT-Thread 的启动过程主要完成 **硬件初始化、内核初始化、系统线程创建、组件初始化以及用户 `main()` 函数运行** 等工作。
+
+![rtt_startup](notes/figures/rtt_startup.png)
+
+根据不同的编译器，程序从启动文件 `startup_xx.S` 进入 RT-Thread 的方式有所不同：
+
+```text
+startup_xx.S
+    │
+    ├── MDK  → $Sub$$main()
+    ├── IAR  → __low_level_init()
+    └── GCC  → entry()
+                │
+                ↓
+        rtthread_startup()
+```
+
+虽然不同编译器的入口函数不同，但最终都会进入：
+
+```c
+rtthread_startup();
+```
+
+`rtthread_startup()` 是 RT-Thread 系统启动的核心函数，负责依次完成 RT-Thread 内核和相关组件的初始化。
+
+### 1. 关闭中断
+
+系统首先执行：
+
+```c
+rt_hw_interrupt_disable();
+```
+
+在系统初始化完成之前暂时关闭中断，避免初始化过程中被外部中断打断，从而保证启动过程能够按照预定顺序执行。
+
+启动流程：
+
+```text
+rtthread_startup()
+        ↓
+rt_hw_interrupt_disable()
+```
+
+------
+
+### 2. 板级硬件初始化
+
+随后执行：
+
+```c
+rt_hw_board_init();
+```
+
+该函数主要用于完成与开发板硬件相关的初始化，例如：
+
+- 系统时钟初始化
+- SysTick 初始化
+- UART 初始化
+- GPIO 初始化
+- Heap 初始化
+- 其他 BSP 相关硬件初始化
+
+在 `rt_hw_board_init()` 过程中，还会调用：
+
+```c
+rt_components_board_init();
+```
+
+用于执行注册到 **Board Init** 阶段的初始化函数。
+
+流程可以表示为：
+
+```text
+rt_hw_board_init()
+        │
+        └── rt_components_board_init()
+                    │
+                    └── board init functions
+```
+
+因此，这一阶段的主要作用就是为 RT-Thread 内核运行准备最基本的硬件环境。
+
+------
+
+### 3. 显示 RT-Thread 版本信息
+
+硬件初始化完成后执行：
+
+```c
+rt_show_version();
+```
+
+该函数会通过 Console 输出 RT-Thread 的版本以及系统启动 Logo。
+
+例如：
+
+```text
+ \ | /
+- RT -     Thread Operating System
+ / | \
+```
+
+如果能够在串口终端看到这些信息，说明 RT-Thread 已经完成了部分基础初始化，并且 Console 可以正常工作。
+
+------
+
+### 4. 初始化系统定时器
+
+接下来执行：
+
+```c
+rt_system_timer_init();
+```
+
+用于初始化 RT-Thread 的系统定时器管理模块。
+
+RT-Thread 中的定时器可以用于实现：
+
+- 软件定时
+- 周期任务
+- 超时处理
+- 延时操作
+
+此时主要完成定时器相关数据结构的初始化。
+
+------
+
+### 5. 初始化系统调度器
+
+随后执行：
+
+```c
+rt_system_scheduler_init();
+```
+
+该函数用于初始化 RT-Thread 的线程调度系统。
+
+调度器负责管理系统中不同线程的运行状态，并根据线程的：
+
+- 优先级
+- 就绪状态
+- 时间片
+
+决定 CPU 当前应该执行哪个线程。
+
+可以将其理解为 RTOS 的核心功能之一。
+
+------
+
+### 6. 初始化 Signal 系统
+
+接下来执行：
+
+```c
+rt_system_signal_init();
+```
+
+用于初始化 RT-Thread 的线程信号机制。
+
+Signal 可以用于线程之间的异步通知和事件处理。
+
+如果当前 RT-Thread 配置没有启用 Signal 功能，则这一部分可能不会被编译进入最终程序。
+
+------
+
+### 7. 创建 Main 线程
+
+系统继续执行：
+
+```c
+rt_application_init();
+```
+
+该函数会创建 RT-Thread 中非常重要的 **Main Thread**。
+
+内部会通过类似下面的方式初始化线程：
+
+```c
+rt_thread_init(main_thread_entry);
+```
+
+因此：
+
+```text
+rt_application_init()
+        │
+        └── rt_thread_init(main_thread_entry)
+```
+
+需要注意，此时只是完成 Main Thread 的**创建和初始化**，并不意味着 `main_thread_entry()` 已经立即开始运行。
+
+线程真正运行需要等到后面的调度器启动。
+
+------
+
+### 8. 创建 Timer 线程
+
+随后执行：
+
+```c
+rt_system_timer_thread_init();
+```
+
+用于创建系统软件定时器线程：
+
+```c
+rt_thread_init(rt_thread_timer_entry);
+```
+
+流程为：
+
+```text
+rt_system_timer_thread_init()
+        │
+        └── rt_thread_init(rt_thread_timer_entry)
+```
+
+该线程主要负责处理软件定时器相关任务。
+
+------
+
+### 9. 创建 Idle 线程
+
+接下来执行：
+
+```c
+rt_thread_idle_init();
+```
+
+创建 RT-Thread 的空闲线程：
+
+```c
+rt_thread_init(rt_thread_idle_entry);
+```
+
+流程为：
+
+```text
+rt_thread_idle_init()
+        │
+        └── rt_thread_init(rt_thread_idle_entry)
+```
+
+Idle Thread 是系统中优先级最低的线程。
+
+当没有其他线程需要运行时，CPU 会运行 Idle Thread。
+
+Idle Thread 还可以用于完成一些系统后台工作，例如：
+
+- 线程资源回收
+- CPU 空闲处理
+- 低功耗处理
+
+------
+
+### 10. 启动线程调度器
+
+所有基础初始化和系统线程创建完成后，执行：
+
+```c
+rt_system_scheduler_start();
+```
+
+此时 RT-Thread 正式启动线程调度。
+
+```text
+rt_system_scheduler_start()
+              │
+              ↓
+        根据调度规则执行
+              │
+       ┌──────┼────────────┐
+       ↓      ↓            ↓
+main_thread  timer_thread  idle_thread
+       │
+       └── 其他线程
+```
+
+从这一刻开始，程序不再按照普通裸机程序单一的顺序执行，而是由 RT-Thread 调度器根据线程优先级和运行状态决定 CPU 执行哪个线程。
+
+------
+
+### 11. Main Thread 运行
+
+调度器启动后，Main Thread 会执行：
+
+```c
+main_thread_entry();
+```
+
+`main_thread_entry()` 中一个非常重要的工作就是调用：
+
+```c
+rt_components_init();
+```
+
+用于初始化 RT-Thread 的各种组件。
+
+流程为：
+
+```text
+main_thread_entry()
+        │
+        ↓
+rt_components_init()
+```
+
+`rt_components_init()` 会按照规定的初始化顺序依次执行不同阶段的自动初始化函数，例如：
+
+```text
+rt_components_init()
+        │
+        ├── pre-initialization functions
+        │
+        ├── device init functions
+        │
+        ├── components init functions
+        │
+        ├── environment init functions
+        │
+        └── applications init functions
+```
+
+也就是说，通过 RT-Thread 自动初始化机制注册的设备、组件和应用，会在这一阶段被依次初始化。
+
+------
+
+### 12. 进入用户 main() 函数
+
+组件初始化完成后，最终进入用户编写的：
+
+```c
+main();
+```
+
+以 MDK 为例，图中通过：
+
+```c
+$Super$$main();
+```
+
+进入原始的 `main()` 函数。
+
+因此可以简化理解为：
+
+```text
+main_thread_entry()
+        │
+        ├── rt_components_init()
+        │
+        └── main()
+```
+
+我们平时在：
+
+```c
+int main(void)
+{
+    /* 用户程序 */
+
+    return 0;
+}
+```
+
+中编写的代码，实际上已经是在 **RT-Thread Main Thread 中运行**。
+
+------
+
+### 13. RT-Thread 完整启动流程
+
+整个启动过程可以总结为：
+
+```text
+startup_xx.S
+     ↓
+编译器入口
+     ↓
+rtthread_startup()
+     ↓
+rt_hw_interrupt_disable()
+     ↓
+rt_hw_board_init()
+     │
+     └── rt_components_board_init()
+     ↓
+rt_show_version()
+     ↓
+rt_system_timer_init()
+     ↓
+rt_system_scheduler_init()
+     ↓
+rt_system_signal_init()
+     ↓
+rt_application_init()
+     │
+     └── 创建 Main Thread
+     ↓
+rt_system_timer_thread_init()
+     │
+     └── 创建 Timer Thread
+     ↓
+rt_thread_idle_init()
+     │
+     └── 创建 Idle Thread
+     ↓
+rt_system_scheduler_start()
+     ↓
+启动线程调度
+     ↓
+main_thread_entry()
+     ↓
+rt_components_init()
+     ↓
+各种组件自动初始化
+     ↓
+main()
+     ↓
+执行用户程序
+```
+
+因此，可以将 RT-Thread 的启动过程概括为：
+
+**启动文件 → RT-Thread 启动函数 → 硬件初始化 → 内核初始化 → 创建系统线程 → 启动调度器 → 组件初始化 → 进入 `main()` 用户程序。**
+
+其中最重要的几个函数可以重点记忆：
+
+| 函数                            | 作用                     |
+| ------------------------------- | ------------------------ |
+| `rtthread_startup()`            | RT-Thread 系统启动入口   |
+| `rt_hw_board_init()`            | 开发板硬件初始化         |
+| `rt_components_board_init()`    | Board 阶段组件初始化     |
+| `rt_system_timer_init()`        | 系统定时器初始化         |
+| `rt_system_scheduler_init()`    | 调度器初始化             |
+| `rt_application_init()`         | 创建 Main Thread         |
+| `rt_system_timer_thread_init()` | 创建 Timer Thread        |
+| `rt_thread_idle_init()`         | 创建 Idle Thread         |
+| `rt_system_scheduler_start()`   | 启动线程调度             |
+| `main_thread_entry()`           | Main Thread 入口         |
+| `rt_components_init()`          | RT-Thread 组件自动初始化 |
+| `main()`                        | 用户程序入口             |
\ No newline at end of file
-- 
Gitee


From a963748af0f81d1ec458091c45953fcc09aa47d7 Mon Sep 17 00:00:00 2001
From: kylehe233-ui <kylehe233@gmail.com>
Date: Tue, 18 Aug 2026 11:09:29 +0800
Subject: [PATCH 3/7] day1 commit

---
 "2026/\347\254\2543\347\273\204/README.md" | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 "2026/\347\254\2543\347\273\204/README.md"

diff --git "a/2026/\347\254\2543\347\273\204/README.md" "b/2026/\347\254\2543\347\273\204/README.md"
deleted file mode 100644
index 655bbb2..0000000
--- "a/2026/\347\254\2543\347\273\204/README.md"
+++ /dev/null
@@ -1 +0,0 @@
-# 第3组
\ No newline at end of file
-- 
Gitee


From d620c7418cbc5d1a8bb4c21e52d2dfb2f80c9226 Mon Sep 17 00:00:00 2001
From: kylehe233-ui <kylehe233@gmail.com>
Date: Wed, 19 Aug 2026 02:57:51 +0800
Subject: [PATCH 4/7] day2

---
 .../\344\275\234\344\270\232/README.md"       | 1090 +++++++++++++++++
 .../\344\275\234\344\270\232/thread_study.c"  |  418 +++++++
 2 files changed, 1508 insertions(+)
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/README.md"
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/thread_study.c"

diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/README.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/README.md"
new file mode 100644
index 0000000..4b56ab5
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/README.md"
@@ -0,0 +1,1090 @@
+# Day2：RT-Thread 内核基础与多线程编程
+
+## Part 1：理论知识总结
+
+### 1. STM32F407 启动流程与 RT-Thread 引导机制
+
+#### 1.1 STM32F407 与 RT-Thread 启动流程
+
+STM32F407 上电或复位后，并不会直接执行用户编写的 `main()`，而是先完成 MCU 启动、C 运行环境初始化以及 RT-Thread 内核初始化。
+
+整体启动流程如下：
+
+```text
+STM32F407 上电 / 复位
+        ↓
+读取中断向量表                  // 获取初始 MSP 和 Reset_Handler 地址
+        ↓
+设置 MSP                       // 设置 Cortex-M4 主栈指针
+        ↓
+Reset_Handler                  // 进入复位处理函数
+        ↓
+SystemInit()                   // 完成 MCU 基础系统初始化
+        ↓
+初始化 .data / .bss           // 建立 C 语言运行环境
+        ↓
+rtthread_startup()             // 进入 RT-Thread 启动流程
+        ↓
+rt_hw_interrupt_disable()      // 暂时关闭中断
+        ↓
+rt_hw_board_init()             // 初始化板级硬件
+        ↓
+rt_system_timer_init()         // 初始化系统定时器
+        ↓
+rt_system_scheduler_init()     // 初始化线程调度器
+        ↓
+rt_application_init()          // 创建 main 线程
+        ↓
+rt_thread_idle_init()          // 创建 idle 空闲线程
+        ↓
+rt_system_scheduler_start()    // 启动线程调度器
+        ↓
+main_thread_entry()            // main 线程入口
+        ↓
+rt_components_init()           // 执行组件自动初始化
+        ↓
+INIT_APP_EXPORT() 注册函数      // 执行 APP 级自动初始化函数
+        ↓
+main()                         // 进入用户程序
+```
+
+其中，`Reset_Handler` 是 MCU 复位后的软件入口。启动阶段会完成 `.data` 数据复制和 `.bss` 清零，为后续 C 程序建立正确的运行环境。
+
+RT-Thread 启动后通过 `rt_application_init()` 创建 Main Thread，再由调度器调度 `main_thread_entry()`，最终执行用户编写的 `main()`。因此，RT-Thread 中的 `main()` 实际运行在线程环境中。
+
+------
+
+#### 1.2 Main Thread 与 Idle Thread
+
+RT-Thread 启动过程中会自动创建多个系统线程，其中比较重要的是 Main Thread 和 Idle Thread。
+
+Main Thread 用于执行用户程序：
+
+```text
+rtthread_startup()
+        ↓
+rt_application_init()
+        ↓
+创建 Main Thread
+        ↓
+启动调度器
+        ↓
+main_thread_entry()
+        ↓
+main()
+```
+
+Idle Thread 是系统中优先级最低的线程，当没有其他就绪线程时运行。
+
+```text
+没有其他 READY 线程
+        ↓
+Idle Thread
+```
+
+Idle Thread 还可用于线程资源回收、空闲 Hook 和低功耗处理等后台任务。
+
+------
+
+#### 1.3 RT-Thread 自动初始化机制
+
+RT-Thread 提供：
+
+```c
+INIT_BOARD_EXPORT()
+INIT_APP_EXPORT()
+```
+
+等自动初始化宏，使模块可以在系统启动过程中自动执行，而不需要在 `main()` 中手动调用。
+
+其基本原理可以概括为：
+
+```text
+初始化函数
+        ↓
+INIT_BOARD_EXPORT(fn)
+或 INIT_APP_EXPORT(fn)
+        ↓
+INIT_EXPORT(fn, level)
+        ↓
+生成初始化函数指针
+        ↓
+放入指定 .rti_fn.x section
+        ↓
+链接器将同一级函数组织起来
+        ↓
+系统启动
+        ↓
+遍历初始化函数表
+        ↓
+依次执行初始化函数
+```
+
+`INIT_BOARD_EXPORT()` 与 `INIT_APP_EXPORT()` 的实现原理基本相同，主要区别在于初始化级别和执行时机不同。
+
+| 宏                    | 初始化阶段               | 典型用途           |
+| --------------------- | ------------------------ | ------------------ |
+| `INIT_BOARD_EXPORT()` | Board 级初始化阶段       | 板级硬件、底层驱动 |
+| `INIT_APP_EXPORT()`   | Application 级初始化阶段 | 用户应用、业务线程 |
+
+例如：
+
+```c
+static int thread_study_init(void)
+{
+    /* 创建应用线程 */
+    return 0;
+}
+
+INIT_APP_EXPORT(thread_study_init);
+```
+
+系统运行到组件初始化阶段时，会自动调用 `thread_study_init()`，因此无需在 `main()` 中再次手动调用。
+
+这种机制可以降低不同模块与 `main()` 之间的耦合，提高代码的模块化程度。
+
+------
+
+### 2. RT-Thread 内核基础与对象模型
+
+#### 2.1 RT-Thread 对象模型
+
+RT-Thread 使用 C 语言实现，但内核中采用了类似面向对象的设计思想。
+
+线程、信号量、互斥量、事件、定时器和设备等都可以作为 RT-Thread 内核对象进行统一管理。
+
+```text
+                RT-Thread Object
+                       │
+        ┌──────────────┼──────────────┐
+        │              │              │
+      Thread        Semaphore       Timer
+```
+
+线程对象基于：
+
+```c
+struct rt_thread
+```
+
+进行描述，而 `struct rt_thread` 又包含 RT-Thread 基础对象相关信息。
+
+因此可以将线程控制块理解为 RT-Thread 为每一个线程建立的一份“线程档案”。
+
+------
+
+#### 2.2 线程控制块 TCB
+
+线程控制块 TCB（Thread Control Block）用于保存线程的各种运行信息。
+
+RT-Thread 中通过：
+
+```c
+struct rt_thread
+```
+
+定义线程控制块。
+
+其中包含：
+
+```text
+线程名称
+线程状态
+线程优先级
+线程入口函数
+线程栈
+时间片
+线程错误码
+调度相关信息
+定时器
+用户数据
+```
+
+一个线程可以简单理解为：
+
+```text
+Thread
+ │
+ ├── 线程入口函数
+ ├── 线程栈
+ └── TCB
+      ├── stat
+      ├── current_priority
+      ├── init_tick
+      ├── sp
+      └── 其他线程信息
+```
+
+作业中需要重点理解以下成员：
+
+| 成员               | 作用                                         |
+| ------------------ | -------------------------------------------- |
+| `stat`             | 保存线程当前运行状态                         |
+| `current_priority` | 保存线程当前优先级                           |
+| `init_tick`        | 保存线程初始化时设置的时间片                 |
+| `sp`               | 保存线程当前栈指针，用于线程上下文保存与恢复 |
+
+------
+
+#### 2.3 线程栈
+
+每个线程都有自己独立的线程栈。
+
+线程栈主要用于保存：
+
+- CPU 上下文
+- 函数局部变量
+- 函数调用信息
+- 寄存器现场
+- 函数返回地址
+
+线程切换时，可以简单理解为：
+
+```text
+线程 A RUNNING
+      ↓
+保存 A 的上下文到线程 A 栈
+      ↓
+加载线程 B 栈中的上下文
+      ↓
+线程 B RUNNING
+```
+
+因此线程栈是实现线程上下文切换的重要基础。
+
+如果栈空间设置过小，可能导致 Stack Overflow，因此创建线程时需要根据函数调用深度和局部变量大小合理设置线程栈。
+
+------
+
+#### 2.4 静态线程与动态线程
+
+RT-Thread 主要支持两种线程创建方式：
+
+```text
+线程
+ │
+ ├── 静态线程
+ └── 动态线程
+```
+
+两者最主要的区别是线程控制块和线程栈的内存来源不同。
+
+##### 静态线程
+
+静态线程的 TCB 和线程栈由程序提前定义：
+
+```c
+static struct rt_thread thread;
+
+static rt_uint8_t thread_stack[1024];
+```
+
+然后使用：
+
+```c
+rt_thread_init();
+```
+
+进行初始化。
+
+##### 动态线程
+
+动态线程使用：
+
+```c
+rt_thread_create();
+```
+
+创建，由系统从动态内存中申请线程控制块和线程栈。
+
+两种方式对比如下：
+
+| 对比项         | 动态线程             | 静态线程           |
+| -------------- | -------------------- | ------------------ |
+| API            | `rt_thread_create()` | `rt_thread_init()` |
+| TCB            | 系统动态分配         | 用户提前定义       |
+| 线程栈         | 系统动态分配         | 用户提前定义       |
+| 内存来源       | Heap                 | 静态存储区         |
+| 灵活性         | 较高                 | 相对较低           |
+| 资源确定性     | 较低                 | 较高               |
+| 运行时动态申请 | 需要                 | 不需要             |
+
+动态线程更加灵活，但依赖运行时动态内存，可能受到 Heap 空间不足和内存碎片的影响。
+
+静态线程的 TCB 和栈空间在程序运行前基本已经确定，因此：
+
+```text
+内存大小确定
+内存位置确定
+资源占用确定
+运行行为更加可预测
+```
+
+所以在工业控制、汽车电子以及对可靠性和实时确定性要求较高的系统中，通常更加倾向使用静态线程。
+
+------
+
+### 3. 线程状态机与调度算法
+
+#### 3.1 RT-Thread 线程五态模型
+
+RT-Thread 中线程主要存在以下五种状态：
+
+| 状态   | 宏定义              | 含义                         |
+| ------ | ------------------- | ---------------------------- |
+| 初始态 | `RT_THREAD_INIT`    | 线程已经创建，但还未参与调度 |
+| 就绪态 | `RT_THREAD_READY`   | 已具备运行条件，等待 CPU     |
+| 运行态 | `RT_THREAD_RUNNING` | 当前正在 CPU 上执行          |
+| 挂起态 | `RT_THREAD_SUSPEND` | 暂时不能运行，不参与正常调度 |
+| 关闭态 | `RT_THREAD_CLOSE`   | 线程生命周期已经结束         |
+
+线程状态变化可以表示为：
+
+```text
+                    rt_thread_startup()
+        INIT  ----------------------------> READY
+                                               │
+                                               │ Scheduler
+                                               ↓
+                                           RUNNING
+                                           /      \
+                                          /        \
+                 delay / suspend / IPC   /          \ 线程结束
+                                        ↓            ↓
+                                    SUSPEND        CLOSE
+                                        │
+                                        │ resume
+                                        │ timeout
+                                        │ 条件满足
+                                        ↓
+                                      READY
+```
+
+需要注意：
+
+**READY 并不代表线程正在运行。**
+
+READY 只表示线程已经满足运行条件，仍需等待调度器分配 CPU。
+
+------
+
+#### 3.2 常用线程状态转换 API
+
+| API / 事件            | 典型状态变化      | 作用             |
+| --------------------- | ----------------- | ---------------- |
+| `rt_thread_create()`  | → INIT            | 动态创建线程     |
+| `rt_thread_init()`    | → INIT            | 静态初始化线程   |
+| `rt_thread_startup()` | INIT → READY      | 启动线程         |
+| 调度器 Scheduler      | READY → RUNNING   | 分配 CPU         |
+| `rt_thread_suspend()` | RUNNING → SUSPEND | 挂起线程         |
+| `rt_thread_resume()`  | SUSPEND → READY   | 恢复线程         |
+| `rt_thread_mdelay()`  | RUNNING → SUSPEND | 当前线程主动延时 |
+| Timeout               | SUSPEND → READY   | 延时结束         |
+| 线程结束              | → CLOSE           | 结束线程生命周期 |
+
+其中：
+
+```c
+rt_thread_mdelay(ms);
+```
+
+不仅表示延时，同时还会使当前线程暂时退出调度。
+
+```text
+RUNNING
+   ↓
+rt_thread_mdelay()
+   ↓
+SUSPEND
+   ↓
+延时到期
+   ↓
+READY
+```
+
+这使 CPU 可以在当前线程等待期间运行其他线程。
+
+------
+
+#### 3.3 线程优先级
+
+RT-Thread 根据线程优先级决定线程被调度的先后顺序。
+
+规则为：
+
+```text
+优先级数字越小
+        ↓
+实际线程优先级越高
+```
+
+例如：
+
+```text
+Thread A：priority = 10
+Thread B：priority = 20
+```
+
+当 A 和 B 同时处于 READY 状态时：
+
+```text
+Thread A
+```
+
+优先获得 CPU。
+
+------
+
+#### 3.4 抢占式调度
+
+RT-Thread 支持基于优先级的抢占式调度。
+
+如果当前正在运行一个低优先级线程，而此时一个更高优先级线程进入 READY：
+
+```text
+低优先级线程 RUNNING
+        ↓
+高优先级线程 READY
+        ↓
+调度器比较优先级
+        ↓
+高优先级线程抢占
+        ↓
+高优先级线程 RUNNING
+```
+
+例如本实验线程配置：
+
+```text
+th_monitor = priority 10
+
+th_led1    = priority 16
+th_led2    = priority 16
+```
+
+因此 `th_monitor` 在延时结束重新进入 READY 后，其优先级高于两个 LED 工作线程，可以优先获得 CPU。
+
+这种机制能够保证更重要、更紧急的线程及时得到响应。
+
+------
+
+#### 3.5 时间片轮转
+
+当多个线程具有相同优先级时，RT-Thread 可以使用时间片轮转机制让这些线程轮流使用 CPU。
+
+例如：
+
+```text
+Thread A
+priority = 16
+time slice = 5 ticks
+
+Thread B
+priority = 16
+time slice = 5 ticks
+```
+
+在两个线程持续处于可运行状态时，可以按照时间片进行轮转：
+
+```text
+Thread A
+运行一个时间片
+      ↓
+Thread B
+运行一个时间片
+      ↓
+Thread A
+      ↓
+...
+```
+
+时间片单位为：
+
+```text
+Tick
+```
+
+其实际时间长度由系统 Tick 频率决定。
+
+例如系统配置为：
+
+```text
+RT_TICK_PER_SECOND = 1000
+```
+
+则：
+
+```text
+1 tick = 1 ms
+```
+
+但如果 Tick 频率不同，实际时间也会发生变化，因此不能简单认为：
+
+```text
+1 tick 永远等于 1 ms
+```
+
+需要根据实际系统配置确定。
+
+------
+
+#### 3.6 抢占、时间片和主动阻塞的区别
+
+线程切换可能由不同原因产生。
+
+```text
+1. 高优先级线程进入 READY
+        ↓
+   抢占式调度
+
+2. 同优先级线程时间片耗尽
+        ↓
+   时间片轮转
+
+3. 当前线程调用 delay / 等待 IPC
+        ↓
+   主动阻塞，让出 CPU
+```
+
+例如：
+
+```c
+rt_thread_mdelay(500);
+```
+
+会使当前线程主动进入挂起状态。
+
+这种线程切换与“时间片耗尽”不是同一个概念。
+
+因此在多线程实验中，如果线程主动调用 `rt_thread_mdelay()`，看到线程交替运行时不能简单认为一定是时间片轮转造成的。
+
+------
+
+### 4. Part 1 小结
+
+RT-Thread 启动后会完成板级初始化、内核初始化、系统线程创建以及调度器启动，最终由 Main Thread 执行用户 `main()`。
+
+RT-Thread 使用统一的对象模型管理线程等内核对象，线程的运行信息保存在 `struct rt_thread` 线程控制块中，其中状态、优先级、时间片和栈指针是线程调度的重要依据。
+
+线程可以通过动态方式和静态方式创建。动态线程使用方便、灵活，但依赖运行时动态内存；静态线程资源提前分配，确定性和可预测性更高。
+
+RT-Thread 线程在 INIT、READY、RUNNING、SUSPEND 和 CLOSE 五种状态之间转换。调度器首先根据线程优先级进行抢占式调度，对于相同优先级的线程则可以使用时间片轮转机制共享 CPU。
+
+这些机制共同构成了 RT-Thread 多线程运行和实时调度的基础。
+
+---
+
+## Part 2：多线程实战实验报告
+
+### 1. 实验目的
+
+本实验基于 STM32F407 星火 1 号开发板和 RT-Thread，实现动态线程、静态线程和监控线程，学习线程的创建、运行、挂起、恢复以及线程状态监控方法。
+
+实验主要完成以下功能：
+
+- 动态创建 `th_led1`，控制红色 LED 周期翻转，并打印运行计数和系统 Tick。
+- 静态初始化 `th_led2`，控制蓝色 LED 周期翻转，并打印运行计数。
+- 动态创建高优先级监控线程 `th_monitor`，周期查看两个工作线程的运行状态和剩余栈空间。
+- 使用 KEY0 控制 `th_led1` 的挂起与恢复。
+- 使用 `INIT_APP_EXPORT()` 自动加载实验模块。
+- 使用 `MSH_CMD_EXPORT()` 导出 `thread_dump` 调试命令。
+
+---
+
+### 2. 实验环境
+
+- 开发板：STM32F407 星火 1 号
+- 操作系统：RT-Thread
+- 红色 LED：PF12
+- 蓝色 LED：PF11
+- KEY0：PC0
+- GPIO 引脚定义头文件：
+
+```c
+#include "drv_common.h"
+```
+
+板载 LED 为低电平点亮：
+
+```text
+PIN_LOW  -> LED 点亮
+PIN_HIGH -> LED 熄灭
+```
+
+---
+
+### 3. 线程设计
+
+本实验共创建 3 个线程：
+
+| 线程名称     | 创建方式   | 优先级 |     栈大小 |  时间片 | 功能                           |
+| ------------ | ---------- | -----: | ---------: | ------: | ------------------------------ |
+| `th_led1`    | 动态创建   |     16 | 1024 Bytes | 5 ticks | 翻转 LED_R，打印计数和 Tick    |
+| `th_led2`    | 静态初始化 |     16 | 1024 Bytes | 5 ticks | 翻转 LED_B，打印计数           |
+| `th_monitor` | 动态创建   |     10 | 1024 Bytes | 5 ticks | 按键检测、线程状态及栈空间监控 |
+
+其中：
+
+```text
+th_monitor priority = 10
+th_led1    priority = 16
+th_led2    priority = 16
+```
+
+RT-Thread 中优先级数字越小，实际优先级越高，因此 `th_monitor` 的优先级高于两个 LED 工作线程。
+
+---
+
+### 4. 自动初始化实验
+
+实验模块通过：
+
+```c
+INIT_APP_EXPORT(thread_study_init);
+```
+
+注册为 APP 级自动初始化函数，没有在 `main()` 中手动调用。
+
+系统启动后的实际输出：
+
+```text
+thread_study_init success!
+th_led1 create success!
+th_led2 init success!
+th_monitor create success!
+```
+
+结果表明：
+
+- `INIT_APP_EXPORT()` 自动初始化成功。
+- `th_led1` 动态创建成功。
+- `th_led2` 静态初始化成功。
+- `th_monitor` 动态创建成功。
+
+---
+
+### 5. 动态线程 th_led1 实验
+
+`th_led1` 使用：
+
+```c
+rt_thread_create()
+```
+
+动态创建，参数为：
+
+```text
+栈大小：1024 Bytes
+优先级：16
+时间片：5 ticks
+```
+
+线程循环翻转红色 LED，并通过：
+
+```c
+rt_tick_get()
+```
+
+读取当前系统 Tick。
+
+部分实际串口数据：
+
+```text
+[th_led1] count = 1, tick = 7
+[th_led1] count = 2, tick = 510
+[th_led1] count = 3, tick = 1013
+[th_led1] count = 4, tick = 1516
+[th_led1] count = 5, tick = 2019
+[th_led1] count = 6, tick = 2522
+```
+
+相邻 Tick 差值：
+
+```text
+510  - 7    = 503 ticks
+1013 - 510  = 503 ticks
+1516 - 1013 = 503 ticks
+```
+
+线程中设置：
+
+```c
+rt_thread_mdelay(500);
+```
+
+实际运行中相邻输出约相差 503 ticks，与设置的 500 ms 周期基本一致。多出的少量 Tick 主要来自 LED 操作、串口打印和线程调度等程序执行时间。
+
+实验过程中红色 LED 能够持续周期翻转，`count` 和 Tick 均持续增加，说明动态线程运行正常。
+
+---
+
+### 6. 静态线程 th_led2 实验
+
+`th_led2` 使用静态方式初始化：
+
+```c
+static struct rt_thread th_led2;
+static rt_uint8_t th_led2_stack[1024];
+```
+
+通过：
+
+```c
+rt_thread_init()
+```
+
+完成线程初始化。
+
+运行时实际输出：
+
+```text
+[th_led2] count = 1
+[th_led1] count = 1, tick = 11
+
+[th_led2] count = 2
+[th_led1] count = 2, tick = 514
+
+[th_led2] count = 3
+[th_led1] count = 3, tick = 1017
+
+[th_led2] count = 4
+[th_led1] count = 4, tick = 1520
+```
+
+两个线程均能够持续运行，红色 LED 和蓝色 LED 均正常周期翻转。
+
+`th_led1` 和 `th_led2` 的优先级均为 16，时间片均设置为 5 ticks。
+
+需要注意的是，两个线程内部都调用了：
+
+```c
+rt_thread_mdelay(500);
+```
+
+因此当前实验中两个线程的交替运行主要包含主动延时让出 CPU 的影响，不能仅通过当前串口输出直接证明 5 ticks 时间片轮转。
+
+---
+
+### 7. th_monitor 线程实验
+
+`th_monitor` 使用动态方式创建：
+
+```text
+优先级：10
+栈大小：1024 Bytes
+时间片：5 ticks
+```
+
+监控线程周期获取 `th_led1` 和 `th_led2` 的：
+
+- 当前线程状态
+- 剩余栈空间
+
+实际输出：
+
+```text
+----- thread monitor -----
+th_led1: state=SUSPEND, stack_free=788 Bytes
+th_led2: state=SUSPEND, stack_free=792 Bytes
+--------------------------
+```
+
+运行一段时间后：
+
+```text
+----- thread monitor -----
+th_led1: state=SUSPEND, stack_free=780 Bytes
+th_led2: state=SUSPEND, stack_free=776 Bytes
+--------------------------
+```
+
+后续剩余栈空间基本稳定在：
+
+```text
+th_led1：约 780 Bytes
+th_led2：约 776 Bytes
+```
+
+说明两个线程当前 1024 Bytes 的栈空间均具有较充足余量。
+
+两个 LED 线程在监控时经常显示：
+
+```text
+SUSPEND
+```
+
+这是因为两个工作线程均周期执行：
+
+```c
+rt_thread_mdelay(500);
+```
+
+线程在延时期间会暂时处于挂起状态，因此该现象属于正常运行结果。
+
+---
+
+### 8. KEY0 挂起与恢复实验
+
+KEY0 用于控制 `th_led1` 的运行状态。
+
+第一次按键后实际输出：
+
+![image-20260819024604667](figures/image-20260819024604667.png)
+
+```text
+[th_led1] count = 12, tick = 5551
+[KEY] request th_led1 suspend
+[th_led1] suspend self
+[th_led2] count = 13
+```
+
+随后只有 `th_led2` 继续运行：
+
+```text
+[th_led2] count = 14
+[th_led2] count = 15
+[th_led2] count = 16
+[th_led2] count = 17
+```
+
+监控线程显示：
+
+```text
+----- thread monitor -----
+th_led1: state=SUSPEND, stack_free=780 Bytes
+th_led2: state=SUSPEND, stack_free=776 Bytes
+--------------------------
+```
+
+此时 `th_led1` 的计数停止在：
+
+```text
+count = 12
+```
+
+说明 `th_led1` 已成功挂起，而 `th_led2` 不受影响，继续正常运行。
+
+再次按下 KEY0 后：
+
+![image-20260819024732173](figures/image-20260819024732173.png)
+
+```text
+[KEY] th_led1 resume request
+[th_led1] resumed
+[th_led1] count = 13, tick = 10298
+```
+
+随后：
+
+```text
+[th_led1] count = 14, tick = 10802
+[th_led1] count = 15, tick = 11305
+[th_led1] count = 16, tick = 11808
+```
+
+可以看到挂起前：
+
+```text
+count = 12
+```
+
+恢复后：
+
+```text
+count = 13
+```
+
+线程从原有执行位置继续运行，而不是重新开始计数。
+
+该实验验证了：
+
+```text
+RUNNING
+   ↓
+rt_thread_suspend()
+   ↓
+SUSPEND
+
+SUSPEND
+   ↓
+rt_thread_resume()
+   ↓
+READY
+   ↓
+Scheduler
+   ↓
+RUNNING
+```
+
+---
+
+### 9. MSH 自定义命令实验
+
+使用：
+
+```c
+MSH_CMD_EXPORT(thread_dump, show thread status and stack usage);
+```
+
+将 `thread_dump` 导出为 MSH 命令。
+
+在 FinSH/MSH 中执行：
+
+```text
+msh > thread_dump
+```
+
+实际运行结果：
+
+![image-20260819024513682](figures/image-20260819024513682.png)
+
+```text
+========== thread dump ==========
+th_led1:
+  state      : SUSPEND
+  priority   : 16
+  stack free : 780 Bytes
+
+th_led2:
+  state      : SUSPEND
+  priority   : 16
+  stack free : 776 Bytes
+=================================
+```
+
+结果表明 `thread_dump` 命令能够正常执行，并正确读取：
+
+- 线程状态
+- 当前优先级
+- 剩余栈空间
+
+说明 `MSH_CMD_EXPORT()` 导出功能正常。
+
+---
+
+### 10. 实验中出现的问题及解决方法
+
+#### 10.1 `GET_PIN` 未定义
+
+首次编译时出现：
+
+```text
+warning: implicit declaration of function 'GET_PIN'
+error: 'F' undeclared
+```
+
+原因是当前 BSP 中 `GET_PIN` 宏对应的头文件没有包含。
+
+解决方法：
+
+```c
+#include "drv_common.h"
+```
+
+加入后重新编译，GPIO 引脚宏可以正常使用。
+
+---
+
+#### 10.2 `rt_thread_suspend()` 触发断言
+
+最初尝试在 `th_monitor` 中直接执行：
+
+```c
+rt_thread_suspend(th_led1);
+```
+
+运行时出现：
+
+```text
+(thread == rt_thread_self()) assertion failed
+at function: rt_thread_suspend
+```
+
+当前工程所使用的 RT-Thread 实现要求线程通过 `rt_thread_suspend()` 挂起自身。
+
+解决方法：
+
+按键线程只设置暂停标志：
+
+```text
+KEY0
+ ↓
+设置暂停请求
+```
+
+随后由 `th_led1` 自身执行：
+
+```c
+rt_thread_suspend(rt_thread_self());
+rt_schedule();
+```
+
+恢复时由监控线程执行：
+
+```c
+rt_thread_resume(th_led1);
+```
+
+修改后挂起和恢复功能运行正常。
+
+---
+
+#### 10.3 多线程串口打印出现交叉
+
+运行过程中出现过：
+
+```text
+[th_led1] count = 5, tick[th_led2] count = 5
+ = 2026
+```
+
+以及：
+
+```text
+0th_led1] count = 15, tick = 706[th_led2] count = 15
+```
+
+这是因为多个线程同时使用：
+
+```c
+rt_kprintf()
+```
+
+输出数据，线程切换过程中不同线程的串口字符串发生交叉。
+
+该问题不会影响线程本身的正常运行。
+
+实验中通过观察完整周期输出以及 `thread_dump` 独立结果判断线程状态。
+
+---
+
+### 11. 实验结果分析
+
+本实验成功实现了一个动态工作线程、一个静态工作线程以及一个高优先级监控线程。
+
+`th_led1` 使用 `rt_thread_create()` 动态创建，其 TCB 和线程栈由系统动态分配；`th_led2` 使用 `rt_thread_init()` 静态初始化，其 TCB 和 1024 Bytes 栈空间由程序提前定义，两种线程均能够正常运行。
+
+两个 LED 工作线程优先级均为 16，监控线程优先级为 10，因此监控线程具有更高调度优先级。监控线程可以周期读取两个工作线程的状态和剩余栈空间。
+
+KEY0 实验中，`th_led1` 挂起后计数停止，而 `th_led2` 继续运行；恢复后 `th_led1` 从原有计数继续执行，验证了线程挂起、恢复以及上下文保持过程。
+
+通过 `thread_dump` 命令可以在 MSH 中手动读取线程状态、优先级和栈空间，验证了 RT-Thread Shell 命令导出机制。
+
+---
+
+### 12. 实验结论
+
+本实验完成了 RT-Thread 多线程编程的主要功能：
+
+- 动态线程创建与启动
+- 静态线程初始化与启动
+- 多线程并发运行
+- 高优先级监控线程
+- 线程状态监控
+- 线程剩余栈空间检测
+- 按键控制线程挂起和恢复
+- `INIT_APP_EXPORT()` 自动初始化
+- `MSH_CMD_EXPORT()` 自定义 Shell 命令
+
+通过实际运行结果，对 RT-Thread 的线程创建方式、线程状态变化、优先级调度和线程控制机制有了进一步理解。
+
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/thread_study.c" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/thread_study.c"
new file mode 100644
index 0000000..30d5d0c
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/thread_study.c"
@@ -0,0 +1,418 @@
+/*
+ * @file    thread_study.c
+ * @author  Kyle He
+ * @date    2026-08-19
+ * @brief   RT-Thread Day2 multithread study
+ */
+
+#include <rtthread.h>
+#include <rtdevice.h>
+#include "drv_common.h"
+
+/* ==================== 硬件引脚定义 ==================== */
+
+/* 星火 1 号红色 LED：PF12，低电平点亮 */
+#define PIN_LED_R    GET_PIN(F, 12)
+
+/* 星火 1 号蓝色 LED：PF11，低电平点亮 */
+#define PIN_LED_B    GET_PIN(F, 11)
+
+/* 星火 1 号按键 KEY0：PC0，按下为低电平 */
+#define PIN_KEY0     GET_PIN(C, 0)
+
+
+/* ==================== th_led1：动态线程 ==================== */
+
+/* 动态线程句柄 */
+static rt_thread_t th_led1 = RT_NULL;
+
+/* LED1 手动挂起标志 */
+static volatile rt_bool_t led1_suspended = RT_FALSE;
+
+
+/* LED1 线程入口 */
+static void led1_entry(void *parameter)
+{
+    rt_uint32_t count = 0;
+    rt_uint8_t led_state = PIN_HIGH;
+
+    /* 配置红色 LED 为输出模式 */
+    rt_pin_mode(PIN_LED_R, PIN_MODE_OUTPUT);
+
+    /* 默认关闭红色 LED */
+    rt_pin_write(PIN_LED_R, PIN_HIGH);
+
+    while (1)
+    {
+        /*
+         * 检查挂起请求
+         * 当前线程主动挂起自身
+         */
+        if (led1_suspended == RT_TRUE)
+        {
+            rt_kprintf("[th_led1] suspend self\n");
+
+            /* RUNNING -> SUSPEND */
+            rt_thread_suspend(rt_thread_self());
+
+            /* 主动触发调度 */
+            rt_schedule();
+
+            /* 被 resume 后从这里继续运行 */
+            rt_kprintf("[th_led1] resumed\n");
+        }
+
+        /* 翻转红色 LED */
+        led_state = !led_state;
+        rt_pin_write(PIN_LED_R, led_state);
+
+        count++;
+
+        /* 输出计数与系统 Tick */
+        rt_kprintf("[th_led1] count = %d, tick = %d\n",
+                   count,
+                   rt_tick_get());
+
+        /* 主动延时 500 ms */
+        rt_thread_mdelay(500);
+    }
+}
+
+
+/* ==================== th_led2：静态线程 ==================== */
+
+/* 静态线程控制块 */
+static struct rt_thread th_led2;
+
+/* 静态线程栈：1024 Bytes */
+static rt_uint8_t th_led2_stack[1024];
+
+
+/* LED2 线程入口 */
+static void led2_entry(void *parameter)
+{
+    rt_uint32_t count = 0;
+    rt_uint8_t led_state = PIN_HIGH;
+
+    /* 配置蓝色 LED 为输出模式 */
+    rt_pin_mode(PIN_LED_B, PIN_MODE_OUTPUT);
+
+    /* 默认关闭蓝色 LED */
+    rt_pin_write(PIN_LED_B, PIN_HIGH);
+
+    while (1)
+    {
+        /* 翻转蓝色 LED */
+        led_state = !led_state;
+        rt_pin_write(PIN_LED_B, led_state);
+
+        count++;
+
+        /* 输出执行次数 */
+        rt_kprintf("[th_led2] count = %d\n", count);
+
+        /* 主动延时 500 ms */
+        rt_thread_mdelay(500);
+    }
+}
+
+
+/* ==================== 线程状态工具函数 ==================== */
+
+/* 将线程状态转换为字符串 */
+static const char *thread_state_str(rt_thread_t thread)
+{
+    rt_uint8_t state;
+
+    state = thread->stat & RT_THREAD_STAT_MASK;
+
+    switch (state)
+    {
+    case RT_THREAD_INIT:
+        return "INIT";
+
+    case RT_THREAD_READY:
+        return "READY";
+
+    case RT_THREAD_RUNNING:
+        return "RUNNING";
+
+    case RT_THREAD_SUSPEND:
+        return "SUSPEND";
+
+    case RT_THREAD_CLOSE:
+        return "CLOSE";
+
+    default:
+        return "UNKNOWN";
+    }
+}
+
+
+/*
+ * 估算线程剩余栈空间
+ * RT-Thread 初始化线程栈时通常使用 0x23 ('#') 填充
+ */
+static rt_uint32_t thread_stack_free(rt_thread_t thread)
+{
+    rt_uint8_t *ptr;
+    rt_uint32_t free_size = 0;
+
+    ptr = (rt_uint8_t *)thread->stack_addr;
+
+    while ((free_size < thread->stack_size) &&
+           (*ptr == '#'))
+    {
+        ptr++;
+        free_size++;
+    }
+
+    return free_size;
+}
+
+
+/* ==================== KEY0 按键检测 ==================== */
+
+static void key_scan(void)
+{
+    /* 检测按键按下 */
+    if (rt_pin_read(PIN_KEY0) == PIN_LOW)
+    {
+        /* 软件消抖 */
+        rt_thread_mdelay(50);
+
+        if (rt_pin_read(PIN_KEY0) == PIN_LOW)
+        {
+            if (led1_suspended == RT_FALSE)
+            {
+                /*
+                 * 第一次按键：
+                 * 请求 th_led1 挂起自身
+                 */
+                led1_suspended = RT_TRUE;
+
+                rt_kprintf("[KEY] request th_led1 suspend\n");
+            }
+            else
+            {
+                /*
+                 * 第二次按键：
+                 * 恢复 th_led1
+                 */
+                led1_suspended = RT_FALSE;
+
+                /* SUSPEND -> READY */
+                rt_thread_resume(th_led1);
+
+                rt_kprintf("[KEY] th_led1 resume request\n");
+
+                /* 重新调度 */
+                rt_schedule();
+            }
+
+            /*
+             * 等待按键释放
+             * 防止长按被识别为多次触发
+             */
+            while (rt_pin_read(PIN_KEY0) == PIN_LOW)
+            {
+                rt_thread_mdelay(10);
+            }
+        }
+    }
+}
+
+
+/* ==================== th_monitor：监控线程 ==================== */
+
+/* 动态监控线程句柄 */
+static rt_thread_t th_monitor = RT_NULL;
+
+
+/* monitor 线程入口 */
+static void monitor_entry(void *parameter)
+{
+    rt_tick_t last_monitor_tick;
+
+    last_monitor_tick = rt_tick_get();
+
+    while (1)
+    {
+        /* 高频扫描按键 */
+        key_scan();
+
+        /* 每 2 秒打印一次线程状态 */
+        if ((rt_tick_get() - last_monitor_tick) >=
+            rt_tick_from_millisecond(2000))
+        {
+            last_monitor_tick = rt_tick_get();
+
+            rt_kprintf("\n");
+            rt_kprintf("----- thread monitor -----\n");
+
+            rt_kprintf("th_led1: state=%s, stack_free=%d Bytes\n",
+                       thread_state_str(th_led1),
+                       thread_stack_free(th_led1));
+
+            rt_kprintf("th_led2: state=%s, stack_free=%d Bytes\n",
+                       thread_state_str(&th_led2),
+                       thread_stack_free(&th_led2));
+
+            rt_kprintf("--------------------------\n");
+        }
+
+        /* monitor 扫描周期约 10 ms */
+        rt_thread_mdelay(10);
+    }
+}
+
+
+/* ==================== MSH 命令 ==================== */
+
+/*
+ * thread_dump
+ * 手动查看工作线程状态、优先级和剩余栈
+ */
+static void thread_dump(void)
+{
+    rt_kprintf("\n");
+    rt_kprintf("========== thread dump ==========\n");
+
+    rt_kprintf("th_led1:\n");
+    rt_kprintf("  state      : %s\n",
+               thread_state_str(th_led1));
+    rt_kprintf("  priority   : %d\n",
+               th_led1->current_priority);
+    rt_kprintf("  stack free : %d Bytes\n",
+               thread_stack_free(th_led1));
+
+    rt_kprintf("\n");
+
+    rt_kprintf("th_led2:\n");
+    rt_kprintf("  state      : %s\n",
+               thread_state_str(&th_led2));
+    rt_kprintf("  priority   : %d\n",
+               th_led2.current_priority);
+    rt_kprintf("  stack free : %d Bytes\n",
+               thread_stack_free(&th_led2));
+
+    rt_kprintf("=================================\n");
+}
+
+
+/* 导出 MSH 命令 */
+MSH_CMD_EXPORT(thread_dump, show thread status and stack usage);
+
+
+/* ==================== 模块初始化 ==================== */
+
+static int thread_study_init(void)
+{
+    rt_err_t result;
+
+    rt_kprintf("thread_study_init success!\n");
+
+
+    /* ---------- 初始化 KEY0 ---------- */
+
+    /* KEY0 上拉输入，按下为低电平 */
+    rt_pin_mode(PIN_KEY0, PIN_MODE_INPUT_PULLUP);
+
+
+    /* ---------- 动态创建 th_led1 ---------- */
+
+    /*
+     * th_led1
+     * 栈大小：1024 Bytes
+     * 优先级：16
+     * 时间片：5 ticks
+     */
+    th_led1 = rt_thread_create("th_led1",
+                               led1_entry,
+                               RT_NULL,
+                               1024,
+                               16,
+                               5);
+
+    if (th_led1 != RT_NULL)
+    {
+        /* INIT -> READY */
+        rt_thread_startup(th_led1);
+
+        rt_kprintf("th_led1 create success!\n");
+    }
+    else
+    {
+        rt_kprintf("th_led1 create failed!\n");
+    }
+
+
+    /* ---------- 静态初始化 th_led2 ---------- */
+
+    /*
+     * th_led2
+     * 静态 TCB
+     * 静态栈：1024 Bytes
+     * 优先级：16
+     * 时间片：5 ticks
+     */
+    result = rt_thread_init(&th_led2,
+                            "th_led2",
+                            led2_entry,
+                            RT_NULL,
+                            th_led2_stack,
+                            sizeof(th_led2_stack),
+                            16,
+                            5);
+
+    if (result == RT_EOK)
+    {
+        /* INIT -> READY */
+        rt_thread_startup(&th_led2);
+
+        rt_kprintf("th_led2 init success!\n");
+    }
+    else
+    {
+        rt_kprintf("th_led2 init failed!\n");
+    }
+
+
+    /* ---------- 动态创建 th_monitor ---------- */
+
+    /*
+     * th_monitor
+     * 栈大小：1024 Bytes
+     * 优先级：10
+     * 时间片：5 ticks
+     *
+     * 优先级 10 高于两个 LED 线程的 16
+     */
+    th_monitor = rt_thread_create("th_monitor",
+                                  monitor_entry,
+                                  RT_NULL,
+                                  1024,
+                                  10,
+                                  5);
+
+    if (th_monitor != RT_NULL)
+    {
+        /* INIT -> READY */
+        rt_thread_startup(th_monitor);
+
+        rt_kprintf("th_monitor create success!\n");
+    }
+    else
+    {
+        rt_kprintf("th_monitor create failed!\n");
+    }
+
+
+    return 0;
+}
+
+
+/*
+ * 自动初始化
+ */
+INIT_APP_EXPORT(thread_study_init);
-- 
Gitee


From a37130fb79450e5ac649105a1739548b304218c0 Mon Sep 17 00:00:00 2001
From: kylehe233-ui <kylehe233@gmail.com>
Date: Wed, 19 Aug 2026 02:59:19 +0800
Subject: [PATCH 5/7] day2 notes commit

---
 ...46\344\271\240\347\254\224\350\256\260.md" | 1590 +++++++++++++++++
 1 file changed, 1590 insertions(+)
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\272\214\345\244\251\345\255\246\344\271\240\347\254\224\350\256\260.md"

diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\272\214\345\244\251\345\255\246\344\271\240\347\254\224\350\256\260.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\272\214\345\244\251\345\255\246\344\271\240\347\254\224\350\256\260.md"
new file mode 100644
index 0000000..02733fb
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\272\214\345\244\251\345\255\246\344\271\240\347\254\224\350\256\260.md"
@@ -0,0 +1,1590 @@
+# Day 2
+
+## Day 2 总结
+
+Day 2 主要学习了 RT-Thread 中两个重要内容：
+
+```text
+Day 2
+ │
+ ├── Thread
+ │
+ │    ├── 线程控制块
+ │    ├── 线程栈
+ │    ├── 线程状态
+ │    ├── 优先级
+ │    ├── 时间片
+ │    ├── 线程入口函数
+ │    ├── Main Thread
+ │    ├── Idle Thread
+ │    ├── rt_thread_init()
+ │    ├── rt_thread_create()
+ │    ├── rt_thread_startup()
+ │    └── rt_thread_mdelay()
+ │
+ └── SCons
+      ├── SConstruct
+      ├── SConscript
+      ├── DefineGroup()
+      ├── scons
+      ├── scons -c
+      ├── menuconfig
+      ├── pkgs --update
+      └── scons --target=mdk5
+```
+
+其中线程部分最核心的是理解：
+
+**RT-Thread 通过调度器管理多个线程，线程依靠优先级、状态和时间片决定何时获得 CPU。**
+
+SCons 部分最核心的是理解：
+
+**SCons 根据 RT-Thread 的配置和 SConscript 脚本决定哪些源码参与工程构建，并能够自动编译或生成 MDK/IAR 工程。**
+
+---
+
+## RT-Thread 的启动流程
+
+RT-Thread 的完整启动流程已经在 Day 1 中进行了整理。
+
+具体内容见：
+
+**Day 1 → RT-Thread 的启动流程**
+
+主要流程可以简单回顾为：
+
+```text
+启动文件
+    ↓
+rtthread_startup()
+    ↓
+硬件初始化
+    ↓
+内核初始化
+    ↓
+创建系统线程
+    ↓
+启动调度器
+    ↓
+main_thread_entry()
+    ↓
+rt_components_init()
+    ↓
+main()
+```
+
+本节不再重复展开，详细内容见 Day 1 笔记。
+
+---
+
+## 从裸机到多线程系统
+
+在学习线程之前，首先需要理解为什么嵌入式系统需要 RTOS。
+
+传统裸机程序通常采用 **前后台系统** 的方式运行。
+
+后台程序一般是一个无限循环：
+
+```c
+int main(void)
+{
+    init();
+
+    while (1)
+    {
+        ADC_Read();
+        SPI_Read();
+        USB_Packet();
+        LCD_Update();
+        Audio_Decode();
+        File_Write();
+    }
+}
+```
+
+前台则主要由各种中断服务程序组成，例如：
+
+```c
+void USB_ISR(void)
+{
+    Clear_Interrupt();
+    Read_Packet();
+}
+```
+
+这种结构比较简单，但是随着系统功能增加，会逐渐暴露出一些问题：
+
+- 并发工作效率较低
+- 系统实时性难以保证
+- 代码之间耦合严重
+- 系统维护困难
+- 模块化程度较低
+- 软件复用能力较差
+
+因此，在复杂嵌入式系统中，可以使用 RTOS 将整个系统拆分成多个相对独立的任务。
+
+RT-Thread 中，任务的执行实体就是：
+
+**线程（Thread）**
+
+可以将复杂系统理解为：
+
+```text
+复杂系统
+    ↓
+拆分任务
+    ↓
+任务 1 → 线程 1
+任务 2 → 线程 2
+任务 3 → 线程 3
+任务 4 → 线程 4
+```
+
+这种方式体现了“**分而治之**”的思想。
+
+---
+
+## RTOS 的多任务机制
+
+RTOS 的一个核心特点就是：
+
+**多任务运行。**
+
+例如，一个系统中可能同时存在：
+
+```text
+线程 1：采集传感器数据
+
+线程 2：更新 LCD
+
+线程 3：串口通信
+
+线程 4：处理网络数据
+```
+
+从用户角度来看，这些任务似乎是在“同时运行”。
+
+但是对于单核 MCU 来说，CPU 在某一个瞬间实际上只能执行一个线程。
+
+RTOS 通过快速切换线程，使多个线程轮流占用 CPU：
+
+```text
+时间 →
+
+线程1  ███
+          线程2 ███
+                   线程1 ███
+                            线程3 ███
+```
+
+由于 CPU 的执行速度非常快，因此从人的观察角度来看，这些线程就像是在并行运行。
+
+RT-Thread 的调度器负责决定：
+
+**当前 CPU 应该运行哪个线程。**
+
+---
+
+## 线程控制块
+
+RT-Thread 内核需要保存每个线程的相关信息。
+
+这些信息存放在线程控制块中。
+
+线程控制块由：
+
+```c
+struct rt_thread
+```
+
+定义。
+
+线程控制块可以理解为 RT-Thread 内核为每个线程建立的一份“线程档案”。
+
+其中会保存：
+
+- 线程名称
+- 线程状态
+- 线程优先级
+- 线程入口函数
+- 线程栈地址
+- 线程栈大小
+- 时间片
+- 线程错误码
+- 线程相关链表
+- 定时器
+- 用户数据等
+
+RT-Thread 内核通过线程控制块对所有线程进行管理。
+
+可以简单理解为：
+
+```text
+线程
+ │
+ └── struct rt_thread
+          │
+          ├── 线程名称
+          ├── 线程状态
+          ├── 优先级
+          ├── 时间片
+          ├── 线程栈
+          ├── 入口函数
+          └── 其他信息
+```
+
+`struct rt_thread` 继承自 RT-Thread 的基础对象：
+
+```c
+struct rt_object
+```
+
+因此线程本身也是 RT-Thread 的一种内核对象。
+
+---
+
+## 线程属性
+
+一个线程需要多个属性才能被操作系统正确管理。
+
+比较重要的属性包括：
+
+```text
+线程
+ │
+ ├── 线程栈
+ ├── 状态
+ ├── 优先级
+ ├── 时间片
+ └── 入口函数
+```
+
+下面分别进行说明。
+
+---
+
+## 线程栈
+
+RT-Thread 中的每个线程都有自己独立的线程栈。
+
+线程栈主要用于保存：
+
+- CPU 上下文
+- 函数局部变量
+- 函数调用信息
+- 寄存器信息
+
+当线程发生切换时，RT-Thread 会将当前线程的运行现场保存在线程栈中。
+
+当线程重新获得 CPU 后，再从线程栈中恢复运行现场。
+
+因此可以将线程切换理解为：
+
+```text
+线程 A 正在运行
+      ↓
+保存线程 A 上下文到线程 A 栈
+      ↓
+加载线程 B 栈中的上下文
+      ↓
+线程 B 继续运行
+```
+
+这也是 RTOS 能够让多个线程交替运行的重要基础。
+
+线程栈还会存储函数中的局部变量。
+
+因此，线程栈设置得太小可能会导致：
+
+```text
+Stack Overflow
+```
+
+即栈溢出。
+
+所以创建线程时需要根据线程中函数调用的复杂程度合理设置栈大小。
+
+---
+
+## 线程状态
+
+RT-Thread 中线程主要存在以下几种状态：
+
+| 状态 | 宏定义 | 含义 |
+| ---- | ---- | ---- |
+| 初始状态 | `RT_THREAD_INIT` | 线程刚创建完成，还没有开始运行 |
+| 就绪状态 | `RT_THREAD_READY` | 线程已经可以运行，正在等待 CPU |
+| 运行状态 | `RT_THREAD_RUNNING` | 当前正在 CPU 上运行 |
+| 挂起状态 | `RT_THREAD_SUSPEND` | 暂时不能运行，不参与调度 |
+| 关闭状态 | `RT_THREAD_CLOSE` | 线程已经结束 |
+
+线程创建完成后首先处于：
+
+```text
+INIT
+```
+
+调用启动函数后进入：
+
+```text
+READY
+```
+
+当调度器选择该线程运行时：
+
+```text
+READY
+ ↓
+RUNNING
+```
+
+如果线程主动延时或者等待某个资源：
+
+```text
+RUNNING
+ ↓
+SUSPEND
+```
+
+等待条件满足后：
+
+```text
+SUSPEND
+ ↓
+READY
+```
+
+线程执行结束后：
+
+```text
+RUNNING
+ ↓
+CLOSE
+```
+
+因此线程的基本状态变化可以表示为：
+
+```text
+        创建
+         ↓
+       INIT
+         ↓
+      startup
+         ↓
+       READY
+         ↓
+      调度器
+         ↓
+      RUNNING
+       ↙    ↘
+  SUSPEND   CLOSE
+     ↓
+   READY
+```
+
+需要特别注意：
+
+**就绪状态并不代表线程当前正在执行。**
+
+就绪状态只表示：
+
+> 线程已经具备运行条件，正在等待调度器分配 CPU。
+
+---
+
+## 线程优先级
+
+RT-Thread 使用线程优先级决定线程被调度的优先程度。
+
+规则非常重要：
+
+**优先级数字越小，线程优先级越高。**
+
+例如：
+
+```text
+优先级 5   → 高
+
+优先级 10  → 中
+
+优先级 20  → 低
+```
+
+如果系统配置支持 256 个优先级，则优先级范围为：
+
+```text
+0 ~ 255
+```
+
+其中：
+
+```text
+0
+```
+
+表示最高优先级。
+
+例如：
+
+```text
+线程 A：priority = 10
+
+线程 B：priority = 20
+```
+
+如果 A 和 B 同时处于 READY 状态，则：
+
+```text
+线程 A
+```
+
+会优先运行。
+
+如果当前正在运行线程 B，此时线程 A 突然进入 READY：
+
+```text
+线程 B：priority = 20
+        ↓
+线程 A READY：priority = 10
+        ↓
+线程 A 优先级更高
+        ↓
+抢占线程 B
+        ↓
+线程 A RUNNING
+```
+
+这种机制称为：
+
+**抢占式调度。**
+
+---
+
+## 线程时间片
+
+每个线程在创建时还可以设置时间片：
+
+```text
+tick
+```
+
+时间片的单位为：
+
+**操作系统时钟节拍 OSTick。**
+
+需要注意：
+
+**时间片主要用于相同优先级线程之间的调度。**
+
+例如：
+
+```text
+线程 A
+priority = 10
+tick = 10
+
+线程 B
+priority = 10
+tick = 5
+```
+
+由于 A 和 B 的优先级相同，所以系统会采用时间片轮转的方式运行：
+
+```text
+A 运行 10 tick
+      ↓
+B 运行 5 tick
+      ↓
+A 运行 10 tick
+      ↓
+B 运行 5 tick
+      ↓
+...
+```
+
+可以简单理解为：
+
+```text
+优先级不同
+    ↓
+优先级决定谁先运行
+
+优先级相同
+    ↓
+时间片决定轮流运行时间
+```
+
+---
+
+## 线程入口函数
+
+线程实际执行的功能由线程入口函数实现。
+
+线程入口函数的基本格式为：
+
+```c
+void thread_entry(void *parameter)
+{
+}
+```
+
+标准形式：
+
+```c
+void (*entry)(void *parameter)
+```
+
+一个常见线程可以写成：
+
+```c
+static void thread1_entry(void *parameter)
+{
+    rt_uint32_t count = 0;
+
+    while (1)
+    {
+        rt_kprintf("thread1 count: %d\n", count++);
+
+        rt_thread_mdelay(500);
+    }
+}
+```
+
+其中：
+
+```c
+rt_thread_mdelay(500);
+```
+
+表示线程延时 500 ms。
+
+线程入口函数中通常需要存在让出 CPU 的操作。
+
+例如：
+
+```c
+rt_thread_mdelay();
+```
+
+否则，如果一个高优先级线程一直：
+
+```c
+while (1)
+{
+}
+```
+
+并且从不主动阻塞或让出 CPU，那么低优先级线程可能一直无法获得运行机会。
+
+因此：
+
+```text
+线程执行任务
+    ↓
+完成本次处理
+    ↓
+delay / wait
+    ↓
+让出 CPU
+    ↓
+其他线程运行
+```
+
+是多线程程序中常见的执行方式。
+
+---
+
+## 系统线程
+
+RT-Thread 在启动过程中会自动创建一些系统线程。
+
+其中比较重要的是：
+
+- 主线程
+- 空闲线程
+- 定时器线程
+
+---
+
+## 主线程 Main Thread
+
+RT-Thread 中：
+
+```c
+main()
+```
+
+本身运行在一个线程中。
+
+这个线程称为：
+
+**Main Thread（主线程）**
+
+系统启动时会创建 main 线程，其入口函数为：
+
+```c
+main_thread_entry()
+```
+
+运行流程为：
+
+```text
+rtthread_startup()
+        ↓
+rt_application_init()
+        ↓
+创建 Main Thread
+        ↓
+启动调度器
+        ↓
+main_thread_entry()
+        ↓
+main()
+```
+
+也就是说，我们编写：
+
+```c
+int main(void)
+{
+    rt_kprintf("hello world!\n");
+
+    return 0;
+}
+```
+
+实际上这些代码是在 Main Thread 中执行的。
+
+---
+
+## 空闲线程 Idle Thread
+
+空闲线程是 RT-Thread 中优先级最低的线程。
+
+当系统中没有其他就绪线程时：
+
+```text
+没有其他 READY Thread
+          ↓
+      Idle Thread
+```
+
+空闲线程的特点：
+
+- 优先级最低
+- 系统始终存在
+- 通常一直保持 READY
+- 不能被挂起
+- 通常内部是一个无限循环
+
+空闲线程还有一些特殊作用。
+
+### 回收线程资源
+
+动态线程运行结束后，并不会立刻完成全部资源回收。
+
+线程结束后会进入：
+
+```text
+rt_thread_defunct
+```
+
+僵尸线程队列。
+
+之后由 Idle Thread 回收这些线程占用的资源。
+
+### 执行 Idle Hook
+
+RT-Thread 允许给空闲线程设置 Hook 函数。
+
+因此可以在 Idle Thread 中完成：
+
+- 功耗管理
+- 看门狗喂狗
+- CPU 空闲处理
+
+等后台工作。
+
+---
+
+## 线程管理 API
+
+RT-Thread 提供两种主要方式创建线程：
+
+```text
+线程
+ │
+ ├── 静态线程
+ │
+ └── 动态线程
+```
+
+两种方式最大的区别在于：
+
+**线程控制块和线程栈由谁分配。**
+
+---
+
+## 静态线程
+
+静态线程的：
+
+- 线程控制块
+- 线程栈
+
+由用户自己定义。
+
+一般设置为：
+
+```c
+static struct rt_thread thread1;
+
+static rt_uint8_t thread1_stack[1024];
+```
+
+静态线程使用：
+
+```c
+rt_thread_init();
+```
+
+进行初始化。
+
+函数形式为：
+
+```c
+rt_err_t rt_thread_init(
+    struct rt_thread *thread,
+    const char       *name,
+    void (*entry)(void *parameter),
+    void             *parameter,
+    void             *stack_start,
+    rt_uint32_t        stack_size,
+    rt_uint8_t         priority,
+    rt_uint32_t        tick
+);
+```
+
+主要参数如下：
+
+| 参数 | 含义 |
+| ---- | ---- |
+| `thread` | 线程控制块 |
+| `name` | 线程名称 |
+| `entry` | 线程入口函数 |
+| `parameter` | 入口函数参数 |
+| `stack_start` | 线程栈起始地址 |
+| `stack_size` | 线程栈大小 |
+| `priority` | 线程优先级 |
+| `tick` | 时间片 |
+
+例如：
+
+```c
+ALIGN(RT_ALIGN_SIZE)
+static char thread2_stack[1024];
+
+static struct rt_thread thread2;
+
+static void thread2_entry(void *parameter)
+{
+    while (1)
+    {
+        rt_kprintf("thread2\n");
+
+        rt_thread_mdelay(500);
+    }
+}
+```
+
+初始化：
+
+```c
+rt_thread_init(
+    &thread2,
+    "thread2",
+    thread2_entry,
+    RT_NULL,
+    &thread2_stack[0],
+    sizeof(thread2_stack),
+    20,
+    10
+);
+```
+
+但是此时线程仍然只是：
+
+```text
+INIT
+```
+
+并没有真正参与调度。
+
+---
+
+## 动态线程
+
+动态线程使用：
+
+```c
+rt_thread_create();
+```
+
+创建。
+
+函数会从动态内存堆中自动申请：
+
+- 线程控制块
+- 线程栈
+
+基本形式：
+
+```c
+rt_thread_t rt_thread_create(
+    const char *name,
+    void (*entry)(void *parameter),
+    void *parameter,
+    rt_uint32_t stack_size,
+    rt_uint8_t priority,
+    rt_uint32_t tick
+);
+```
+
+例如：
+
+```c
+rt_thread_t tid;
+
+tid = rt_thread_create(
+    "thread1",
+    thread1_entry,
+    RT_NULL,
+    1024,
+    20,
+    10
+);
+```
+
+可以简单对比：
+
+| 类型 | API | 内存来源 |
+| ---- | ---- | ---- |
+| 静态线程 | `rt_thread_init()` | 用户提供 |
+| 动态线程 | `rt_thread_create()` | 系统动态分配 |
+
+---
+
+## 启动线程
+
+不管通过：
+
+```c
+rt_thread_init()
+```
+
+还是：
+
+```c
+rt_thread_create()
+```
+
+创建线程以后，线程最初都处于：
+
+```text
+RT_THREAD_INIT
+```
+
+因此还需要调用：
+
+```c
+rt_thread_startup();
+```
+
+让线程进入就绪状态。
+
+例如：
+
+```c
+rt_thread_startup(&thread2);
+```
+
+或者动态线程：
+
+```c
+rt_thread_startup(tid);
+```
+
+完整流程：
+
+```text
+定义入口函数
+      ↓
+创建 / 初始化线程
+      ↓
+INIT
+      ↓
+rt_thread_startup()
+      ↓
+READY
+      ↓
+调度器
+      ↓
+RUNNING
+```
+
+需要注意：
+
+如果启动的新线程优先级比当前线程高，那么线程进入 READY 后可能立即抢占当前线程运行。
+
+---
+
+## 线程延时与 CPU 使用权
+
+在抢占式 RTOS 中，线程不需要使用 CPU 时应该主动让出 CPU。
+
+RT-Thread 提供了线程延时 API。
+
+以 Tick 为单位：
+
+```c
+rt_thread_delay(tick);
+```
+
+以毫秒为单位：
+
+```c
+rt_thread_mdelay(ms);
+```
+
+例如：
+
+```c
+while (1)
+{
+    rt_kprintf("thread running\n");
+
+    rt_thread_mdelay(1000);
+}
+```
+
+运行过程：
+
+```text
+线程运行
+   ↓
+打印信息
+   ↓
+rt_thread_mdelay(1000)
+   ↓
+线程进入挂起状态
+   ↓
+CPU 运行其他线程
+   ↓
+1000 ms 到达
+   ↓
+线程重新进入 READY
+   ↓
+等待再次调度
+```
+
+所以：
+
+```c
+rt_thread_mdelay();
+```
+
+不仅仅是简单的“延时”，它还会使当前线程暂时不参与调度，将 CPU 使用权交给其他线程。
+
+---
+
+## 线程学习小结
+
+RT-Thread 的线程可以总结为：
+
+```text
+线程
+ │
+ ├── 线程控制块
+ │     └── struct rt_thread
+ │
+ ├── 线程栈
+ │     └── 保存上下文和局部变量
+ │
+ ├── 状态
+ │     ├── INIT
+ │     ├── READY
+ │     ├── RUNNING
+ │     ├── SUSPEND
+ │     └── CLOSE
+ │
+ ├── 优先级
+ │     └── 数字越小优先级越高
+ │
+ ├── 时间片
+ │     └── 同优先级线程轮转
+ │
+ └── 入口函数
+       └── thread_entry()
+```
+
+线程最基本的使用流程：
+
+```text
+编写线程入口函数
+        ↓
+创建线程
+        ↓
+设置栈、优先级、时间片
+        ↓
+启动线程
+        ↓
+进入 READY
+        ↓
+等待调度器调度
+        ↓
+RUNNING
+        ↓
+delay / wait
+        ↓
+让出 CPU
+```
+
+---
+
+## SCons 构建系统
+
+RT-Thread 使用：
+
+```text
+SCons
+```
+
+作为工程构建工具。
+
+SCons 是基于 Python 的自动化构建工具。
+
+RT-Thread 可以通过 SCons 实现：
+
+- 编译工程
+- 管理源码文件
+- 管理头文件路径
+- 管理宏定义
+- 管理不同模块
+- 根据配置裁剪代码
+- 生成 MDK / IAR 工程
+
+因此，RT-Thread 的工程并不是单纯依赖 Keil 工程文件进行管理，而是可以通过 SCons 脚本描述整个工程结构。
+
+常见相关文件有：
+
+```text
+SConstruct
+
+SConscript
+```
+
+可以简单理解为：
+
+```text
+SConstruct
+    ↓
+工程顶层构建脚本
+    ↓
+调用各目录中的 SConscript
+    ↓
+添加源码、头文件和宏
+    ↓
+SCons 根据配置完成构建
+```
+
+---
+
+## SConstruct
+
+`SConstruct` 通常是整个工程最上层的 SCons 构建文件。
+
+可以将它理解为：
+
+**整个工程构建的入口脚本。**
+
+当执行：
+
+```bash
+scons
+```
+
+时，SCons 会首先读取：
+
+```text
+SConstruct
+```
+
+然后根据 SConstruct 中定义的内容继续执行其他构建脚本。
+
+典型关系：
+
+```text
+Project
+ │
+ ├── SConstruct
+ │
+ ├── applications
+ │    └── SConscript
+ │
+ ├── drivers
+ │    └── SConscript
+ │
+ └── rt-thread
+      └── ...
+```
+
+其中：
+
+```text
+SConstruct
+```
+
+负责整个工程，
+
+各目录中的：
+
+```text
+SConscript
+```
+
+负责当前模块。
+
+---
+
+## SConscript
+
+`SConscript` 用于描述某一个模块：
+
+**哪些源文件应该参与编译，以及这些文件需要哪些头文件和宏定义。**
+
+例如一个简单的目录：
+
+```text
+applications
+ │
+ ├── main.c
+ ├── led.c
+ ├── led.h
+ └── SConscript
+```
+
+其 SConscript 可以类似：
+
+```python
+from building import *
+
+cwd = GetCurrentDir()
+
+src = Glob('*.c')
+
+CPPPATH = [cwd]
+
+group = DefineGroup(
+    'Applications',
+    src,
+    depend = [''],
+    CPPPATH = CPPPATH
+)
+
+Return('group')
+```
+
+这里几个重要内容分别表示：
+
+```python
+cwd = GetCurrentDir()
+```
+
+获取当前目录。
+
+```python
+src = Glob('*.c')
+```
+
+获取当前目录中的 C 文件。
+
+```python
+CPPPATH = [cwd]
+```
+
+添加头文件搜索路径。
+
+最后通过：
+
+```python
+DefineGroup()
+```
+
+把这些文件组成一个编译组。
+
+因此可以简单理解：
+
+```text
+SConscript
+    ↓
+告诉 SCons：
+
+哪些 .c 要编译
+
+哪些 include 目录要加入
+
+需要哪些宏
+
+满足什么条件才编译
+```
+
+---
+
+## DefineGroup
+
+RT-Thread 的 SCons 脚本中经常可以看到：
+
+```python
+DefineGroup()
+```
+
+例如：
+
+```python
+group = DefineGroup(
+    'Applications',
+    src,
+    depend = [''],
+    CPPPATH = CPPPATH
+)
+```
+
+可以把它理解为：
+
+**定义一个工程代码组。**
+
+第一个参数：
+
+```python
+'Applications'
+```
+
+表示组名称。
+
+第二个参数：
+
+```python
+src
+```
+
+表示需要编译的源文件。
+
+还可以指定：
+
+```python
+CPPPATH
+```
+
+头文件搜索路径。
+
+以及：
+
+```python
+CPPDEFINES
+```
+
+宏定义。
+
+例如：
+
+```python
+group = DefineGroup(
+    'Drivers',
+    src,
+    depend = ['BSP_USING_UART1'],
+    CPPPATH = CPPPATH
+)
+```
+
+表示：
+
+只有：
+
+```text
+BSP_USING_UART1
+```
+
+被使能时，这一组代码才会加入工程。
+
+这就是 RT-Thread 可以根据配置自动裁剪工程的重要原因之一。
+
+---
+
+## SCons 基本命令
+
+进入 RT-Thread BSP 或工程目录后，可以直接使用：
+
+```bash
+scons
+```
+
+编译工程。
+
+基本流程：
+
+```text
+工程目录
+   ↓
+scons
+   ↓
+读取 SConstruct
+   ↓
+加载 SConscript
+   ↓
+分析工程配置
+   ↓
+编译源码
+   ↓
+链接
+   ↓
+生成最终程序
+```
+
+如果代码没有发生变化，SCons 会根据依赖关系判断哪些文件需要重新编译，而不是每次都重新编译整个工程。
+
+---
+
+## 清理工程
+
+如果希望删除已经生成的编译文件，可以使用：
+
+```bash
+scons -c
+```
+
+即：
+
+```text
+scons -c
+    ↓
+Clean
+    ↓
+清理工程编译产生的文件
+```
+
+通常在工程配置发生较大变化或者需要完全重新构建时使用。
+
+---
+
+## 生成 Keil MDK5 工程
+
+RT-Thread 可以通过 SCons 自动生成 Keil 工程。
+
+对于 MDK5：
+
+```bash
+scons --target=mdk5
+```
+
+执行后 SCons 会根据当前工程中的：
+
+```text
+SConstruct
+SConscript
+rtconfig.h
+```
+
+等配置重新生成 MDK5 工程。
+
+因此如果修改了：
+
+- SConscript
+- 软件包
+- menuconfig 配置
+- BSP 配置
+
+通常需要重新执行：
+
+```bash
+scons --target=mdk5
+```
+
+让 Keil 工程同步最新配置。
+
+其他常见目标还有：
+
+```bash
+scons --target=mdk4
+```
+
+生成 MDK4 工程。
+
+```bash
+scons --target=iar
+```
+
+生成 IAR 工程。
+
+可以总结为：
+
+| 命令 | 作用 |
+| ---- | ---- |
+| `scons` | 编译工程 |
+| `scons -c` | 清理工程 |
+| `scons --target=mdk5` | 生成 MDK5 工程 |
+| `scons --target=mdk4` | 生成 MDK4 工程 |
+| `scons --target=iar` | 生成 IAR 工程 |
+
+---
+
+## menuconfig 与 SCons
+
+RT-Thread 可以使用：
+
+```bash
+menuconfig
+```
+
+对系统功能进行配置。
+
+例如：
+
+```text
+RT-Thread Kernel
+RT-Thread Components
+Hardware Drivers
+Network
+File System
+Packages
+```
+
+配置完成后会生成或修改相关配置内容，例如：
+
+```text
+.config
+```
+
+以及：
+
+```text
+rtconfig.h
+```
+
+一个典型配置流程为：
+
+```text
+menuconfig
+      ↓
+选择需要的功能
+      ↓
+保存配置
+      ↓
+更新 rtconfig.h
+      ↓
+SCons 根据宏判断代码是否参与编译
+      ↓
+生成新的工程
+```
+
+因此：
+
+```text
+menuconfig
+```
+
+负责“选择功能”，
+
+而：
+
+```text
+SCons
+```
+
+负责“根据这些功能构建工程”。
+
+---
+
+## pkgs --update
+
+如果工程使用了 RT-Thread 软件包，修改配置后通常需要执行：
+
+```bash
+pkgs --update
+```
+
+它会根据当前配置更新对应的软件包。
+
+常见流程：
+
+```text
+menuconfig
+     ↓
+选择软件包
+     ↓
+保存
+     ↓
+pkgs --update
+     ↓
+下载 / 更新软件包
+     ↓
+scons --target=mdk5
+     ↓
+重新生成 Keil 工程
+```
+
+因此，在使用 RT-Thread 软件包时，可以记住下面这组命令：
+
+```bash
+menuconfig
+
+pkgs --update
+
+scons --target=mdk5
+```
+
+---
+
+## SCons 与 RT-Thread 工程的关系
+
+整个构建流程可以理解为：
+
+```text
+menuconfig
+     ↓
+决定系统需要什么功能
+     ↓
+.config / rtconfig.h
+     ↓
+SConstruct
+     ↓
+调用各模块 SConscript
+     ↓
+根据宏决定哪些源码参与编译
+     ↓
+SCons
+     ↓
+编译 / 生成 IDE 工程
+```
+
+例如：
+
+```text
+menuconfig 中开启 UART
+          ↓
+BSP_USING_UART = y
+          ↓
+生成对应宏
+          ↓
+SConscript 检查 depend
+          ↓
+UART 驱动加入工程
+          ↓
+编译 UART 驱动
+```
+
+所以 SCons 并不是简单地“代替 Keil 点一下 Build”。
+
+它实际上承担了：
+
+**整个 RT-Thread 工程代码组织和自动构建的工作。**
+
-- 
Gitee


From c6f7d89286f351ca6bce4a20224f5178493e067c Mon Sep 17 00:00:00 2001
From: kylehe233-ui <kylehe233@gmail.com>
Date: Thu, 20 Aug 2026 20:19:49 +0800
Subject: [PATCH 6/7] fix 2

---
 .../README.md"                                                    | 0
 .../thread_study.c"                                               | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/README.md" => "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\272\214\345\244\251\344\275\234\344\270\232/README.md" (100%)
 rename "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/thread_study.c" => "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\272\214\345\244\251\344\275\234\344\270\232/thread_study.c" (100%)

diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/README.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\272\214\345\244\251\344\275\234\344\270\232/README.md"
similarity index 100%
rename from "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/README.md"
rename to "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\272\214\345\244\251\344\275\234\344\270\232/README.md"
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/thread_study.c" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\272\214\345\244\251\344\275\234\344\270\232/thread_study.c"
similarity index 100%
rename from "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/thread_study.c"
rename to "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\272\214\345\244\251\344\275\234\344\270\232/thread_study.c"
-- 
Gitee


From daada18f2a04caeacbc4579240013b94f0eb7a78 Mon Sep 17 00:00:00 2001
From: kylehe233-ui <kylehe233@gmail.com>
Date: Thu, 20 Aug 2026 20:22:18 +0800
Subject: [PATCH 7/7] day3

---
 .../package_demo.c"                           |  372 ++++
 .../parking_demo.c"                           |  187 ++
 .../startup_demo.c"                           |  326 +++
 .../ticket_demo.c"                            |  177 ++
 .../ticketdiffer_demo.c"                      |  144 ++
 ...\254\254\344\270\211\345\244\251README.md" | 1031 +++++++++
 ...46\344\271\240\347\254\224\350\256\260.md" | 1842 +++++++++++++++++
 7 files changed, 4079 insertions(+)
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/package_demo.c"
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/parking_demo.c"
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/startup_demo.c"
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/ticket_demo.c"
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/ticketdiffer_demo.c"
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251README.md"
 create mode 100644 "2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\211\345\244\251\345\255\246\344\271\240\347\254\224\350\256\260.md"

diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/package_demo.c" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/package_demo.c"
new file mode 100644
index 0000000..b37f338
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/package_demo.c"
@@ -0,0 +1,372 @@
+#include <rtthread.h>
+
+#define PACKAGE_QUEUE_SIZE      5
+#define PACKAGE_PER_SENDER      5
+#define PACKAGE_END_ID          0xFFFFFFFFU
+
+#define THREAD_STACK_SIZE       1024
+#define SORT_PRIORITY           19
+#define SEND_PRIORITY           20
+#define THREAD_TIMESLICE        10
+
+#define REGION_EAST             1
+#define REGION_SOUTH            2
+#define REGION_NORTH            3
+
+struct package_msg
+{
+    rt_uint32_t id;
+    rt_uint8_t region;
+    rt_uint16_t weight;
+};
+
+struct sender_info
+{
+    rt_uint32_t base_id;
+    rt_uint8_t sender_id;
+};
+
+static rt_mq_t package_mq = RT_NULL;
+
+static rt_uint8_t demo_running = 0;
+static rt_uint8_t sender_finished = 0;
+
+static rt_uint32_t send_failed = 0;
+
+static struct sender_info sender_info[2] =
+{
+    {1000, 1},
+    {2000, 2}
+};
+
+
+/* 获取区域名称 */
+static const char *get_region_name(rt_uint8_t region)
+{
+    switch (region)
+    {
+    case REGION_EAST:
+        return "east";
+
+    case REGION_SOUTH:
+        return "south";
+
+    case REGION_NORTH:
+        return "north";
+
+    default:
+        return "unknown";
+    }
+}
+
+
+/* 发送结束消息 */
+static void send_end_message(void)
+{
+    struct package_msg msg;
+    rt_err_t result;
+
+    msg.id = PACKAGE_END_ID;
+    msg.region = 0;
+    msg.weight = 0;
+
+    while (1)
+    {
+        result = rt_mq_send(package_mq,
+                            &msg,
+                            sizeof(msg));
+
+        if (result == RT_EOK)
+        {
+            break;
+        }
+
+        rt_thread_mdelay(20);
+    }
+}
+
+
+/* 快递发送线程 */
+static void sender_entry(void *parameter)
+{
+    struct sender_info *info;
+    struct package_msg msg;
+
+    rt_uint8_t i;
+    rt_uint8_t finished;
+    rt_err_t result;
+
+    info = (struct sender_info *)parameter;
+
+    for (i = 1; i <= PACKAGE_PER_SENDER; i++)
+    {
+        /* 生成快递信息 */
+        msg.id = info->base_id + i;
+        msg.region = ((i + info->sender_id - 2) % 3) + 1;
+        msg.weight = 700 + info->sender_id * 100 + i * 80;
+
+        while (1)
+        {
+            /* 发送快递消息 */
+            result = rt_mq_send(package_mq,
+                                &msg,
+                                sizeof(msg));
+
+            if (result == RT_EOK)
+            {
+                break;
+            }
+
+            if (result == -RT_EFULL)
+            {
+                /* 记录队列满 */
+                rt_enter_critical();
+                send_failed++;
+                rt_exit_critical();
+
+                rt_thread_mdelay(50);
+            }
+            else
+            {
+                rt_kprintf("package %d send error: %d\n",
+                           msg.id,
+                           result);
+
+                rt_thread_mdelay(50);
+            }
+        }
+
+        rt_thread_mdelay(50);
+    }
+
+    /* 记录发送线程完成 */
+    rt_enter_critical();
+
+    sender_finished++;
+    finished = sender_finished;
+
+    rt_exit_critical();
+
+    /* 最后一个发送线程发送结束消息 */
+    if (finished == 2)
+    {
+        send_end_message();
+    }
+}
+
+
+/* 快递分拣线程 */
+static void sorter_entry(void *parameter)
+{
+    struct package_msg msg;
+
+    rt_uint32_t total_packages = 0;
+    rt_uint32_t east_count = 0;
+    rt_uint32_t south_count = 0;
+    rt_uint32_t north_count = 0;
+    rt_uint32_t total_weight = 0;
+
+    rt_uint32_t failed;
+    rt_err_t result;
+
+    while (1)
+    {
+        /* 等待快递消息 */
+        result = rt_mq_recv(package_mq,
+                            &msg,
+                            sizeof(msg),
+                            RT_WAITING_FOREVER);
+
+        if (result != RT_EOK)
+        {
+            rt_kprintf("receive package failed: %d\n",
+                       result);
+            continue;
+        }
+
+        /* 检查结束消息 */
+        if (msg.id == PACKAGE_END_ID)
+        {
+            break;
+        }
+
+        rt_kprintf("package %d -> %s, weight: %d g\n",
+                   msg.id,
+                   get_region_name(msg.region),
+                   msg.weight);
+
+        /* 统计快递 */
+        total_packages++;
+        total_weight += msg.weight;
+
+        switch (msg.region)
+        {
+        case REGION_EAST:
+            east_count++;
+            break;
+
+        case REGION_SOUTH:
+            south_count++;
+            break;
+
+        case REGION_NORTH:
+            north_count++;
+            break;
+
+        default:
+            break;
+        }
+
+        /* 模拟分拣过程 */
+        rt_thread_mdelay(100);
+    }
+
+    rt_enter_critical();
+    failed = send_failed;
+    rt_exit_critical();
+
+    /* 打印统计结果 */
+    rt_kprintf("total packages: %d\n",
+               total_packages);
+
+    rt_kprintf("east: %d, south: %d, north: %d\n",
+               east_count,
+               south_count,
+               north_count);
+
+    rt_kprintf("total weight: %d g\n",
+               total_weight);
+
+    rt_kprintf("send failed: %d\n",
+               failed);
+
+    /* 删除消息队列 */
+    if (package_mq != RT_NULL)
+    {
+        rt_mq_delete(package_mq);
+        package_mq = RT_NULL;
+    }
+
+    rt_enter_critical();
+
+    sender_finished = 0;
+    send_failed = 0;
+    demo_running = 0;
+
+    rt_exit_critical();
+
+    rt_kprintf("package demo finished\n");
+}
+
+
+/* 快递分拣实验 */
+static void package_demo(void)
+{
+    rt_thread_t sender1_tid;
+    rt_thread_t sender2_tid;
+    rt_thread_t sorter_tid;
+
+    /* 防止重复启动 */
+    rt_enter_critical();
+
+    if (demo_running)
+    {
+        rt_exit_critical();
+
+        rt_kprintf("package demo is already running\n");
+        return;
+    }
+
+    demo_running = 1;
+    sender_finished = 0;
+    send_failed = 0;
+
+    rt_exit_critical();
+
+    /* 创建消息队列 */
+    package_mq = rt_mq_create("pkg_mq",
+                              sizeof(struct package_msg),
+                              PACKAGE_QUEUE_SIZE,
+                              RT_IPC_FLAG_FIFO);
+
+    if (package_mq == RT_NULL)
+    {
+        rt_kprintf("create package queue failed\n");
+
+        demo_running = 0;
+        return;
+    }
+
+    /* 创建发送线程 1 */
+    sender1_tid = rt_thread_create("pkg_send1",
+                                   sender_entry,
+                                   &sender_info[0],
+                                   THREAD_STACK_SIZE,
+                                   SEND_PRIORITY,
+                                   THREAD_TIMESLICE);
+
+    if (sender1_tid == RT_NULL)
+    {
+        rt_kprintf("create sender1 thread failed\n");
+
+        rt_mq_delete(package_mq);
+        package_mq = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    /* 创建发送线程 2 */
+    sender2_tid = rt_thread_create("pkg_send2",
+                                   sender_entry,
+                                   &sender_info[1],
+                                   THREAD_STACK_SIZE,
+                                   SEND_PRIORITY,
+                                   THREAD_TIMESLICE);
+
+    if (sender2_tid == RT_NULL)
+    {
+        rt_kprintf("create sender2 thread failed\n");
+
+        rt_thread_delete(sender1_tid);
+
+        rt_mq_delete(package_mq);
+        package_mq = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    /* 创建分拣线程 */
+    sorter_tid = rt_thread_create("pkg_sort",
+                                  sorter_entry,
+                                  RT_NULL,
+                                  THREAD_STACK_SIZE,
+                                  SORT_PRIORITY,
+                                  THREAD_TIMESLICE);
+
+    if (sorter_tid == RT_NULL)
+    {
+        rt_kprintf("create sorter thread failed\n");
+
+        rt_thread_delete(sender1_tid);
+        rt_thread_delete(sender2_tid);
+
+        rt_mq_delete(package_mq);
+        package_mq = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    rt_kprintf("package demo start\n");
+
+    /* 启动分拣线程 */
+    rt_thread_startup(sorter_tid);
+
+    /* 启动发送线程 */
+    rt_thread_startup(sender1_tid);
+    rt_thread_startup(sender2_tid);
+}
+
+MSH_CMD_EXPORT(package_demo, package message queue demo);
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/parking_demo.c" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/parking_demo.c"
new file mode 100644
index 0000000..35c7f36
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/parking_demo.c"
@@ -0,0 +1,187 @@
+#include <rtthread.h>
+
+#define CAR_NUM             5
+#define PARKING_SPACES      3
+#define WAIT_TIME_MS        2000
+#define PARK_TIME_MS        3000
+#define RETRY_TIME_MS       500
+
+static rt_sem_t parking_sem = RT_NULL;
+
+static rt_uint8_t used_spaces = 0;
+static rt_uint8_t finished_cars = 0;
+static rt_uint8_t demo_running = 0;
+
+static rt_uint8_t car_id[CAR_NUM] = {1, 2, 3, 4, 5};
+
+/* 车辆线程 */
+static void car_entry(void *parameter)
+{
+    rt_uint8_t id;
+    rt_uint8_t spaces;
+    rt_uint8_t finished;
+    rt_err_t result;
+
+    id = *(rt_uint8_t *)parameter;
+
+    while (1)
+    {
+        /* 申请车位，最多等待 2 秒 */
+        result = rt_sem_take(parking_sem,
+                             rt_tick_from_millisecond(WAIT_TIME_MS));
+
+        if (result == RT_EOK)
+        {
+            /* 更新已使用车位 */
+            rt_enter_critical();
+            used_spaces++;
+            spaces = used_spaces;
+            rt_exit_critical();
+
+            rt_kprintf("car%d entered, used spaces: %d\n",
+                       id, spaces);
+
+            /* 模拟停车 */
+            rt_thread_mdelay(PARK_TIME_MS);
+
+            /* 更新已使用车位 */
+            rt_enter_critical();
+            used_spaces--;
+            spaces = used_spaces;
+            rt_exit_critical();
+
+            rt_kprintf("car%d left, used spaces: %d\n",
+                       id, spaces);
+
+            /* 释放车位 */
+            rt_sem_release(parking_sem);
+
+            break;
+        }
+        else if (result == -RT_ETIMEOUT)
+        {
+            rt_kprintf("car%d waiting for a space\n", id);
+
+            /* 稍后重新申请 */
+            rt_thread_mdelay(RETRY_TIME_MS);
+        }
+        else
+        {
+            rt_kprintf("car%d take semaphore failed: %d\n",
+                       id, result);
+
+            rt_thread_mdelay(RETRY_TIME_MS);
+        }
+    }
+
+    /* 记录完成车辆数量 */
+    rt_enter_critical();
+    finished_cars++;
+    finished = finished_cars;
+    rt_exit_critical();
+
+    /* 最后一辆车负责释放资源 */
+    if (finished == CAR_NUM)
+    {
+        rt_kprintf("all cars finished\n");
+
+        if (parking_sem != RT_NULL)
+        {
+            rt_sem_delete(parking_sem);
+            parking_sem = RT_NULL;
+        }
+
+        rt_enter_critical();
+        used_spaces = 0;
+        finished_cars = 0;
+        demo_running = 0;
+        rt_exit_critical();
+
+        rt_kprintf("parking demo finished\n");
+    }
+}
+
+
+/* 停车场实验 */
+static void parking_demo(void)
+{
+    rt_thread_t tid[CAR_NUM];
+    rt_uint8_t i;
+
+    /* 防止重复启动 */
+    rt_enter_critical();
+
+    if (demo_running)
+    {
+        rt_exit_critical();
+
+        rt_kprintf("parking demo is already running\n");
+        return;
+    }
+
+    demo_running = 1;
+    used_spaces = 0;
+    finished_cars = 0;
+
+    rt_exit_critical();
+
+    /* 创建计数信号量 */
+    parking_sem = rt_sem_create("park_sem",
+                                PARKING_SPACES,
+                                RT_IPC_FLAG_FIFO);
+
+    if (parking_sem == RT_NULL)
+    {
+        rt_kprintf("create parking semaphore failed\n");
+
+        demo_running = 0;
+        return;
+    }
+
+    /* 创建车辆线程 */
+    for (i = 0; i < CAR_NUM; i++)
+    {
+        tid[i] = rt_thread_create("car",
+                                  car_entry,
+                                  &car_id[i],
+                                  1024,
+                                  20,
+                                  10);
+
+        if (tid[i] == RT_NULL)
+        {
+            rt_uint8_t j;
+
+            rt_kprintf("create car%d thread failed\n",
+                       car_id[i]);
+
+            /* 删除已创建但未启动的线程 */
+            for (j = 0; j < i; j++)
+            {
+                if (tid[j] != RT_NULL)
+                {
+                    rt_thread_delete(tid[j]);
+                }
+            }
+
+            rt_sem_delete(parking_sem);
+            parking_sem = RT_NULL;
+
+            demo_running = 0;
+
+            return;
+        }
+    }
+
+    rt_kprintf("parking demo start\n");
+    rt_kprintf("total spaces: %d, total cars: %d\n",
+               PARKING_SPACES, CAR_NUM);
+
+    /* 启动车辆线程 */
+    for (i = 0; i < CAR_NUM; i++)
+    {
+        rt_thread_startup(tid[i]);
+    }
+}
+
+MSH_CMD_EXPORT(parking_demo, parking semaphore demo);
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/startup_demo.c" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/startup_demo.c"
new file mode 100644
index 0000000..61abd8d
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/startup_demo.c"
@@ -0,0 +1,326 @@
+#include <rtthread.h>
+
+#define EVENT_NET_READY       (1U << 0)
+#define EVENT_SENSOR_READY    (1U << 1)
+#define EVENT_STORAGE_READY   (1U << 2)
+
+#define EVENT_ALL_READY       (EVENT_NET_READY    | \
+                               EVENT_SENSOR_READY | \
+                               EVENT_STORAGE_READY)
+
+#define THREAD_STACK_SIZE     1024
+#define INIT_PRIORITY         20
+#define BUSINESS_PRIORITY     21
+#define THREAD_TIMESLICE      10
+
+#define NET_DELAY_MS          1000
+#define SENSOR_DELAY_MS       2000
+#define STORAGE_DELAY_MS      5000
+#define FIRST_WAIT_MS         3000
+
+static rt_event_t startup_event = RT_NULL;
+
+static rt_uint32_t ready_flags = 0;
+static rt_uint8_t demo_running = 0;
+
+
+/* 记录模块状态 */
+static void set_ready_flag(rt_uint32_t flag)
+{
+    rt_enter_critical();
+
+    ready_flags |= flag;
+
+    rt_exit_critical();
+}
+
+
+/* 网络初始化线程 */
+static void net_init_entry(void *parameter)
+{
+    rt_err_t result;
+
+    rt_thread_mdelay(NET_DELAY_MS);
+
+    set_ready_flag(EVENT_NET_READY);
+
+    result = rt_event_send(startup_event,
+                           EVENT_NET_READY);
+
+    if (result == RT_EOK)
+    {
+        rt_kprintf("network ready\n");
+    }
+    else
+    {
+        rt_kprintf("network event send failed\n");
+    }
+}
+
+
+/* 传感器初始化线程 */
+static void sensor_init_entry(void *parameter)
+{
+    rt_err_t result;
+
+    rt_thread_mdelay(SENSOR_DELAY_MS);
+
+    set_ready_flag(EVENT_SENSOR_READY);
+
+    result = rt_event_send(startup_event,
+                           EVENT_SENSOR_READY);
+
+    if (result == RT_EOK)
+    {
+        rt_kprintf("sensor ready\n");
+    }
+    else
+    {
+        rt_kprintf("sensor event send failed\n");
+    }
+}
+
+
+/* 存储初始化线程 */
+static void storage_init_entry(void *parameter)
+{
+    rt_err_t result;
+
+    rt_thread_mdelay(STORAGE_DELAY_MS);
+
+    set_ready_flag(EVENT_STORAGE_READY);
+
+    result = rt_event_send(startup_event,
+                           EVENT_STORAGE_READY);
+
+    if (result == RT_EOK)
+    {
+        rt_kprintf("storage ready\n");
+    }
+    else
+    {
+        rt_kprintf("storage event send failed\n");
+    }
+}
+
+
+/* 打印未完成模块 */
+static void print_not_ready(void)
+{
+    rt_uint32_t flags;
+
+    rt_enter_critical();
+
+    flags = ready_flags;
+
+    rt_exit_critical();
+
+    rt_kprintf("wait modules timeout");
+
+    if ((flags & EVENT_NET_READY) == 0)
+    {
+        rt_kprintf(", network is not ready");
+    }
+
+    if ((flags & EVENT_SENSOR_READY) == 0)
+    {
+        rt_kprintf(", sensor is not ready");
+    }
+
+    if ((flags & EVENT_STORAGE_READY) == 0)
+    {
+        rt_kprintf(", storage is not ready");
+    }
+
+    rt_kprintf("\n");
+}
+
+
+/* 主业务线程 */
+static void business_entry(void *parameter)
+{
+    rt_uint32_t received;
+    rt_err_t result;
+
+    /* 第一次等待，最多 3 秒 */
+    result = rt_event_recv(startup_event,
+                           EVENT_ALL_READY,
+                           RT_EVENT_FLAG_AND,
+                           rt_tick_from_millisecond(FIRST_WAIT_MS),
+                           &received);
+
+    if (result == -RT_ETIMEOUT)
+    {
+        print_not_ready();
+
+        /* 超时后再次等待 */
+        result = rt_event_recv(startup_event,
+                               EVENT_ALL_READY,
+                               RT_EVENT_FLAG_AND |
+                               RT_EVENT_FLAG_CLEAR,
+                               RT_WAITING_FOREVER,
+                               &received);
+    }
+
+    if (result == RT_EOK)
+    {
+        rt_kprintf("all modules are ready\n");
+        rt_kprintf("business task started\n");
+    }
+    else
+    {
+        rt_kprintf("receive startup event failed: %d\n",
+                   result);
+    }
+
+    /* 删除事件集 */
+    if (startup_event != RT_NULL)
+    {
+        rt_event_delete(startup_event);
+        startup_event = RT_NULL;
+    }
+
+    rt_enter_critical();
+
+    ready_flags = 0;
+    demo_running = 0;
+
+    rt_exit_critical();
+
+    rt_kprintf("startup demo finished\n");
+}
+
+
+/* 系统启动实验 */
+static void startup_demo(void)
+{
+    rt_thread_t net_tid;
+    rt_thread_t sensor_tid;
+    rt_thread_t storage_tid;
+    rt_thread_t business_tid;
+
+    /* 防止重复启动 */
+    rt_enter_critical();
+
+    if (demo_running)
+    {
+        rt_exit_critical();
+
+        rt_kprintf("startup demo is already running\n");
+        return;
+    }
+
+    demo_running = 1;
+    ready_flags = 0;
+
+    rt_exit_critical();
+
+    /* 创建事件集 */
+    startup_event = rt_event_create("startup",
+                                    RT_IPC_FLAG_FIFO);
+
+    if (startup_event == RT_NULL)
+    {
+        rt_kprintf("create startup event failed\n");
+
+        demo_running = 0;
+        return;
+    }
+
+    /* 创建网络线程 */
+    net_tid = rt_thread_create("net_init",
+                               net_init_entry,
+                               RT_NULL,
+                               THREAD_STACK_SIZE,
+                               INIT_PRIORITY,
+                               THREAD_TIMESLICE);
+
+    if (net_tid == RT_NULL)
+    {
+        rt_kprintf("create network thread failed\n");
+
+        rt_event_delete(startup_event);
+        startup_event = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    /* 创建传感器线程 */
+    sensor_tid = rt_thread_create("sensor",
+                                  sensor_init_entry,
+                                  RT_NULL,
+                                  THREAD_STACK_SIZE,
+                                  INIT_PRIORITY,
+                                  THREAD_TIMESLICE);
+
+    if (sensor_tid == RT_NULL)
+    {
+        rt_kprintf("create sensor thread failed\n");
+
+        rt_thread_delete(net_tid);
+
+        rt_event_delete(startup_event);
+        startup_event = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    /* 创建存储线程 */
+    storage_tid = rt_thread_create("storage",
+                                   storage_init_entry,
+                                   RT_NULL,
+                                   THREAD_STACK_SIZE,
+                                   INIT_PRIORITY,
+                                   THREAD_TIMESLICE);
+
+    if (storage_tid == RT_NULL)
+    {
+        rt_kprintf("create storage thread failed\n");
+
+        rt_thread_delete(net_tid);
+        rt_thread_delete(sensor_tid);
+
+        rt_event_delete(startup_event);
+        startup_event = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    /* 创建业务线程 */
+    business_tid = rt_thread_create("business",
+                                    business_entry,
+                                    RT_NULL,
+                                    THREAD_STACK_SIZE,
+                                    BUSINESS_PRIORITY,
+                                    THREAD_TIMESLICE);
+
+    if (business_tid == RT_NULL)
+    {
+        rt_kprintf("create business thread failed\n");
+
+        rt_thread_delete(net_tid);
+        rt_thread_delete(sensor_tid);
+        rt_thread_delete(storage_tid);
+
+        rt_event_delete(startup_event);
+        startup_event = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    rt_kprintf("startup demo start\n");
+
+    /* 启动初始化线程 */
+    rt_thread_startup(net_tid);
+    rt_thread_startup(sensor_tid);
+    rt_thread_startup(storage_tid);
+
+    /* 启动业务线程 */
+    rt_thread_startup(business_tid);
+}
+
+MSH_CMD_EXPORT(startup_demo, startup event demo);
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/ticket_demo.c" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/ticket_demo.c"
new file mode 100644
index 0000000..f082732
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/ticket_demo.c"
@@ -0,0 +1,177 @@
+#include <rtthread.h>
+
+#define TOTAL_TICKETS       20
+
+#define THREAD_STACK_SIZE   1024
+#define THREAD_PRIORITY     20
+#define THREAD_TIMESLICE    10
+
+static rt_mutex_t ticket_mutex = RT_NULL;
+
+static rt_int32_t ticket_count = TOTAL_TICKETS;
+static rt_uint8_t finished_windows = 0;
+static rt_uint8_t demo_running = 0;
+
+static char window_name[2] = {'A', 'B'};
+
+
+/* 售票线程 */
+static void ticket_entry(void *parameter)
+{
+    char name;
+    rt_int32_t ticket_no;
+    rt_uint8_t finished;
+
+    name = *(char *)parameter;
+
+    while (1)
+    {
+        /* 获取互斥量 */
+        if (rt_mutex_take(ticket_mutex, RT_WAITING_FOREVER) != RT_EOK)
+        {
+            rt_kprintf("window %c take mutex failed\n", name);
+            break;
+        }
+
+        /* 检查余票 */
+        if (ticket_count <= 0)
+        {
+            rt_mutex_release(ticket_mutex);
+            break;
+        }
+
+        /* 记录当前票号 */
+        ticket_no = ticket_count;
+
+        /* 售出一张票 */
+        ticket_count--;
+
+        rt_kprintf("window %c sold ticket %d\n",
+                   name,
+                   ticket_no);
+
+        /* 释放互斥量 */
+        rt_mutex_release(ticket_mutex);
+
+        /* 模拟售票间隔 */
+        rt_thread_mdelay(100);
+    }
+
+    /* 记录完成窗口数量 */
+    rt_enter_critical();
+
+    finished_windows++;
+    finished = finished_windows;
+
+    rt_exit_critical();
+
+    /* 最后一个线程负责清理 */
+    if (finished == 2)
+    {
+        rt_kprintf("all tickets sold\n");
+        rt_kprintf("remaining tickets: %d\n",
+                   ticket_count);
+
+        if (ticket_mutex != RT_NULL)
+        {
+            rt_mutex_delete(ticket_mutex);
+            ticket_mutex = RT_NULL;
+        }
+
+        rt_enter_critical();
+
+        ticket_count = TOTAL_TICKETS;
+        finished_windows = 0;
+        demo_running = 0;
+
+        rt_exit_critical();
+
+        rt_kprintf("ticket demo finished\n");
+    }
+}
+
+
+/* 售票实验 */
+static void ticket_demo(void)
+{
+    rt_thread_t tid_a;
+    rt_thread_t tid_b;
+
+    /* 防止重复启动 */
+    rt_enter_critical();
+
+    if (demo_running)
+    {
+        rt_exit_critical();
+
+        rt_kprintf("ticket demo is already running\n");
+        return;
+    }
+
+    demo_running = 1;
+    ticket_count = TOTAL_TICKETS;
+    finished_windows = 0;
+
+    rt_exit_critical();
+
+    /* 创建互斥量 */
+    ticket_mutex = rt_mutex_create("ticket_mtx",
+                                   RT_IPC_FLAG_PRIO);
+
+    if (ticket_mutex == RT_NULL)
+    {
+        rt_kprintf("create ticket mutex failed\n");
+
+        demo_running = 0;
+        return;
+    }
+
+    /* 创建窗口 A 线程 */
+    tid_a = rt_thread_create("win_a",
+                             ticket_entry,
+                             &window_name[0],
+                             THREAD_STACK_SIZE,
+                             THREAD_PRIORITY,
+                             THREAD_TIMESLICE);
+
+    if (tid_a == RT_NULL)
+    {
+        rt_kprintf("create window A thread failed\n");
+
+        rt_mutex_delete(ticket_mutex);
+        ticket_mutex = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    /* 创建窗口 B 线程 */
+    tid_b = rt_thread_create("win_b",
+                             ticket_entry,
+                             &window_name[1],
+                             THREAD_STACK_SIZE,
+                             THREAD_PRIORITY,
+                             THREAD_TIMESLICE);
+
+    if (tid_b == RT_NULL)
+    {
+        rt_kprintf("create window B thread failed\n");
+
+        rt_thread_delete(tid_a);
+
+        rt_mutex_delete(ticket_mutex);
+        ticket_mutex = RT_NULL;
+        demo_running = 0;
+
+        return;
+    }
+
+    rt_kprintf("ticket demo start\n");
+    rt_kprintf("total tickets: %d\n", TOTAL_TICKETS);
+
+    /* 启动售票线程 */
+    rt_thread_startup(tid_a);
+    rt_thread_startup(tid_b);
+}
+
+MSH_CMD_EXPORT(ticket_demo, ticket mutex demo);
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/ticketdiffer_demo.c" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/ticketdiffer_demo.c"
new file mode 100644
index 0000000..659f255
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/ticketdiffer_demo.c"
@@ -0,0 +1,144 @@
+#include <rtthread.h>
+
+#define TOTAL_TICKETS       20
+
+#define THREAD_STACK_SIZE   1024
+#define THREAD_PRIORITY     20
+#define THREAD_TIMESLICE    10
+
+static rt_int32_t ticket_count = TOTAL_TICKETS;
+static rt_uint8_t finished_windows = 0;
+static rt_uint8_t demo_running = 0;
+
+static char window_name[2] = {'A', 'B'};
+
+
+/* 售票线程 */
+static void ticket_entry(void *parameter)
+{
+    char name;
+    rt_int32_t ticket_no;
+    rt_uint8_t finished;
+
+    name = *(char *)parameter;
+
+    while (1)
+    {
+        /* 检查余票 */
+        if (ticket_count <= 0)
+        {
+            break;
+        }
+
+        /* 读取当前票号 */
+        ticket_no = ticket_count;
+
+        /* 放大线程竞争 */
+        rt_thread_mdelay(50);
+
+        /* 修改余票 */
+        ticket_count--;
+
+        rt_kprintf("window %c sold ticket %d\n",
+                   name,
+                   ticket_no);
+
+        /* 模拟售票间隔 */
+        rt_thread_mdelay(100);
+    }
+
+    /* 记录完成窗口数量 */
+    rt_enter_critical();
+
+    finished_windows++;
+    finished = finished_windows;
+
+    rt_exit_critical();
+
+    /* 最后一个线程负责结束实验 */
+    if (finished == 2)
+    {
+        rt_kprintf("all tickets sold\n");
+        rt_kprintf("remaining tickets: %d\n",
+                   ticket_count);
+
+        rt_enter_critical();
+
+        ticket_count = TOTAL_TICKETS;
+        finished_windows = 0;
+        demo_running = 0;
+
+        rt_exit_critical();
+
+        rt_kprintf("ticket differ demo finished\n");
+    }
+}
+
+
+/* 无互斥量售票实验 */
+static void ticketdiffer_demo(void)
+{
+    rt_thread_t tid_a;
+    rt_thread_t tid_b;
+
+    /* 防止重复启动 */
+    rt_enter_critical();
+
+    if (demo_running)
+    {
+        rt_exit_critical();
+
+        rt_kprintf("ticket differ demo is already running\n");
+        return;
+    }
+
+    demo_running = 1;
+    ticket_count = TOTAL_TICKETS;
+    finished_windows = 0;
+
+    rt_exit_critical();
+
+    /* 创建窗口 A 线程 */
+    tid_a = rt_thread_create("diff_a",
+                             ticket_entry,
+                             &window_name[0],
+                             THREAD_STACK_SIZE,
+                             THREAD_PRIORITY,
+                             THREAD_TIMESLICE);
+
+    if (tid_a == RT_NULL)
+    {
+        rt_kprintf("create window A thread failed\n");
+
+        demo_running = 0;
+        return;
+    }
+
+    /* 创建窗口 B 线程 */
+    tid_b = rt_thread_create("diff_b",
+                             ticket_entry,
+                             &window_name[1],
+                             THREAD_STACK_SIZE,
+                             THREAD_PRIORITY,
+                             THREAD_TIMESLICE);
+
+    if (tid_b == RT_NULL)
+    {
+        rt_kprintf("create window B thread failed\n");
+
+        rt_thread_delete(tid_a);
+
+        demo_running = 0;
+        return;
+    }
+
+    rt_kprintf("ticket differ demo start\n");
+    rt_kprintf("total tickets: %d\n", TOTAL_TICKETS);
+    rt_kprintf("mutex: disabled\n");
+
+    /* 启动售票线程 */
+    rt_thread_startup(tid_a);
+    rt_thread_startup(tid_b);
+}
+
+MSH_CMD_EXPORT(ticketdiffer_demo, ticket race condition demo);
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251README.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251README.md"
new file mode 100644
index 0000000..dddecbb
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251\344\275\234\344\270\232/\347\254\254\344\270\211\345\244\251README.md"
@@ -0,0 +1,1031 @@
+# Day3 IPC 实验报告
+
+## 实验一：停车场车位管理
+
+### 实验大纲
+
+| 项目           | 内容                                                         |
+| -------------- | ------------------------------------------------------------ |
+| 是什么知识点   | 计数信号量 `Semaphore`，主要涉及 `rt_sem_create()`、`rt_sem_take()`、`rt_sem_release()`、`rt_sem_delete()` 以及超时等待机制 |
+| 为什么要这么做 | 停车场只有 3 个车位，但同时有 5 辆车申请进入，需要通过计数信号量限制同时获得资源的线程数量 |
+| 意义是什么     | 掌握有限资源的管理方式，理解信号量如何在线程之间完成资源计数、阻塞等待、超时重试和资源释放 |
+
+### 1. 实验目的
+
+模拟只有 3 个车位的停车场，同时创建 5 个车辆线程。每辆车进入停车场前必须申请一个车位，离开时释放车位。当停车场已满时，车辆最多等待 2 秒，超时后打印等待信息，并在稍后重新申请。
+
+通过该实验验证计数信号量对有限资源数量的控制作用。
+
+### 2. 实验文件
+
+```text
+parking_demo.c
+```
+
+MSH 命令：
+
+```text
+parking_demo
+```
+
+### 3. 实验设计
+
+停车场车位数量设置为：
+
+```c
+#define PARKING_SPACES 3
+```
+
+车辆线程数量设置为：
+
+```c
+#define CAR_NUM 5
+```
+
+创建初始值为 3 的计数信号量：
+
+```c
+parking_sem = rt_sem_create("park_sem",
+                            PARKING_SPACES,
+                            RT_IPC_FLAG_FIFO);
+```
+
+车辆进入前使用：
+
+```c
+rt_sem_take()
+```
+
+申请车位，并设置 2 秒超时时间。
+
+车辆离开后使用：
+
+```c
+rt_sem_release()
+```
+
+归还车位。
+
+所有车辆线程结束后使用：
+
+```c
+rt_sem_delete()
+```
+
+删除动态创建的信号量对象。
+
+### 4. 实际运行结果
+
+执行：
+
+```text
+msh >parking_demo
+```
+
+实际输出：
+
+![524f1d54-c940-4f06-b499-3276fcf9362f](figures/524f1d54-c940-4f06-b499-3276fcf9362f.png)
+
+```text
+parking demo start
+total spaces: 3, total cars: 5
+
+car5 entered, used spaces: 1
+car4 entered, used spaces: 2
+car3 entered, used spaces: 3
+
+car2 waiting for a space
+car1 waiting for a space
+
+car5 left, used spaces: 2
+car2 entered, used spaces: 3
+
+car4 left, used spaces: 2
+car1 entered, used spaces: 3
+
+car3 left, used spaces: 2
+car2 left, used spaces: 1
+car1 left, used spaces: 0
+
+all cars finished
+parking demo finished
+```
+
+### 5. 实验结果分析
+
+实验启动后，car5、car4 和 car3 首先成功进入停车场：
+
+```text
+car5 entered, used spaces: 1
+car4 entered, used spaces: 2
+car3 entered, used spaces: 3
+```
+
+此时 3 个车位已经全部被占用，因此 car2 和 car1 无法获得信号量。在等待 2 秒后输出：
+
+```text
+car2 waiting for a space
+car1 waiting for a space
+```
+
+car5 离开后释放一个信号量，car2 随后成功获得车位：
+
+```text
+car5 left, used spaces: 2
+car2 entered, used spaces: 3
+```
+
+car4 离开后，car1 同样成功进入。
+
+整个实验过程中：
+
+```text
+最大同时占用车位数 = 3
+```
+
+没有出现 4 辆或 5 辆车同时进入停车场的情况。
+
+最终：
+
+```text
+car1 left, used spaces: 0
+```
+
+说明所有车辆均已离开，已使用车位数量恢复为 0。
+
+### 6. 实验数据总结
+
+| 项目             | 实际数据         |
+| ---------------- | ---------------- |
+| 总车位数量       | 3                |
+| 车辆线程数量     | 5                |
+| 首批进入车辆     | car5、car4、car3 |
+| 首次等待车辆     | car2、car1       |
+| 最大同时占用车位 | 3                |
+| 最终占用车位     | 0                |
+| 实验结果         | 正常完成         |
+
+### 7. 问题与解决方法
+
+运行过程中出现过：
+
+```text
+msh >car5 entered...
+```
+
+类似现象。
+
+这是由于 MSH 命令执行完成后重新输出命令提示符，而车辆线程同时调用 `rt_kprintf()` 输出信息，导致两个输出在串口终端中发生交错。
+
+该现象不会影响信号量以及线程的实际运行结果，因此无需修改核心逻辑。
+
+### 8. 思考题
+
+**为什么这里使用计数信号量，而不是互斥量？**
+
+停车场存在 3 个相同的车位资源，因此需要允许最多 3 个车辆线程同时获得资源。
+
+计数信号量可以通过初始值表示可用资源数量。本实验将信号量初始值设置为 3，每辆车进入时获取一次信号量，离开时释放一次信号量，从而保证同时进入停车场的车辆数量不超过 3。
+
+互斥量主要用于保护只能由一个线程独占访问的共享资源。如果使用互斥量，同一时刻通常只能有一个车辆线程获得资源，无法正确表示停车场具有 3 个车位的实际情况。
+
+------
+
+## 实验二：多窗口售票系统
+
+### 实验大纲
+
+| 项目           | 内容                                                         |
+| -------------- | ------------------------------------------------------------ |
+| 是什么知识点   | 互斥量 `Mutex`、临界区以及多线程访问共享变量时产生的竞态条件 |
+| 为什么要这么做 | 两个售票窗口同时修改同一个 `ticket_count`，如果缺少互斥保护，线程可能同时读取相同票号并产生重复售票 |
+| 意义是什么     | 理解共享资源必须进行完整的互斥保护，掌握竞态条件产生的原因以及 Mutex 对临界区的保护作用 |
+
+### 1. 实验目的
+
+创建窗口 A 和窗口 B 两个售票线程，共同出售 20 张票。
+
+首先进行无互斥量实验，在读取余票和修改余票之间加入延时，主动放大竞态条件。
+
+随后使用互斥量保护完整售票过程，对比两次实验结果。
+
+实验要求最终正确版本满足：
+
+```text
+20 张票全部售出
+没有重复票号
+余票不能小于 0
+remaining tickets = 0
+```
+
+### 2. 实验文件
+
+正确版本：
+
+```text
+ticket_demo.c
+```
+
+无互斥量对比版本：
+
+```text
+ticketdiffer_demo.c
+```
+
+对应 MSH 命令：
+
+```text
+ticket_demo
+ticketdiffer_demo
+```
+
+------
+
+### 3. 无互斥量对比实验
+
+无互斥量版本中，两个线程均直接访问：
+
+```c
+ticket_count
+```
+
+在读取当前票号和修改余票之间故意加入：
+
+```c
+rt_thread_mdelay(50);
+```
+
+其主要过程为：
+
+```c
+ticket_no = ticket_count;
+
+rt_thread_mdelay(50);
+
+ticket_count--;
+```
+
+该延时增加了两个线程同时读取相同 `ticket_count` 的概率。
+
+### 4. 无互斥量实际运行结果
+
+实际运行后出现大量重复票号。
+
+关键输出为：
+
+![abd99143-5245-4c1d-a2c7-bc8249680eaf](figures/abd99143-5245-4c1d-a2c7-bc8249680eaf.png)
+
+```text
+window B sold ticket 20
+window A sold ticket 20
+
+window B sold ticket 18
+window A sold ticket 18
+
+window B sold ticket 16
+window A sold ticket 16
+
+window B sold ticket 14
+window A sold ticket 14
+
+window B sold ticket 12
+window A sold ticket 12
+
+window B sold ticket 10
+window A sold ticket 10
+
+window B sold ticket 8
+window A sold ticket 8
+
+window B sold ticket 6
+window A sold ticket 6
+
+...
+```
+
+后续票号 4 和票号 2 同样出现两个窗口同时输出的情况。
+
+最终：
+
+```text
+all tickets sold
+remaining tickets: 0
+ticket differ demo finished
+```
+
+### 5. 无互斥量结果分析
+
+虽然最终：
+
+```text
+remaining tickets: 0
+```
+
+但售票过程并不正确。
+
+例如初始：
+
+```text
+ticket_count = 20
+```
+
+两个线程可能执行：
+
+```text
+窗口 A 读取 ticket_count = 20
+窗口 B 读取 ticket_count = 20
+```
+
+因此两个线程保存的票号均为：
+
+```text
+ticket_no = 20
+```
+
+随后两个线程分别执行：
+
+```c
+ticket_count--;
+```
+
+虽然 `ticket_count` 最终从 20 减少到 18，但是两个窗口打印出的票号均为：
+
+```text
+ticket 20
+```
+
+于是出现：
+
+```text
+20、20
+18、18
+16、16
+...
+```
+
+说明“读取票号”和“修改余票”并不是一个不可分割的操作，从而产生竞态条件。
+
+------
+
+### 6. 加入互斥量实验
+
+正确版本使用：
+
+```c
+rt_mutex_take()
+```
+
+获取互斥量。
+
+完整的以下过程均放入临界区：
+
+```text
+检查余票
+   ↓
+读取当前票号
+   ↓
+修改剩余票数
+   ↓
+打印售票结果
+```
+
+完成后调用：
+
+```c
+rt_mutex_release()
+```
+
+释放互斥量。
+
+所有线程完成后调用：
+
+![e5f26e3a-f99e-46ea-bd29-4e8cdb92c3d3](figures/e5f26e3a-f99e-46ea-bd29-4e8cdb92c3d3.png)
+
+```c
+rt_mutex_delete()
+```
+
+删除互斥量对象。
+
+### 7. 加互斥量实际运行结果
+
+实际输出：
+
+```text
+window B sold ticket 20
+window A sold ticket 19
+window B sold ticket 18
+window A sold ticket 17
+window B sold ticket 16
+window A sold ticket 15
+window B sold ticket 14
+window A sold ticket 13
+window B sold ticket 12
+window A sold ticket 11
+window B sold ticket 10
+window A sold ticket 9
+window B sold ticket 8
+window A sold ticket 7
+window B sold ticket 6
+window A sold ticket 5
+window B sold ticket 4
+window A sold ticket 3
+window B sold ticket 2
+window A sold ticket 1
+
+all tickets sold
+remaining tickets: 0
+ticket demo finished
+```
+
+### 8. 对比结果
+
+| 对比项           | 无 Mutex         | 使用 Mutex        |
+| ---------------- | ---------------- | ----------------- |
+| 初始票数         | 20               | 20                |
+| 两个窗口并发运行 | 是               | 是                |
+| 重复售票         | 大量出现         | 未出现            |
+| 实际票号         | 20、20、18、18…… | 20、19、18、17……1 |
+| 最终余票         | 0                | 0                 |
+| 是否存在竞态条件 | 是               | 否                |
+| 售票结果         | 错误             | 正确              |
+
+实验说明，即使最终余票为 0，也不能说明并发程序一定正确，还必须检查每次共享数据操作是否保持一致性。
+
+### 9. 问题与解决方法
+
+无互斥量实验中出现了两个窗口售出相同票号的问题。
+
+原因是两个线程可以在同一时刻读取同一个 `ticket_count`，随后分别修改共享变量。
+
+解决方法是使用互斥量，将：
+
+```text
+检查余票
+读取票号
+余票减 1
+记录结果
+```
+
+作为一个完整的临界区进行保护。
+
+### 10. 思考题
+
+**为什么只给 `ticket_count--` 加锁仍可能不安全？**
+
+售票操作不仅包含 `ticket_count--`，还包含检查余票和读取当前票号。
+
+如果两个线程在获取锁之前都执行：
+
+```c
+ticket_no = ticket_count;
+```
+
+那么两个线程仍然可能读取到相同票号。
+
+即使随后：
+
+```c
+ticket_count--;
+```
+
+分别受到互斥保护，也已经无法避免重复售票。
+
+因此需要保护完整的售票过程，而不能只保护单独的一条减法语句。
+
+------
+
+## 实验三：系统启动条件检查
+
+### 实验大纲
+
+| 项目           | 内容                                                         |
+| -------------- | ------------------------------------------------------------ |
+| 是什么知识点   | 事件集 `Event`、事件位、`RT_EVENT_FLAG_AND`、事件超时等待    |
+| 为什么要这么做 | 系统启动需要同时满足网络、传感器和存储三个独立条件，单个条件完成时业务线程不能提前启动 |
+| 意义是什么     | 掌握一个线程同时等待多个条件的方法，理解事件集在多条件同步场景中的优势 |
+
+### 1. 实验目的
+
+模拟系统启动过程中的三个独立模块：
+
+```text
+网络模块
+传感器模块
+存储模块
+```
+
+分别定义三个事件：
+
+```c
+#define EVENT_NET_READY      (1U << 0)
+#define EVENT_SENSOR_READY   (1U << 1)
+#define EVENT_STORAGE_READY  (1U << 2)
+```
+
+主业务线程使用 AND 模式等待三个事件全部完成。
+
+同时设置：
+
+```text
+网络初始化：1 秒
+传感器初始化：2 秒
+存储初始化：5 秒
+主业务线程首次最大等待：3 秒
+```
+
+通过该设计验证事件集的 AND 等待以及超时机制。
+
+### 2. 实验文件
+
+```text
+startup_demo.c
+```
+
+MSH 命令：
+
+```text
+startup_demo
+```
+
+### 3. 实验设计
+
+三个初始化线程分别完成初始化后发送对应事件：
+
+```c
+rt_event_send()
+```
+
+主业务线程第一次调用：
+
+```c
+rt_event_recv()
+```
+
+并设置：
+
+```c
+RT_EVENT_FLAG_AND
+```
+
+要求三个事件必须全部满足。
+
+首次等待时间设置为：
+
+```text
+3 秒
+```
+
+由于存储线程需要：
+
+```text
+5 秒
+```
+
+因此第一次等待必然发生超时。
+
+超时后程序检查未完成模块，并再次等待三个事件全部到达。
+
+### 4. 实际运行结果
+
+执行：
+
+```text
+msh >startup_demo
+```
+
+实际输出：
+
+![da3d734b-9772-4860-8a95-941c0695e303](figures/da3d734b-9772-4860-8a95-941c0695e303.png)
+
+```text
+startup demo start
+
+network ready
+sensor ready
+
+wait modules timeout, storage is not ready
+
+storage ready
+
+all modules are ready
+business task started
+startup demo finished
+```
+
+### 5. 实验结果分析
+
+实验启动约 1 秒后：
+
+```text
+network ready
+```
+
+说明网络初始化线程完成。
+
+约 2 秒后：
+
+```text
+sensor ready
+```
+
+说明传感器初始化线程完成。
+
+此时存储模块尚未初始化完成，因此即使已经有两个事件到达，业务线程仍然不能启动。
+
+主业务线程等待 3 秒后输出：
+
+```text
+wait modules timeout, storage is not ready
+```
+
+说明第一次 `rt_event_recv()` 等待发生超时，并正确判断出存储模块尚未完成。
+
+约 5 秒时：
+
+```text
+storage ready
+```
+
+此时：
+
+```text
+NETWORK
+    AND
+SENSOR
+    AND
+STORAGE
+```
+
+三个条件全部满足，因此业务线程继续执行：
+
+```text
+all modules are ready
+business task started
+```
+
+实验结果证明 `RT_EVENT_FLAG_AND` 可以正确实现多个条件全部满足后再继续运行的同步要求。
+
+### 6. 实验数据总结
+
+| 项目             | 实际结果         |
+| ---------------- | ---------------- |
+| 网络初始化时间   | 约 1 s           |
+| 传感器初始化时间 | 约 2 s           |
+| 存储初始化时间   | 约 5 s           |
+| 首次最大等待时间 | 3 s              |
+| 第一次等待       | 超时             |
+| 未完成模块       | Storage          |
+| 第二次等待       | 成功             |
+| 业务线程启动条件 | 三个事件全部到达 |
+| 最终结果         | 正常启动         |
+
+### 7. 问题与解决方法
+
+本实验中的首次超时属于主动设计的测试条件，并不是程序异常。
+
+存储模块延时设置为 5 秒，而业务线程第一次仅等待 3 秒，因此能够稳定触发超时。
+
+超时后没有直接退出业务线程，而是打印未完成模块并再次调用事件等待，使程序能够在存储模块最终完成后继续启动。
+
+### 8. 思考题
+
+**如果使用三个独立信号量，与使用事件集相比有什么区别？**
+
+如果使用三个独立信号量，需要分别创建三个信号量，并由主业务线程依次获取：
+
+```text
+net_sem
+sensor_sem
+storage_sem
+```
+
+程序需要分别维护三个同步对象。
+
+事件集可以使用不同的 bit 表示多个状态：
+
+```text
+bit0：network
+bit1：sensor
+bit2：storage
+```
+
+再使用：
+
+```c
+RT_EVENT_FLAG_AND
+```
+
+一次等待多个条件全部满足。
+
+因此，对于“多个独立条件全部完成后才能继续”的场景，事件集的状态表示和等待逻辑更加集中、直观。
+
+------
+
+## 实验四：快递分拣中心
+
+### 实验大纲
+
+| 项目           | 内容                                                         |
+| -------------- | ------------------------------------------------------------ |
+| 是什么知识点   | 消息队列 `Message Queue`、结构体消息传递、生产者与消费者模型、队列满处理 |
+| 为什么要这么做 | 两个收件线程需要把包含编号、区域和重量的完整快递信息发送给分拣线程，仅使用同步机制无法直接完成结构化数据传输 |
+| 意义是什么     | 掌握线程之间传递复杂数据的方法，并理解消息缓存、发送失败、重试以及生产速度和消费速度不一致时的处理方式 |
+
+### 1. 实验目的
+
+创建两个快递发送线程，每个线程产生 5 条快递信息。
+
+快递使用以下结构：
+
+```c
+struct package_msg
+{
+    rt_uint32_t id;
+    rt_uint8_t region;
+    rt_uint16_t weight;
+};
+```
+
+两个发送线程通过消息队列将快递信息发送给分拣线程。
+
+分拣线程完成：
+
+```text
+快递编号输出
+区域分类
+重量输出
+总数量统计
+各区域数量统计
+总重量统计
+```
+
+消息队列容量限制为 5 条，并记录队列满时的发送失败次数。
+
+### 2. 实验文件
+
+```text
+package_demo.c
+```
+
+MSH 命令：
+
+```text
+package_demo
+```
+
+### 3. 实验设计
+
+消息队列容量设置为：
+
+```c
+#define PACKAGE_QUEUE_SIZE 5
+```
+
+Sender 1 产生：
+
+```text
+1001 ~ 1005
+```
+
+Sender 2 产生：
+
+```text
+2001 ~ 2005
+```
+
+因此不存在快递编号重复问题。
+
+两个发送线程使用：
+
+```c
+rt_mq_send()
+```
+
+发送消息。
+
+分拣线程使用：
+
+```c
+rt_mq_recv()
+```
+
+接收完整的 `package_msg` 数据。
+
+当消息队列已满时：
+
+```c
+rt_mq_send()
+```
+
+发送失败，程序记录：
+
+```c
+send_failed++;
+```
+
+随后等待一段时间并重新发送当前消息，避免快递数据丢失。
+
+最后一个发送线程完成后发送结束消息，分拣线程收到结束消息后输出统计结果并退出。
+
+### 4. 实际运行结果
+
+执行：
+
+```text
+msh >package_demo
+```
+
+实际输出：
+
+![b375f5f5-5d33-47d4-973c-6646adb2c1aa](figures/b375f5f5-5d33-47d4-973c-6646adb2c1aa.png)
+
+```text
+package demo start
+
+package 2001 -> south, weight: 980 g
+package 1001 -> east, weight: 880 g
+package 2002 -> north, weight: 1060 g
+package 1002 -> south, weight: 960 g
+package 1003 -> north, weight: 1040 g
+package 2003 -> east, weight: 1140 g
+package 1004 -> east, weight: 1120 g
+package 2004 -> south, weight: 1220 g
+package 1005 -> south, weight: 1200 g
+package 2005 -> north, weight: 1300 g
+
+total packages: 10
+east: 3, south: 4, north: 3
+total weight: 10900 g
+send failed: 6
+package demo finished
+```
+
+### 5. 实验结果分析
+
+两个发送线程总共产生：
+
+```text
+5 + 5 = 10
+```
+
+条快递消息。
+
+实际分拣结果：
+
+```text
+total packages: 10
+```
+
+说明 10 条快递最终全部被分拣线程成功接收。
+
+各区域统计为：
+
+```text
+east: 3
+south: 4
+north: 3
+```
+
+满足：
+
+```text
+3 + 4 + 3 = 10
+```
+
+总重量统计为：
+
+```text
+10900 g
+```
+
+与 10 条实际快递重量之和一致。
+
+实验中还得到：
+
+```text
+send failed: 6
+```
+
+说明运行过程中消息队列曾经达到容量上限。
+
+由于消息队列只能存储 5 条消息，而两个发送线程同时不断产生消息，分拣线程还需要一定时间处理每一条快递，因此在部分时刻出现：
+
+```text
+生产速度 > 消费速度
+```
+
+导致：
+
+```c
+rt_mq_send()
+```
+
+返回队列满错误。
+
+程序没有直接丢弃该快递，而是在记录一次失败后重新尝试发送，因此虽然出现：
+
+```text
+send failed: 6
+```
+
+最终仍然完成：
+
+```text
+total packages: 10
+```
+
+说明队列满处理和重试逻辑正常。
+
+### 6. 实验数据总结
+
+| 项目            | 实际数据 |
+| --------------- | -------- |
+| 消息队列容量    | 5        |
+| 发送线程数量    | 2        |
+| Sender 1 消息数 | 5        |
+| Sender 2 消息数 | 5        |
+| 总快递数量      | 10       |
+| East            | 3        |
+| South           | 4        |
+| North           | 3        |
+| 总重量          | 10900 g  |
+| 发送失败次数    | 6        |
+| 最终丢失消息    | 0        |
+| 实验结果        | 正常完成 |
+
+### 7. 问题与解决方法
+
+实验中出现：
+
+```text
+send failed: 6
+```
+
+说明部分消息发送时消息队列已经达到容量上限。
+
+如果发送失败后直接进入下一条消息，会导致部分快递丢失，最终：
+
+```text
+total packages
+```
+
+可能小于 10。
+
+因此在发送失败后采用：
+
+```text
+记录失败次数
+    ↓
+短暂延时
+    ↓
+重新发送当前消息
+```
+
+的方式处理。
+
+最终虽然出现 6 次发送失败，但 10 条快递均成功进入消息队列并完成分拣。
+
+同时运行过程中出现：
+
+```text
+msh >package 2001...
+```
+
+属于 MSH 命令提示符与线程打印输出交错，对实验结果无影响。
+
+------
+
+# 实验总结
+
+本次实验分别使用不同 IPC 机制解决不同类型的多线程问题。
+
+| 实验           | IPC 机制      | 主要解决的问题       | 实际结果                       |
+| -------------- | ------------- | -------------------- | ------------------------------ |
+| 停车场车位管理 | Semaphore     | 有限资源数量控制     | 最大同时停车 3 辆              |
+| 多窗口售票     | Mutex         | 共享资源互斥访问     | 20 张票无重复售出              |
+| 售票对比实验   | 无 Mutex      | 验证竞态条件         | 出现大量重复票号               |
+| 系统启动检查   | Event         | 多条件同步           | 3 秒超时，5 秒后三模块全部就绪 |
+| 快递分拣       | Message Queue | 线程间结构化数据通信 | 10 条全部完成，队满 6 次       |
+
+实验结果表明，不同 IPC 机制解决的问题并不相同：
+
+```text
+Semaphore
+    ↓
+控制有限资源数量
+
+Mutex
+    ↓
+保护共享资源
+
+Event
+    ↓
+等待多个条件
+
+Message Queue
+    ↓
+在线程之间传递完整消息
+```
+
+通过实际的线程竞争、超时等待和队列满实验，可以更加直观地观察 RT-Thread IPC 机制在线程同步与线程通信中的作用。
\ No newline at end of file
diff --git "a/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\211\345\244\251\345\255\246\344\271\240\347\254\224\350\256\260.md" "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\211\345\244\251\345\255\246\344\271\240\347\254\224\350\256\260.md"
new file mode 100644
index 0000000..8f5ebf2
--- /dev/null
+++ "b/2026/\347\254\2543\347\273\204/\344\275\225\345\230\211\344\271\220/\347\254\224\350\256\260/\347\254\254\344\270\211\345\244\251\345\255\246\344\271\240\347\254\224\350\256\260.md"
@@ -0,0 +1,1842 @@
+# Day3
+
+## IPC —— 线程间同步与通信
+
+在多线程实时系统中，一个任务通常需要多个线程相互配合完成。不同线程之间可能会访问相同的资源，也可能需要按照一定的先后顺序执行，因此需要使用 **IPC（Inter-Process Communication，线程间通信机制）** 来完成线程之间的同步与数据交换。
+
+RT-Thread 中常用的 IPC 机制主要包括：
+
+### 线程同步
+
+- 信号量 `Semaphore`
+- 互斥量 `Mutex`
+- 事件集 `Event`
+
+### 线程间通信
+
+- 邮箱 `Mailbox`
+- 消息队列 `Message Queue`
+
+其中，信号量、互斥量和事件集主要用于控制多个线程之间的执行顺序以及共享资源访问；邮箱和消息队列主要用于在线程之间传递数据。RT-Thread 的 IPC 对象支持按照 **FIFO** 或 **线程优先级** 管理等待线程。
+
+常用 IPC 等待标志：
+
+```c
+RT_IPC_FLAG_FIFO
+RT_IPC_FLAG_PRIO
+```
+
+含义：
+
+```text
+RT_IPC_FLAG_FIFO
+按照先进先出顺序唤醒等待线程。
+
+RT_IPC_FLAG_PRIO
+按照线程优先级排列等待线程，
+优先级较高的线程优先获得资源。
+```
+
+常用等待时间：
+
+```c
+RT_WAITING_FOREVER
+RT_WAITING_NO
+```
+
+其中：
+
+```text
+RT_WAITING_FOREVER = -1
+一直阻塞，直到获得资源。
+
+RT_WAITING_NO = 0
+不等待，如果资源当前不可用立即返回。
+```
+
+------
+
+## 线程同步
+
+线程同步指多个线程通过一定的机制控制执行顺序，使线程按照预期的次序运行。
+
+例如：
+
+```text
+线程1：采集传感器数据
+        ↓
+     写入共享内存
+        ↓
+线程2：读取共享内存
+        ↓
+      显示数据
+```
+
+如果线程 1 还没有完成数据写入，线程 2 就开始读取数据，可能导致读取到不完整的数据。
+
+因此多个线程访问同一个共享资源时，需要对共享资源进行保护。
+
+多个线程共同访问的代码区域或资源称为：
+
+```text
+临界区（Critical Section）
+```
+
+同一时刻通常只允许一个线程进入临界区。
+
+RT-Thread 中常见的线程同步方式包括：
+
+```text
+信号量
+互斥量
+事件集
+```
+
+除此之外，还可以通过：
+
+```c
+rt_enter_critical();
+rt_exit_critical();
+```
+
+进入和退出临界区。RT-Thread 官方文档将线程同步描述为通过互斥量、事件对象、临界区等机制建立线程之间的执行顺序关系。
+
+------
+
+# 信号量 Semaphore
+
+## 信号量基本概念
+
+信号量是一种轻量级的内核对象，可以用于解决线程之间的：
+
+```text
+同步
++
+互斥
+```
+
+问题。
+
+可以将信号量理解为一个 **资源计数器**。
+
+例如停车场共有 5 个停车位：
+
+```text
+信号量初值 = 5
+```
+
+一辆车进入停车场：
+
+```text
+获取一个信号量
+
+5 → 4
+```
+
+一辆车离开停车场：
+
+```text
+释放一个信号量
+
+4 → 5
+```
+
+如果：
+
+```text
+信号量 = 0
+```
+
+表示当前已经没有可用资源。
+
+此时继续申请信号量的线程会进入等待状态，直到其他线程释放信号量。RT-Thread 中每个信号量都包含一个信号量值以及一个等待线程队列。
+
+------
+
+## 信号量控制块
+
+RT-Thread 使用：
+
+```c
+struct rt_semaphore
+```
+
+管理信号量。
+
+信号量句柄类型为：
+
+```c
+rt_sem_t
+```
+
+其本质是一个指向信号量控制块的指针。
+
+```c
+typedef struct rt_semaphore *rt_sem_t;
+```
+
+------
+
+## 信号量的基本操作
+
+信号量的生命周期可以概括为：
+
+```text
+创建
+ ↓
+获取
+ ↓
+使用资源
+ ↓
+释放
+ ↓
+删除
+```
+
+即：
+
+```c
+rt_sem_create()
+       ↓
+rt_sem_take()
+       ↓
+   临界区
+       ↓
+rt_sem_release()
+       ↓
+rt_sem_delete()
+```
+
+对于静态信号量则为：
+
+```c
+rt_sem_init()
+       ↓
+rt_sem_take()
+       ↓
+rt_sem_release()
+       ↓
+rt_sem_detach()
+```
+
+官方手册明确将信号量操作划分为创建/初始化、获取、释放以及删除/脱离。
+
+------
+
+## 创建信号量
+
+动态创建信号量：
+
+```c
+rt_sem_t rt_sem_create(const char *name,
+                       rt_uint32_t value,
+                       rt_uint8_t flag);
+```
+
+参数：
+
+| 参数    | 说明               |
+| ------- | ------------------ |
+| `name`  | 信号量名称         |
+| `value` | 信号量初始值       |
+| `flag`  | 等待线程的排队方式 |
+
+其中 `flag` 可以为：
+
+```c
+RT_IPC_FLAG_FIFO
+```
+
+或者：
+
+```c
+RT_IPC_FLAG_PRIO
+```
+
+例如：
+
+```c
+rt_sem_t sem;
+
+sem = rt_sem_create("sem",
+                    0,
+                    RT_IPC_FLAG_FIFO);
+```
+
+这里：
+
+```text
+名称 = sem
+初值 = 0
+等待方式 = FIFO
+```
+
+创建成功返回信号量句柄，创建失败返回：
+
+```c
+RT_NULL
+```
+
+------
+
+## 获取信号量
+
+线程通过：
+
+```c
+rt_sem_take()
+```
+
+获取信号量。
+
+基本形式：
+
+```c
+rt_sem_take(sem, timeout);
+```
+
+例如：
+
+```c
+rt_sem_take(sem, RT_WAITING_FOREVER);
+```
+
+表示：
+
+```text
+如果当前存在信号量：
+    信号量值 -1
+    线程继续运行
+
+如果当前信号量为 0：
+    当前线程挂起
+    一直等待其他线程释放信号量
+```
+
+也可以使用：
+
+```c
+rt_sem_take(sem, RT_WAITING_NO);
+```
+
+表示：
+
+```text
+不等待。
+
+如果当前无法获得信号量，
+立即返回。
+```
+
+------
+
+## 释放信号量
+
+线程完成操作之后，可以释放信号量：
+
+```c
+rt_sem_release(sem);
+```
+
+例如：
+
+```c
+rt_sem_release(sem);
+```
+
+其作用可以理解为：
+
+```text
+信号量值 +1
+```
+
+如果当前已经有线程因为等待这个信号量而挂起，则释放信号量后，系统会唤醒相应的等待线程。
+
+因此一种非常常见的线程同步方式为：
+
+```text
+线程 A
+    |
+完成某项工作
+    |
+rt_sem_release()
+    |
+    V
+信号量
+    |
+rt_sem_take()
+    |
+线程 B
+    |
+继续执行
+```
+
+------
+
+## 删除信号量
+
+使用：
+
+```c
+rt_sem_create()
+```
+
+动态创建的信号量，在不再使用时需要调用：
+
+```c
+rt_sem_delete();
+```
+
+函数：
+
+```c
+rt_err_t rt_sem_delete(rt_sem_t sem);
+```
+
+例如：
+
+```c
+rt_sem_delete(sem);
+```
+
+删除信号量后，系统会释放对应的内存资源。
+
+如果此时仍有线程等待该信号量，RT-Thread 会先唤醒这些线程，这些等待线程得到：
+
+```c
+-RT_ERROR
+```
+
+随后再释放信号量占用的内存。
+
+------
+
+## 静态信号量
+
+如果不希望动态申请内存，也可以使用静态信号量。
+
+首先定义：
+
+```c
+static struct rt_semaphore sem;
+```
+
+初始化：
+
+```c
+rt_sem_init(&sem,
+            "sem",
+            0,
+            RT_IPC_FLAG_FIFO);
+```
+
+使用结束后：
+
+```c
+rt_sem_detach(&sem);
+```
+
+因此：
+
+```text
+动态对象
+
+rt_sem_create()
+rt_sem_delete()
+```
+
+对应：
+
+```text
+静态对象
+
+rt_sem_init()
+rt_sem_detach()
+```
+
+------
+
+## 信号量同步示例
+
+假设：
+
+```text
+线程1负责采集数据
+线程2负责处理数据
+```
+
+线程 2 必须等线程 1 采集完成后才能运行。
+
+可以建立：
+
+```c
+static rt_sem_t sem;
+```
+
+创建：
+
+```c
+sem = rt_sem_create("sem",
+                    0,
+                    RT_IPC_FLAG_FIFO);
+```
+
+线程 1：
+
+```c
+void thread1_entry(void *parameter)
+{
+    while (1)
+    {
+        /* 采集数据 */
+
+        rt_kprintf("thread1: data ready\n");
+
+        rt_sem_release(sem);
+
+        rt_thread_mdelay(1000);
+    }
+}
+```
+
+线程 2：
+
+```c
+void thread2_entry(void *parameter)
+{
+    while (1)
+    {
+        rt_sem_take(sem, RT_WAITING_FOREVER);
+
+        rt_kprintf("thread2: process data\n");
+    }
+}
+```
+
+执行过程：
+
+```text
+thread2
+   |
+rt_sem_take()
+   |
+信号量 = 0
+   |
+线程挂起
+   |
+thread1
+   |
+采集完成
+   |
+rt_sem_release()
+   |
+唤醒 thread2
+   |
+thread2 继续运行
+```
+
+------
+
+# 互斥量 Mutex
+
+## 互斥量基本概念
+
+互斥量主要用于：
+
+```text
+保护共享资源
+```
+
+例如两个线程同时操作串口：
+
+```text
+Thread 1 ----\
+              ---> UART
+Thread 2 ----/
+```
+
+如果两个线程同时输出数据，可能导致输出内容混乱。
+
+因此可以添加互斥量：
+
+```text
+Thread 1
+   |
+获取 Mutex
+   |
+使用 UART
+   |
+释放 Mutex
+
+Thread 2
+   |
+等待 Mutex
+   |
+使用 UART
+```
+
+从而保证：
+
+```text
+同一时刻只有一个线程访问 UART
+```
+
+------
+
+## 互斥量和信号量的区别
+
+互斥量可以看作一种特殊的二值信号量，但它具有：
+
+```text
+所有权
+递归获取
+优先级继承
+```
+
+等特点。
+
+RT-Thread 官方文档指出，互斥量可以避免实时系统中常见的 **优先级翻转问题**。
+
+------
+
+## 优先级翻转
+
+假设三个线程：
+
+```text
+Thread A    高优先级
+Thread B    中优先级
+Thread C    低优先级
+```
+
+Thread C 先获得共享资源：
+
+```text
+C 获取 Mutex
+```
+
+此时高优先级 Thread A 也需要这个资源：
+
+```text
+A 等待 C
+```
+
+但是 Thread B 又抢占了 C：
+
+```text
+B 抢占 C
+```
+
+最终出现：
+
+```text
+高优先级 A
+
+却必须等待
+
+中优先级 B
+```
+
+这就是：
+
+```text
+优先级翻转
+```
+
+RT-Thread 的互斥量使用 **优先级继承**：
+
+```text
+C 原本：低优先级
+
+A 等待 C 后：
+
+C 临时继承 A 的高优先级
+
+C 快速执行完临界区
+ ↓
+释放 Mutex
+ ↓
+优先级恢复
+```
+
+从而降低优先级翻转造成的影响。
+
+------
+
+## 创建互斥量
+
+```c
+rt_mutex_t rt_mutex_create(const char *name,
+                           rt_uint8_t flag);
+```
+
+例如：
+
+```c
+rt_mutex_t mutex;
+
+mutex = rt_mutex_create("mutex",
+                        RT_IPC_FLAG_PRIO);
+```
+
+创建失败返回：
+
+```c
+RT_NULL
+```
+
+------
+
+## 获取互斥量
+
+```c
+rt_mutex_take(mutex,
+              RT_WAITING_FOREVER);
+```
+
+获取成功后：
+
+```text
+当前线程成为 Mutex 的拥有者
+```
+
+其他线程如果再次申请：
+
+```text
+进入等待状态
+```
+
+但是拥有 Mutex 的线程本身可以再次获取同一个 Mutex，即支持：
+
+```text
+递归获取
+```
+
+------
+
+## 释放互斥量
+
+```c
+rt_mutex_release(mutex);
+```
+
+使用原则：
+
+```c
+rt_mutex_take()
+        ↓
+     临界区
+        ↓
+rt_mutex_release()
+```
+
+互斥量获取后应该尽快释放，避免长时间占用共享资源。RT-Thread 官方还特别指出，在持有互斥量期间不应修改持有线程的优先级。
+
+------
+
+## 删除互斥量
+
+动态创建：
+
+```c
+rt_mutex_create()
+```
+
+对应删除：
+
+```c
+rt_mutex_delete(mutex);
+```
+
+函数：
+
+```c
+rt_err_t rt_mutex_delete(rt_mutex_t mutex);
+```
+
+删除时如果还有线程等待该互斥量，等待线程会被唤醒并返回：
+
+```c
+-RT_ERROR
+```
+
+------
+
+## 静态互斥量
+
+静态初始化：
+
+```c
+rt_mutex_init();
+```
+
+例如：
+
+```c
+static struct rt_mutex mutex;
+
+rt_mutex_init(&mutex,
+              "mutex",
+              RT_IPC_FLAG_PRIO);
+```
+
+不再使用：
+
+```c
+rt_mutex_detach(&mutex);
+```
+
+因此：
+
+```text
+动态：
+create → delete
+
+静态：
+init → detach
+```
+
+------
+
+## 互斥量注意事项
+
+互斥量不能用于：
+
+```text
+中断服务程序 ISR
+```
+
+因为互斥量具有线程所有权和阻塞等待机制。
+
+因此：
+
+```c
+/* 不要在 ISR 中这样做 */
+rt_mutex_take(...);
+```
+
+RT-Thread 官方明确规定 Mutex 不能在中断服务程序中使用。
+
+------
+
+# 事件集 Event
+
+## 事件集基本概念
+
+信号量通常用于：
+
+```text
+等待一个条件
+```
+
+而事件集可以让线程同时等待：
+
+```text
+多个事件
+```
+
+RT-Thread 中一个事件集使用一个：
+
+```c
+rt_uint32_t
+```
+
+来保存事件，因此一个事件集可以表示：
+
+```text
+32 个事件
+```
+
+每一个 bit 表示一个事件：
+
+```text
+bit0  → Event 0
+bit1  → Event 1
+bit2  → Event 2
+
+...
+
+bit31 → Event 31
+```
+
+例如：
+
+```c
+#define EVENT_KEY1 (1 << 0)
+#define EVENT_KEY2 (1 << 1)
+#define EVENT_UART (1 << 2)
+```
+
+------
+
+## 事件触发方式
+
+事件集支持：
+
+```c
+RT_EVENT_FLAG_OR
+```
+
+和：
+
+```c
+RT_EVENT_FLAG_AND
+```
+
+### OR
+
+```c
+RT_EVENT_FLAG_OR
+```
+
+表示：
+
+```text
+任意一个指定事件发生
+即可唤醒线程。
+```
+
+例如：
+
+```text
+等待：
+
+EVENT1 | EVENT2
+
+只要：
+
+EVENT1
+
+或者：
+
+EVENT2
+
+任意一个发生即可。
+```
+
+------
+
+### AND
+
+```c
+RT_EVENT_FLAG_AND
+```
+
+表示：
+
+```text
+所有指定事件全部发生后
+才唤醒线程。
+```
+
+例如：
+
+```text
+EVENT1
++
+EVENT2
+```
+
+必须两个事件都已经发生才能满足条件。
+
+RT-Thread 还支持：
+
+```c
+RT_EVENT_FLAG_CLEAR
+```
+
+表示线程成功接收到事件以后：
+
+```text
+自动清除对应事件标志位
+```
+
+------
+
+## 创建事件集
+
+```c
+rt_event_t rt_event_create(const char *name,
+                           rt_uint8_t flag);
+```
+
+例如：
+
+```c
+rt_event_t event;
+
+event = rt_event_create("event",
+                        RT_IPC_FLAG_FIFO);
+```
+
+------
+
+## 发送事件
+
+使用：
+
+```c
+rt_event_send();
+```
+
+例如：
+
+```c
+rt_event_send(event, EVENT_KEY1);
+```
+
+表示：
+
+```text
+EVENT_KEY1 发生
+```
+
+可以一次发送多个事件：
+
+```c
+rt_event_send(event,
+              EVENT_KEY1 | EVENT_KEY2);
+```
+
+------
+
+## 接收事件
+
+使用：
+
+```c
+rt_event_recv();
+```
+
+典型形式：
+
+```c
+rt_event_recv(event,
+              EVENT_KEY1 | EVENT_KEY2,
+              RT_EVENT_FLAG_OR |
+              RT_EVENT_FLAG_CLEAR,
+              RT_WAITING_FOREVER,
+              &received);
+```
+
+含义：
+
+```text
+等待 EVENT_KEY1 或 EVENT_KEY2
+
+任意一个发生即可唤醒
+
+接收成功后自动清除事件
+
+如果没有事件则一直等待
+```
+
+------
+
+## 删除事件集
+
+动态创建：
+
+```c
+rt_event_create()
+```
+
+对应：
+
+```c
+rt_event_delete(event);
+```
+
+静态事件集则：
+
+```c
+rt_event_init();
+```
+
+最终使用：
+
+```c
+rt_event_detach();
+```
+
+官方事件集管理接口包括创建/初始化、发送、接收和删除/脱离。
+
+------
+
+# 线程之间的通信
+
+线程同步主要解决：
+
+```text
+什么时候执行？
+谁先执行？
+谁能访问资源？
+```
+
+线程通信主要解决：
+
+```text
+线程之间传递什么数据？
+```
+
+RT-Thread 中常用：
+
+```text
+Mailbox
+Message Queue
+```
+
+即：
+
+```text
+邮箱
+消息队列
+```
+
+------
+
+# 邮箱 Mailbox
+
+## 邮箱基本原理
+
+邮箱是一种开销较低、效率较高的线程通信机制。
+
+基本结构：
+
+```text
+Thread 1
+   |
+发送邮件
+   |
+   V
++---------+
+| Mailbox |
++---------+
+   |
+接收邮件
+   |
+Thread 2
+```
+
+RT-Thread 的邮箱中：
+
+```text
+每封邮件固定为 4 字节
+```
+
+在 32 位系统中：
+
+```text
+一个指针通常也是 4 字节
+```
+
+因此邮箱除了发送：
+
+```text
+整数
+状态
+命令
+```
+
+也可以发送：
+
+```text
+数据指针
+```
+
+------
+
+## 创建邮箱
+
+```c
+rt_mailbox_t rt_mb_create(const char *name,
+                          rt_size_t size,
+                          rt_uint8_t flag);
+```
+
+其中：
+
+```text
+name
+邮箱名称
+
+size
+邮箱容量，即可以保存多少封邮件
+
+flag
+FIFO / PRIO
+```
+
+例如：
+
+```c
+rt_mailbox_t mb;
+
+mb = rt_mb_create("mb",
+                  8,
+                  RT_IPC_FLAG_FIFO);
+```
+
+表示：
+
+```text
+邮箱最多保存 8 封邮件
+```
+
+每封邮件为 4 字节。
+
+------
+
+## 发送邮件
+
+普通发送：
+
+```c
+rt_mb_send(mb, value);
+```
+
+例如：
+
+```c
+rt_mb_send(mb, 100);
+```
+
+如果邮箱未满：
+
+```text
+数据写入邮箱
+```
+
+邮箱非阻塞发送可以安全地用于中断服务程序。
+
+------
+
+## 等待发送
+
+也可以：
+
+```c
+rt_mb_send_wait(mb,
+                value,
+                timeout);
+```
+
+如果邮箱已经满了，可以等待邮箱出现空闲空间。
+
+------
+
+## 接收邮件
+
+```c
+rt_mb_recv(mb,
+           &value,
+           timeout);
+```
+
+例如：
+
+```c
+rt_ubase_t value;
+
+rt_mb_recv(mb,
+           &value,
+           RT_WAITING_FOREVER);
+```
+
+如果邮箱为空：
+
+```text
+当前线程挂起
+```
+
+收到新邮件后：
+
+```text
+线程被唤醒
+```
+
+如果设置了超时时间，并且一直没有邮件，则返回超时错误。
+
+------
+
+## 删除邮箱
+
+动态邮箱：
+
+```c
+rt_mb_delete(mb);
+```
+
+完整生命周期：
+
+```text
+rt_mb_create()
+      ↓
+rt_mb_send()
+      ↓
+rt_mb_recv()
+      ↓
+rt_mb_delete()
+```
+
+静态邮箱：
+
+```text
+rt_mb_init()
+      ↓
+发送 / 接收
+      ↓
+rt_mb_detach()
+```
+
+动态创建的邮箱不再使用时应通过 `rt_mb_delete()` 释放对应系统资源。
+
+------
+
+# 消息队列 Message Queue
+
+## 消息队列基本概念
+
+消息队列也是一种常见的线程间通信方式，可以认为是邮箱的扩展。
+
+邮箱：
+
+```text
+固定 4 字节
+```
+
+消息队列：
+
+```text
+可以传输长度大于 4 字节的消息
+```
+
+因此消息队列更适合传输：
+
+```text
+结构体
+传感器数据
+UART 数据
+协议数据包
+复杂消息
+```
+
+RT-Thread 消息队列可以接收来自：
+
+```text
+线程
+中断服务程序
+```
+
+发送的消息，并将这些消息缓存到内部存储空间。普通消息按照 FIFO 顺序传递。
+
+------
+
+## 创建消息队列
+
+```c
+rt_mq_t rt_mq_create(const char *name,
+                     rt_size_t msg_size,
+                     rt_size_t max_msgs,
+                     rt_uint8_t flag);
+```
+
+例如：
+
+```c
+rt_mq_t mq;
+
+mq = rt_mq_create("mq",
+                  sizeof(struct msg),
+                  10,
+                  RT_IPC_FLAG_FIFO);
+```
+
+参数：
+
+| 参数       | 含义                   |
+| ---------- | ---------------------- |
+| `name`     | 消息队列名称           |
+| `msg_size` | 单条消息最大长度       |
+| `max_msgs` | 最多能够存储多少条消息 |
+| `flag`     | FIFO 或 PRIO           |
+
+------
+
+## 发送消息
+
+使用：
+
+```c
+rt_mq_send();
+```
+
+例如：
+
+```c
+struct msg
+{
+    rt_uint32_t id;
+    rt_uint32_t value;
+};
+
+struct msg data;
+
+data.id = 1;
+data.value = 100;
+
+rt_mq_send(mq,
+           &data,
+           sizeof(data));
+```
+
+消息的数据本身会被复制进消息队列。
+
+------
+
+## 等待发送
+
+如果需要在消息队列满时等待：
+
+```c
+rt_mq_send_wait();
+```
+
+可以指定等待时间。
+
+------
+
+## 紧急消息
+
+消息队列还支持：
+
+```c
+rt_mq_urgent();
+```
+
+普通消息：
+
+```text
+插入队列尾部
+```
+
+紧急消息：
+
+```text
+插入队列头部
+```
+
+所以紧急消息会比普通消息更早被接收。
+
+------
+
+## 接收消息
+
+```c
+rt_mq_recv();
+```
+
+例如：
+
+```c
+struct msg data;
+
+rt_mq_recv(mq,
+           &data,
+           sizeof(data),
+           RT_WAITING_FOREVER);
+```
+
+如果当前队列为空：
+
+```text
+接收线程挂起
+```
+
+当新的消息进入：
+
+```text
+线程被唤醒
+```
+
+然后读取消息并继续执行。
+
+------
+
+## 删除消息队列
+
+动态创建：
+
+```c
+rt_mq_create()
+```
+
+对应：
+
+```c
+rt_mq_delete(mq);
+```
+
+完整过程：
+
+```text
+rt_mq_create()
+      ↓
+rt_mq_send()
+      ↓
+rt_mq_recv()
+      ↓
+rt_mq_delete()
+```
+
+如果使用静态消息队列：
+
+```text
+rt_mq_init()
+      ↓
+发送 / 接收
+      ↓
+rt_mq_detach()
+```
+
+RT-Thread 官方将消息队列的主要操作归纳为创建、发送、接收和删除，并为静态对象提供 `rt_mq_init()`。
+
+------
+
+# 邮箱与消息队列的区别
+
+| 对比                   | 邮箱 Mailbox       | 消息队列 Message Queue |
+| ---------------------- | ------------------ | ---------------------- |
+| 单条消息大小           | 固定 4 字节        | 可自定义               |
+| 数据类型               | 整数、状态、指针等 | 数组、结构体、数据块等 |
+| 内存开销               | 较小               | 相对较大               |
+| 效率                   | 较高               | 相对较低               |
+| 是否缓存消息           | 是                 | 是                     |
+| 普通发送是否可用于 ISR | 可以               | 可以                   |
+| 接收是否可阻塞         | 可以               | 可以                   |
+| 是否支持紧急消息       | 否                 | 是，`rt_mq_urgent()`   |
+
+因此：
+
+```text
+简单状态、命令、指针
+        ↓
+      Mailbox
+```
+
+而：
+
+```text
+结构体、数据包、较大的消息
+        ↓
+   Message Queue
+```
+
+------
+
+# IPC 使用场景总结
+
+## 信号量
+
+主要解决：
+
+```text
+线程同步
+资源计数
+```
+
+典型场景：
+
+```text
+采集线程完成
+      ↓
+release semaphore
+      ↓
+处理线程开始运行
+```
+
+------
+
+## 互斥量
+
+主要解决：
+
+```text
+共享资源互斥访问
+```
+
+典型场景：
+
+```text
+UART
+I2C
+SPI
+共享数据结构
+文件系统资源
+```
+
+------
+
+## 事件集
+
+主要解决：
+
+```text
+一个线程等待多个条件
+```
+
+例如：
+
+```text
+网络连接成功
+     AND
+设备初始化完成
+     AND
+传感器准备完成
+```
+
+满足全部条件后线程开始工作。
+
+------
+
+## 邮箱
+
+主要解决：
+
+```text
+小数据、高效率线程通信
+```
+
+例如：
+
+```text
+按键状态
+命令
+ADC 数值
+对象指针
+```
+
+------
+
+## 消息队列
+
+主要解决：
+
+```text
+较复杂的数据传输
+```
+
+例如：
+
+```text
+传感器数据结构体
+UART 数据包
+控制命令结构体
+协议消息
+```
+
+------
+
+# IPC 生命周期总结
+
+这是使用 RT-Thread IPC 时非常重要的一组对应关系：
+
+| IPC      | 动态创建            | 动态删除            | 静态初始化        | 静态脱离            |
+| -------- | ------------------- | ------------------- | ----------------- | ------------------- |
+| 信号量   | `rt_sem_create()`   | `rt_sem_delete()`   | `rt_sem_init()`   | `rt_sem_detach()`   |
+| 互斥量   | `rt_mutex_create()` | `rt_mutex_delete()` | `rt_mutex_init()` | `rt_mutex_detach()` |
+| 事件集   | `rt_event_create()` | `rt_event_delete()` | `rt_event_init()` | `rt_event_detach()` |
+| 邮箱     | `rt_mb_create()`    | `rt_mb_delete()`    | `rt_mb_init()`    | `rt_mb_detach()`    |
+| 消息队列 | `rt_mq_create()`    | `rt_mq_delete()`    | `rt_mq_init()`    | `rt_mq_detach()`    |
+
+可以统一记忆为：
+
+```text
+动态对象：
+
+create
+  ↓
+使用
+  ↓
+delete
+```
+
+静态对象：
+
+```text
+init
+ ↓
+使用
+ ↓
+detach
+```
+
+------
+
+# 常用 API 总结
+
+## Semaphore
+
+```c
+rt_sem_create()
+rt_sem_delete()
+
+rt_sem_init()
+rt_sem_detach()
+
+rt_sem_take()
+rt_sem_release()
+```
+
+------
+
+## Mutex
+
+```c
+rt_mutex_create()
+rt_mutex_delete()
+
+rt_mutex_init()
+rt_mutex_detach()
+
+rt_mutex_take()
+rt_mutex_release()
+```
+
+------
+
+## Event
+
+```c
+rt_event_create()
+rt_event_delete()
+
+rt_event_init()
+rt_event_detach()
+
+rt_event_send()
+rt_event_recv()
+```
+
+------
+
+## Mailbox
+
+```c
+rt_mb_create()
+rt_mb_delete()
+
+rt_mb_init()
+rt_mb_detach()
+
+rt_mb_send()
+rt_mb_send_wait()
+rt_mb_recv()
+```
+
+------
+
+## Message Queue
+
+```c
+rt_mq_create()
+rt_mq_delete()
+
+rt_mq_init()
+rt_mq_detach()
+
+rt_mq_send()
+rt_mq_send_wait()
+rt_mq_urgent()
+rt_mq_recv()
+```
+
+------
+
+# Day3 理论总结
+
+RT-Thread 的 IPC 机制主要解决两个问题：
+
+```text
+同步
++
+通信
+```
+
+其中：
+
+```text
+Semaphore
+    ↓
+控制线程执行顺序、资源数量
+
+Mutex
+    ↓
+保护共享资源
+
+Event
+    ↓
+等待一个或多个事件条件
+
+Mailbox
+    ↓
+传递简单的 4 字节消息
+
+Message Queue
+    ↓
+传递较复杂的数据
+```
+
+可以进一步记忆为：
+
+```text
+          RT-Thread IPC
+               |
+       +-------+-------+
+       |               |
+     同步              通信
+       |               |
+   +---+---+        +--+--+
+   |   |   |        |     |
+ Sem Mutex Event   Mailbox MQ
+```
+
+信号量重点记住：
+
+```c
+rt_sem_create()
+rt_sem_take()
+rt_sem_release()
+rt_sem_delete()
+```
+
+互斥量重点记住：
+
+```c
+rt_mutex_create()
+rt_mutex_take()
+rt_mutex_release()
+rt_mutex_delete()
+```
+
+事件集重点记住：
+
+```c
+RT_EVENT_FLAG_OR
+RT_EVENT_FLAG_AND
+RT_EVENT_FLAG_CLEAR
+```
+
+线程通信重点区分：
+
+```text
+Mailbox
+    固定 4 字节
+    开销小、效率高
+
+Message Queue
+    消息长度可配置
+    可以传递结构体等复杂数据
+```
+
+在实际 RT-Thread 程序中，应根据不同应用需求选择合适的 IPC 机制，而不是仅使用全局变量在线程之间交换信息。
\ No newline at end of file
-- 
Gitee