今天主要复盘了两个部分：一是Keil 工程配置中的 Linker、Scatter File、时钟配置问题；二是FreeRTOS 内核中链表结构、类型转换和常用宏定义的理解。
一、Keil 中 Linker 和 Scatter File 的理解
一开始遇到的报错是：
Error: L6218E: Undefined symbol Image$$ARM_LIB_STACK$$ZI$$Limit这个错误不是main.c的语法问题，而是链接阶段的问题。
Keil 构建工程大致分为几个阶段：
.c 文件 ↓ 编译 .o 目标文件 ↓ 链接 .axf 可执行文件 ↓ 下载/调试其中Compiler 编译器负责把每个.c文件单独编译成.o文件，而Linker 链接器负责把这些.o文件组合起来，生成最终的.axf文件。
Linker 主要做三件事：
- 把多个
.o文件合并成完整程序； - 解决函数、变量之间的引用关系；
- 根据内存布局文件，把代码和数据放到正确的 Flash/RAM 地址中。
Keil 里面的.sct文件就是Scatter File，也就是内存布局说明文件。它告诉链接器：
代码放在哪里 只读数据放在哪里 全局变量放在哪里 堆和栈放在哪里比如 Cortex-M3 常见地址是：
Flash 起始地址：0x00000000 RAM 起始地址：0x20000000之前报错的原因是启动文件需要一个栈顶地址符号：
Image$$ARM_LIB_STACK$$ZI$$Limit但是 Linker 没有从当前的 Scatter File 中找到对应的栈区定义，所以无法生成这个符号。后来把 Scatter File 修改成：
.\RTE\Device\ARMCM3\ARMCM3_ac6.sct参考博客：Keil5报错：Error: L6218E: Undefined symbol Image$$ARM_LIB_STACK$$ZI$$Limit_keil5 l6218e-CSDN博客
二、UL、U这类整数后缀的含义
在system_ARMCM3.c里面看到：
#define XTAL (50000000UL) #define SYSTEM_CLOCK (XTAL / 2U)这里的UL是 C 语言整数常量后缀。
U = unsigned，无符号 L = long，长整型 UL = unsigned long，无符号长整型所以：
50000000UL表示这个数字是一个unsigned long类型的常量。
而：
2U表示数字2是一个unsigned int类型。
这样写的好处是类型更明确，尤其在嵌入式里，时钟频率、寄存器值、地址值通常都希望使用无符号类型，避免符号扩展或者编译警告。
这段代码的含义是：
XTAL = 50 MHz SYSTEM_CLOCK = XTAL / 2 = 25 MHz也就是系统时钟为 25 MHz。
三、Keil 中 Xtal 灰色无法修改的原因
在 Keil 的 Target 页面里看到：
Xtal (MHz): <undefined>而且是灰色的，无法修改。
原因是当前工程选择的是：
ARM ARMCM3这是一个通用 Cortex-M3 内核模板，不是某一颗真实芯片。Keil 不知道这颗“芯片”的外部晶振是多少 MHz，所以这个地方显示<undefined>，并且不能修改。
如果选择真实芯片，例如 STM32F103、LPC1768 等，Keil 可能会根据芯片包提供更多可配置项。
四、FreeRTOS 链表的基本结构
今天重点学习了 FreeRTOS 的链表机制。
FreeRTOS 链表不是普通的NULL结尾链表，而是一个带哨兵节点的双向循环链表。
核心结构有三个：
typedef struct xLIST_ITEM { TickType_t xItemValue; struct xLIST_ITEM * pxNext; struct xLIST_ITEM * pxPrevious; void * pvOwner; struct xLIST * pxContainer; } ListItem_t;普通链表节点ListItem_t中：
xItemValue ：排序辅助值 pxNext ：下一个节点 pxPrevious ：上一个节点 pvOwner ：节点拥有者，通常是 TCB pxContainer ：该节点当前属于哪个链表链表本体大致是：
typedef struct xLIST { UBaseType_t uxNumberOfItems; ListItem_t * pxIndex; MiniListItem_t xListEnd; } List_t;其中：
uxNumberOfItems ：链表中真实节点数量 pxIndex ：链表遍历游标 xListEnd ：链表结束标记节点，也叫哨兵节点空链表不是NULL，而是：
xListEnd.pxNext 指向 xListEnd 自己 xListEnd.pxPrevious 指向 xListEnd 自己 uxNumberOfItems 等于 0有节点时结构类似：
xListEnd <-> A <-> B <-> C <-> xListEnd这种设计的好处是：插入、删除、遍历时不需要频繁判断头节点、尾节点或者空指针，代码更统一。
五、FreeRTOS 中的类型转换
之前看到这句代码：
pxList->xListEnd.pxNext = ( ListItem_t * ) &pxList->xListEnd;这句代码的意思是：
让 xListEnd 的 next 指针指向它自己也就是初始化空链表。
其中：
&pxList->xListEnd表示取xListEnd的地址。
而：
( ListItem_t * )是强制类型转换，把xListEnd的地址转换成ListItem_t *类型。
这里之所以需要强制转换，是因为xListEnd的真实类型是MiniListItem_t，而pxNext的类型是ListItem_t *。
MiniListItem_t比ListItem_t少了后两个成员：
pvOwner pxContainer但它们前三个成员布局一致：
xItemValue pxNext pxPrevious所以 FreeRTOS 可以把MiniListItem_t当成一个简化版的ListItem_t使用。这样既能作为链表结束节点，又能节省内存。
六、删除链表节点时为什么要处理pxIndex
在uxListRemove()中看到这段代码：
if( pxList->pxIndex == pxItemToRemove ) { pxList->pxIndex = pxItemToRemove->pxPrevious; }这段代码的作用是：如果链表的遍历游标正好指向要删除的节点，就必须把游标移到一个仍然有效的节点上。
比如链表是：
xListEnd <-> A <-> B <-> C <-> xListEnd假设：
pxIndex = B pxItemToRemove = B如果删除 B 之后不处理pxIndex，那么pxIndex仍然指向 B，但 B 已经不在链表中，这样后续遍历可能出错。
所以删除前要把它改成：
pxList->pxIndex = pxItemToRemove->pxPrevious;也就是让pxIndex退回到 B 的前一个节点 A。
为什么不是指向 B 的后一个节点 C？
因为 FreeRTOS 在获取下一个节点时，通常会先执行：
pxIndex = pxIndex->pxNext;如果删除 B 后让pxIndex = A，下一次遍历时就会走到 C，刚好不会跳过节点。
如果直接让pxIndex = C，下一次再执行pxIndex = pxIndex->pxNext，就会跳过 C。
所以这里设置为pxPrevious是为了配合 FreeRTOS 的遍历逻辑。
)
