嵌入式开发面试知识手册

azhezhezhe

— 阅读时间 636 分钟
分享

嵌入式开发工程师面试知识手册

适用对象：零基础起步、目标是通过嵌入式软件/驱动/BSP 方向面试的读者
编写依据：赵哲简历全部知识点 + 智能车 AGV 控制平台完整项目代码（i.MX6ULL Linux 端 + STM32F407 固件）+ Linux 驱动练习代码包 + embedded-agent 嵌入式开发智能体仓库 + 真实面试手撕代码与追问记录
使用方法：每篇按"通俗解释 → 原理细节 → 命令/API → 代码实例 → 项目结合 → 记忆口诀 → 面试问答"组织；口诀用于快速记忆，问答用于自测。第9篇是讲项目的演练场，第10篇是手撕代码实战题库。

总目录

第1篇 C语言与数据结构

本篇面向零基础读者，目标是让你在嵌入式工程师面试中，把 C 语言这一"必考科目"答得有深度、有细节、有项目味。阅读建议：每节先读通俗解释建立直觉，再啃原理细节，最后亲手敲一遍代码。嵌入式面试里 80% 的 C 语言问题都能在本篇找到答案。

1.1 编译链接全过程

通俗解释：从源码到固件，像做菜的四道工序

你写的 main.c 只是"菜谱"，CPU 只认二进制指令（机器码）。把菜谱变成菜，要经过四道工序：

  1. 预处理（Preprocessing）：像备菜——把 #include 的头文件"展开"塞进源码，把 #define 宏全部替换掉，把 #if/#ifdef 条件编译算好、删掉注释。产出还是一个"纯净的 .c 文本"（.i 文件）。
  2. 编译（Compilation）：像切配——把 C 代码翻译成汇编代码（.s 文件），这一步做语法检查、优化（-O2 就在这干活）。
  3. 汇编（Assembly）：像下锅——汇编器（as）把汇编翻译成机器码，产出目标文件 .o（object file）。注意：此时函数之间的"调用地址"还是空的占位符。
  4. 链接（Linking）：像摆盘上桌——链接器（ld）把多个 .o 和库拼在一起，填上每个函数、变量的真实地址，按链接脚本排布代码段/数据段，产出可执行文件（Linux 下 ELF，单片机下常转成 .hex/.bin）。

面试最爱问："编译时报错和链接时报错有什么区别？"——编译错误是单个文件内部的语法/类型问题；链接错误是"符号找不到"或"符号重复"，比如函数只声明没定义（undefined reference）、两个 .c 定义了同名全局变量（multiple definition）。

gcc 命令一条龙

# 一步到位：预处理+编译+汇编+链接
gcc main.c -o main

# 分步演示（面试能让你写出这四条就是加分项）
gcc -E main.c -o main.i    # 只预处理：展开宏和头文件
gcc -S main.i -o main.s    # 只编译：生成汇编
gcc -c main.s -o main.o    # 只汇编：生成目标文件（-c 表示 compile only，不链接）
gcc main.o -o main         # 链接：生成可执行文件

# 常用选项
gcc -Wall -g -O2 main.c -o main   # 开所有警告、带调试信息、二级优化
gcc -I./inc -L./lib -lfoo main.c  # -I 头文件搜索路径 -L 库路径 -l 链接 libfoo

.o / .a / .so 三兄弟

文件 全称 比喻 特点
.o 目标文件 半成品零件 机器码+符号表，地址未确定
.a 静态库（archive） 零件包，直接焊死在成品里 链接时把用到的 .o 拷进可执行文件，体积大、无依赖、启动快
.so 动态库（shared object） 公共零件仓库，用的时候才去取 运行时才加载，多个程序共享一份，体积小、可单独升级，但依赖版本（"缺 .so 跑不起来"） 
# 制作静态库
gcc -c foo.c bar.c
ar rcs libmy.a foo.o bar.o
gcc main.c -L. -lmy -o main          # 链接静态库，-lmy 即找 libmy.a

# 制作动态库
gcc -fPIC -shared foo.c -o libfoo.so # -fPIC 位置无关代码，动态库必备
gcc main.c -L. -lfoo -o main
export LD_LIBRARY_PATH=.             # 运行时告诉系统去哪找 .so

面试点：多个 .so 同名符号冲突怎么办？动态库的符号默认全局可见，可以用 static 或 -fvisibility=hidden 隐藏内部符号。

交叉编译：嵌入式工程师的日常

你的 x86 电脑编译出的程序，ARM 开发板（如 i.MX6ULL）跑不了——因为指令集不同。交叉编译 = 在 A 平台（host）上编译出 B 平台（target）能跑的程序。

# 使用交叉工具链（前缀暴露了目标平台）
arm-linux-gnueabihf-gcc main.c -o main
#  arm  = 目标 CPU 架构
#  linux= 目标系统
#  gnueabihf = 使用 glibc + 硬浮点 ABI

# 查看生成的 ELF 是给谁用的
file main
# main: ELF 32-bit LSB executable, ARM, ... ← 确认是 ARM 而非 x86-64

在赵哲的 robotd 项目里，Makefile 中 CC ?= arm-linux-gnueabihf-gcc，主机上编译、通过 scp/NFS 把可执行文件传到 i.MX6ULL 上运行；而 STM32 固件用的是 arm-none-eabi-gcc（none 表示裸机/无操作系统，eabi 是嵌入式 ABI）——"gnueabihf 跑 Linux 应用，none-eabi 跑裸机/RTOS" 这个区分面试常考。

【记忆口诀】
"预编汇编链四关，-E -S -c 记心间；点 a 焊死点 so 借，交叉编译看前缀。"

1.2 数据类型与内存

基本类型：先记住"宽度是平台相关的"

C 标准只规定了最小宽度，具体多宽看平台和编译器。嵌入式面试常考"int 几个字节"——正确回答是：在 32 位 ARM（i.MX6ULL/STM32）上 int 是 4 字节；但在一些 8 位单片机上是 2 字节。

类型 32 位 ARM 上宽度 取值范围（有符号）
char 1 字节 -128 ~ 127
short 2 字节 -32768 ~ 32767
int / long 4 字节 约 ±21 亿
long long 8 字节 约 ±9.2×10¹⁸
float 4 字节 精度约 6-7 位有效数字
double 8 字节 精度约 15-16 位

可移植写法（写驱动和通信协议必用）：#include <stdint.h> 里的 uint8_t / uint16_t / uint32_t / int32_t，宽度写死，跨平台不踩坑。CAN 帧解析、MQTT 报文组装全部用定宽类型。

补码：负数在内存里长什么样

计算机用补码表示负数。以 8 位的 -1 为例：

原码：1000 0001   （符号位 1 + 数值 1）
反码：1111 1110   （符号位不变，其余取反）
补码：1111 1111   （反码 + 1）← 内存里实际存的就是这个

为什么用补码？因为补码让减法变加法，CPU 只需要加法器：3 - 1 = 3 + (-1)，补码相加自然得到正确结果，且 0 只有一种表示。

面试常考：char c = 255; printf("%d", c); 输出 -1（有符号 char 下 0xFF 即补码 -1）。另一个经典：unsigned char c = 256; 截断为 0。

大小端：字节怎么排队

一个 32 位整数 0x12345678 占 4 个字节，在内存里怎么排？

  • 大端（Big-Endian）：高位字节放低地址 → 内存里依次是 12 34 56 78（像人写字，从左到右）。网络字节序（TCP/IP、MQTT 报文）是大端。
  • 小端（Little-Endian）：低位字节放低地址 → 内存里依次是 78 56 34 12。x86、ARM 默认是小端。
/* 判断大小端的经典代码（union 法） */
int check_endian(void)
{
    union {
        uint32_t i;
        uint8_t  c[4];
    } u;
    u.i = 0x12345678;
    if (u.c[0] == 0x78) {
        printf("小端\n");
    } else {
        printf("大端\n");
    }
    return 0;
}

嵌入式场景：i.MX6ULL（小端）和 STM32（小端）通过 CAN 通信时没问题；但解析网络协议（大端）时要用 htons/htonl/ntohs/ntohl 转换。赵哲项目里打包 MQTT 报文的多字节字段时就做了显式的"高字节在前"拼接，避免依赖机器端序。

结构体对齐与填充（#pragma pack）

CPU 读内存不是逐字节读的，喜欢"对齐"的地址（比如 4 字节类型放 4 的倍数地址上），不对齐要么慢、要么硬件直接异常（某些 ARM 平台）。所以编译器会自动填充（padding）。

struct A {
    char  a;   // 1 字节，偏移 0
               // 编译器填充 3 字节
    int   b;   // 4 字节，必须放偏移 4
    short c;   // 2 字节，偏移 8
               // 尾部填充 2 字节，使总大小是最大对齐数(4)的倍数
};
/* sizeof(struct A) = 12，不是 1+4+2=7！ */

对齐规则三条（背下来）：

  1. 每个成员的偏移量必须是"min(自身大小, 对齐模数)"的整数倍（对齐模数默认 8，可用 #pragma pack(n) 修改）；
  2. 结构体总大小必须是"最大成员对齐值"的整数倍；
  3. 数组元素按元素类型对齐。
#pragma pack(1)          /* 取消对齐，按 1 字节紧密排列 */
struct pkt {
    uint8_t  head;       /* CAN/串口协议包必须 pack，否则字段错位 */
    uint32_t id;
    uint8_t  data[8];
    uint8_t  crc;
};                       /* sizeof = 14，无填充 */
#pragma pack()           /* 恢复默认对齐 */

面试点：成员重排能省空间——把大类型放前面、小类型聚一起，可以减少填充。网络/总线协议结构体必须 pack 并用定宽类型，否则两端 sizeof 都对不上。

volatile / const / static / extern——四大修饰符

volatile（易变的）：告诉编译器"这个变量随时可能被看不见的手改掉，每次都要老老实实从内存读，不许用寄存器里的缓存值，不许优化掉"。三种必须使用的场景：

  1. 硬件寄存器（如 GPIO 状态寄存器，硬件自己会变）：#define REG (*(volatile uint32_t *)0x0209C000)
  2. 中断服务程序修改的全局变量（主循环在等它）；
  3. 多线程共享变量（但更推荐用互斥锁/原子操作，volatile 不保证原子性！）。

经典反例：while (flag == 0); 如果 flag 不加 volatile，-O2 优化后编译器只读一次就死循环。

const（只读）：const int a = 10; 变量不可修改，改了编译报错。好处：意图清晰、编译器可优化、真正的常量（如校准参数表）可被放进 Flash 省 RAM。注意 C 里 const 变量不是编译期常量（不能当数组长度用，C++ 才可以，C 里要用宏或 enum）。

static（三个作用，面试必背）：

  1. 修饰局部变量：延长生命周期到整个程序运行期，只初始化一次，存在数据段而非栈（常用于"记住上次状态"，如状态机里的计数）；
  2. 修饰全局变量/函数：限制作用域为本文件可见（内部链接），防止命名冲突——大项目里所有非接口函数都该加 static；
  3. （同 2，针对函数）static int helper(void) 表示这是模块私有函数。

extern：声明"这个变量/函数在别的文件里定义，链接时去找"。头文件里写 extern int g_count;，某一个 .c 里写 int g_count = 0; 才真正分配内存。声明不分配内存，定义才分配——这句话能答出很多追问。

typedef / enum / union / 位域

/* typedef：给类型起别名 */
typedef uint8_t u8;
typedef void (*mqtt_cb_t)(const char *topic, const uint8_t *payload, int len);
/* 函数指针类型起别名后可读性暴增： */
mqtt_cb_t g_on_message = my_handler;

/* enum：一组相关常量，从 0 递增 */
typedef enum {
    ST_IDLE = 0,
    ST_TRIG,          /* 1 */
    ST_WAIT_ECHO,     /* 2 */
    ST_DONE           /* 3 */
} sr04_state_t;       /* 赵哲项目里超声波状态机就是这么写的 */

/* union：所有成员共享同一块内存，大小 = 最大成员 */
union {
    float    f;
    uint8_t  bytes[4];  /* 拆字节发串口/CAN 的经典手法 */
} fconv;
fconv.f = 3.14f;
can_send(fconv.bytes, 4);   /* 按字节发出，接收端原样拼回 float */

/* 位域：一个变量占几个 bit，省空间 */
struct can_ctrl {
    uint32_t id    : 29;  /* 扩展帧 ID 29 位 */
    uint32_t rtr   : 1;
    uint32_t ide   : 1;
    uint32_t resvd : 1;
};

位域的移植性坑（面试加分项）：C 标准不规定位域成员的排列方向（从高位还是从低位排）和对齐方式，不同编译器可能不同。所以跨平台的协议不要用位域解析，用移位+掩码（见 1.6）。位域只适合本机内部的省空间场景。

【记忆口诀】
"负数补码加一取反，大小端看低地址；对齐填隙 pack 救，volatile 防优化；static 锁文件又续命，extern 只声明不安家；位域省位莫跨界，协议解析靠移码。"

1.3 指针全家桶

通俗解释：指针就是"门牌号"

把内存想象成一栋大楼，每个字节是一个房间，指针就是写着房间号的纸条。int *p 这张纸条上写的是"某个 int 房间的门牌号"；*p 就是"按门牌号去房间里取东西/放东西"（解引用）；&a 是"问 a 的门牌号"。

int a = 10;
int *p = &a;   /* p 保存 a 的地址 */
printf("%d\n", *p);   /* 10：按地址取出值 */
*p = 20;              /* 通过指针改 a 的值 */
printf("%zu\n", sizeof(p));  /* 32 位机上指针本身占 4 字节，64 位机 8 字节 */

关键认知：指针变量本身也占内存、也有自己的地址。p + 1 不是地址加 1 个字节，而是加 sizeof(指向类型) 个字节——int *p; p+1 前进 4 字节，char *p; p+1 前进 1 字节。这就是"指针运算以类型为单位"。

指针与数组：像但不是一回事

int arr[5] = {1, 2, 3, 4, 5};
int *p = arr;          /* 数组名在大多数表达式中"退化"为首元素指针 */

相同点：arr[i]、*(arr+i)、p[i]、*(p+i) 四种访问等价。
不同点（面试必考）：

数组名 arr 指针 p
本质 一块连续内存的名字 一个存地址的变量
sizeof 整个数组大小（5×4=20） 指针本身大小（4 或 8）
可否赋值 不可（arr = p; 编译错） 可（p = arr;）
&arr 类型是 int(*)[5]，+1 跳整个数组 &p 类型是 int**

注意数组名退化的两个例外：sizeof(arr) 和 &arr 时不退化。函数形参里的 void f(int arr[10]) 实际上等价于 void f(int *arr)——数组传参会退化成指针，所以函数内 sizeof 拿不到真实长度，必须另传 len。这是无数 bug 的源头。

指针数组 vs 数组指针：看谁说了算

读复杂声明用右左法则：从变量名出发，先右后左，遇括号换方向。

int *p1[5];    /* 指针数组：p1 先与 [5] 结合 → 是数组，5 个元素都是 int* */
int (*p2)[5];  /* 数组指针：括号让 p2 先与 * 结合 → 是指针，指向 int[5] 数组 */

int arr[5] = {0};
p2 = &arr;     /* 指向整个数组 */
(*p2)[0] = 1;

char *names[] = {"motor", "imu", "ultra"};  /* 指针数组的典型用法：字符串表 */

函数指针与回调：嵌入式的灵魂

/* 函数指针：指向函数的指针 */
int add(int a, int b) { return a + b; }
int (*fp)(int, int) = add;   /* 函数名即地址，&add 也行 */
printf("%d\n", fp(1, 2));    /* 3 */

/* 回调：把函数当参数传给别人，别人在合适的时候"回头调你" */
void mqtt_subscribe(const char *topic, void (*cb)(const char *msg))
{
    /* ... 收到消息后： */
    cb("payload");
}

void on_msg(const char *msg) { printf("got: %s\n", msg); }
mqtt_subscribe("robot/cmd", on_msg);

赵哲 robotd 项目里 MQTT 消息分发、线程邮箱的消息处理函数都是回调：注册时传函数指针，事件发生时框架调用——这就是"好莱坞法则：别调我们，我们会调你"。回调也是实现状态机、事件驱动架构的地基（见 1.8）。

二级指针：改变"指针本身"

void alloc_buf(uint8_t **pp, int len)   /* 要在函数里修改调用者的指针，必须传指针的地址 */
{
    *pp = malloc(len);
}
uint8_t *buf = NULL;
alloc_buf(&buf, 128);   /* buf 现在指向新内存 */

常见用途：① 函数内修改外部指针；② 字符串数组 char **argv；③ 链表删除时简化边界处理（struct node **pp 指向"指向下一个节点的指针"）。

void*：万能门牌号

void * 可以存任何类型对象的地址，但不能直接解引用（不知道房间多大），用之前必须强转回来。malloc 返回 void *、memcpy 的参数是 void *、线程入口 void *(*)(void *) 都是它。通用容器、线程参数传递全靠 void*。

void *thread_main(void *arg)
{
    struct mailbox *mb = (struct mailbox *)arg;  /* 转回真实类型 */
    /* ... */
}

const 修饰指针的四种组合（读法：从右往左）

const int *p1;        /* 指向"常量 int"的指针：*p1 不可改，p1 可改指向 */
int const *p2;        /* 与 p1 完全相同 */
int * const p3 = &a;  /* 常量指针：p3 不可改指向，*p3 可改 */
const int * const p4 = &a; /* 双锁：指向和值都不能改 */

判断技巧：看 const 在 * 的哪边——const 在 * 左边锁"内容"，在右边锁"指针本身"。记忆："左值右指"（const 在左锁定值，在右锁定指针）。

野指针 / 悬空指针 / 内存泄漏——三大杀手

/* 1. 野指针：未初始化就乱指 */
int *p;        /* 值是垃圾，指向随机地址 */
*p = 10;       /* 段错误 or 悄悄破坏别的数据（更可怕） */

/* 2. 悬空指针：指向的内存已被释放 */
int *q = malloc(4);
free(q);
*q = 10;       /* q 还指着那块已归还的内存：use-after-free */

/* 3. 内存泄漏：只借不还 */
while (1) {
    char *buf = malloc(1024);
    /* 忘记 free，内存越耗越多，长跑设备几天后崩溃 */
}

防御性写法（团队规范级别，面试说出来很加分）：

free(p);
p = NULL;        /* free 后立刻置空：再次 free(NULL) 安全，误用立刻崩出来好查 */

int *p = NULL;   /* 定义即初始化 */
if (p != NULL) { /* 用之前判空 */ }

嵌入式里悬空指针的隐蔽变体：中断里 free 了主循环正在用的 buffer——所以共享缓冲区要么关中断保护、要么用无锁环形队列（见 1.7）。

【记忆口诀】
"指针是地址，星号去取物；数组名是家，sizeof 见真屋；指针数组一窝针，数组指针指一窝；回调传址回头调，二级指针改指针；const 左值右指要分清，free 后置空防悬空。"

1.4 内存四区/五区

通俗解释：程序内存像一家公司

  • 代码段（.text）：公司的"操作手册"——编译好的机器指令，只读，多个进程可共享。
  • 数据段（.data）：公司的"固定资产"——已初始化的全局变量和 static 变量，程序一启动就就位。
  • BSS 段（.bss）：公司的"空地"——未初始化或初始化为 0 的全局/static 变量。可执行文件里只占一行"面积备注"不占实际空间，加载时由系统清零。
  • 堆（heap）：公司的"临时仓库"——你 malloc 多少租多少，用完必须 free 归还，从低地址向上生长。
  • 栈（stack）：每个员工的"办公桌"——函数调用时的局部变量、参数、返回地址，自动分配自动释放，从高地址向下生长，大小有限（Linux 线程默认几 MB，RTOS 任务常常只有 512B~2KB）。
#include <stdio.h>
#include <stdlib.h>

int g_init = 42;        /* .data：已初始化全局 */
int g_bss;              /* .bss ：未初始化，自动为 0 */
static int s_cnt;       /* .bss ：static 同理 */
const int g_ro = 7;     /* .rodata（常并入代码段）：只读 */

int main(void)
{
    int  local = 1;             /* 栈 */
    static int s2 = 5;          /* .data：static 局部变量不进栈！ */
    char *heap = malloc(64);    /* 指针本身在栈，指向的 64 字节在堆 */
    char *str  = "hello";       /* 指针在栈，"hello" 在 .rodata，不可写 */
    free(heap);
    return 0;
}

经典送命题：char *s = "abc"; s[0] = 'x'; → 段错误（字符串字面量在只读区）。而 char s[] = "abc"; s[0] = 'x'; 合法（数组在栈上，是字面量的拷贝）。

malloc / free / calloc / realloc

int *a = malloc(10 * sizeof(int));   /* 申请 40 字节，内容是垃圾值 */
int *b = calloc(10, sizeof(int));    /* 申请并清零 */
a = realloc(a, 20 * sizeof(int));    /* 扩容/缩容，可能搬家（旧地址失效） */
free(a); a = NULL;
free(b); b = NULL;

要点：

  • malloc 参数是字节数，失败返回 NULL，必须判空；
  • realloc 可能把块搬到新地址并拷贝旧数据，原指针必须用返回值覆盖；realloc(NULL, n) 等价 malloc，realloc(p, 0) 等价 free；
  • malloc 底层（glibc）：小块用 brk 扩展堆顶，大块（>128KB 默认）用 mmap 直接映射；free 的内存通常先还给内存分配器的空闲链表而不是立刻还给操作系统——所以 top 里看进程内存不下降是正常现象。

嵌入式为何慎用 malloc

  1. 碎片化：长时间运行中反复申请/释放不同大小的块，堆碎成渣——总空闲够但没有连续大块，申请失败。设备要跑几个月的，这是定时炸弹。
  2. 时间不确定：malloc 内部要找空闲块、可能加锁，执行时间不可预测，实时系统（电机 PID 控制环）里不允许。
  3. 线程/中断安全：裸机环境的 malloc 默认不可重入，RTOS 里要用其提供的线程安全版本（如 FreeRTOS 的 heap_4）。

嵌入式对策（赵哲项目实践）：

  • 启动时一次性分配：所有 buffer、结构体在初始化时静态分配或一次性 malloc，运行期零分配；
  • 内存池：预先切好固定大小的块，申请/释放 O(1) 且无碎片；
  • 环形队列：线程邮箱、CAN 收发缓冲用固定大小的 ring buffer，天然无动态分配（见 1.7）；
  • RTOS 里用 xTaskCreateStatic、静态队列，连任务栈都静态给。

栈溢出：最诡异的崩溃

void big(void)
{
    char buf[4096];   /* FreeRTOS 任务栈若只有 1KB：瞬间溢出 */
    /* 溢出后悄悄踩坏相邻内存，表现为"莫名其妙死机"、"变量自己变了" */
}
void recurse(void) { recurse(); }  /* 无限递归也会爆栈 */

排查手段：FreeRTOS 开 configCHECK_FOR_STACK_OVERFLOW 钩子、填栈魔数法（启动时把栈填满 0xA5，运行时看还剩多少 0xA5）、Linux 下用 ulimit -s 查看/调整。RTOS 任务栈要按"最深调用链 + 最大局部数组 + 中断嵌套"估算并留 50% 余量。

【记忆口诀】
"代码只读数两段，data 有值 bss 零；堆要借还栈自动，栈向下长堆上攀；嵌入式里少 malloc，碎片定时是炸弹；字面量区莫乱改，数组拷贝才平安。"

1.5 字符串与常用库函数

C 字符串的本质：以 '\0' 结尾的字符数组

char s[] = "abc";
/* 内存里其实是 'a' 'b' 'c' '\0' 共 4 字节，strlen(s)=3，sizeof(s)=4 */

所有坑都源于一个事实：C 字符串不带长度信息，全靠 '\0' 收尾。忘了留 '\0' 的位置，函数就会一路读到越界。

逐个击破（区别与坑）

/* strlen：数到 '\0' 为止，不含 '\0'。sizeof 是编译期算数组大小 */
char a[32] = "hi";
strlen(a);   /* 2 */
sizeof(a);   /* 32 ← 面试高频：别混！ */

/* strcpy：无长度保护，源比目标长就溢出——高危 */
char dst[8];
strcpy(dst, "hello world");   /* 栈溢出！ */

/* strncpy：限长，但有两大坑 */
strncpy(dst, "hello world", sizeof(dst));
/* 坑1：源 >= n 时不会补 '\0'，dst 变成"无结尾字符串" */
/* 坑2：源 < n 时会把剩余空间全填 '\0'，大 buffer 浪费性能 */
dst[sizeof(dst) - 1] = '\0';  /* 必须手动补结尾 */

/* strcat：拼接，同样无保护；strncat 的 n 是"最多追加的字符数"（还会补 \0） */
char line[32] = "id=";
strncat(line, "123456", sizeof(line) - strlen(line) - 1);  /* 正确姿势 */

/* strcmp：逐字节比 ASCII，返回 <0 / 0 / >0。 == 比的是地址不是内容！ */
if (strcmp(cmd, "STOP") == 0) { /* 相等是 == 0，别写反 */ }

/* sprintf：无边界，危险；snprintf：带上限，返回值是"本来想写多少" */
char buf[16];
int n = snprintf(buf, sizeof(buf), "t=%d,h=%d", 25, 60);
/* snprintf 保证 '\0' 结尾；n >= sizeof(buf) 说明被截断了 */

内存四件套：memcpy / memmove / memset / memcmp

/* memcpy：按字节拷贝，【源和目标重叠时行为未定义】 */
uint8_t buf[16] = {1,2,3,4,5,6,7,8};
memcpy(buf, buf + 2, 6);   /* 重叠！结果不可预料 */

/* memmove：允许重叠（内部判断方向，必要时从后往前拷），略慢 */
memmove(buf, buf + 2, 6);  /* 安全：{3,4,5,6,7,8,7,8} */
/* 环形队列整理数据、滑动窗口必须 memmove */

/* memset：按【字节】填充 */
int arr[10];
memset(arr, 0, sizeof(arr));       /* 清零 OK */
memset(arr, 1, sizeof(arr));       /* 坑！每个字节都是 0x01 → 元素值 0x01010101，不是 1 */

/* memcmp：逐字节比内存，常用于协议包/结构体比较 */
if (memcmp(frame_a, frame_b, sizeof(can_frame_t)) == 0) { /* 完全相同 */ }
/* 注意：含填充字节的结构体直接 memcmp 可能误判（填充内容是垃圾），先 memset 再赋值 */

memcpy 重叠问题面试深挖：很多平台的 memcpy 实现是"从低地址往高地址拷"，当 dst < src 时恰好没事、dst > src 时会先把源数据盖掉再拷——结果依赖实现就是"未定义行为"的可怕之处：换编译器/换优化等级就炸。规则只有一条：可能重叠一律 memmove。

嵌入式场景注意

  • 串口/CAN 收到的原始字节流不一定有 '\0'，绝不能用 str 系列处理二进制数据（遇到 0x00 就停）——二进制协议用 memcpy/memcmp + 显式长度；
  • 裸机环境有些 newlib 裁剪版 snprintf 不支持 %f（浮点格式化），要么开 --specs=nano.specs -u _printf_float，要么手动拆整数小数打印；
  • 高频路径（PID 控制环每 1ms 一次）避免大 buffer 的 strcpy/strlen，改成维护长度计数。

【记忆口诀】
"strlen 数到零，sizeof 看全程；str 家族怕超长，snprintf 保平安；memcpy 怕重叠，memmove 管搬移；memset 按字节，清零才放心。"

1.6 位操作与寄存器编程

通俗解释：寄存器就是硬件的"开关面板"

单片机的外设（GPIO、定时器、CAN 控制器）通过内存映射寄存器控制——某个固定地址对应一排开关，写 1 开、写 0 关。位操作就是"只动其中一个开关，不碰其他开关"的手艺。

六大运算符与四大基本操作

uint32_t reg = 0;

/* 置位（置1）：用 | 和 (1 << n) */
reg |= (1U << 3);            /* bit3 = 1 */

/* 清位（清0）：用 & 和 取反的掩码 */
reg &= ~(1U << 3);           /* bit3 = 0，其他位不变 */

/* 翻转：用 ^（1 的位翻，0 的位不变） */
reg ^= (1U << 3);

/* 读位：& 之后右移（或直接判断是否为 0） */
if (reg & (1U << 3)) { /* bit3 为 1 */ }
uint32_t bit3 = (reg >> 3) & 1U;

/* 多位置值：先清再或 */
#define SET_BITS(reg, mask, val)  ((reg) = ((reg) & ~(mask)) | ((val) & (mask)))

面试级宏写法（背到能默写）：

#define BIT(n)              (1U << (n))
#define SET_BIT(r, n)       ((r) |=  BIT(n))
#define CLR_BIT(r, n)       ((r) &= ~BIT(n))
#define TOG_BIT(r, n)       ((r) ^=  BIT(n))
#define READ_BIT(r, n)      (((r) >> (n)) & 1U)

易错点：

  • 用 1U 不用 1：1 << 31 在有符号 int 上溢出是未定义行为；
  • 宏参数加括号：(r) |= BIT(n) 防止 SET_BIT(a + b, 3) 展开出错；
  • ~ 对无符号数的位宽问题：uint8_t x = ~0x01; 得到 0xFE 没问题，但参与 int 运算时会先整型提升。

结构体映射寄存器：驱动开发的标准手法

/* 把一片连续寄存器映射成结构体，成员名即寄存器名 */
typedef struct {
    volatile uint32_t CR1;      /* 偏移 0x00 */
    volatile uint32_t CR2;      /* 偏移 0x04 */
    volatile uint32_t SR;       /* 偏移 0x08 */
    volatile uint32_t DR;       /* 偏移 0x0C */
} uart_reg_t;

#define UART1  ((uart_reg_t *)0x40011000UL)

UART1->CR1 |= BIT(13);          /* 使能 USART */
while (!(UART1->SR & BIT(7)));  /* 等发送寄存器空 */
UART1->DR = 'A';

三个生死细节：

  1. 必须加 volatile——寄存器被硬件异步修改，不加就被编译器优化掉；
  2. 成员顺序和宽度必须与硬件手册逐字节对应，中间有保留寄存器要插 uint32_t RESERVED;；
  3. 基地址强转加 UL 后缀，64 位机上更安全。

Linux 内核驱动里不直接用物理地址，而是 ioremap() 后用 readl/writel（带内存屏障）。赵哲在 i.MX6ULL 字符设备驱动中：reg_base = ioremap(GPIO1_BASE, 8); writel(val | BIT(3), reg_base + GPIO_DR);

结构体映射 vs 位域：移植性坑

/* 有些厂商头文件用位域描述寄存器： */
typedef struct {
    uint32_t EN    : 1;
    uint32_t MODE  : 3;
    uint32_t RESVD : 28;
} cr1_bits_t;

问题：C 标准不保证位域从高位还是低位开始分配，也不保证跨单元行为——GCC 小端下从低位排，换个编译器/大端机可能全错。ST、NXP 官方头文件因此用结构体+volatile 成员表示"寄存器级"，用掩码宏表示"位级"，从不用位域表示硬件。自己写可移植代码也要遵守：硬件寄存器用移位+掩码，不用位域。位域只用于纯软件内部的紧凑标志位存储。

另一个坑：读-改-写（read-modify-write）不是原子的。reg |= BIT(3) 实际是"读、改、写"三步，中断若在中间打断也改同一寄存器，主程序的写会把中断的改动覆盖回去。解决：关中断临界区、原子操作，或用硬件提供的"置位/清零独立寄存器"（如 STM32 的 BSRR：写 1 置位、写高 16 位清零，单次写操作天然原子）。

【记忆口诀】
"置位或一清零与非，翻转异或读位移；宏带括号 1U 移，volatile 贴寄存；位域看着美，移植两行泪；读改写三步走，临界区里才动手。"

1.7 常见数据结构手写

数组：一切的基础

连续内存、O(1) 随机访问、大小固定。嵌入式里大部分"表"都是数组：PWM 占空比查找表、CAN ID 过滤器表、消息处理函数表。缺点：中间插入删除要搬数据 O(n)、大小写死。

单链表：面试手撕常客

#include <stdio.h>
#include <stdlib.h>

typedef struct node {
    int data;
    struct node *next;
} node_t;

/* 头插：O(1)，最常用 */
void list_push_front(node_t **head, int val)
{
    node_t *n = malloc(sizeof(node_t));
    n->data = val;
    n->next = *head;
    *head = n;                 /* 头指针变了，所以传二级指针 */
}

/* 删除指定值：用"指向指针的指针"技巧，免去头节点特判 */
void list_remove(node_t **head, int val)
{
    node_t **pp = head;        /* pp 指向"指向下一个节点的那个指针" */
    while (*pp) {
        if ((*pp)->data == val) {
            node_t *victim = *pp;
            *pp = victim->next;    /* 绕过 victim */
            free(victim);
            return;
        }
        pp = &(*pp)->next;
    }
}

void list_print(const node_t *head)
{
    for (const node_t *p = head; p; p = p->next)
        printf("%d -> ", p->data);
    printf("NULL\n");
}

面试加试：链表反转（三个指针 prev/cur/next 原地掉头）、找倒数第 k 个节点（快慢指针，快的先走 k 步）、判环（快慢指针相遇即有环）。

双向链表：删除 O(1) 的代价是多一个指针

typedef struct dnode {
    int data;
    struct dnode *prev, *next;
} dnode_t;

/* 在 head 之后插入 n */
void dlist_insert_after(dnode_t *head, dnode_t *n)
{
    n->next = head->next;
    n->prev = head;
    if (head->next) head->next->prev = n;
    head->next = n;
}
/* 已知节点指针即可 O(1) 删除自己——单链表做不到（要找前驱） */
void dlist_remove(dnode_t *n)
{
    if (n->prev) n->prev->next = n->next;
    if (n->next) n->next->prev = n->prev;
}

双向链表适合"已知节点频繁删除"的场景，比如定时器管理、LRU 缓存。带哨兵头节点的循环双链表可以让插入删除完全没有空指针特判——这正是 Linux 内核 list.h 的做法（见下文）。

环形队列（Ring Buffer）：嵌入式第一数据结构

思想：固定大小的数组 + 头尾两个下标，取模回绕，数组像被掰成一个环。空满判断的经典方案是牺牲一个槽位：(tail + 1) % size == head 为满，head == tail 为空。

下面是完整可用于"线程邮箱"的实现（赵哲 robotd 项目同款思路：CAN 接收线程投递、主控线程消费）：

#include <stdint.h>
#include <stdbool.h>
#include <string.h>

typedef struct {
    uint32_t id;
    uint8_t  data[8];
    uint8_t  len;
} msg_t;                          /* 邮箱里传递的消息 */

#define MB_CAP  16                /* 容量，建议 2 的幂：% 可优化为 & */

typedef struct {
    msg_t buf[MB_CAP];
    volatile uint32_t head;       /* 消费者（读方）拥有 */
    volatile uint32_t tail;       /* 生产者（写方）拥有 */
} mailbox_t;

static inline uint32_t mb_count(const mailbox_t *mb)
{
    return (mb->tail - mb->head + MB_CAP) % MB_CAP;
}
bool mb_full(const mailbox_t *mb)  { return mb_count(mb) == MB_CAP - 1; }
bool mb_empty(const mailbox_t *mb) { return mb_count(mb) == 0; }

/* 生产者调用：中断或其他线程 */
bool mb_push(mailbox_t *mb, const msg_t *m)
{
    if (mb_full(mb)) return false;
    mb->buf[mb->tail] = *m;              /* 整结构体拷贝 */
    mb->tail = (mb->tail + 1) % MB_CAP;  /* 最后更新 tail：对消费者而言"发布" */
    return true;
}

/* 消费者调用 */
bool mb_pop(mailbox_t *mb, msg_t *out)
{
    if (mb_empty(mb)) return false;
    *out = mb->buf[mb->head];
    mb->head = (mb->head + 1) % MB_CAP;
    return true;
}

为什么单生产者-单消费者（SPSC）可以无锁？（面试高频）：head 只被消费者写、tail 只被生产者写，两个下标各只有一个写者，另一方只读；32 位机上对 32 位整数的单次读/写是原子的，所以不会出现"读到改了一半的值"。生产者先写完数据再更新 tail（相当于"发布"），消费者看到 tail 变了就知道数据已就绪。注意两点：① 下标必须 volatile（防编译器缓存）；② 严格说要内存屏障保证"数据先于下标可见"，在单核 MCU/有缓存一致性的 Linux 用户态通常无碍，多生产者或多消费者必须加锁/信号量。robotd 里多线程版本就在 push/pop 外套了 pthread_mutex，并用条件变量 pthread_cond_wait 让消费者"睡到有消息再醒"，避免空转。

用未回绕计数器的小技巧：让 head/tail 单调递增不回绕，取元素时 buf[idx & (CAP-1)]，空满判断变成 tail == head（空）、tail - head == CAP（满）——不浪费槽位，且溢出回绕后减法依然正确（无符号整数回绕的妙用）。

栈：数组就能搞定

typedef struct {
    int data[64];
    int top;          /* 指向下一个空位 */
} stack_t;

void  s_push(stack_t *s, int v) { s->data[s->top++] = v; }
int   s_pop (stack_t *s)        { return s->data[--s->top]; }
bool  s_empty(const stack_t *s) { return s->top == 0; }

应用场景：表达式求值、括号匹配、函数调用本身就是栈、协议解析的状态回退、DFS。

哈希表：概念与嵌入式用法

哈希 = 用哈希函数把键（key）映射到数组下标，理想 O(1) 查找。冲突解决方案：链地址法（每个桶挂链表）和开放寻址法（冲突就往下找空位）。嵌入式里 RAM 紧张，常见简化：CAN ID 过滤用"位图哈希"（ID % 128 置位）、字符串命令查找用小型静态哈希表或直接二分有序数组——有序数组 + 二分查找 O(log n) 常常比真哈希表更实用。

Linux 内核 list.h 的思想：侵入式链表

内核链表节点不含数据，只把 struct list_head 嵌进你的结构体里：

struct list_head { struct list_head *next, *prev; };

struct can_rx_item {
    struct can_frame frame;
    struct list_head  list;      /* 链表节点"寄生"在数据结构里 */
};

/* 已知节点指针，反推宿主结构体地址——container_of 宏 */
#define container_of(ptr, type, member) \
    ((type *)((char *)(ptr) - offsetof(type, member)))

好处：一份链表代码适配所有类型（不需要 void* 强转，类型安全）、一个结构体可同时挂在多条链表上。赵哲 robotd 里管理 CAN 帧队列就借鉴了这种"宿主内嵌节点 + offsetof 反推"的写法，比 void* 通用链表更省内存也更安全。

【记忆口诀】
"数组连续查得快，链表插删只换针；单链头插双指针，删除巧用指向针；环形队列牺牲槽，头尾各归一人操；哈希冲突挂链条，内核链表寄身术。"

1.8 回调与状态机编程范式

为什么嵌入式离不开状态机

裸机/RTOS 里没有"等"这回事——delay(1000) 这种阻塞写法会让整个系统瘫痪：电机没人调、串口没人收。非阻塞编程的核心就是把"等待"变成"状态"：现在进行到哪一步？条件满足就跳下一步，不满足立刻返回去干别的。

事件驱动 + 回调：先搭好骨架

typedef void (*event_cb_t)(int event, void *ctx);

typedef struct {
    event_cb_t cb;
    void      *ctx;
} listener_t;

static listener_t listeners[8];
static int listener_cnt = 0;

void on_event(event_cb_t cb, void *ctx)          /* 注册回调 */
{
    listeners[listener_cnt++] = (listener_t){ cb, ctx };
}
void fire_event(int ev)                          /* 事件发生时逐个回调 */
{
    for (int i = 0; i < listener_cnt; i++)
        listeners[i].cb(ev, listeners[i].ctx);
}

表驱动状态机：HC-SR04 非阻塞测距实战

HC-SR04 超声波测距流程：发 10us 触发脉冲 → 等 Echo 引脚拉高 → 等 Echo 拉低 → 高电平时长换算距离。阻塞写法要 while 死等几十毫秒，表驱动状态机写法每次循环只花几微秒——这正是赵哲 STM32 固件里的实现思路：

#include <stdint.h>

typedef enum {
    ST_IDLE = 0,
    ST_TRIG_HIGH,        /* 触发脚输出高电平中 */
    ST_WAIT_ECHO_RISE,   /* 等待回响脚拉高 */
    ST_WAIT_ECHO_FALL,   /* 等待回响脚拉低（计时中） */
    ST_DONE
} sr04_state_t;

typedef struct {
    sr04_state_t state;
    uint32_t ts;          /* 进入本状态的时间戳 */
    uint32_t echo_start;  /* Echo 拉高时刻 */
    float    distance;    /* 结果，cm */
    bool     valid;
} sr04_t;

/* —— 表驱动：状态 = 状态处理函数 + 超时/条件转移 —— */
typedef sr04_state_t (*state_fn)(sr04_t *s, uint32_t now);

static sr04_state_t fn_idle(sr04_t *s, uint32_t now)
{
    (void)now;
    trig_high();  s->ts = now_us();
    return ST_TRIG_HIGH;
}
static sr04_state_t fn_trig_high(sr04_t *s, uint32_t now)
{
    if (now - s->ts >= 10) { trig_low(); s->ts = now; return ST_WAIT_ECHO_RISE; }
    return ST_TRIG_HIGH;                       /* 条件不满足：保持 */
}
static sr04_state_t fn_wait_rise(sr04_t *s, uint32_t now)
{
    if (echo_read()) { s->echo_start = now; return ST_WAIT_ECHO_FALL; }
    if (now - s->ts > 30000) return ST_IDLE;   /* 30ms 超时：放弃本轮 */
    return ST_WAIT_ECHO_RISE;
}
static sr04_state_t fn_wait_fall(sr04_t *s, uint32_t now)
{
    if (!echo_read()) {
        uint32_t us = now - s->echo_start;
        s->distance = us * 0.017f;             /* 声速 340m/s，往返 ÷2 */
        s->valid = true;
        return ST_DONE;
    }
    if (now - s->ts > 30000) return ST_IDLE;
    return ST_WAIT_ECHO_FALL;
}
static sr04_state_t fn_done(sr04_t *s, uint32_t now)
{
    (void)now; return ST_IDLE;                 /* 结果已就绪，回到待命 */
}

/* —— 驱动表：状态号 → 处理函数，这就是"表驱动" —— */
static state_fn state_table[] = {
    [ST_IDLE]           = fn_idle,
    [ST_TRIG_HIGH]      = fn_trig_high,
    [ST_WAIT_ECHO_RISE] = fn_wait_rise,
    [ST_WAIT_ECHO_FALL] = fn_wait_fall,
    [ST_DONE]           = fn_done,
};

/* 主循环里每次调用一次：非阻塞，最多几微秒 */
void sr04_tick(sr04_t *s)
{
    uint32_t now = now_us();
    s->state = state_table[s->state](s, now);
}

表驱动的精髓：状态转移逻辑写进"函数指针数组"，主循环只剩一行查表调用。加状态 = 加一个函数 + 表里加一行，不写一坨 if-else/switch。相比巨型 switch，表驱动更易测、更难漏 case（数组下标越界编译期可检查）。robotd 的机器人行为层（避障→减速→转向→恢复）同样用此范式。

状态机设计三问（面试主动讲）：① 每个状态有没有超时退出？（防硬件异常卡死，上面的 30ms 超时就是）② 异常路径回哪个状态？③ 状态变量放哪？（static 或上下文结构体，绝不用全局裸奔。）

【记忆口诀】
"等待变状态，死等换轮询；状态配函数，表里查指针；每态留超时，异常有归程；回调先注册，事发再唤人。"

1.9 嵌入式 C 高频坑

1. 整数溢出：静悄悄的炸弹

uint8_t  a = 200, b = 100;
uint8_t  c = a + b;          /* 300 超出 8 位 → 截断为 44 */
int16_t  x = 32767;
x++;                         /* 有符号溢出是【未定义行为】，不是 -32768！（无符号回绕才是定义好的）*/

/* 时间戳比较的经典错误：*/
uint32_t now = millis();
if (now - last > 1000) { }   /* 正确：无符号减法天然抗回绕 */
if (now > last + 1000) { }   /* 错误：last+1000 可能在 49 天后溢出，判断永远成立 */

对策：加法前先判 if (a > UINT8_MAX - b)；时间比较永远用减法形式；有符号溢出用更宽类型或显式检查。

2. 隐式类型转换：整型提升与"无符号污染"

uint8_t a = 200, b = 100;
int c = a + b;               /* 300 ✓：运算前小类型先提升为 int */

unsigned int u = 1;
int i = -1;
if (i < u) printf("yes");    /* 不打印！i 被转成无符号 → 4294967295 */
/* 规则：有符号和无符号混合运算，有符号被转成无符号（"无符号污染"）*/

float f = 1 / 2;             /* 0！整数除法先算完才转 float */
float g = 1.0f / 2;          /* 0.5 ✓ */

int32_t t = (uint16_t)hi << 16 | lo;  /* 位移前注意提升，<< 16 丢高位 */

对策：混合运算先强转；字面量带后缀（1U、1UL、1.0f）；开 -Wconversion 警告。

3. 有符号右移：是实现定义，别赌

int x = -8;
x >> 1;    /* 大多数编译器是算术右移（补符号位）→ -4，但 C 标准只说"实现定义" */
/* 可移植写法：无符号类型做移位，除法用 /2 让编译器自己处理 */
uint32_t ux = 0x80000000U;
ux >> 1;   /* 逻辑右移，确定是 0x40000000 ✓ */

铁律：位操作只用无符号类型。有符号左移溢出同样是未定义行为（1 << 31）。

4. 浮点比较：== 是禁区

float f = 0.1f + 0.2f;
if (f == 0.3f) { }           /* 大概率不成立！0.1 是二进制无限循环小数 */
/* 正确：比差值和误差 eps */
#include <math.h>
if (fabsf(f - 0.3f) < 1e-6f) { }

嵌入式附加坑：STM32F103 没有 FPU，float 全靠软件模拟，一次乘法几十上百个周期——PID 控制环要么用定点数（Q15/Q31），要么选带 FPU 的 M4/M7 并确认编译开了 -mfloat-abi=hard。

5. 未初始化变量：栈上的垃圾

int flag;
if (flag) { }                /* 值是栈上残留的垃圾， Debug 可能碰巧是 0，Release 崩 */
uint8_t buf[64];
uart_send(buf, 64);          /* 把上个函数留在栈上的隐私数据发出去了 */

对策：定义即初始化（int flag = 0;）、开 -Wall -Wextra（编译器会报 maybe-uninitialized）、关键 buffer 用前 memset。

6. 数组越界：没有边界检查的 C

int arr[8];
arr[8] = 1;                  /* 合法编译！踩的是隔壁变量的内存 */
char name[8] = "motor ctl";  /* 9 个字符 + '\0'，数组装不下，越界写 */

后果分级：踩了栈上的返回地址 → 程序飞掉（还可能被利用成安全漏洞）；踩了全局变量 → "变量自己变了"；踩了寄存器映射区附近 → 硬件乱动。对策：长度常量用 #define 或 sizeof 统一管理，循环条件用 < N 而非 <= N，拷贝一律用带 n 的函数，能上 -fsanitize=address（主机测试时）就上。

7. 其他高频暗坑速览

  • if (a = 1) 赋值当判断：写反的 ==，开 -Wall 会警告，养成 if (1 == a) 习惯（yoda 写法）；
  • switch 漏 break 贯穿：故意贯穿要加 /* fall through */ 注释；
  • 宏的副作用：MAX(a++, b) 展开后 a 自增两次 → 宏参数绝不带副作用；
  • sizeof(char *) 和 sizeof(char[10]) 混淆（1.3 已讲）；
  • 多字节强转：uint8_t *p; *(uint32_t *)p = x; 在非对齐地址上 ARM 会硬件异常（总线错误），协议解包用 memcpy 而不是指针强转；
  • 中断与主程序共享变量没加 volatile（1.2 已讲），改了优化等级（-O0 → -O2）才暴露——"Debug 好使 Release 崩"的头号嫌疑人。

【记忆口诀】
"溢出无声减法稳，无符污染符号沉；移位只碰无符号，浮点相等用误差；定义就要赋初值，越界无声毁邻家；等号写反 yoda 救，宏里莫放副作用。"

1.10 面试高频问答

Q1：指针和数组有什么区别？
A：数组是一块连续内存本身，数组名是这段内存的名字（不可修改指向）；指针是一个存放地址的变量。sizeof(数组) 得总字节数，sizeof(指针) 得 4/8 字节。数组作函数参数时退化为指针，所以函数内必须另传长度。&arr 类型是"指向整个数组的指针"，步长是整个数组；&p 是二级指针。

Q2：static 的三个作用？
A：① 修饰局部变量：生命周期延长到整个程序，只初始化一次，存数据段；② 修饰全局变量：作用域限制在本文件（内部链接）；③ 修饰函数：同样限制为本文件可见，相当于模块私有函数。

Q3：volatile 什么时候必须用？
A：三种场景：① 内存映射的硬件寄存器；② 中断服务程序修改、主循环读取的共享变量；③ 多线程/信号处理共享的变量。它保证每次访问都重新读内存、禁止编译器优化缓存。注意 volatile 不保证原子性、不保证顺序（无内存屏障语义），多线程仍要锁或原子操作。

Q4：怎么判断大小端？
A：union 法：写入 32 位值 0x12345678，看第一个字节是 0x78（小端）还是 0x12（大端）。ARM/x86 默认小端，网络字节序是大端，跨机通信用 htonl/htons 系列转换。

Q5：结构体对齐怎么算？char+int+short 为什么 sizeof 是 12？
A：规则：每个成员偏移量是自身对齐值的整数倍；总大小是最大对齐值的整数倍。char(1) 占偏移 0，int 需对齐到 4 → 填 3 字节，int 占 4~7，short 占 8~9，尾部填 2 字节凑成 4 的倍数 → 12。协议结构体用 #pragma pack(1) 取消填充。

Q6：malloc 底层怎么实现的？
A：glibc 里小块（<128KB）通过 brk/sbrk 扩展堆顶，从空闲链表（bins）里找块切割；大块走 mmap 单独映射，free 时直接 munmap 归还。free 的小块先进分配器缓存复用，不一定立刻还给 OS。嵌入式慎用 malloc：碎片化 + 时间不确定 + 可重入性问题，生产环境用静态分配/内存池/环形队列。

Q7：memcpy 和 memmove 的区别？
A：memcpy 假设源和目标不重叠，重叠时行为未定义（可能从前往后拷导致源被提前覆盖）；memmove 允许重叠，内部按地址关系选择拷贝方向，代价是略慢。规则：可能重叠一律 memmove，比如环形队列整理、滑动窗口。

Q8：环形队列为什么单生产者单消费者可以不用锁？
A：head 只有消费者写、tail 只有生产者写，每个共享变量只有一个写者，另一方只读；32 位对齐整数的单次读写天然原子，不会读到撕裂值。生产者"先写数据、最后更新 tail"相当于发布。注意下标要 volatile，严格场合需内存屏障；多生产者/多消费者必须加锁。

Q9：strcpy 和 strncpy 的坑？
A：strcpy 无长度保护，溢出高危。strncpy 坑两个：源长度 ≥ n 时不补 '\0'（目标变成无结尾字符串，后续 str 函数越界）；源短时把剩余全填 '\0' 浪费性能。安全用法：strncpy(d, s, sizeof(d)-1); d[sizeof(d)-1] = '\0'; 或直接 snprintf。

**Q10：const int *p、int const p、const int const p 区别？
A：const 在 * 左边锁内容（指向的值不可改，指针可改指向）；在 * 右边锁指针（指针不可改指向，值可改）；两边都有则双锁。口诀"左值右指"。

Q11：什么是野指针、悬空指针？怎么防？
A：野指针：未初始化就被使用，指向随机地址；悬空指针：指向的内存已 free 后仍被使用（use-after-free）。防御：定义即初始化 NULL、用前判空、free 后立即置 NULL、谁申请谁释放、避免函数返回局部变量地址。

Q12：堆和栈的区别？栈溢出怎么查？
A：栈由编译器自动管理，存局部变量/调用现场，速度快但容量小且固定（RTOS 任务常 1~2KB）；堆由程序员手动管理，容量大但有碎片和开销。栈溢出表现为莫名死机/变量异常，排查用 FreeRTOS 栈溢出钩子、栈填充魔数（0xA5）法、WaterMark 统计，并避免大局部数组和深递归。

Q13：为什么位操作要用无符号类型？
A：有符号右移是"实现定义"（算术还是逻辑右移看编译器），有符号左移溢出是未定义行为；无符号的移位和回绕行为由标准严格定义。另外 1<<31 在有符号 int 上溢出，应写 1U<<31。

Q14：回调函数是什么？项目里哪里用了？
A：回调 = 把函数指针作为参数传给框架，框架在事件发生时调用它。项目中：MQTT 客户端注册消息到达回调、线程邮箱注册消息处理函数、状态机用函数指针表分发状态处理——本质是"控制反转"，让框架代码和业务代码解耦。

Q15：位域为什么不建议用于硬件寄存器和通信协议？
A：C 标准不规定位域成员的分配方向（高位先还是低位先）、跨存储单元的行为和对齐填充，全部由编译器实现决定。换编译器、换端序、换 ABI，同一份位域代码解析结果可能不同。可移植代码一律用移位+掩码宏操作定宽无符号类型，位域只用于本机内部的紧凑标志存储。

Q16：编译错误和链接错误怎么区分？undefined reference 常见原因？
A：编译错误发生在单个翻译单元内部（语法错、类型不匹配、头文件没找到）；链接错误发生在把所有 .o 拼起来时——符号找不到（undefined reference）或符号重复（multiple definition）。undefined reference 常见原因：只声明没定义、函数签名不一致（C++ 还有 name mangling 问题，调 C 库要 extern "C"）、库没链接上或 -l 顺序不对（被依赖的库放后面）、目标文件没参与链接。

Q17：char c = 0xFF，printf("%d", c) 输出什么？
A：输出 -1。0xFF 作为有符号 char 是补码 -1；printf 的 %d 会把它整型提升为 int，符号扩展后仍是 -1。延伸考点：char 是否有符号是"实现定义"的（x86 GCC 默认有符号），写可移植代码要么显式 signed char/unsigned char，要么直接用 uint8_t/int8_t。

Q18：为什么函数不能返回局部变量的地址？
A：局部变量在栈上，函数返回时栈帧销毁，那块内存随即被后续调用覆盖——返回的指针立刻成为悬空指针，读它可能"碰巧"还是旧值（更危险，bug 时隐时现），写它会破坏别人的栈。需要返回动态数据时：用 malloc（调用者负责 free）、用调用者传入的 buffer、或用 static 变量（不可重入，仅单线程场景）。

Q19：什么是可重入函数？中断里的函数有什么要求？
A：可重入函数指"执行到一半被打断、再次进入也正确"的函数：不使用全局/static 可写变量（或对其有保护）、不调用不可重入函数。中断服务程序（ISR）要求更高：要快（不做浮点运算、不 printf）、不能阻塞（不能等待锁/信号量，只能 trylock 或释放信号量）、与主程序共享的变量要 volatile、用的每个函数都要可重入。FreeRTOS 里中断要用带 FromISR 后缀的 API。

Q20：#define 和 const、enum 定义常量怎么选？
A：#define 不占内存、无类型、无作用域，预处理期纯文本替换（要注意加括号防优先级坑）；const 变量有类型检查、有作用域，但 C 里不是编译期常量（不能做数组长度和 case 标号），且可能占内存；enum 是真正的编译期整型常量，天然适合一组相关取值（状态机状态、错误码），不占内存、调试器可见。嵌入式实践：状态/错误码用 enum，简单数值配置用 #define，需要类型安全和指针指向的用 const。

【本篇总口诀】
"四步成固件，补码记负值；指针看门牌，四区安其位；字符串零尾，位操无符号；环队邮箱稳，状态表驱动；坑从溢出起，volatile 镇全场。"

第 2 篇 Linux 系统编程

本篇面向零基础读者，目标是：学完能在嵌入式 Linux 面试中，把"进程/线程/同步/IPC/IO 多路复用/Socket/Makefile"这条主线讲清楚、写得出代码、答得上追问。每一节按 原理 → API 原型逐参数解释 → 代码示例 → 常用命令 的顺序展开，并穿插作者真实项目 robotd（7 线程主控：mqtt / can_rx / can_tx / command / state / storage / monitor）的实战案例。

2.1 Linux 基础与常用命令

2.1.1 一切皆文件：Linux 文件系统结构

Linux 的哲学是"一切皆文件"：普通文件是文件，目录是文件，键盘、串口、CAN 控制器、进程信息也统统以文件形式暴露。进程通过统一的 open/read/write/close 接口操作它们——这是整篇系统编程的地基。

/           根目录，一切的起点
├── bin     常用命令（ls、cp，软链到 /usr/bin）
├── sbin    系统管理命令（ifconfig、reboot，root 用）
├── etc     配置文件（/etc/passwd、/etc/network/interfaces）
├── dev     设备文件（/dev/ttyS0 串口、/dev/can0、/dev/null）
├── proc    进程信息虚拟文件系统（/proc/cpuinfo、/proc/1/status）
├── sys     内核对象与驱动 sysfs（调 GPIO、读温度都在这里）
├── tmp     临时文件（重启清空）
├── var     可变数据（/var/log 日志）
├── usr     用户程序与库（Unix System Resources）
├── lib     共享库（libc.so、ld-linux.so）
├── home    普通用户家目录
├── root    root 用户家目录
├── mnt     临时挂载点（U 盘、NFS）
└── opt     第三方软件

嵌入式工程师最常打交道的四个：/dev（操作硬件）、/proc（看进程和内核状态）、/sys（调驱动参数）、/etc（改开机配置）。

三种文件路径概念：

  • 绝对路径：从 / 开始，如 /home/robot/robotd
  • 相对路径：从当前目录开始，如 ../lib/can.so
  • 特殊符号：~ 家目录、. 当前目录、.. 上级目录、- 上一次所在目录

文件类型（ls -l 第一列的第一个字符）：

字符 类型 例子
- 普通文件 main.c
d 目录 /etc
l 符号链接（快捷方式） /bin → /usr/bin
c 字符设备（按字节流，如串口） /dev/ttyS0
b 块设备（按块，如 EMMC） /dev/mmcblk0
p 命名管道 FIFO 见 2.7
s 套接字 socket 文件 见 2.9

【记忆口诀】"根下带兵（bin）装（sbin）设备（dev），配置（etc）进程（proc）系统（sys）家（home）" —— 一句话记住根目录七大核心目录。

2.1.2 权限：chmod / chown

ls -l 的输出逐列拆解：

-rwxr-xr--  1  robot  robot  4096  Jun 1 10:00  robotd
 │└┬┘└┬┘└┬┘   │    │      │      │        │         └─ 文件名
 │  │  │  │    链接数  属主   属组    大小     修改时间
 │  │  │  └─ 其他用户权限 o：r--
 │  │  └─ 属组权限 g：r-x
 │  └─ 属主权限 u：rwx
 └─ 文件类型：普通文件

权限三位一组：r（读=4）w（写=2）x（执行=1），所以：

  • rwxr-xr-x = 755（目录和可执行程序最常见）
  • rw-r--r-- = 644（普通文件最常见）
  • rwx------ = 700（私密脚本）
  • 777 = 人人可读写执行（面试会问为什么危险：任何用户可篡改/执行）
chmod 755 robotd            # 数字法
chmod u+x script.sh         # 符号法：给属主加执行权限
chmod a-w config.cfg        # a=all，所有人去掉写权限
chmod -R 644 ./html/        # -R 递归
chown robot:robot robotd    # 同时改属主和属组
chgrp robotdata log.txt     # 只改属组

嵌入式易错点：交叉编译出的程序 scp 到开发板后常忘 chmod +x，报 Permission denied；串口 /dev/ttyS0 属组是 dialout，普通用户要加入该组才能打开。

【记忆口诀】"四二一，读写行（x），主人组员外人三段分" —— r=4、w=2、x=1，按 user/group/other 三组相加。

2.1.3 日常命令速查（面试实操常考）

# —— 目录与文件 ——
ls -lht              # 按时间倒序、人类可读大小（h）
ls -a                # 显示隐藏文件（. 开头）
cd -                 # 回上一次目录
pwd                  # 当前绝对路径
cp -r src/ dst/      # 递归复制目录
mv old new           # 移动/重命名
rm -rf build/        # 递归强制删除（慎用！）
ln -s /data/robotd /usr/bin/robotd   # 创建软链接
touch a.c            # 创建空文件/刷新时间戳
file robotd          # 看文件类型（ARM ELF？x86 ELF？）
which gcc            # 命令在哪

# —— 文本搜索两大杀器 ——
grep -rn "mailbox_init" ./src     # -r 递归 -n 行号
grep -E "err|fail" log.txt        # -E 扩展正则（等价 egrep）
grep -i -v "debug" log.txt        # -i 忽略大小写 -v 反选
ps aux | grep robotd              # 管道组合：找进程

find / -name "*.ko" 2>/dev/null          # 按文件名找（丢弃错误信息）
find . -type f -mtime -1                 # 一天内改过的文件
find . -size +10M -exec ls -lh {} \;     # 大于10M的列出来
find . -name "*.c" | xargs grep "TODO"   # 找文件+搜内容组合拳

grep 和 find 的区别（面试高频）：grep 是"在文件内容里搜"，find 是"按文件属性（名字/大小/时间/类型）找文件"，二者用管道+xargs 组合威力最大。

# —— 进程管理 ——
ps aux               # 静态快照：所有进程（a所有用户 u详细 x含无终端）
ps -ef               # 另一种风格，能看到父进程 PID 树关系
ps -eLf              # 看线程！每个线程一行（LWP 列）
top                  # 动态监控，按 P 按 CPU 排序，按 M 按内存排序
top -H -p 1234       # -H 看 1234 号进程内的各个线程占用
htop                 # 更友好的 top（需安装）
kill 1234            # 发 SIGTERM（15），礼貌请它退出
kill -9 1234         # 发 SIGKILL（9），强制杀死（不可捕获！）
kill -l              # 列出全部信号
killall robotd       # 按名字杀

# —— 系统与磁盘 ——
dmesg                # 内核环形日志：驱动加载、oops、硬件检测都在这
dmesg | tail -20     # 看最新的内核消息（插 USB 后必敲）
dmesg -w             # 实时跟踪（= tail -f）
df -h                # 各分区使用情况（-h 人类可读）
du -sh /data/log/    # 某目录实际占用（s 汇总）
du -sh ./* | sort -rh | head   # 找出当前目录谁最占空间
free -h              # 内存使用（重点看 available 而非 free）
uname -a             # 内核版本、架构（armv7l? aarch64?）
cat /proc/cpuinfo    # CPU 型号核数
uptime               # 开机时长 + 负载均值（1/5/15分钟）

# —— 打包压缩 ——
tar -czvf log.tar.gz log/     # 打包+gzip压缩：c创建 z用gzip v显示 f文件名
tar -xzvf log.tar.gz          # 解压：x释放
tar -cjvf a.tar.bz2 dir/      # bzip2（j）压缩率更高更慢
tar -tvf a.tar.gz             # 只看内容不解压

【记忆口诀】"打包 cxf 三件宝：c 创建、x 释放、f 文件少不了；z 是 gzip、j 是 bz2"。

2.1.4 vi 基础（考场和串口终端里救命用）

嵌入式设备上往往只有 vi，三种模式：

        ┌──────────┐  i / a / o   ┌──────────┐
        │ 命令模式  │ ───────────→ │ 插入模式  │
        │ (默认)   │ ←─────────── │          │
        └────┬─────┘     Esc      └──────────┘
             │ : 进入底行命令
             ▼
        ┌──────────┐
        │ 底行模式  │  :wq 保存退出  :q! 强制不保存退出
        └──────────┘

命令模式高频键：dd 删行、yy 复制行、p 粘贴、u 撤销、/word 搜索（n 下一个）、gg 文件头、G 文件尾、x 删字符。

【记忆口诀】"i 进 Esc 退，冒号 wq 保存退；q! 强制走，改了全白给"。

2.1.5 环境变量

环境变量是"进程从父进程继承的键值对"，程序用 getenv("PATH") 读取。

echo $PATH                    # 可执行程序搜索路径（冒号分隔）
export PATH=$PATH:/opt/arm/bin    # 追加（仅当前 shell 有效）
env                           # 列出全部环境变量
export LD_LIBRARY_PATH=/app/lib   # 动态库搜索路径（嵌入式调试常用！）

永久生效写入 ~/.bashrc（用户级）或 /etc/profile（系统级）。嵌入式调试动态库找不到时，临时 export LD_LIBRARY_PATH=. 是最快的办法。

常见环境变量：PATH（命令搜索）、LD_LIBRARY_PATH（动态库搜索）、HOME（家目录）、SHELL、LANG（语言）、CROSS_COMPILE（交叉编译前缀，如 arm-linux-gnueabihf-）。

【记忆口诀】"export 当场用，bashrc 永久用；库找不到，LD_LIBRARY_PATH 救"。

2.2 标准 IO vs 文件 IO

2.2.1 两套接口的本质区别

维度 标准 IO（库函数） 文件 IO（系统调用）
头文件 <stdio.h> <fcntl.h> <unistd.h>
操作对象 FILE *（流） int fd（文件描述符）
打开/关闭 fopen / fclose open / close
读/写 fread/fwrite/fgets/fprintf read / write
缓冲 有用户态缓冲区（默认 4096/8192 字节） 无用户缓冲，每次直接进入内核
可移植性 C 标准，跨平台（Windows 也有） POSIX，仅 Unix/Linux
效率特点 少量多次读写快（攒够缓冲再进内核） 频繁小调用慢（每次一次系统调用）
能否操作设备/socket 能但不合适（缓冲捣乱） 必须用它（fd 是万物的句柄）

核心认知：printf 不是系统调用！它把数据写进用户态 FILE 缓冲区，条件满足（缓冲满/遇换行/调用 fflush/程序退出）才调用 write 真正进入内核。面试经典题"printf 后 fork，为什么子进程打印了重复内容？"——答案就是 fork 时缓冲区被原样复制，父子各自 flush 一次。

文件描述符 fd：进程打开文件的整数句柄，本质是进程 fd 表的下标，表里每项指向内核的"打开文件对象"。每个进程启动自带三个：

0  STDIN_FILENO   标准输入（键盘）
1  STDOUT_FILENO  标准输出（屏幕）
2  STDERR_FILENO  标准错误（屏幕）

新打开的 fd 总是取当前最小可用整数——这是 dup2 重定向的原理基础。

【记忆口诀】"标准 IO 带仓库（缓冲区），文件 IO 直通内核库；fd 从零一二起步，新开的取最小数"。

2.2.2 open / read / write / close 逐参数精讲

#include <fcntl.h>
#include <unistd.h>

int open(const char *pathname, int flags, ... /* mode_t mode */);
  • pathname：文件路径，如 "/dev/can0"、"./log.txt"
  • flags（必须三选一再或上修饰位）：
    • O_RDONLY 只读 / O_WRONLY 只写 / O_RDWR 读写（三选一）
    • O_CREAT 不存在则创建（此时必须给第三个参数 mode 权限，如 0644）
    • O_APPEND 追加写（多进程写日志用它防覆盖）
    • O_TRUNC 打开即清空
    • O_NONBLOCK 非阻塞（IO 多路复用、ET 模式的关键，见 2.8）
    • O_EXCL 配合 O_CREAT，文件已存在则报错（做锁文件用）
  • mode：仅创建时生效的新文件权限，注意还要被 umask 掩码（实际 = mode & ~umask）
  • 返回值：成功返回 fd（≥0），失败返回 -1 并置 errno
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);
  • fd：open 返回的描述符；buf：用户缓冲区；count：期望读/写的字节数
  • 返回值（面试必考）：
    • read 返回 实际读到的字节数（可能小于 count！）；返回 0 表示 EOF（对端关闭/文件读完）；返回 -1 出错，errno == EINTR 表示被信号打断（应重试）、EAGAIN 表示非阻塞无数据（不是错误！）
    • write 同理，可能"短写"，必须循环写直到写完
  • int close(int fd)：关闭并释放 fd。进程退出时内核自动关，但长期运行的 daemon 必须手动关（fd 上限默认 1024，泄漏会 EMFILE: Too many open files）
off_t lseek(int fd, off_t offset, int whence);
  • whence 三选一：SEEK_SET（从文件头）、SEEK_CUR（从当前位置）、SEEK_END（从文件尾）
  • 返回新的文件偏移量；配合 SEEK_END, 0 可以测文件大小
  • 妙用：lseek(fd, 100MB, SEEK_SET); write(fd,"x",1); 制造稀疏文件（hole，不占真实磁盘块）

2.2.3 代码示例：用文件 IO 复制一个文件

/* file_copy.c —— 纯系统调用实现 cp */
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>

int main(int argc, char *argv[])
{
    if (argc != 3) { fprintf(stderr, "usage: %s src dst\n", argv[0]); return 1; }

    int sfd = open(argv[1], O_RDONLY);
    if (sfd < 0) { fprintf(stderr, "open src: %s\n", strerror(errno)); return 1; }

    /* O_CREAT|O_TRUNC|O_WRONLY：没有就建，有就清空，0644 权限 */
    int dfd = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0644);
    if (dfd < 0) { fprintf(stderr, "open dst: %s\n", strerror(errno)); close(sfd); return 1; }

    char buf[4096];
    ssize_t n;
    while ((n = read(sfd, buf, sizeof(buf))) > 0) {
        ssize_t written = 0;
        while (written < n) {                    /* 循环处理"短写" */
            ssize_t w = write(dfd, buf + written, n - written);
            if (w < 0) {
                if (errno == EINTR) continue;    /* 被信号打断，重试 */
                perror("write"); goto out;
            }
            written += w;
        }
    }
    if (n < 0) perror("read");

out:
    close(dfd);
    close(sfd);
    return 0;
}

2.2.4 fcntl 与 dup/dup2

#include <fcntl.h>
int fcntl(int fd, int cmd, ... /* arg */);

fcntl 是 fd 的"瑞士军刀"，常用 cmd：

  • F_GETFL / F_SETFL：读/改文件状态标志。把 fd 设为非阻塞的标准写法：
int flags = fcntl(fd, F_GETFL);              /* 先读出现有标志 */
fcntl(fd, F_SETFL, flags | O_NONBLOCK);      /* 或上非阻塞再写回 */
/* 错误示范：fcntl(fd, F_SETFL, O_NONBLOCK); —— 会把 O_APPEND 等原标志冲掉！ */
  • F_SETLK：设置文件记录锁（多进程写同一文件的互斥）

dup / dup2：复制文件描述符

int dup(int oldfd);              /* 返回最小可用 fd，与 oldfd 指向同一文件 */
int dup2(int oldfd, int newfd);  /* 强制复制到 newfd（若占用先关闭它） */

复制出的两个 fd 共享文件偏移量和状态标志（指向同一个内核文件对象）。dup2 的经典用途是重定向——daemon 守护进程把 printf 的输出扔进日志文件：

int logfd = open("/var/log/robotd.log", O_WRONLY | O_CREAT | O_APPEND, 0644);
dup2(logfd, STDOUT_FILENO);   /* 1 号 fd 现在指向日志文件 */
dup2(logfd, STDERR_FILENO);   /* 2 号同理 */
close(logfd);
printf("goes to log file now\n");

shell 里的 ls > out.txt 2>&1 底层就是 dup2。

2.2.5 缓冲机制：fflush 与 fsync

数据从应用写到磁盘要经过两层缓冲：

应用程序 ──fwrite──▶ FILE用户态缓冲区 ──fflush/write──▶ 内核页缓存(page cache) ──fsync──▶ 物理磁盘
  • int fflush(FILE *stream)：把用户态缓冲刷进内核（fflush(NULL) 刷所有流）
  • int fsync(int fd)：把内核页缓存真正落盘（慢，毫秒级，机械盘更慢）
  • int fdatasync(int fd)：只刷数据不刷元数据，比 fsync 略快

为什么区分两者：fflush 后数据还在内核里，机器掉电照样丢；只有 fsync 返回了才算真正安全。代价是 fsync 极慢——这正是数据库/日志系统的核心矛盾。

项目实战（robotd）：我们的 storage 线程写 SQLite 就是在这层矛盾上做的取舍——攒批 32 条或 200ms 才提交一次事务（SQLite 事务提交内部伴随 fsync），把"每帧一次 fsync"摊薄成"每批一次"，磁盘 IO 下降两个数量级。并且 storage 是独立线程，就算 SD 卡偶发卡顿，也只堵 storage 自己，不反压 can_rx→command→can_tx 的实时控制链——这是"快慢分离"的线程划分思想。

三个标准流的缓冲模式（面试常考）：

  • stdout 接终端时是行缓冲（遇 \n 刷新）
  • stdout 重定向到文件/管道时变全缓冲（4KB 攒满才刷）——所以 printf 后立刻看日志文件经常"没有输出"
  • stderr 无缓冲，立即输出
setvbuf(stdout, NULL, _IONBF, 0);   /* 关闭 stdout 缓冲，调试 daemon 常用 */

【记忆口诀】"fflush 出库（用户缓冲）进内核，fsync 出内核进磁盘；掉电要问 fsync，慢也是它"。

2.3 进程

2.3.1 进程是什么

进程 = 正在运行的程序的实例，是资源分配（内存空间、fd 表、信号表）的最小单位。每个进程有独立的虚拟地址空间（32 位下 4G：用户态 3G + 内核态 1G），进程间天然隔离——A 崩溃不拖死 B，这是用多进程架构（如 robotd/wifid/webd/hmi 四进程）的根本原因。

2.3.2 fork：写时复制的分身术

#include <unistd.h>
pid_t fork(void);

无参数。返回值（面试必考）：

  • 父进程中返回 子进程 PID（>0）
  • 子进程中返回 0
  • 失败返回 -1

一次调用，两次返回——父子从 fork 的下一条语句开始各自执行，靠返回值区分身份：

pid_t pid = fork();
if (pid < 0)      { perror("fork"); }
else if (pid == 0) { /* 子进程 */ printf("child, my pid=%d\n", getpid()); _exit(0); }
else              { /* 父进程 */ printf("parent, child pid=%d\n", pid); }

fork 复制什么：地址空间（代码/数据/堆/栈）、fd 表、信号处理方式、当前目录……但 PID、PPID 不同。现代 Linux 用 写时复制（COW, Copy-On-Write）：fork 瞬间父子共享物理页，谁写入谁才真正复制那一页——所以 fork 很快。

继承注意点：子进程复制父进程打开的所有 fd（指向同一内核文件对象，共享偏移量）；但不复制线程（多线程进程 fork，子进程只有调用 fork 的那一个线程——这会带来"锁被别的线程持有"的死锁隐患，所以多线程程序 fork 后通常立即 exec）。

2.3.3 exec 家族：换芯不换壳

fork 造出分身，exec 把分身的代码和数据整个替换成新程序（PID 不变、fd 默认保留）：

#include <unistd.h>
int execl(const char *path, const char *arg, ..., NULL);          /* l=list，逐个列参数 */
int execlp(const char *file, const char *arg, ..., NULL);         /* p=PATH，按PATH搜索 */
int execv(const char *path, char *const argv[]);                  /* v=vector，参数数组 */
int execvp(const char *file, char *const argv[]);
  • path：可执行文件的完整路径；file：文件名（带 p 的版本去 PATH 里找）
  • 参数约定：argv[0] 惯例是程序名自身，最后一个必须是 NULL
  • 返回值：成功则永不返回（原进程映像已被覆盖）；返回 -1 必是失败
/* 经典组合：fork + exec = 启动一个新程序 */
pid_t pid = fork();
if (pid == 0) {
    execlp("ifconfig", "ifconfig", "can0", "up", NULL);
    _exit(127);              /* exec 失败才走到这，必须退出！ */
}
/* 父进程继续干自己的事 */

shell 执行你敲的每条命令，内部就是 fork+exec。

2.3.4 wait / waitpid：收尸与回收

#include <sys/wait.h>
pid_t wait(int *wstatus);
pid_t waitpid(pid_t pid, int *wstatus, int options);

子进程退出后，内核保留其"尸体"（退出码等少量信息），父进程必须 wait 收尸，否则子进程变成僵尸（Zombie）。

  • pid：-1 等任意子进程；>0 等指定 PID；0 等同组任意子进程
  • wstatus：带出退出状态，用宏解析：
    • WIFEXITED(status) 是否正常退出（exit/return）
    • WEXITSTATUS(status) 取退出码（exit(3) → 3）
    • WIFSIGNALED(status) 是否被信号杀死；WTERMSIG(status) 取信号号
  • options：0 阻塞等待；WNOHANG 非阻塞（没孩子退出就立即返回 0——常用于主循环里"顺手收尸"）
  • 返回值：成功=收掉的子进程 PID；WNOHANG 且无尸可收=0；出错=-1
int status;
pid_t w = waitpid(pid, &status, 0);          /* 阻塞等这个子进程 */
if (WIFEXITED(status))
    printf("child exit code = %d\n", WEXITSTATUS(status));

2.3.5 孤儿进程与僵尸进程（面试必考）

僵尸进程 (Zombie) 孤儿进程 (Orphan)
定义 子死了，父没 wait 父死了，子还活着
状态 Z，只占一个 PCB 项，不占内存/CPU 正常运行，被 init(PID 1) 收养
危害 尸体堆积，耗尽 PID 资源 无害，init 会定期 wait 收尸
怎么造 子 exit，父 sleep 不 wait 父先 exit
怎么防 ①父进程 wait/waitpid；②捕获 SIGCHLD 在处理函数里 waitpid；③signal(SIGCHLD, SIG_IGN) 让内核自动回收；④fork 两次：父→子→孙，子立刻退出，孙被 init 收养（daemon 标准做法） 不需要防，是特性 
/* 推荐写法：SIGCHLD 处理函数里循环非阻塞收尸 */
void sigchld_handler(int sig) {
    while (waitpid(-1, NULL, WNOHANG) > 0)  /* 一次可能死多个，循环收 */
        ;
}
signal(SIGCHLD, sigchld_handler);

2.3.6 进程状态 R/S/D/Z（top 和 ps 的 STAT 列）

状态 含义 触发场景
R Running/Runnable 正在运行或在就绪队列排队 计算密集型任务
S Sleeping（可中断） 等事件，可被信号唤醒 read 等键盘、sleep()
D Uninterruptible Sleep（不可中断） 等 IO（磁盘/NFS），kill -9 都杀不死 磁盘故障时进程卡 D，是系统告警信号
Z Zombie 死而未收 见上节
T Stopped 被 SIGSTOP 暂停或 gdb 断点 Ctrl+Z（SIGTSTP）
X Dead 已死亡（瞬间态，看不到） —

附加字符：< 高优先级、N 低优先级、s 会话首进程、+ 前台进程组、l 多线程。

2.3.7 exit vs _exit（细节分）

exit()（库函数，stdlib.h） _exit()（系统调用，unistd.h）
刷标准 IO 缓冲 会（fflush 所有流） 不会
调用 atexit 注册的函数 会 不会
最终 内部调用 _exit 直接进入内核终止进程

黄金法则：fork 出的子进程若不调 exec，退出时用 _exit()——否则子进程会把从父进程继承的、尚未刷新的 stdout 缓冲区再刷一遍，造成重复输出。

2.3.8 守护进程（daemon）编写五步法

守护进程 = 脱离终端、在后台长期运行的服务进程（robotd 就是一个 daemon）。手写步骤：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <signal.h>

void daemonize(void)
{
    /* 1. fork 后父进程退出：让子进程不是进程组长（setsid 的前提），
           同时 shell 认为命令已结束 */
    pid_t pid = fork();
    if (pid < 0) exit(1);
    if (pid > 0) exit(0);            /* 父进程退场 */

    /* 2. setsid：创建新会话，成为会话首进程，彻底脱离控制终端 */
    if (setsid() < 0) exit(1);

    /* 3. 第二次 fork：孙子进程不再是会话首进程，
           永远失去重新获得控制终端的资格（可选但严谨） */
    pid = fork();
    if (pid < 0) exit(1);
    if (pid > 0) exit(0);

    /* 4. 清 umask、切目录：防止创建文件权限被掩掉；防止占用挂载点导致无法 umount */
    umask(0);
    chdir("/");

    /* 5. 关闭继承来的 fd（或重定向 0/1/2 到 /dev/null 或日志文件） */
    for (int i = 0; i < 3; i++) close(i);
    int nullfd = open("/dev/null", O_RDWR);
    dup2(nullfd, 0); dup2(nullfd, 1); dup2(nullfd, 2);
    signal(SIGCHLD, SIG_IGN);        /* 自动回收子进程，免僵尸 */
}

工程上也可以直接用 glibc 的 int daemon(int nochdir, int noclose)（一步封装了上面流程），或交给 systemd/supervisord 托管。

2.3.9 system()：一行起 shell

#include <stdlib.h>
int system(const char *command);

内部 = fork + exec("/bin/sh", "-c", command) + waitpid，阻塞到命令执行完。返回值：-1 失败；否则用 WEXITSTATUS 取命令退出码。

if (WEXITSTATUS(system("ifconfig can0 up")) != 0)
    fprintf(stderr, "can0 up failed\n");

面试考点：system 会阻塞调用者、fork 出 shell 开销大、命令拼接有注入风险（system("ping " + 用户输入) 是经典漏洞）。正式工程里简单命令可以用，频繁调用应改用 fork+exec。

【记忆口诀】"fork 分身 exec 换芯，wait 收尸防僵尸；exit 刷缓冲，子退用 _exit；守护五步：fork、setsid、再 fork、换目录、关 fd"。

2.4 线程

2.4.1 线程是什么：与进程的本质区别

线程是 CPU 调度的最小单位（进程是资源分配的最小单位）。同一进程内的线程共享同一地址空间，各自只私有栈和寄存器现场。

维度 进程 线程
地址空间 独立 与兄弟线程共享
切换开销 大（换页表、刷 TLB） 小（同地址空间内切换）
创建开销 fork+COW，较重 只建栈+TCB，轻（~10KB 级）
通信 必须 IPC（管道/shm/socket） 直接读写全局变量（但要同步！）
隔离性 强，崩溃互不影响 弱，一个线程段错误全进程陪葬
调试难度 较低 高（竞态、死锁难复现）

共享 vs 私有清单（面试必背）：

共享：代码段、全局变量/堆（数据段+BSS+heap）、打开的文件 fd、
      信号处理方式(signal handler 是进程级的)、当前目录、用户ID
私有：线程ID(TID)、栈、寄存器/程序计数器、errno（每线程一份！）、
      信号掩码（每个线程可独立屏蔽信号）、调度优先级

选型经验：需要强隔离（一个挂了不影响其他）选多进程；需要高频共享数据、低延迟通信选多线程。

项目实战（robotd）：主控选 7 线程单进程架构（mqtt/can_rx/can_tx/command/state/storage/monitor），正因为控制链路要求微秒级数据交换——can_rx 收到帧放全局状态区，command 立即读取决策，走内存零拷贝；用多进程则每帧都要过 IPC。代价是任一线程段错误会拖垮整个 robotd，所以我们给 monitor 线程加了"线程心跳看门狗"兜底重启。

2.4.2 pthread 四大基本 API 逐参数精讲

编译记得加 -pthread（不是 -lpthread 最好，前者同时处理编译和链接宏）。

#include <pthread.h>

int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
                   void *(*start_routine)(void *), void *arg);
  • thread：输出参数，带回新线程的 ID
  • attr：线程属性（栈大小、detach 状态等），传 NULL 用默认（默认栈 8MB）
  • start_routine：线程入口函数，原型固定 void *func(void *)
  • arg：传给入口函数的唯一参数——想传多个就打包成结构体（注意：传局部变量地址要防其生命周期结束！）
  • 返回值：0 成功，错误码直接作为返回值返回（不是 -1+errno！）——这是 pthread 全家桶的统一风格，面试细节分
int pthread_join(pthread_t thread, void **retval);
  • 阻塞等待 thread 结束，并回收其资源（不 join 也不 detach 的线程退出后成"僵尸线程"，栈和 TCB 泄漏）
  • retval：带出线程返回值（入口函数 return 的或 pthread_exit 给的）；不关心传 NULL
  • 谁 join 谁：通常创建者 join；一个线程只能被一个线程 join
int pthread_detach(pthread_t thread);
  • 把线程设为分离态：退出时自动回收资源，此后不能再 join
  • 常用于"发射后不管"的任务线程；也可在入口函数首行 pthread_detach(pthread_self()) 自我分离
void pthread_exit(void *retval);
  • 线程主动退出，retval 供 join 者接收
  • 与 exit() 的区别（必考）：pthread_exit 只退当前线程；exit() 退整个进程（所有线程陪葬）。main 函数 return 也是退整个进程；想让 main 等其他线程，结尾用 pthread_exit(NULL)。

2.4.3 代码示例：创建、传参、回收

/* thread_basic.c —— gcc thread_basic.c -pthread */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <pthread.h>

typedef struct {          /* 多参数打包 */
    int  id;
    char name[32];
} worker_arg_t;

void *worker(void *arg)
{
    worker_arg_t *a = (worker_arg_t *)arg;
    for (int i = 0; i < 3; i++) {
        printf("thread %d(%s) working, tid=%lu\n",
               a->id, a->name, (unsigned long)pthread_self());
        usleep(100 * 1000);
    }
    int *ret = malloc(sizeof(int));   /* 返回值用堆内存，别返回局部变量地址！ */
    *ret = a->id * 100;
    pthread_exit(ret);                /* 或 return ret; */
}

int main(void)
{
    pthread_t t1, t2;
    /* 静态/堆参数：栈上的 worker_arg_t 在 main 活着期间也安全 */
    static worker_arg_t a1 = {1, "can_rx"}, a2 = {2, "mqtt"};

    int rc = pthread_create(&t1, NULL, worker, &a1);
    if (rc != 0) { fprintf(stderr, "create: %s\n", strerror(rc)); return 1; }
    pthread_create(&t2, NULL, worker, &a2);

    void *r1, *r2;
    pthread_join(t1, &r1);
    pthread_join(t2, &r2);
    printf("t1 ret=%d, t2 ret=%d\n", *(int *)r1, *(int *)r2);
    free(r1); free(r2);
    return 0;
}

2.4.4 其余常用 pthread API 一套全

pthread_t pthread_self(void);                    /* 拿自己的 TID */
int pthread_equal(pthread_t t1, pthread_t t2);   /* 比较（pthread_t 可能是结构体，不能用==） */
int pthread_cancel(pthread_t thread);            /* 请求取消对方（对方在取消点才响应） */
int pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);  /* 关闭可被取消 */
void pthread_cleanup_push(func, arg);            /* 注册线程退出清理函数（成对宏） */
void pthread_cleanup_pop(execute);
int pthread_attr_init(&attr);                    /* 属性对象生命周期 */
int pthread_attr_setstacksize(&attr, 256*1024);  /* 嵌入式常缩栈省内存 */
int pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); /* 创建即分离 */
int pthread_attr_destroy(&attr);
int pthread_setname_np(thread, "can_rx");        /* 给线程起名！top -H 和 /proc/pid/task 里可见 */
int pthread_setaffinity_np(thread, sizeof(mask), &mask);         /* 绑核（CPU 亲和性） */
int pthread_once(&once_ctl, init_func);          /* 保证全局只执行一次（单例初始化） */
pthread_key_create(&key, destructor);            /* 线程局部存储 TLS（等价 __thread 变量） */
pthread_setspecific(key, value);  pthread_getspecific(key);

查看线程的命令：ps -eLf、top -H -p <pid>、ls /proc/<pid>/task/（每个线程一个目录）、cat /proc/<pid>/status（Threads 计数）。

2.4.5 线程安全与可重入

  • 线程安全（Thread-Safe）：函数被多线程并发调用结果仍正确。实现手段：加锁，或不用共享状态。
  • 可重入（Reentrant）：函数可被中断后再次进入仍正确——不使用全局/静态变量、不返回静态缓冲区、不调用不可重入函数的函数天然可重入。
  • 关系：可重入 ⇒ 一定线程安全；线程安全 ⇏ 可重入（比如靠锁实现安全的函数，信号处理里重入会死锁）。

经典反面教材：strtok（内部用静态指针）、asctime/localtime（返回静态缓冲区）、rand——它们都有 _r 后缀的可重入版：strtok_r、localtime_r、rand_r。信号处理函数里只能调用 async-signal-safe 函数（如 write、_exit），绝不能 printf（内部有锁，会死锁）。

/* 不可重入（错） */           /* 可重入（对） */
char *get_name(int id) {        char *get_name_r(int id, char *buf, size_t len) {
    static char buf[64];            snprintf(buf, len, "node%d", id);
    sprintf(buf, "node%d", id);     return buf;
    return buf;                 }
}                                /* 缓冲区由调用者提供 */

/* 或用 TLS：__thread char buf[64]; 每个线程一份 */

【记忆口诀】"join 收尸 detach 放，create 传参打包上；共享全局私有栈，errno 线程各一份；安全不一定可重入，可重入一定安全"。

2.5 同步原语

多线程共享内存是"方便"与"灾难"的一体两面：两个线程同时 counter++（实际是 读-改-写 三条指令），结果可能只加了一次——这就是竞态条件（Race Condition）。同步原语就是给共享资源立规矩。

2.5.1 互斥锁 mutex

#include <pthread.h>

int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *attr);
int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_trylock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);
int pthread_mutex_destroy(pthread_mutex_t *mutex);

/* 静态初始化（推荐，免 init/destroy） */
pthread_mutex_t g_lock = PTHREAD_MUTEX_INITIALIZER;
  • attr：锁属性（类型、进程间共享等），传 NULL 默认
  • lock：锁空闲则获得并继续；已被持有则阻塞（挂起等待，不占 CPU）
  • trylock：拿不到立即返回 EBUSY，不阻塞——用于"拿不到就先干别的"
  • 返回值统一：0 成功，错误码直接返回

铁律：①谁加锁谁解锁（不能跨线程传递）；②临界区尽量短（锁内只动共享数据，别干耗时操作）；③加锁后每一条退出路径都要解锁（含 return/break/出错分支——常用 goto 统一收尾或 RAII 思路）。

static pthread_mutex_t g_state_lock = PTHREAD_MUTEX_INITIALIZER;
static struct { int speed; int mode; } g_state;

int robot_get_speed(void)
{
    int s;
    pthread_mutex_lock(&g_state_lock);
    s = g_state.speed;                 /* 临界区：只做一次读 */
    pthread_mutex_unlock(&g_state_lock);
    return s;
}

属性扩展（面试加分项）：PTHREAD_MUTEX_RECURSIVE 递归锁（同线程可重复加锁，要配对解锁）；PTHREAD_MUTEX_ERRORCHECK 检错锁（重复加锁/未持锁解锁会报错而非死锁，调试期好用）；PTHREAD_PROCESS_SHARED 放共享内存里跨进程互斥。

2.5.2 死锁：四条件与避免

死锁四必要条件（面试必背，缺一不可，破坏其一即可防死锁）：

  1. 互斥：资源同一时刻只能一个线程持有
  2. 持有并等待：拿着锁 A 又去等锁 B
  3. 不可剥夺：锁只能持有者主动释放，别人抢不走
  4. 循环等待：线程 1 等线程 2 的锁，线程 2 等线程 1 的锁，成环

工程避免手段：

  • 固定加锁顺序（最常用）：全项目约定"永远先锁 state 再锁 mailbox"，从根上断环
  • trylock + 回退：拿不到第二把锁就放掉第一把，重试
  • 锁超时：pthread_mutex_timedlock()，超时返回报警
  • 减少嵌套：能用一把大锁就别玩锁中锁（并发度换简单可靠）
  • 排查工具：gdb -p <pid> 后 thread apply all bt 看每个线程卡在哪把锁

2.5.3 读写锁 rwlock

读多写少场景的优化：读锁可多人共享，写锁独占（写时无人可读可写）：

pthread_rwlock_t rwlock = PTHREAD_RWLOCK_INITIALIZER;
pthread_rwlock_rdlock(&rwlock);     /* 读锁：可并发 */
pthread_rwlock_wrlock(&rwlock);     /* 写锁：独占 */
pthread_rwlock_tryrdlock(...);  pthread_rwlock_trywrlock(...);
pthread_rwlock_unlock(&rwlock);     /* 不区分读写，统一解锁 */

典型场景：配置参数——99% 的时间各线程在读配置，只有 OTA 升级时写一次。注意写者可能饥饿（读者源源不断时写者排不上），glibc 默认实现读者优先，需评估。

2.5.4 自旋锁 spinlock（概念）

  • 与 mutex 的本质区别：拿不到锁时 mutex 挂起睡眠（让出 CPU），spinlock 忙等轮询（占着 CPU 空转）
  • 适用：临界区极短（几条指令）且预计等待时间小于两次上下文切换的开销——内核中断上下文只能用它（中断里不能睡眠！）
  • 用户态有 pthread_spin_lock/unlock；应用层 99% 场景用 mutex 更稳（临界区稍长 spin 就烧 CPU）
  • 对比记忆："mutex 睡觉等叫醒，spin 原地转圈等"

2.5.5 条件变量 condition variable（重头戏）

条件变量解决的是"等待某个条件成立"的问题。为什么不用 while 轮询？——while (!ready) ; 烧光 CPU；while(!ready) usleep(1000); 延迟与 CPU 不可兼得。cond 让线程睡进内核等待队列，条件满足时被精确唤醒。

pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex,
                           const struct timespec *abstime);
int pthread_cond_signal(pthread_cond_t *cond);      /* 唤醒一个等待者 */
int pthread_cond_broadcast(pthread_cond_t *cond);   /* 唤醒全部等待者 */

cond 为什么必须配 mutex（面试必考）：因为"检查条件"和"进入等待"之间存在竞态——若不加锁：线程 A 检查条件不成立，还没来得及 wait，线程 B 改了条件并 signal，这次唤醒就丢了，A 将永远睡死。mutex 把"检查条件 + wait"捆成原子操作。

pthread_cond_wait 内部三步曲（必背）：

  1. 原子地：解锁 mutex + 睡入等待队列（两步不可分——这就是防丢唤醒的关键）
  2. 被唤醒时：先重新获得 mutex（可能还要跟别的线程抢）
  3. 返回时调用者持有锁，处理完自行解锁

虚假唤醒（Spurious Wakeup）与为什么必须 while（必考中的必考）：pthread_cond_wait 可能没有任何人 signal 也返回（POSIX 明确允许，信号打断、多核实现代价等原因），而且就算有人 signal，被唤醒时条件也可能已被别的线程抢先消费。所以判断条件必须用 while 不能用 if：

/* ============ 标准范式（背下来！） ============ */
/* 等待方 */
pthread_mutex_lock(&m);
while (queue_is_empty(&q))              /* while！不是 if！ */
    pthread_cond_wait(&cond, &m);       /* 睡醒回来条件未必成立，回到while再查 */
msg = queue_pop(&q);
pthread_mutex_unlock(&m);

/* 通知方 */
pthread_mutex_lock(&m);
queue_push(&q, msg);
pthread_cond_signal(&cond);             /* 持锁内 signal 或解锁后 signal 都对 */
pthread_mutex_unlock(&m);

pthread_cond_timedwait 的绝对时间（细节分）：第三个参数是 绝对时间（abstime），不是相对时长！且默认基于 CLOCK_REALTIME（系统墙上时间，会被 NTP 校时影响；严谨做法用 pthread_condattr_setclock 换成 CLOCK_MONOTONIC）。用绝对时间的原因：while 循环重入 wait 时不需要重新计算剩余时间，直接把同一个截止时刻传进去即可：

struct timespec ts;
clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_sec += 1;                          /* 1 秒超时 */

pthread_mutex_lock(&m);
while (queue_is_empty(&q) && rc != ETIMEDOUT)
    rc = pthread_cond_timedwait(&cond, &m, &ts);   /* 超时返回 ETIMEDOUT */
pthread_mutex_unlock(&m);

signal vs broadcast：signal 只叫醒一个（适合"每来一条消息只需一个工人处理"）；broadcast 叫醒全部（适合"状态变了大家都来看看"、shutdown 时叫醒所有阻塞线程）。拿不准就 broadcast，反正等待方 while 会复查条件，多醒几个无害（惊群但正确）。

【记忆口诀】"先加锁后判断，while 循环防假唤；wait 三步曲：解锁睡、醒抢锁、回来锁还在；超时传绝对时间，shutdown 用 broadcast"。

2.5.6 信号量 sem_t

信号量 = 计数器版的锁：P 操作（wait）计数 -1，减到 0 以下就阻塞；V 操作（post）计数 +1，唤醒等待者。

#include <semaphore.h>

int sem_init(sem_t *sem, int pshared, unsigned int value);
int sem_wait(sem_t *sem);        /* P 操作，计数为0则阻塞 */
int sem_trywait(sem_t *sem);
int sem_timedwait(sem_t *sem, const struct timespec *abs_timeout);
int sem_post(sem_t *sem);        /* V 操作，计数+1 */
int sem_destroy(sem_t *sem);
  • pshared：0 = 线程间；非 0 = 进程间（需放共享内存）
  • value：初始计数。初值 1 = 互斥锁（二值信号量）；初值 N = 限流 N 个并发（资源池）；初值 0 = 事件通知/同步点

信号量 vs mutex 的区别（面试高频）：

  1. mutex 有所有者概念——谁锁谁解；信号量没有所有权——A 线程 wait 的可以由 B 线程 post（所以能做"生产者-消费者"通知，mutex 做不到）
  2. 信号量可计数，mutex 只能是 0/1
  3. 经典用途分工：互斥用 mutex，同步（事件通知）用 cond 或信号量，资源池用计数信号量

经典生产者-消费者用两个信号量：sem_empty（空位数，初值 N）+ sem_full（满位数，初值 0），生产 wait(empty)→放→post(full)，消费 wait(full)→取→post(empty)。

2.5.7 原子操作 __sync / __atomic

简单计数场景用锁太重（加解锁各一次原子指令+可能系统调用），编译器/CPU 提供无锁原子指令：

/* 老接口 __sync（GCC 内置） */
int old = __sync_fetch_and_add(&counter, 1);    /* 原子加，返回旧值 */
int new = __sync_add_and_fetch(&counter, 1);    /* 原子加，返回新值 */
bool ok = __sync_bool_compare_and_swap(&flag, 0, 1);  /* CAS：flag==0才置1 */

/* 新接口 __atomic（C++11 内存序对齐，推荐） */
int old = __atomic_fetch_add(&counter, 1, __ATOMIC_SEQ_CST);
__atomic_store_n(&flag, 1, __ATOMIC_RELEASE);
int v = __atomic_load_n(&flag, __ATOMIC_ACQUIRE);
  • CAS（Compare-And-Swap） 是无锁编程的基石：比较旧值相等才交换，一条指令搞定
  • 适用：单个变量的简单计数/标志位（比如统计收发帧数、shutdown 标志）。多变量关联更新的复杂临界区，老老实实用 mutex——无锁队列之类的结构写错概率极高，面试能说清就行，工程上慎自研
  • C11 标准版：<stdatomic.h> 的 atomic_int、atomic_fetch_add

【记忆口诀】"互斥用锁、通知用条件、计数用信号、单变量用原子；锁顺序防死锁，临界区要短小"。

2.6 线程邮箱 / 消息队列实战（robotd 方案完整复现）

2.6.1 需求分析

robotd 七个线程之间不直接调函数，而是互相投信：每个线程有一个"邮箱"，想跟谁通信就往谁的邮箱塞消息。邮箱要满足：

  1. 线程安全：多生产者并发投递
  2. 阻塞取信：没消息时消费者睡死，不占 CPU（can_tx 没活干时零功耗等待）
  3. 超时取信：storage 线程要"攒批 200ms"——等消息最多等 200ms，超时也要醒来落盘
  4. shutdown 唤醒：进程退出时广播，所有阻塞在邮箱上的线程立刻醒来退出
  5. 周期消息丢旧保新：monitor 的周期遥测消息，队列满时丢最旧的留最新的（控制命令绝不能丢，遥测丢一帧无所谓——这是实时系统的典型取舍）

底层结构：环形队列（ring buffer）+ mutex + 两个条件变量（not_empty / not_full）。

2.6.2 完整代码

/* mailbox.h —— robotd 线程邮箱 */
#ifndef MAILBOX_H
#define MAILBOX_H

#include <pthread.h>
#include <stdint.h>
#include <stdbool.h>

#define MB_CAP 64                    /* 容量取 2 的幂，下标可用位运算 */

typedef enum {
    MSG_CAN_FRAME = 0,               /* CAN 帧（控制链，高优先级，绝不丢） */
    MSG_MQTT_CMD,                    /* 云端命令 */
    MSG_TELEMETRY,                   /* 周期遥测（队列满可丢旧保新） */
    MSG_SHUTDOWN,                    /* 停机通知 */
} msg_type_t;

typedef struct {
    msg_type_t type;
    uint32_t   id;
    uint8_t    data[8];
    uint32_t   len;
    int64_t    timestamp_ms;
} mb_msg_t;

typedef struct {
    mb_msg_t  buf[MB_CAP];           /* 环形存储 */
    int       head;                  /* 读指针：下次从这里取 */
    int       tail;                  /* 写指针：下次往这里放 */
    int       count;                 /* 当前消息数 */
    bool      shutdown;              /* 停机标志 */

    pthread_mutex_t mtx;             /* 保护上面所有字段 */
    pthread_cond_t  not_empty;       /* 消费者睡眠点：队列从空变有 */
    pthread_cond_t  not_full;        /* 生产者睡眠点：队列从满变空 */
} mailbox_t;

/* 返回值约定：0 成功；-1 shutdown；-2 超时；-3 消息被丢弃策略拒绝 */
int  mailbox_init(mailbox_t *mb);
int  mailbox_send(mailbox_t *mb, const mb_msg_t *msg);          /* 阻塞投递 */
int  mailbox_recv(mailbox_t *mb, mb_msg_t *out);                /* 阻塞收信 */
int  mailbox_recv_timeout(mailbox_t *mb, mb_msg_t *out, int timeout_ms);
int  mailbox_send_overwrite(mailbox_t *mb, const mb_msg_t *msg); /* 丢旧保新 */
void mailbox_shutdown(mailbox_t *mb);
void mailbox_destroy(mailbox_t *mb);

#endif

/* mailbox.c —— 实现 */
#include "mailbox.h"
#include <errno.h>
#include <string.h>
#include <time.h>

int mailbox_init(mailbox_t *mb)
{
    memset(mb, 0, sizeof(*mb));
    pthread_mutex_init(&mb->mtx, NULL);
    pthread_cond_init(&mb->not_empty, NULL);
    pthread_cond_init(&mb->not_full, NULL);
    return 0;
}

/* ---------- 阻塞投递：满则等 ---------- */
int mailbox_send(mailbox_t *mb, const mb_msg_t *msg)
{
    pthread_mutex_lock(&mb->mtx);

    while (mb->count == MB_CAP && !mb->shutdown)   /* while 防虚假唤醒 */
        pthread_cond_wait(&mb->not_full, &mb->mtx);

    if (mb->shutdown) {                            /* 停机中拒收 */
        pthread_mutex_unlock(&mb->mtx);
        return -1;
    }

    mb->buf[mb->tail] = *msg;
    mb->tail = (mb->tail + 1) % MB_CAP;
    mb->count++;

    pthread_cond_signal(&mb->not_empty);           /* 叫醒一个消费者 */
    pthread_mutex_unlock(&mb->mtx);
    return 0;
}

/* ---------- 丢旧保新投递（遥测专用）：满则扔掉最旧的那条 ---------- */
int mailbox_send_overwrite(mailbox_t *mb, const mb_msg_t *msg)
{
    pthread_mutex_lock(&mb->mtx);

    if (mb->shutdown) {
        pthread_mutex_unlock(&mb->mtx);
        return -1;
    }
    if (mb->count == MB_CAP) {
        /* 队列满：head 前进一格 = 丢弃最旧消息，腾出一个位置 */
        mb->head = (mb->head + 1) % MB_CAP;
        mb->count--;
    }

    mb->buf[mb->tail] = *msg;
    mb->tail = (mb->tail + 1) % MB_CAP;
    mb->count++;

    pthread_cond_signal(&mb->not_empty);
    pthread_mutex_unlock(&mb->mtx);
    return 0;
}

/* ---------- 阻塞收信 ---------- */
int mailbox_recv(mailbox_t *mb, mb_msg_t *out)
{
    pthread_mutex_lock(&mb->mtx);

    while (mb->count == 0 && !mb->shutdown)        /* while 防虚假唤醒 */
        pthread_cond_wait(&mb->not_empty, &mb->mtx);

    /* 醒来的三种原因：有消息 / shutdown / 虚假唤醒（已回while复查） */
    if (mb->count == 0 && mb->shutdown) {          /* 停机且无残留消息 */
        pthread_mutex_unlock(&mb->mtx);
        return -1;
    }

    *out = mb->buf[mb->head];
    mb->head = (mb->head + 1) % MB_CAP;
    mb->count--;

    pthread_cond_signal(&mb->not_full);            /* 给生产者腾位通知 */
    pthread_mutex_unlock(&mb->mtx);
    return 0;
}

/* ---------- 超时收信（storage 攒批就靠它） ---------- */
int mailbox_recv_timeout(mailbox_t *mb, mb_msg_t *out, int timeout_ms)
{
    /* 1. 计算绝对截止时间：pthread_cond_timedwait 要的是绝对时间！ */
    struct timespec abstime;
    clock_gettime(CLOCK_REALTIME, &abstime);
    abstime.tv_sec  += timeout_ms / 1000;
    abstime.tv_nsec += (timeout_ms % 1000) * 1000000L;
    if (abstime.tv_nsec >= 1000000000L) {          /* 纳秒进位 */
        abstime.tv_sec++;
        abstime.tv_nsec -= 1000000000L;
    }

    pthread_mutex_lock(&mb->mtx);

    int rc = 0;
    while (mb->count == 0 && !mb->shutdown && rc != ETIMEDOUT)
        rc = pthread_cond_timedwait(&mb->not_empty, &mb->mtx, &abstime);

    if (mb->count == 0) {                          /* 超时 or shutdown 且队列空 */
        int ret = mb->shutdown ? -1 : -2;
        pthread_mutex_unlock(&mb->mtx);
        return ret;
    }

    *out = mb->buf[mb->head];
    mb->head = (mb->head + 1) % MB_CAP;
    mb->count--;

    pthread_cond_signal(&mb->not_full);
    pthread_mutex_unlock(&mb->mtx);
    return 0;
}

/* ---------- 停机：广播唤醒所有阻塞者 ---------- */
void mailbox_shutdown(mailbox_t *mb)
{
    pthread_mutex_lock(&mb->mtx);
    mb->shutdown = true;
    pthread_cond_broadcast(&mb->not_empty);        /* 叫醒所有消费者 */
    pthread_cond_broadcast(&mb->not_full);         /* 叫醒所有生产者 */
    pthread_mutex_unlock(&mb->mtx);
}

void mailbox_destroy(mailbox_t *mb)
{
    pthread_mutex_destroy(&mb->mtx);
    pthread_cond_destroy(&mb->not_empty);
    pthread_cond_destroy(&mb->not_full);
}

2.6.3 用法示例：storage 线程的攒批落盘

/* robotd 的 storage 线程主循环（简化版） */
void *storage_thread(void *arg)
{
    mailbox_t *mb = (mailbox_t *)arg;
    mb_msg_t batch[32];
    int n = 0;

    for (;;) {
        mb_msg_t msg;
        /* 关键：等第一条消息最多等 200ms —— "攒批窗口" */
        int rc = mailbox_recv_timeout(mb, &msg, 200);

        if (rc == 0) {
            batch[n++] = msg;
            /* 队列里还有就继续捞，凑满 32 条 */
            while (n < 32 && mailbox_recv_timeout(mb, &msg, 0) == 0)
                batch[n++] = msg;
        } else if (rc == -1) {          /* shutdown */
            if (n > 0) sqlite_batch_insert(batch, n);   /* 残余落盘 */
            break;
        }                                /* rc == -2 超时：窗口到点 */

        if (n > 0) {                     /* 32条满 或 200ms到 → 一次事务落盘 */
            sqlite_batch_insert(batch, n);
            n = 0;
        }
    }
    return NULL;
}

2.6.4 设计要点复盘（面试可以这样讲）

  1. 双条件变量分工：not_empty 给消费者睡，not_full 给生产者睡——有界队列的标准配置。
  2. 环形队列为什么取 2 的幂：下标回绕可以用 (i+1) & (CAP-1) 位运算代替取模（这里用 % 可读性优先，编译器对常量也会优化）。
  3. shutdown 语义：置标志 + broadcast 两个条件变量，保证所有睡眠线程都醒；醒来后 while 复查到 shutdown 按约定返回 -1，线程走到函数末尾自行退出——这是线程优雅退出的标准模式，比 pthread_cancel 安全（cancel 可能把线程杀在持锁状态）。
  4. 丢旧保新只给遥测用：控制命令走 mailbox_send 阻塞投递，宁可反压上游也不丢帧；遥测走 overwrite，实时性优先于完整性。不同 QoS 的消息走不同投递策略，是嵌入式消息系统的核心思想。
  5. 快慢隔离：storage 卡顿（SD 卡写阻塞在 D 态）只堵它自己的邮箱，控制链 can_rx→command→can_tx 的邮箱照常流动——队列本身就是天然的解耦缓冲。

【记忆口诀】"环形队列两个条件：空了等 not_empty，满了等 not_full；shutdown 广播双叫醒，遥测丢旧保新情"。

2.6.5 线程邮箱面试追问九连（面试官视角）

这是真实面试中围绕"自研线程邮箱"被连环追问的九个问题。每问给一段可以直接背的口语话术，再预测面试官的下一刀——九问往往是一路深挖下来的，答到第三问就能判断对方想考你到哪一层。

Q1：使用线程邮箱是为了解决什么问题？

参考回答话术：解决的是多线程之间的解耦问题。我们 robotd 是 7 线程架构，如果线程之间直接共享变量加锁通信，锁会散得到处都是，一个线程改坏了全局状态排查起来就是噩梦。所以我把线程间通信收敛成唯一原语：邮箱。生产者只管往邮箱投消息，消费者从邮箱取，线程之间互不知道对方存在——这样每个线程的输入输出边界非常清晰，能单测，出问题也只查队列两头。

追问预测："解耦之外还有什么好处？"→ 接"流量整形"：队列本身是缓冲，消费方慢的时候积压的是队列不是生产者（控制链除外）；还能接"慢快隔离"——storage 写 SD 卡 D 态卡住只堵自己的邮箱，控制链照跑。

Q2：线程邮箱是怎么实现的？

参考回答话术：核心是一个有界环形队列：固定容量数组加 head/tail 两个下标，取模回绕。并发保护用一把 pthread_mutex，再加一对条件变量——not_empty 给消费者睡，not_full 给生产者睡，这是有界生产者-消费者模型的标准配置。消息是按值拷贝进槽位的结构化 robot_msg_t，收发双方没有共享指针，所以没有所有权和释放时序问题。整体 200 行左右，能白板默写。

追问预测："为什么用环形队列不用链表？"→ 数组无 malloc 热路径（嵌入式嵌入式最忌讳运行期分配）、cache 友好、容量固定天然背压；"为什么两个条件变量不是一个？"→ 一个 cond 区分不了"等空的消费者"和"等满的生产者"，broadcast 会叫错人，效率低且逻辑绕。

Q3：解决多线程并发/互斥还有什么其他方式？

参考回答话术：我按场景分三类。互斥类：互斥锁、读写锁、自旋锁——临界区极短才考虑自旋锁，mutex 拿不到就睡，spinlock 拿不到烧 CPU 忙等。同步通知类：条件变量、信号量——条件变量是"条件+等待"，信号量是计数器，能跨线程 post。无锁类：C11 原子操作，适合只读共享和标志位，我们 health_t 健康位图就是原子量。但注意这些方式解决的是"共享数据怎么安全访问"，邮箱解决的是"干脆不共享"——把共享换成消息传递，是我认为复杂系统里更可控的路线。

追问预测："原子操作和锁怎么选？"→ 单个标量读改写用原子量，涉及多字段一致性就必须锁；"读写锁什么时候用？"→ 读远多于写且临界区长才划算，否则开销反而大于 mutex（详见 2.5）。

Q4：线程邮箱和消息队列的区别？

参考回答话术：看比哪一种。POSIX/System V 消息队列在内核里排队，能跨进程，但每次收发要过系统调用、数据要拷进内核再拷出来，还有 mq_open/mq_notify 那套接口复杂度；我的线程邮箱纯用户态，只在同一进程的线程间用，收发就是内存拷贝加一次 mutex，开销小一个量级，而且丢旧保新、shutdown 广播这些语义可以按业务定制——内核 mq 给不了。System V 消息队列比管道强在有消息边界和按类型选择性接收，但生命周期随内核，进程死了消息还在，忘删就泄漏。所以结论是：进程间用内核消息队列或 /dev/shm，线程间用自研邮箱。

追问预测："那为什么不直接用 POSIX mq？"→ 优先级机制用不上、丢旧保新要自己包一层、shutdown 唤醒不支持、还要管内核资源清理——204 行自研换来四个内建语义，划算（这条也是第 9 篇 9.3 第 6 问的考点）。

Q5：邮箱和"全局变量+互斥锁"的方式有什么区别？优点？

参考回答话术：本质区别是通信模型不同：全局变量加锁是共享内存模型，邮箱是消息传递模型。全局变量的痛在于：锁的粒度不好把握，粗了阻塞别人，细了容易漏；读方不知道什么时候数据更新了，只能轮询或再加通知机制；所有线程耦合在同一块数据上，改结构全员重编。邮箱反过来：自带消息边界，一条就是一条；自带唤醒，没消息消费者睡着不占 CPU；天然背压，队列满了能阻塞能丢旧保新；线程之间只见消息不见彼此，接口收敛。代价是多一次拷贝，但对几十字节的控制消息，这点拷贝换架构清晰度完全值。

追问预测："什么情况下全局变量加锁反而更好？"→ 高频只读共享（比如配置表、健康位图）用锁或原子量读比过邮箱快；邮箱适合"事件/命令/状态更新"这种离散的、有明确生产者消费者的场景。

Q6：你觉得线程邮箱有什么难点？

参考回答话术：三个。第一是条件变量的正确使用：wait 必须在 while 里复查条件，因为有虚假唤醒和"醒来时条件已被别人消费"两种情况，漏了就是偶发灵异 bug。第二是超时语义：pthread_cond_timedwait 吃的是绝对时间，而且默认 CLOCK_REALTIME，系统校时一跳超时就乱套，必须 pthread_condattr_setclock 绑单调时钟——车载设备 NTP 校时很常见，这是真踩过坑的点。第三是优雅退出：线程可能正阻塞在 cond_wait 上，shutdown 必须置标志后 broadcast 两个条件变量把所有人叫醒，让它们复查标志后返回 -1 自然退出，比 pthread_cancel 安全——cancel 可能把线程杀在持锁状态，那就是死锁。

追问预测："还有吗？"→ 丢旧保新的线程安全细节：队满覆盖最老消息要在持锁状态下先推进 tail 再写入，顺序反了消费者会读到半新半旧的消息。

Q7：使用邮箱时有没有丢数据？怎么实现的？

参考回答话术：会丢，但丢是设计出来的，不是事故。我把消息按重要性分级：命令和故障事件不可丢，走阻塞投递——队列满了生产者等，宁可反压上游也不丢帧；周期状态类消息（速度、轮速这类 20ms/200ms 就来一帧新的）走丢旧保新——队列满时覆盖最老的那条，再记一个丢帧计数器。判断标准就一句话：这条消息的价值随时间衰减吗？衰减就丢旧保新，旧值没有保留价值；不衰减就保证送达。实现上就是 send_overwrite 接口：持锁后如果队满，先把 tail 推进一格丢弃最老消息，再把新消息写到空出的槽位。

追问预测："丢帧计数器干嘛用的？"→ 可观测性，perf_log 定期落盘邮箱深度和丢帧数，长稳测试里它就是健康指标；"为什么不扩大队列避免丢？"→ 队列容量治不了根本，消费方持续比生产慢，多大的队列都会满，而且队列越深积压的消息越陈旧——状态消息及时丢旧的比延迟消费新的更正确。

Q8：邮箱存数据时只能存结构体吗？

参考回答话术：不是必须结构体，但强烈建议定长。我的设计是固定槽位的环形数组，每个槽位就是一个 robot_msg_t——type 枚举加 union 载荷，按值拷进拷出。这样做的好处：没有堆分配、没有所有权问题、没有深浅拷贝的坑。如果业务消息大小差异很大，技术上可以让槽位存指针，但那等于把生命周期管理和堆分配请回来了，谁 malloc 谁 free、消费者晚取导致悬垂，全是嵌入式里最贵的那类 bug。所以我的原则是：载荷用 union 容纳几种消息类型，最大那个决定槽位大小，简单可预测。

追问预测："union 是什么？为什么省内存？"→ 所有成员共享同一块存储，大小取最大成员（接第 1 篇内存对齐）；"可变长消息怎么办？"→ 大消息放共享内存或 /dev/shm，邮箱里只传句柄/偏移量——大数据走零拷贝，通知走邮箱，分工。

Q9：数据的接收和发送是怎么实现的？

参考回答话术：发送三变体：阻塞 send——持锁后队满就 wait 在 not_full 上，被消费者 signal 叫醒后写入槽位再 signal not_empty；限时 send——pthread_cond_timedwait 传单调时钟算的绝对时间，超了返回错误码，这个我顺手当周期任务的节拍器用；overwrite send——丢旧保新，上面讲过。接收也是对称的：阻塞 recv 队空就 wait not_empty，取走消息后 signal not_full 唤醒生产者；超时 recv 让 storage 线程"等第一条最多 200ms"，期间攒够 32 条或到点就整批一个事务落盘。所有 wait 都在 while 循环里复查条件，所有路径出锁前都检查 shutdown 标志。

追问预测："为什么 timedwait 传绝对时间不是相对时间？"→ 因为虚假唤醒后要回 while 重等，绝对 deadline 不变，剩余时间自动正确；传相对时间每次重算会累积误差甚至无限等下去。"怎么和 IO 多路复用配合？"→ 需要同时等 fd 和邮箱的线程（如 can_rx），用 socketpair 把"邮箱有消息"变成一个可读 fd，poll 一起盯（见 2.7.6/2.8.4）。

延伸问题索引（面试官从邮箱往外扩的常规路线，都在本手册内）：

  • 进程、线程概念与区别 → 回 2.3（进程：fork/COW/僵尸）和 2.4（线程：共享什么私有什么、pthread API）
  • IPC 通信方式全家桶（管道/fifo/mq/shm/信号/socketpair，及 /dev/shm 文件即接口实战）→ 2.7
  • 同步原语细节（mutex/死锁四条件/读写锁/自旋锁/条件变量深坑/信号量/原子操作）→ 2.5
  • "一个线程同时等 fd 和邮箱" → 2.8 IO 多路复用（poll 实战代码在 2.8.4）

【记忆口诀】"九问一条线：为什么（解耦）→ 怎么做（环形队列双条件）→ 还有啥（锁原语）→ 比一比（mq/全局变量）→ 难在哪（假唤/单调钟/优雅退）→ 丢不丢（分级丢旧保新）→ 存什么（定长 union 按值拷）→ 怎么收发（三发两收全 while）"。

2.7 进程间通信 IPC 全景

进程地址空间互相隔离，通信必须借助内核做中转站。下图是面试要能默写的全景：

┌─────────────┬───────────────┬──────────┬───────────┬──────────────────┐
│ 方式         │ 血缘要求       │ 速度      │ 生命周期   │ 典型场景          │
├─────────────┼───────────────┼──────────┼───────────┼──────────────────┤
│ pipe 匿名管道 │ 父子/兄弟      │ 中       │ 随进程     │ shell 的 |       │
│ fifo 命名管道 │ 任意          │ 中       │ 随文件     │ 本机简单流通信    │
│ 消息队列      │ 任意          │ 中       │ 随内核     │ 带类型的消息      │
│ 共享内存 shm  │ 任意          │ 最快     │ 随内核     │ 大数据量(配信号量)│
│ 信号 signal   │ 任意(同用户)   │ —       │ —         │ 异步事件通知      │
│ socketpair   │ 父子(通常)     │ 中       │ 随进程     │ 全双工管道        │
│ socket       │ 任意(可跨机)   │ 慢       │ 随进程     │ 网络/本机通用     │
│ 文件         │ 任意          │ 最慢     │ 随文件系统  │ 配置/状态共享     │
└─────────────┴───────────────┴──────────┴───────────┴──────────────────┘

2.7.1 匿名管道 pipe

#include <unistd.h>
int pipe(int pipefd[2]);   /* pipefd[0]=读端, pipefd[1]=写端 */
  • 半双工（数据只能单向流）、只用于有血缘关系的进程（fork 后父子各持一端）
  • 是字节流（无消息边界，write 两次的数据可能一次 read 出来）
  • 阻塞特性（面试常考）：写端全关 → read 返回 0（EOF）；读端全关 → write 触发 SIGPIPE（默认杀进程！）；管道满（默认 64KB）写阻塞、空则读阻塞
/* 父进程通过管道收子进程数据 —— shell 的 "ps aux | grep x" 原理 */
int fd[2];
pipe(fd);
pid_t pid = fork();
if (pid == 0) {                 /* 子：关读端，写 */
    close(fd[0]);
    dup2(fd[1], STDOUT_FILENO); /* 标准输出重定向到管道 */
    execlp("ps", "ps", "aux", NULL);
    _exit(127);
}
close(fd[1]);                   /* 父：关写端，读 */
char buf[256];
ssize_t n;
while ((n = read(fd[0], buf, sizeof(buf))) > 0)
    write(STDOUT_FILENO, buf, n);
waitpid(pid, NULL, 0);

2.7.2 命名管道 fifo

mkfifo /tmp/myfifo              # 命令创建（文件类型 p）

#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);   /* C 创建 */
  • 突破血缘限制：任意进程按路径名打开即可通信
  • 打开规则：以只读 open 会阻塞直到有进程以写打开（反之亦然），除非 O_NONBLOCK
  • 其余语义与 pipe 相同（字节流、半双工）

2.7.3 System V 消息队列

#include <sys/msg.h>
int msgget(key_t key, int msgflg);                    /* 创建/获取，key 常用 ftok 生成 */
int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg);
ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp, int msgflg);
int msgctl(int msqid, int cmd, struct msqid_ds *buf); /* IPC_RMID 删除 */
  • 与管道的本质区别：有消息边界（一条就是一条），且每条消息带 type 字段，可按类型选择性接收（msgtyp）
  • 生命周期随内核——进程全死了消息还在（要用 msgctl(IPC_RMID) 或 ipcrm 清理，否则泄漏！）
  • 查看命令：ipcs -q，删除：ipcrm -q <msqid>

2.7.4 共享内存 shm（最快的 IPC）

#include <sys/shm.h>
int   shmget(key_t key, size_t size, int shmflg);     /* 创建/获取 */
void *shmat(int shmid, const void *shmaddr, int shmflg); /* 挂接到本进程地址空间 */
int   shmdt(const void *shmaddr);                     /* 脱离 */
int   shmctl(int shmid, int cmd, struct shmid_ds *buf);   /* IPC_RMID 删除 */

为什么共享内存最快（面试必考）：管道/消息队列/socket 的数据路径是"用户态 → 内核拷贝 → 用户态"，两次拷贝；共享内存是同一块物理内存直接映射进两个进程的地址空间，数据零拷贝——写完对方立即可见。

代价：共享内存本身没有任何同步机制——一个写一个读必然撕裂，必须**配合信号量/互斥锁（PTHREAD_PROCESS_SHARED）**使用。"最快但最不省心"。

/* 极简示例：两个进程共享一个计数器 */
int shmid = shmget(0x1234, sizeof(int), IPC_CREAT | 0666);
int *cnt = (int *)shmat(shmid, NULL, 0);
*cnt = 42;                              /* 另一个进程 shmat 后立即可见 */
shmdt(cnt);
/* 清理：shmctl(shmid, IPC_RMID, NULL); 命令：ipcs -m / ipcrm -m <id> */

/dev/shm（tmpfs）：Linux 把 POSIX 共享内存和内存文件系统挂在 /dev/shm，在这建文件 = 直接用内存当文件读写，重启丢失、速度等同内存，不用走 System V 那套 API。工程上 open("/dev/shm/xxx", O_RDWR) + mmap 是现代做法。

2.7.5 信号 signal / sigaction

信号是异步事件通知（软件中断）：Ctrl+C（SIGINT）、段错误（SIGSEGV）、子进程死亡（SIGCHLD）、管道断裂（SIGPIPE）……

#include <signal.h>

/* 老式（不推荐：语义随平台漂移，且处理函数执行时可能被同类信号打断） */
sighandler_t signal(int signum, sighandler_t handler);

/* 现代标准姿势 */
struct sigaction {
    void     (*sa_handler)(int);        /* 处理函数，或 SIG_DFL / SIG_IGN */
    sigset_t   sa_mask;                 /* 处理期间额外屏蔽的信号集 */
    int        sa_flags;                /* SA_RESTART / SA_SIGINFO 等 */
    void     (*sa_sigaction)(int, siginfo_t *, void *);  /* 增强版（SA_SIGINFO 时用） */
};
int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);
int kill(pid_t pid, int sig);           /* 给进程发信号（kill 命令的底层） */
  • signum：SIGINT(2)、SIGTERM(15)、SIGUSR1(10) 等；SIGKILL(9) 和 SIGSTOP(19) 不可捕获、不可忽略、不可阻塞——这是系统留的"最后的手段"
  • sa_flags 常用：SA_RESTART（被该信号打断的慢速系统调用自动重启，否则 read 等返回 EINTR）；SA_SIGINFO（用增强版处理函数，能拿到发送者 PID、伴随数据）

处理函数里的两条铁律：①只调 async-signal-safe 函数（write、_exit；禁 printf/malloc——内部有锁，与主流程重入即死锁）；②标志位法是黄金模式——处理函数里只 volatile sig_atomic_t g_stop = 1;，主循环检测到标志再干正经活（daemon 收到 SIGTERM 优雅退出全靠这招）。

信号不是可靠的计数机制：相同信号连续到达多个可能合并为一个（非实时信号不排队）——所以 SIGCHLD 处理函数里要 while (waitpid(-1, NULL, WNOHANG) > 0) 循环收尸。

/* daemon 优雅退出标准模板 */
static volatile sig_atomic_t g_stop = 0;
static void on_term(int sig) { (void)sig; g_stop = 1; }

int main(void)
{
    struct sigaction sa = { .sa_handler = on_term };
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;                    /* 不自动重启，让阻塞的 read/poll 返回 EINTR 醒来 */
    sigaction(SIGTERM, &sa, NULL);
    sigaction(SIGINT,  &sa, NULL);

    while (!g_stop) {
        /* ... poll/read 被打断返回 EINTR → 回到 while 查 g_stop → 退出 ... */
    }
    /* 释放资源、mailbox_shutdown、回收线程 */
    return 0;
}

2.7.6 socketpair：全双工的"无名管道对"

#include <sys/socket.h>
int socketpair(int domain, int type, int protocol, int sv[2]);
/* 固定用法：socketpair(AF_UNIX, SOCK_STREAM, 0, sv); */

创建一对互联的 socket fd，双向通信，常用于父子进程双向对话，或"主线程唤醒 IO 多路复用线程"（往 sv[0] 写 1 字节，阻塞在 poll 上的线程立刻醒——比信号更安全，这是事件循环的标准唤醒术）。

2.7.7 项目实战：robotd/wifid/webd/hmi 的"/dev/shm 文件即接口"

真实架构：我们的机器人有四个常驻进程——robotd（控制主控）、wifid（网络）、webd（HTTP 服务）、hmi（屏显）。进程间不建 socket 不用消息队列，而是约定 /dev/shm/ 下的 JSON 文件就是接口：robotd 每 100ms 把整机状态写成 /dev/shm/robot_state.json，webd 和 hmi 需要状态时直接打开读；反过来 hmi 把用户操作写进 /dev/shm/user_cmd.json，robotd 轮询读取。

这种"文件即接口"的优缺点（面试如实讲，能体现工程权衡能力）：

优点 缺点
零依赖：不需要任何 IPC 框架，任何语言（含 shell 脚本！cat 一下就能读状态）都能接入 无通知机制：读方只能轮询，实时性差（100ms 级延迟）
天然解耦：写方挂了，读方读到的是最后一次状态（陈旧但可用），不会跟着崩 原子性靠技巧：必须"写临时文件 + rename"（rename 是原子操作），否则读方可能读到写了一半的 JSON
可观测性极强：调试时 cat /dev/shm/robot_state.json 一目了然，这是 socket/消息队列给不了的 无并发保护：多写者场景要 flock，我们约定每文件单写者规避
内存级速度：/dev/shm 是 tmpfs，不落盘，读写就是内存拷贝 无容量/背压控制：写方无节制会把 tmpfs 撑满
崩溃现场保留：进程死了文件还在，事后可复盘 重启即失（tmpfs 易失），不能当持久存储

一句话总结：状态类、单写多读、可容忍百毫秒延迟的数据，用 /dev/shm 文件是最省事的选择；控制类、需要即时通知的数据，仍要走 socket/邮箱。

【记忆口诀】"管道有血缘、fifo 给名分、消息带类型、shm 零拷贝最快但要自己管同步、信号只发通知不送货、socket 通吃本机与网络"。

2.8 IO 多路复用

2.8.1 为什么需要它：从一个现实问题说起

robotd 的 can_rx 线程要同时盯：CAN fd（总线帧随时来）+ 线程邮箱的唤醒 fd（别的线程要我发帧）+ 信号唤醒（shutdown）。如果用阻塞 read(canfd)，CAN 没数据时线程睡死在 read 里，邮箱有活也叫不醒。一个线程要同时等 N 个 fd，任一个有数据就处理——这就是 IO 多路复用。

2.8.2 先厘清：阻塞/非阻塞 与 五种 IO 模型

  • 阻塞 IO：read 没数据就睡到有数据（默认行为）
  • 非阻塞 IO：read 没数据立即返回 -1，errno = EAGAIN——线程可以去干别的，但要轮询
  • 设置：fcntl(fd, F_SETFL, flags | O_NONBLOCK) 或 open 时带 O_NONBLOCK

五种 IO 模型（面试必背，UNPv1 经典）：

模型 工作机制 一句话
阻塞 IO 等数据+拷数据全程阻塞 死等
非阻塞 IO 轮询查数据，拷数据时阻塞 勤问
IO 多路复用 先阻塞在 select/poll/epoll 等"就绪事件"，再阻塞 read 拷数据 一个人盯多个门
信号驱动 IO 数据到了内核发 SIGIO 通知 打电话叫我
异步 IO (AIO) 内核把"等+拷"全包了，完成后通知 快递送上门

注意：IO 多路复用不是"更快"，而是"一个线程管更多 fd"——两个阶段仍然都是阻塞的，真正的全程不阻塞只有 AIO（Linux 原生 AIO 只支持磁盘文件，网络 AIO 生态不成熟，所以 Nginx/Redis 全用 epoll）。

2.8.3 select：祖师爷

#include <sys/select.h>
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
           struct timeval *timeout);

void FD_ZERO(fd_set *set);        /* 清空集合 */
void FD_SET(int fd, fd_set *set); /* 加入 fd */
void FD_CLR(int fd, fd_set *set); /* 移除 */
int  FD_ISSET(int fd, fd_set *set); /* 返回后检测谁就绪 */
  • nfds：所有监听 fd 中最大值 + 1（内核要线性扫描 [0, nfds)，所以填错了性能崩塌）
  • 三个 fd_set：监听"可读/可写/异常"事件，传入传出复用——返回时被内核改写，只剩就绪的 fd，所以每次循环必须重新 FD_ZERO+FD_SET（select 最反人类的一点）
  • timeout：{秒, 微秒}；NULL = 永久阻塞；{0,0} = 轮询立即返回
  • 返回值：>0 就绪 fd 总数；0 超时；-1 出错（EINTR 被信号打断）

select 三大硬伤（必考）：①fd 上限 1024（FD_SETSIZE，fd_set 是位图，编译期定死）；②每次调用把集合从用户态拷到内核态；③内核O(n) 线性遍历所有 fd 找就绪者，用户也得 O(n) 遍历找谁就绪——fd 多了性能雪崩。

2.8.4 poll：去掉 1024 上限的改良版

#include <poll.h>
int poll(struct pollfd *fds, nfds_t nfds, int timeout);

struct pollfd {
    int   fd;        /* 监听的描述符 */
    short events;    /* 关心的事件（输入） */
    short revents;   /* 实际发生的事件（内核输出） */
};
  • 事件标志：POLLIN 可读、POLLOUT 可写、POLLERR 出错、POLLHUP 对端挂断、POLLNVAL fd 非法
  • timeout：毫秒；-1 永久阻塞；0 立即返回
  • 相比 select 的进步：①fd 数量无上限（数组而非位图）；②events/revents 分离——输入输出不打架，数组不用每次重建（只清 revents 由内核做）；③事件类型更丰富
  • 没解决的：仍然是每次全量拷贝 + O(n) 线性扫描——一万个 fd 只有 3 个活跃，也得遍历一万个
/* robotd can_rx 线程的真实姿势：poll 同时盯 CAN fd 和邮箱唤醒 fd */
struct pollfd pfds[2];
pfds[0].fd = can_fd;      pfds[0].events = POLLIN;   /* CAN 总线帧 */
pfds[1].fd = wakeup_fd;   pfds[1].events = POLLIN;   /* socketpair 唤醒 */

for (;;) {
    int n = poll(pfds, 2, 1000);              /* 最多睡 1s（周期任务兜底） */
    if (n < 0) { if (errno == EINTR) continue; break; }   /* 信号打断 */
    if (n == 0) { do_periodic_work(); continue; }         /* 超时 */
    if (pfds[0].revents & POLLIN)  read_can_frame();
    if (pfds[1].revents & POLLIN)  drain_wakeup_and_check_shutdown();
}

2.8.5 epoll：Linux 的终极答案（重点中的重点）

select/poll 的痛根：每次调用都要重复告诉内核"我关心哪些 fd"，内核每次都重新遍历。epoll 拆成三个 API，把这件事变成"注册一次，永久生效，内核主动告诉你谁就绪"：

#include <sys/epoll.h>

int epoll_create(int size);   /* 创建 epoll 实例，返回 epfd（size 现代内核已忽略，传>0） */

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
/* op: EPOLL_CTL_ADD 注册 / EPOLL_CTL_MOD 修改 / EPOLL_CTL_DEL 删除 */

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

struct epoll_event {
    uint32_t     events;  /* EPOLLIN 可读 / EPOLLOUT 可写 / EPOLLET 边沿触发 / EPOLLONESHOT */
    epoll_data_t data;    /* 用户数据！通常塞 fd 或连接对象指针，返回时原样带回 */
};

用法三步曲：

int epfd = epoll_create(1);

struct epoll_event ev = { .events = EPOLLIN, .data.fd = listen_fd };
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);       /* 注册一次即可 */

struct epoll_event events[64];
for (;;) {
    int n = epoll_wait(epfd, events, 64, -1);         /* 睡到有事件 */
    for (int i = 0; i < n; i++) {                     /* 只遍历就绪的！ */
        if (events[i].data.fd == listen_fd)  accept_new_client();
        else                                 handle_client(events[i].data.fd);
    }
}

为什么 epoll 是 O(1)（面试必考，要能讲出三个机制）：

  1. 红黑树存 fd：epoll_ctl 把 fd 注册进内核红黑树，一次注册终身有效，不用每次拷贝全量集合
  2. 回调挂就绪队列：fd 上有事件发生时，驱动层回调直接把该 fd 挂进"就绪链表"——不是轮询出来的，是事件驱动推进来的
  3. epoll_wait 只摘就绪链表：有就取走返回，空才睡眠。返回的 events 数组里全是活跃的，用户遍历的也是有效集——所以"O(1)"的准确含义是：开销只与活跃 fd 数有关，与监听总数无关（严格说摘链表是 O(就绪数)，但习惯叫 O(1)，与 select 的 O(总数) 对立）

LT vs ET（必考中的必考）：

LT 水平触发（默认） ET 边沿触发（EPOLLET）
通知语义 只要缓冲区还有数据没读完，epoll_wait 每次都报 只在"无数据→有数据"的边沿报一次
编程容错 高：这次没读完，下次还会通知 低：通知后没读完，剩下的数据将永远不再通知（直到新数据来）
强制要求 阻塞/非阻塞都行 必须非阻塞 fd + 循环 read 到 EAGAIN——否则阻塞 read 会把整个事件循环卡死（et 模式下你只被通知一次，read 阻塞在无数据的 fd 上就完蛋）
效率 略低（可能重复通知） 高（通知次数最少，Nginx 用它）

ET 模式的读循环范式：

/* ET + 非阻塞：一次事件，榨干缓冲区 */
for (;;) {
    ssize_t n = read(fd, buf, sizeof(buf));
    if (n > 0) { process(buf, n); }
    else if (n == 0) { close_peer(); break; }         /* 对端关闭 */
    else {
        if (errno == EAGAIN) break;                   /* 读干净了，等下次边沿 */
        if (errno == EINTR)  continue;
        perror("read"); break;
    }
}

补充技巧：EPOLLONESHOT——事件只报一次，处理完需 epoll_ctl(MOD) 重新武装，用于防止多线程同时处理同一 fd；epoll 还能监听 pipe、socketpair、timerfd、eventfd、signalfd——"万物皆可 epoll"（timerfd 把定时器变 fd，eventfd 做线程唤醒，robotd 的周期任务可以用 timerfd 优雅并入事件循环）。

2.8.6 三者对比总结（背这张表）

select poll epoll
出现年代 1983 1997 2002（Linux 2.5.44）
fd 上限 1024（FD_SETSIZE） 无（受系统资源限） 无
数据结构 位图 fd_set pollfd 数组 红黑树+就绪链表
每次调用开销 全量拷贝+O(n)扫描 全量拷贝+O(n)扫描 只取就绪，与总数无关
集合要每次重建吗 要 不要 不要（注册一次）
触发模式 LT LT LT / ET
适用 老代码/跨平台/fd 少 fd 中等、活跃度高 高并发、海量 fd 少活跃（服务器标配）
跨平台 全平台 Unix Linux 专有（FreeBSD 对应物 kqueue，Windows 是 IOCP）

选型口诀：fd 不过百，select/poll 简单可靠；fd 成千上万且活跃少，epoll 独步天下；如果活跃率极高（几乎个个就绪），epoll 优势缩水，poll 反而简单。

【记忆口诀】"select 千廿四上限每次重建集，poll 数组无上限照样 O(n) 扫，epoll 红黑树注册一次，就绪链表主动送，ET 必须非阻塞读到 EAGAIN"。

2.9 Socket 网络编程

2.9.1 socket 是什么

socket 是"进程间通信的端点"，把"两台机器的两个进程对话"抽象成"对一个 fd 做 read/write"。创建时指定三要素：协议族（IPv4/IPv6/Unix 本地）、类型（TCP 流 / UDP 报）、协议号（通常 0 自动）。

2.9.2 核心 API 逐参数精讲（按 TCP 服务端流程顺序）

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

/* ① 创建 socket */
int socket(int domain, int type, int protocol);
  • domain：AF_INET（IPv4）、AF_INET6（IPv6）、AF_UNIX/AF_LOCAL（本机进程间）
  • type：SOCK_STREAM（TCP：可靠、有序、字节流）、SOCK_DGRAM（UDP：不可靠、有报文边界）；可或上 SOCK_NONBLOCK、SOCK_CLOEXEC
  • protocol：0 = 按前两个参数自动选（TCP/UDP）
  • 返回值：socket fd，失败 -1
/* ② 绑定地址（服务端必做） */
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

地址结构体（IPv4 必背）：

struct sockaddr_in {
    sa_family_t    sin_family;   /* AF_INET */
    in_port_t      sin_port;     /* 端口号，网络字节序！要 htons() */
    struct in_addr sin_addr;     /* IP 地址，网络字节序！要 inet_pton/htonl */
    char           sin_zero[8];  /* 填充对齐，置 0 */
};

struct sockaddr_in addr = {0};
addr.sin_family      = AF_INET;
addr.sin_port        = htons(8080);                /* 主机序→网络序 */
addr.sin_addr.s_addr = htonl(INADDR_ANY);          /* 0.0.0.0 监听所有网卡 */
/* 或指定 IP：inet_pton(AF_INET, "192.168.1.10", &addr.sin_addr); */
bind(sockfd, (struct sockaddr *)&addr, sizeof(addr));

字节序（必考）：x86/ARM 是小端（低位在低地址），网络协议规定大端传输。四个转换函数：host to network short/htons（16 位端口）、htonl（32 位 IP）、ntohs、ntohl。忘记 htons 的端口 8080（0x1F90）会变成 36895（0x901F）——经典翻车现场。

/* ③ 开始监听（服务端） */
int listen(int sockfd, int backlog);
  • backlog：已完成三次握手、等待 accept 的连接队列长度上限（历史上曾含半连接队列，语义随内核版本变化；现代内核全连接队列还受 somaxconn 限制，实际取 min(backlog, somaxconn)）
  • listen 之后 socket 从"主动"变"被动"：只能 accept，不能 connect
/* ④ 接受连接（服务端）—— 返回一个全新 fd！ */
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
  • 返回值是新的已连接 fd，后续收发都用它；原 listen fd 继续等下一个客户——"一个 listen fd 生无数个连接 fd"，这是 TCP 服务器的基本结构
  • addr/addrlen：输出参数，带出客户端的 IP/端口（addrlen 是值-结果参数，调用前要先填 sizeof(addr)）；不关心可都传 NULL
  • 默认阻塞：没客户来就睡着
/* ⑤ 发起连接（客户端） */
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);
  • 向服务端发起三次握手，返回 0 成功；阻塞模式下握手超时可长达分钟级（由内核 SYN 重传策略决定）
  • 客户端一般不需要 bind——内核自动分配临时端口（ephemeral port）
/* ⑥ 收发 */
ssize_t send(int sockfd, const void *buf, size_t len, int flags);
ssize_t recv(int sockfd, void *buf, size_t len, int flags);
/* flags 常用：0；MSG_NOSIGNAL（对端已关闭时不发 SIGPIPE，服务器必加！） */
/* 或用 write/read 也行，等价于 flags=0 */

send/recv 返回值处理（面试必考，TCP 字节流无边界）：

  • send 可能短发送（返回 < len），必须循环发完；返回 -1/EAGAIN（非阻塞）表示缓冲区满，稍后重试
  • recv 返回 0 = 对端优雅关闭（FIN），这是"对方走了"的唯一信号，必须处理；返回 -1 且 EAGAIN = 暂无数据（非阻塞下正常）
  • TCP 是字节流：send 三次 "abc" 可能 recv 一次 "abcabcabc" 收全——应用层必须自己做消息边界（定长 / 分隔符 / 长度头，工业协议多用"4 字节长度头 + 包体"）
/* ⑦ 关闭 */
int close(int fd);
int shutdown(int sockfd, int how);   /* SHUT_RD/SHUT_WR/SHUT_RDWR 半关闭 */

2.9.3 setsockopt 与 SO_REUSEADDR

int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);

int on = 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));   /* bind 之前设！ */
  • SO_REUSEADDR（必考）：解决"服务器重启后 bind 失败 Address already in use"——因为上次连接残留 TIME_WAIT 状态（主动关闭方要等 2MSL，默认 60 秒）占着端口。设了它，允许 bind 到 TIME_WAIT 中的端口。所有服务端代码的标配第一行。
  • 其他常用：SO_RCVBUF/SO_SNDBUF（收发缓冲区）、SO_RCVTIMEO/SO_SNDTIMEO（收发超时，见下）、TCP_NODELAY（关 Nagle 算法，降延迟——控制类指令必关）、SO_KEEPALIVE（TCP 保活）、SO_BROADCAST（UDP 广播使能）

超时设置的三种层次（面试加分）：

  1. SO_RCVTIMEO：recv 超时返回 -1/EAGAIN——最简单
  2. select/poll/epoll + 非阻塞 connect：可控的连接超时（工程标准做法：设非阻塞 → connect 返回 EINPROGRESS → poll 等 POLLOUT → getsockopt(SO_ERROR) 确认结果）
  3. alarm/timerfd 兜底

2.9.4 TCP 服务端完整示例

/* tcp_server.c —— 回显服务器 gcc tcp_server.c -o server */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main(void)
{
    int lfd = socket(AF_INET, SOCK_STREAM, 0);

    int on = 1;
    setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));  /* 标配 */

    struct sockaddr_in addr = {0};
    addr.sin_family      = AF_INET;
    addr.sin_port        = htons(8080);
    addr.sin_addr.s_addr = htonl(INADDR_ANY);

    if (bind(lfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("bind"); return 1; }
    if (listen(lfd, 128) < 0) { perror("listen"); return 1; }
    printf("listening on 0.0.0.0:8080 ...\n");

    for (;;) {
        struct sockaddr_in cli;  socklen_t clen = sizeof(cli);
        int cfd = accept(lfd, (struct sockaddr *)&cli, &clen);
        if (cfd < 0) { if (errno == EINTR) continue; perror("accept"); break; }

        char ip[INET_ADDRSTRLEN];
        inet_ntop(AF_INET, &cli.sin_addr, ip, sizeof(ip));       /* 网络序→点分十进制 */
        printf("client %s:%d connected\n", ip, ntohs(cli.sin_port));

        /* 教学用：一次服务一个客户（真实服务器用 epoll 或每连接一线程） */
        char buf[1024];
        ssize_t n;
        while ((n = recv(cfd, buf, sizeof(buf), 0)) > 0) {       /* 0 = 对端关闭 */
            ssize_t sent = 0;
            while (sent < n) {                                   /* 循环防短写 */
                ssize_t w = send(cfd, buf + sent, n - sent, MSG_NOSIGNAL);
                if (w < 0) { if (errno == EINTR) continue; goto done; }
                sent += w;
            }
        }
done:   close(cfd);
        printf("client disconnected\n");
    }
    close(lfd);
    return 0;
}

2.9.5 TCP 客户端完整示例

/* tcp_client.c —— 带连接超时与接收超时 */
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/time.h>

int main(void)
{
    int fd = socket(AF_INET, SOCK_STREAM, 0);

    struct timeval tv = { .tv_sec = 3, .tv_usec = 0 };
    setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));  /* recv 3s 超时 */
    setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv));

    struct sockaddr_in srv = {0};
    srv.sin_family = AF_INET;
    srv.sin_port   = htons(8080);
    inet_pton(AF_INET, "127.0.0.1", &srv.sin_addr);

    if (connect(fd, (struct sockaddr *)&srv, sizeof(srv)) < 0) { perror("connect"); return 1; }

    const char *msg = "hello robotd";
    send(fd, msg, strlen(msg), MSG_NOSIGNAL);

    char buf[1024];
    ssize_t n = recv(fd, buf, sizeof(buf) - 1, 0);
    if (n > 0) { buf[n] = '\0'; printf("echo: %s\n", buf); }

    close(fd);
    return 0;
}

2.9.6 UDP 示例：无连接，用 sendto/recvfrom

/* UDP 没有 listen/accept/connect，每台机器都是"对等端" */
/* —— 接收方 —— */
int fd = socket(AF_INET, SOCK_DGRAM, 0);
struct sockaddr_in addr = {0};
addr.sin_family = AF_INET;  addr.sin_port = htons(9000);
addr.sin_addr.s_addr = htonl(INADDR_ANY);
bind(fd, (struct sockaddr *)&addr, sizeof(addr));

char buf[1024];  struct sockaddr_in from;  socklen_t flen = sizeof(from);
ssize_t n = recvfrom(fd, buf, sizeof(buf), 0, (struct sockaddr *)&from, &flen);
/* recvfrom 多出的两个参数：带出"谁发来的"，回复时直接用 */

/* —— 发送方 —— */
struct sockaddr_in to = {0};
to.sin_family = AF_INET;  to.sin_port = htons(9000);
inet_pton(AF_INET, "192.168.1.100", &to.sin_addr);
sendto(fd, "ping", 4, 0, (struct sockaddr *)&to, sizeof(to));

UDP 特性（对比 TCP 必背）：无连接（不需要握手）、保留报文边界（sendto 一次 = recvfrom 一次，不会粘连）、不保证可靠/有序/不丢包、头部开销小（8 字节 vs TCP 20+）、支持广播/组播。适用：音视频实时流（丢一帧比等重传强）、局域网发现（广播）、DNS。嵌入式场景：设备发现用 UDP 广播，控制指令用 TCP，遥测大流量用 UDP。

2.9.7 常用网络命令

netstat -tlnp            # 看谁在监听（t=tcp l=listen n=数字端口 p=进程名）老命令
ss -tlnp                 # netstat 的现代替代，更快
ss -ant | grep 8080      # 看 8080 的所有连接状态（TIME_WAIT 排查必备）
tcpdump -i eth0 port 8080 -nn   # 抓包（嵌入式板子上常带）
nc -l 8080               # nc 当临时服务器；nc 192.168.1.10 8080 当客户端
ping 192.168.1.1         # 测通断
telnet 192.168.1.10 8080 # 手测 TCP 端口连通性

【记忆口诀】"服务端五步走：socket、bind、listen、accept、recv/send；REUSEADDR 先设上，TIME_WAIT 不慌张；客户端两步走：socket、connect；字节流无边界，短写要循环，recv 返回 0 对端说再见；htons 转端口，htonl 转 IP"。

2.10 Makefile 工程

2.10.1 为什么需要 Makefile

单文件 gcc main.c 够了，但 robotd 这种几十上百个 .c 的工程，每次全量编译几分钟；Makefile 的核心价值是增量编译：靠"目标文件比源文件新吗"的时间戳比较，只重编改动的文件。make 命令读当前目录的 Makefile（或 makefile）执行。

2.10.2 规则三要素

目标(target): 依赖(prerequisites)
<Tab>命令(recipe)        ← 注意：命令行必须以 Tab 开头，不能是空格！

工作逻辑：make 发现"目标不存在"或"任一依赖比目标新"，就执行命令。依赖会递归求解（a 依赖 b，b 依赖 c，c 变了 b 和 a 都会重建）。

robotd: main.o can.o mqtt.o
	gcc main.o can.o mqtt.o -o robotd -lpthread

main.o: main.c can.h
	gcc -c main.c -o main.o

2.10.3 变量与自动变量

CC      = gcc                      # 递归展开变量（=，用时才展开）
CFLAGS := -Wall -Wextra -O2 -g     # 立即展开变量（:=，定义时展开，推荐）
LDFLAGS = -lpthread -lsqlite3

SRCS = main.c can.c mqtt.c
OBJS = $(SRCS:.c=.o)               # 替换引用：main.o can.o mqtt.o
OBJS = $(patsubst %.c,%.o,$(SRCS)) # 等价函数写法
SRCS = $(wildcard src/*.c)         # 通配符函数：展开成实际文件列表

自动变量（面试必考三兄弟）：

变量 含义 例子 app: main.o util.o
$@ 目标 app
$^ 所有依赖（去重） main.o util.o
$< 第一个依赖 main.o 
robotd: $(OBJS)
	$(CC) $^ -o $@ $(LDFLAGS)      # 链接：所有 .o → 目标

2.10.4 模式规则与伪目标

# 模式规则：任何 .o 都由同名 .c 编译而来，一条规则管全项目
%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@

# 伪目标：不产出同名文件的目标（clean 目录里若有个叫 clean 的文件，没有 .PHONY 就永远不执行）
.PHONY: all clean
all: robotd

clean:
	rm -f $(OBJS) robotd

其他内置规则活用：make -p 查看全部隐式规则；make -n 只打印命令不执行（调试 Makefile 用）；make -j8 并行编译（8 核开发机提速必备）。

2.10.5 交叉编译：换一套工具链变量

嵌入式 Makefile 的灵魂：CC 指向交叉工具链，其它照旧：

# 本机调试：make
# 交叉编译：make CROSS=arm-linux-gnueabihf-   （或写死）
CROSS  ?=
CC      = $(CROSS)gcc
AR      = $(CROSS)ar
STRIP   = $(CROSS)strip
  • arm-linux-gnueabihf-gcc：ARM 32 位、硬浮点（hf）Linux 工具链；aarch64 板子用 aarch64-linux-gnu-gcc
  • 工具链安装后 which arm-linux-gnueabihf-gcc 验证；编出的二进制用 file robotd 确认是 ARM 而非 x86-64
  • 内核/uboot 编译约定 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

2.10.6 多目录项目 Makefile 实例（robotd 简化版）

robotd/
├── Makefile
├── src/        # main.c 各线程入口
├── net/        # mqtt.c 网络
├── hal/        # can.c 硬件抽象
└── inc/        # 头文件

# ================= 工具链 =================
CROSS   ?=
CC       = $(CROSS)gcc
STRIP    = $(CROSS)strip

# ================= 目录与文件 =================
TARGET   = robotd
SRCDIRS  = src net hal
INCDIR   = inc
BUILD    = build

# wildcard 展开各目录的 .c；patsubst 把 src/x.c 映射成 build/src/x.o
SRCS = $(foreach d,$(SRCDIRS),$(wildcard $(d)/*.c))
OBJS = $(patsubst %.c,$(BUILD)/%.o,$(SRCS))
DEPS = $(OBJS:.o=.d)                    # 自动头文件依赖

# ================= 编译选项 =================
CFLAGS  = -Wall -Wextra -O2 -g -I$(INCDIR) -pthread
LDFLAGS = -pthread -lsqlite3

# ================= 规则 =================
all: $(TARGET)

$(TARGET): $(OBJS)
	$(CC) $^ -o $@ $(LDFLAGS)
	@echo "==> link ok: $@"

# 模式规则：build/src/x.o ← src/x.c；| $(BUILD) 是"仅顺序依赖"
$(BUILD)/%.o: %.c
	@mkdir -p $(dir $@)                          # 自动建 build 子目录
	$(CC) $(CFLAGS) -MMD -MP -c $< -o $@         # -MMD 生成 .d 头文件依赖

-include $(DEPS)          # 包含依赖：改了 .h 也会触发重编（前面 - 表示文件不存在不报错）

.PHONY: all clean strip install
strip: $(TARGET)
	$(STRIP) $(TARGET)                           # 裁剪符号，嵌入式省 Flash

clean:
	rm -rf $(BUILD) $(TARGET)

install: $(TARGET)
	cp $(TARGET) /usr/bin/

亮点解读：①-MMD -MP 让 gcc 自动生成头文件依赖（改 can.h 会重编所有包含它的 .c，这是新手 Makefile 最常漏的坑）；②mkdir -p $(dir $@) 自动建 build 镜像目录；③$(foreach) + $(wildcard) 自动收集源码，新增文件零改动；④换交叉编译只需 make CROSS=aarch64-linux-gnu-。

【记忆口诀】"目标依赖加命令，Tab 开头是铁律；@目标、^全依赖、<第一依赖；%.o 模式规则一条管全；.PHONY 保 clean；交叉编译只换 CC"。

2.11 面试高频问答

Q1：进程和线程的区别？

调度与资源两个维度：进程是资源分配的最小单位（独立地址空间、fd 表），线程是 CPU 调度的最小单位。同进程线程共享代码段、全局数据、堆、fd、信号处理方式；私有栈、寄存器、TID、errno、信号掩码。后果三连：①线程切换/创建开销远小于进程（不换页表不刷 TLB）；②线程间通信直接读写全局变量即可但要加锁，进程必须走 IPC；③进程间天然隔离一个崩不影响其他，线程一个段错误全进程陪葬。选型：要隔离用多进程，要高频低延迟共享数据用多线程（robotd 控制链选 7 线程，与外围 wifid/webd/hmi 之间选多进程）。

Q2：select、poll、epoll 的区别？

四刀切：①fd 上限：select 1024（位图定死），poll/epoll 无上限；②数据结构：位图 / pollfd 数组 / 红黑树+就绪链表；③时间复杂度：select 和 poll 每次调用全量拷贝到内核并 O(n) 线性扫描，epoll 用 epoll_ctl 注册一次，事件发生时回调挂就绪链表，epoll_wait 只取就绪项——开销与监听总数无关只与活跃数有关；④触发模式：select/poll 只有 LT，epoll 支持 LT 和 ET。场景：fd 少且跨平台用 select；fd 中等用 poll；海量连接低活跃（高并发服务器）用 epoll。

Q3：epoll 为什么快？为什么叫 O(1)？

三个机制：①红黑树管理注册 fd，注册一次终身有效，免去每次全量拷贝；②fd 事件就绪由驱动回调主动挂入就绪链表，不是轮询发现的；③epoll_wait 只摘取就绪链表返回，用户遍历的每一项都是有效事件。所以开销只跟活跃 fd 数有关，与监听总数无关——对比 select 的"一万个 fd 三个活跃也要扫一万个"。

Q4：epoll 的 ET 模式为什么必须配非阻塞 fd？

ET 只在"无数据→有数据"的边沿通知一次。若用阻塞 fd：你 read 一次没读干净，内核不再通知，等你下次 read 时如果剩余数据不足一次 read 请求，线程就永久阻塞在这个 fd 上，整个事件循环卡死。所以 ET 的正确姿势是：fd 设非阻塞 + 循环 read 直到返回 EAGAIN（数据读干净），下次边沿来了再榨一轮。LT 没这问题：没读完下次还会通知，但通知次数多、效率略低。

Q5：条件变量为什么必须配合 mutex？为什么必须用 while 不能用 if？

两个问题两个答案。配 mutex：为了消除"检查条件"与"进入睡眠"之间的竞态窗口——若不持锁，线程 A 查完条件为假、还没 wait，线程 B 恰好改条件并 signal，这次唤醒丢失，A 永久睡死。pthread_cond_wait 把"释放锁+睡眠"做成原子操作堵死这个窗口。用 while：因为 ①POSIX 允许虚假唤醒（没人 signal 也可能返回）；②即使真被 signal，醒来抢到锁时条件可能已被别的线程抢先消费。醒来必须回到 while 重新判断，条件不成立就继续睡——口诀"先加锁后判断，while 循环防假唤"。

Q6：僵尸进程怎么产生？怎么避免？

产生：子进程退出后内核保留其退出状态（尸体），父进程没调用 wait/waitpid 收尸，子进程就成了 Z 状态的僵尸——不占内存 CPU 但占 PID 表项，多了会耗尽进程号。避免四招：①父进程及时 wait/waitpid；②捕获 SIGCHLD，处理函数里 while (waitpid(-1, NULL, WNOHANG) > 0) 循环收（循环是因为信号会合并，一次可能死多个）；③signal(SIGCHLD, SIG_IGN) 让内核自动回收；④fork 两次让孙子被 init 收养（daemon 做法）。追问"已经有僵尸了怎么办"：杀父进程——僵尸被 init 收养后由 init 收尸。

Q7：fork 的返回值？子进程复制了什么？为什么 fork 很快？

父进程拿到子 PID，子进程拿到 0，失败 -1，一次调用两次返回。子进程复制：地址空间（代码/数据/堆/栈）、fd 表（共享内核文件对象和偏移量）、信号处理、工作目录；不复制：PID/PPID、线程（只有调用 fork 的线程）。快的原因是写时复制 COW：fork 时父子共享全部物理页，只复制页表，谁写谁才真正复制那一页。追问：多线程进程 fork 后应立即 exec，因为其他线程持有的锁在子进程里永远不会被释放。

Q8：exit 和 _exit 的区别？printf 之后 fork 为什么输出重复？

exit 是库函数：先 flush 所有标准 IO 缓冲区、执行 atexit 注册的函数，再调 _exit 进内核；_exit 直接终止，不刷缓冲。所以 fork 出的子进程若不 exec，退出要用 _exit。printf 重复输出的原理：stdout 接管道/文件时是全缓冲，printf 的内容还躺在用户缓冲区里没进内核，fork 把缓冲区原样复制给子进程，父子各自退出时各 flush 一次——同样内容输出两遍。

Q9：共享内存为什么是最快的 IPC？它有什么坑？

快在零拷贝：管道/消息队列/socket 的数据路径是"用户态→内核→用户态"两次拷贝，共享内存把同一物理页映射进双方地址空间，写方落笔读方立即可见，数据根本不动。坑：没有任何同步机制——必须配信号量或进程间互斥锁（PTHREAD_PROCESS_SHARED）防读写撕裂；生命周期随内核，进程全死它还在，要记得 shmctl(IPC_RMID) 或用 ipcrm 清理；另外共享内存里不能存裸指针（两进程虚拟地址不同，指针值无意义，要存偏移量）。

Q10：互斥锁和信号量的区别？

三点：①所有权：mutex 有属主概念，必须谁加锁谁解锁；信号量无所有权，A 线程 wait 的可以由 B 线程 post——所以信号量能做事件通知，mutex 不能。②计数：mutex 只有 0/1；信号量初值 N 就是资源池限流 N 个并发。③分工口诀：互斥用 mutex，同步通知用条件变量或二值信号量，资源池用计数信号量。追问自旋锁：mutex 拿不到就睡（让 CPU），spinlock 拿不到忙等（烧 CPU），只在临界区极短或内核中断上下文用。

Q11：send 返回成功数据就一定到达对端了吗？recv 的返回值有哪些情况？

send 返回 >0 只表示数据拷进了本机内核发送缓冲区，不代表到达对端、更不代表对端应用读了——可靠性由 TCP 协议栈后续保证。recv 三种返回值：>0 实际读到的字节数（可能小于请求值）；=0 对端有序关闭（收到 FIN，必须处理，否则死循环）；<0 出错，EAGAIN 是非阻塞无数据（正常）、EINTR 被信号打断（重试）。另外 send 有"短写"必须循环发完；对端已关闭还 send 会触发 SIGPIPE，服务器要么 signal 忽略要么用 MSG_NOSIGNAL。

Q12：TIME_WAIT 是什么？SO_REUSEADDR 解决什么问题？

主动关闭 TCP 连接的一方，发完最后一个 ACK 后要等 2MSL（约 60 秒） 才彻底释放——两个目的：保证最后一个 ACK 丢失时能重传；让本次连接的迷途报文在网络里死透，不污染下一个同四元组连接。副作用：服务器主动重启后旧端口还在 TIME_WAIT，bind 报 Address already in use。SO_REUSEADDR 允许 bind 处于 TIME_WAIT 的端口，是服务端标配（要在 bind 之前设置）。追问：大量 TIME_WAIT 多半是服务器主动关连接导致的，可以让客户端先关或调整连接复用策略。

Q13：TCP 和 UDP 的区别？各适合什么场景？

连接性：TCP 面向连接（三次握手），UDP 无连接；可靠性：TCP 保证不丢不重不乱序（确认+重传+排序），UDP 都不保证；数据边界：TCP 是字节流无边界（应用层要自己做分包），UDP 保留报文边界；开销：TCP 头 20 字节起+状态机，UDP 头 8 字节；拓扑：UDP 支持广播组播，TCP 只能一对一。场景：控制指令、文件传输、MQTT 用 TCP（要可靠）；音视频流、设备发现广播、高频遥测（丢一帧无所谓的）用 UDP。嵌入式常见分工：UDP 广播做设备发现，TCP 传控制，UDP 传遥测。

Q14：写一个守护进程要哪几步？

五步：①fork 后父进程退出（子进程不是组长，且 shell 认为命令结束）；②setsid 创建新会话脱离控制终端；③再 fork 一次，孙子不是会话首进程，永远拿不到控制终端；④umask(0) + chdir("/")（防权限被掩、防占用挂载点）；⑤关闭或重定向继承的 fd（0/1/2 指向 /dev/null 或日志文件）。最后别忘了处理 SIGTERM 置标志优雅退出、SIGCHLD 收尸。工程上也常用 daemon(0, 0) 一步封装或交给 systemd 托管。

Q15：线程安全的函数和可重入函数是什么关系？strtok 为什么不能用？

可重入：函数可在任意时刻被中断并重入仍正确，条件是不碰全局/静态状态、不调不可重入函数。线程安全：多线程并发调用结果正确（可以靠锁实现）。关系：可重入必然线程安全，线程安全不一定可重入（靠锁实现的函数在信号处理函数里重入会死锁）。strtok 内部用静态指针记录切分位置，两个线程同时切不同字符串会互相踩；用可重入版 strtok_r（位置指针由调用者持有），同类还有 localtime_r、rand_r。信号处理函数里只准调 async-signal-safe 函数（write、_exit），禁 printf/malloc。

Q16（项目向）：你们 robotd 的线程邮箱怎么设计的？storage 线程为什么要超时收信？

邮箱 = 环形队列 + mutex + 双条件变量（not_empty/not_full），有界容量。三收一发：阻塞收（控制链）、超时收（pthread_cond_timedwait 传绝对时间）、丢旧保新发（队列满丢最旧消息，专供周期遥测，控制命令走阻塞投递绝不丢）。shutdown 时置标志 + broadcast 双条件变量，所有阻塞线程醒来走优雅退出路径。storage 用超时收信实现攒批：等第一条最多 200ms，期间攒满 32 条或窗口到点就把整批塞进一个 SQLite 事务落盘——把每帧一次的 fsync 摊薄到每批一次，磁盘 IO 降两个数量级；storage 独立线程 + 队列解耦，SD 卡偶尔卡顿也不反压 can_rx→command→can_tx 实时控制链。

【本篇总口诀】"fork 分身 exec 换芯 wait 收尸；线程共享全局私有栈，mutex 管互斥 cond 管通知；ring buffer 加双条件变量就是邮箱；IPC 里 shm 最快信号最轻；IO 多路复用记 epoll 红黑树加就绪链表；socket 五步走加 REUSEADDR；Makefile 三要素目标依赖 Tab 命令"。

第3篇 嵌入式 Linux 系统移植与构建

本篇面向零基础读者，目标：能在 BSP/系统移植方向面试中，把"从上电到 shell 亮起"的完整链路讲清楚，并结合 i.MX6ULL（Cortex-A7）真实移植经历（U-Boot 2025.04 + Linux Kernel 6.12.34 + 设备树裁剪 + BusyBox rootfs + Buildroot）回答高频问题。

3.1 嵌入式 Linux 系统全景

3.1.1 一个嵌入式 Linux 系统由哪几部分组成

一个能跑起来的嵌入式 Linux 产品，存储介质里（SD 卡 / eMMC / NAND Flash）通常躺着四类东西：

+---------------------------------------------------+
|  Bootloader   |  Kernel + DTB  |  RootFS  |  App  |
| (U-Boot/SPL)  | (zImage+.dtb)  | (BusyBox)| (你的程序)|
+---------------------------------------------------+
  • Bootloader（引导加载程序）：上电后第一段运行的代码，负责初始化 DDR、时钟等最底层硬件，然后把内核镜像从存储搬到内存并跳转执行。嵌入式领域事实标准是 U-Boot。
  • Linux Kernel（内核）：管理 CPU、内存、进程、驱动。镜像常见形式为 zImage（自解压压缩镜像）。
  • DTB（设备树二进制）：描述"这块板子上有什么硬件"的数据结构，由内核解析。内核代码本身不再写死板级信息。
  • RootFS（根文件系统）：内核启动后挂载的第一个文件系统，里面有 /bin /sbin /etc /lib 等目录和第一个用户态进程 init。最小系统常用 BusyBox 一把梭提供所有命令。
  • App（应用程序）：你交叉编译出来的业务程序，通常由开机脚本（如 S99xxx）拉起来。

3.1.2 上电启动流程：ROM → SPL → U-Boot → Kernel → init

以 i.MX6ULL（Cortex-A7 单核）为例，按一下电源键后发生的事：

上电
 │
 ▼
① BootROM（芯片出厂固化在 ROM 里的代码，不可修改）
 │   - 读 BOOT_MODE 引脚/eFuse，判断从哪儿启动（SD/eMMC/NAND/USB）
 │   - 从启动介质固定偏移处读 IVT/DCD 头，按 DCD 表初始化 DDR
 │   - 把 SPL（或完整 U-Boot）拷进 DDR，跳转执行
 ▼
② SPL（Secondary Program Loader，U-Boot 的第一阶段）
 │   - 进一步初始化时钟树、DDR 时序
 │   - 把完整版 U-Boot 从存储加载到 DDR，跳转
 ▼
③ U-Boot  proper（第二阶段，功能完整的引导程序）
 │   - 初始化串口、网口、MMC、LCD 等
 │   - 执行 bootcmd：把 zImage 和 .dtb 从 eMMC/TFTP 加载到 DDR
 │   - 把 bootargs 通过 dtb 的 chosen 节点传给内核，跳转内核入口
 ▼
④ Linux Kernel
 │   - 自解压 → 汇编 head.S → start_kernel()
 │   - 解析 dtb，初始化内存管理、驱动模型，挂载根文件系统
 │   - 启动 1 号进程：执行 bootargs 里 init= 指定的程序（默认 /sbin/init）
 ▼
⑤ init → /etc/inittab → /etc/init.d/rcS → S99 自启动脚本 → 你的 App

面试时能把这条链一口气画出来，再加一句"每一步崩了对应什么现象"，就已经赢过大多数人：

  • 串口一个字都没有 → BootROM 没找到可启动镜像（镜像烧错偏移/启动方式拨码错）。
  • 只有 SPL/U-Boot 早期输出后停住 → DDR 初始化参数不对。
  • U-Boot 正常、内核无输出 → bootargs 的 console= 写错，或 dtb 与内核不匹配。
  • 内核跑到最后 Kernel panic: not syncing: VFS: Unable to mount root fs → rootfs 挂载失败（root= 写错/文件系统损坏）。
  • 挂载成功但没有 shell → inittab/rcS 配置问题。

【记忆口诀】先 SPL 后 U-Boot，内核设备树，根里 init 起。
（启动顺序：SPL → U-Boot → Kernel(带 dtb) → rootfs 里的 init）

3.1.3 i.MX6ULL 的启动方式

i.MX6ULL 通过 BOOT_MODE[1:0] 两个引脚 + eFuse/拨码开关决定从哪里启动：

启动介质 说明 典型场景
SD 卡 镜像写在 SD 卡固定偏移（如 1KB/33KB 处） 开发期、量产烧录母卡
eMMC 板上焊接的 eMMC 芯片，分区存放 bootloader/kernel/rootfs 产品正式形态
NAND Flash 大容量低成本，需 ECC/BCH 校验，写 UBI 文件系统 成本敏感产品
USB（SDP） 通过 NXP 的 uuu（mfgtools）工具经 USB OTG 下载镜像 空片救砖、产线烧录

判断当前从哪启动：U-Boot 里看环境变量 printenv bootcmd，或看原理图拨码。开发期的经典组合是 TFTP 下载内核 + NFS 挂载根文件系统（改代码不用拔卡），量产时切换为 eMMC 独立启动，这两条路线本篇 3.7、3.8 会完整给出。

3.2 交叉编译工具链

3.2.1 为什么需要交叉编译

PC 是 x86_64 架构、几 GHz 主频、几十 GB 内存；i.MX6ULL 是 ARM Cortex-A7、528MHz、512MB DDR。在开发板上装 gcc 编译内核，慢到不可接受甚至内存都不够。所以采用交叉编译（Cross Compile）：在 x86 PC 上运行编译器，生成 ARM 板子上能跑的机器码。

  • 运行编译器的机器叫 host（宿主机）：x86_64 Ubuntu PC。
  • 程序最终运行的机器叫 target（目标机）：ARM 开发板。

【记忆口诀】宿主编，目标跑；架构不同才交叉。 同架构（如在 x86 PC 编译给另一台 x86）叫本地编译，不需要交叉。

3.2.2 工具链命名含义：arch-vendor-os-abi

arm-linux-gnueabihf-gcc 这个名字本身就是一道面试题，按 - 拆开：

字段 值 含义
arch arm 目标 CPU 架构：32 位 ARM（64 位则是 aarch64）
vendor （省略，常见 none/unknown/buildroot） 工具链制作方
os linux 目标操作系统是 Linux（裸机则是 none，即 arm-none-eabi-）
abi gnueabihf C 库用 glibc（gnu），EABI 接口，hf=hard-float 硬浮点

gnueabi vs gnueabihf（高频考点）：

  • gnueabi：软浮点 ABI。浮点运算用整数指令模拟（softfp 是用 FPU 指令但按软浮点约定传参，注意区分）。
  • gnueabihf：硬浮点 ABI。浮点参数直接走 VFP/NEON 寄存器，速度快很多。Cortex-A7 带 VFPv4，所以选 hf。
  • 坑：用 hf 工具链编译的程序，链接的所有库（包括 rootfs 里的 libc）也必须是 hf 版本，混用会报 VFP register arguments 链接错误或运行崩溃。

常见工具链一览：

工具链前缀 用途
arm-none-eabi- 裸机/RTOS（STM32、Cortex-M），无操作系统
arm-linux-gnueabihf- 32 位 ARM Linux，硬浮点（i.MX6ULL、全志、瑞芯微 32 位平台）
aarch64-linux-gnu- 64 位 ARM Linux（RK3399、树莓派 4 64 位系统）

3.2.3 安装方法

# 方式一：apt 直接装（版本较老，但够用）
sudo apt install gcc-arm-linux-gnueabihf

# 方式二：解压官方/厂商提供的压缩包（版本可控，移植项目常用）
tar -xf gcc-arm-13.2.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz -C /opt/
export PATH=/opt/gcc-arm-13.2.rel1-x86_64-arm-none-linux-gnueabihf/bin:$PATH
# 建议写进 ~/.bashrc，或写成 env 脚本 source 使用

# 验证
arm-linux-gnueabihf-gcc -v

编译 U-Boot / Kernel 时通过变量告诉构建系统用哪个工具链：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- xxx_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8

CROSS_COMPILE 是前缀，构建系统会拼出 arm-linux-gnueabihf-gcc、arm-linux-gnueabihf-ld 等。注意末尾的 - 不能丢。

--sysroot：工具链自带的"目标系统根目录"，里面有 target 版的头文件（/usr/include）和库（/lib、/usr/lib）。交叉编译时 gcc 自动到 sysroot 找 stdio.h、libc.so，而不会用 PC 的 x86 版本：

arm-linux-gnueabihf-gcc -print-sysroot        # 查看 sysroot 路径
arm-linux-gnueabihf-gcc --sysroot=/path/to/sysroot hello.c -o hello

3.2.4 交叉 Binutils 五件套：ldd / readelf / objdump / nm / strip

工具链里除了 gcc，还有一组分析工具，面试经常让现场用：

# ① file：看文件是给什么架构编的（最先用的一个）
file hello
# hello: ELF 32-bit LSB executable, ARM, EABI5, dynamically linked ...

# ② ldd 的交叉版：看程序依赖哪些动态库（PC 的 ldd 对 ARM 程序无效）
arm-linux-gnueabihf-readelf -d hello | grep NEEDED
# 0x00000001 (NEEDED)  Shared library: [libpthread.so.0]
# 0x00000001 (NEEDED)  Shared library: [libc.so.6]

# ③ readelf：看 ELF 头、段、符号、动态段
arm-linux-gnueabihf-readelf -h hello      # ELF 头（Machine: ARM）
arm-linux-gnueabihf-readelf -S hello      # section 表
arm-linux-gnueabihf-readelf -l hello | grep interpreter
#   [Requesting program interpreter: /lib/ld-linux-armhf.so.3]
#   ↑ 动态链接器路径，rootfs 里必须有它，否则 "No such file or directory"

# ④ objdump：反汇编，定位崩溃地址
arm-linux-gnueabihf-objdump -d hello > hello.asm     # 反汇编
arm-linux-gnueabihf-objdump -S hello | less          # 源码+汇编混合（需 -g 编译）

# ⑤ nm：看符号表（函数/变量地址、是否定义）
arm-linux-gnueabihf-nm hello | grep main
# T 表示在代码段有定义；U 表示未定义（需要链接库提供）

# ⑥ strip：裁剪符号表，给 rootfs 瘦身
arm-linux-gnueabihf-strip hello          # 体积可缩小 30%~70%

经典面试现象题：程序在板子上运行报 -sh: ./hello: not found，但文件明明存在、有执行权限——原因不是文件不存在，而是解释器/动态库不存在。用 readelf -l 看 interpreter，用 readelf -d 看 NEEDED，把缺的库补齐即可。

3.2.5 动态库依赖怎么部署到板子

这是每个移植工程师都干过无数次的活，标准流程：

# 1. PC 上查依赖
arm-linux-gnueabihf-readelf -d ./myapp | grep NEEDED
# NEEDED: libsqlite3.so.0 / libpthread.so.0 / libc.so.6

# 2. 去工具链 sysroot 里找对应的库（连同软链接一起拷）
TOOLCHAIN_SYSROOT=$(arm-linux-gnueabihf-gcc -print-sysroot)
cp -a $TOOLCHAIN_SYSROOT/lib/libc.so.6        ~/rootfs/lib/
cp -a $TOOLCHAIN_SYSROOT/lib/ld-linux-armhf.so.3 ~/rootfs/lib/
cp -a $TOOLCHAIN_SYSROOT/usr/lib/libsqlite3.so* ~/rootfs/usr/lib/

# 3. 拷完后 strip 一遍瘦身
arm-linux-gnueabihf-strip ~/rootfs/lib/*.so*

# 4. 板上确认动态链接器找得到
export LD_LIBRARY_PATH=/lib:/usr/lib:/app/lib    # 写进 /etc/profile

要点：

  • 用 cp -a 保留软链接：libc.so.6 往往是指向 libc-2.3x.so 的软链接，只拷实体不拷链接会失败。
  • ld-linux-armhf.so.3 是动态链接器本尊，所有动态链接程序的"入口保姆"，少它一切免谈。
  • 第三方库（自己交叉编译的）统一放 /usr/lib 或自定义目录 + LD_LIBRARY_PATH。

【记忆口诀】查依赖 readelf -d，找库去 sysroot，拷链接用 -a，路径不够 LD_LIBRARY_PATH 补。

3.3 U-Boot

3.3.1 U-Boot 是什么、干什么

U-Boot（Das U-Boot，Universal Bootloader）是嵌入式 Linux 的事实标准 Bootloader，开源、支持几乎所有架构。它的核心职责：

  1. 初始化硬件：DDR、时钟、串口、MMC/SD、网口、LCD 等（内核接管的硬件它不管）。
  2. 加载内核：把 zImage + dtb 从存储/网络读进 DDR 指定地址。
  3. 传递参数：通过 dtb 的 chosen 节点把 bootargs 交给内核。
  4. 跳转内核：关闭中断、关 MMU/cache（按架构要求），跳到内核入口，此后 U-Boot 使命结束，内存被内核接管。
  5. 开发期附加功能：命令行（敲命令调试）、环境变量存储、网络下载（TFTP/NFS）、烧写 Flash——开发期的瑞士军刀。

类比：U-Boot 之于嵌入式板卡 ≈ BIOS/UEFI + GRUB 之于 PC。

3.3.2 两阶段启动：SPL 与 U-Boot proper

为什么一个小小的 bootloader 还要分两阶段？因为 BootROM 只能把程序加载到片内 SRAM（i.MX6ULL 的 OCRAM 只有 128KB），完整 U-Boot 几百 KB 根本放不下。于是：

  • SPL（Secondary Program Loader）：U-Boot 源码编译出的迷你版（u-boot-spl.bin），几十 KB，先被 BootROM 加载到 SRAM。它的唯一使命是初始化 DDR，然后把完整 U-Boot 从 eMMC/SD 读进 DDR 再跳转。
  • U-Boot proper：功能完整的第二阶段，跑在 DDR 里，提供命令行。

【记忆口诀】SRAM 小放不下，SPL 先起 DDR；DDR 好了大 U-Boot，内核 dtb 往里拉。

3.3.3 编译流程

# 1. 获取源码
wget https://ftp.denx.de/pub/u-boot/u-boot-2025.04.tar.bz2
tar -xf u-boot-2025.04.tar.bz2 && cd u-boot-2025.04

# 2. 选一个最接近自己板子的 defconfig（在 configs/ 目录下）
ls configs/ | grep mx6ull
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mx6ull_14x14_evk_defconfig

# 3. （可选）图形化微调配置
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

# 4. 编译
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8

# 产物：
#   u-boot.bin          完整 U-Boot
#   SPL / u-boot-spl.bin  第一阶段
#   u-boot.imx          带 IVT 头、可直接烧给 i.MX6ULL BootROM 的镜像

烧到 SD 卡（i.MX6ULL 要求 bootloader 写在 1KB 偏移处）：

sudo dd if=u-boot.imx of=/dev/sdX bs=1k seek=1 conv=fsync

3.3.4 U-Boot 常用命令大全

进入 U-Boot 命令行（启动时串口狂按回车打断倒计时），help 看全部命令。高频命令按用途分组：

① 环境变量（最重要，面试必考）

=> printenv                     # 打印所有环境变量
=> printenv bootcmd             # 只看某一个
=> setenv ipaddr 192.168.1.50   # 设置变量（仅内存生效，重启丢失）
=> setenv bootdelay 3
=> saveenv                      # 保存到存储介质（eMMC/SD 的环境分区）
=> editenv bootargs             # 编辑器方式修改长变量
=> env default -a               # 恢复默认环境变量

② 存储操作（MMC/eMMC/SD 与文件系统）

=> mmc list                     # 列出 MMC 设备（0: SD, 1: eMMC 之类）
=> mmc dev 1                    # 切换到 eMMC
=> mmc info                     # 看容量、速度模式
=> mmc read 0x80800000 0x800 0x2000   # 按扇区裸读：从第 0x800 块读 0x2000 块到 DDR
=> mmc write 0x80800000 0x800 0x2000  # 裸写（烧录用）

=> fatls mmc 0:1                # 列出 SD 卡第 1 分区（FAT）的文件
=> fatload mmc 0:1 0x80800000 zImage          # 从 FAT 分区读文件到 DDR
=> ext4load mmc 1:2 0x83000000 /boot/imx6ull.dtb  # 从 ext4 分区读文件

③ 网络（开发期命根子）

=> setenv ipaddr 192.168.1.50        # 板子 IP
=> setenv serverip 192.168.1.10      # PC（TFTP/NFS 服务器）IP
=> setenv ethaddr 00:04:9f:04:d2:35  # MAC 地址（出厂唯一，别乱改）
=> ping 192.168.1.10                 # 测连通（注意：U-Boot 里只能板子 ping PC）
=> mii info / mii dump               # 查看 PHY 芯片寄存器，排查网口不通

=> tftp 0x80800000 zImage            # TFTP 下载内核到 DDR
=> tftp 0x83000000 imx6ull-myboard.dtb
=> nfs 0x80800000 192.168.1.10:/nfsroot/zImage   # NFS 方式下载

④ 内存操作（底层调试）

=> md 0x80800000                  # 按字显示内存（memory display）
=> mw 0x80800000 0x12345678 10    # 写内存
=> cp 0x80800000 0x83000000 1000  # 内存拷贝
=> cmp 0x80800000 0x83000000 100  # 比较（验证烧录是否正确）

⑤ 启动内核（三个 boot 命令要分清）

=> bootz 0x80800000 - 0x83000000   # 启动 zImage：内核地址 - dtb 地址
                                   # 中间的 "-" 是 initrd 占位，不用就写 -
=> bootm 0x80800000 - 0x83000000   # 启动 uImage（带 U-Boot 头的老格式）
=> booti ...                       # 启动 64 位 ARM 的 Image
=> boot                            # 执行 bootcmd 变量里保存的一串命令（默认行为）

【记忆口诀】print 看、set 改、save 存；fat/ext4 读卡，tftp/nfs 走网；bootz 三参数：内核、initrd、设备树。

3.3.5 bootcmd 与 bootargs 详解（面试核心）

bootcmd：U-Boot 倒计时结束后自动执行的一串命令。一个典型的 eMMC 独立启动 bootcmd：

setenv bootcmd 'mmc dev 1; fatload mmc 1:1 0x80800000 zImage; \
                fatload mmc 1:1 0x83000000 imx6ull-myboard.dtb; \
                bootz 0x80800000 - 0x83000000'
saveenv

含义：切到 eMMC → 从 eMMC 第 1 分区读内核到 DDR 0x80800000 → 读 dtb 到 0x83000000 → 启动。

开发期 TFTP+NFS 版本：

setenv bootcmd 'tftp 0x80800000 zImage; tftp 0x83000000 imx6ull-myboard.dtb; \
                bootz 0x80800000 - 0x83000000'

bootargs：传给 Linux 内核的启动参数字符串，内核启动时逐字段解析。逐字段拆解一个真实例子：

setenv bootargs 'console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw \
                 init=/sbin/init mem=512M'
字段 含义
console=ttymxc0,115200 内核打印输出到哪个串口、波特率多少。i.MX6ULL 的串口 1 在设备树里叫 ttymxc0（ttyS0 是 x86/通用 8250 的叫法）。写错 = 内核启动后串口哑火，经典大坑
root=/dev/mmcblk1p2 根文件系统在哪儿：eMMC（mmcblk1）的第 2 分区（p2）。SD 卡一般是 mmcblk0p2
rootwait 等存储设备就绪再挂载（eMMC 初始化慢，不加可能 panic）
rw 以可读写方式挂载 rootfs（默认只读再 remount）
init=/sbin/init 指定 1 号进程路径，默认就是 /sbin/init，BusyBox 系统也常写 init=/linuxrc
mem=512M 告诉内核物理内存大小（一般从 dtb 的 memory 节点读，显式指定可覆盖）

NFS 根文件系统版本的 bootargs（3.7 详解）：

setenv bootargs 'console=ttymxc0,115200 root=/dev/nfs rw \
  nfsroot=192.168.1.10:/home/book/nfs/rootfs,v3,tcp \
  ip=192.168.1.50:192.168.1.10:192.168.1.1:255.255.255.0::eth0:off'

3.3.6 环境变量存在哪里

saveenv 保存的环境变量不是存在文件里，而是写在存储介质的固定偏移的裸扇区里（由 defconfig 的 CONFIG_ENV_OFFSET、CONFIG_ENV_SIZE 决定，常见 eMMC 上 0xC0000 附近、或 SD 卡 1MB 偏移处）。所以：

  • 重新 dd 烧写整卡可能覆盖环境变量区，导致配置丢失。
  • U-Boot 启动时先读该区域，CRC 校验失败则用代码里的默认环境（env default）。

【记忆口诀】环境变量不落文件，裸扇区里带 CRC；烧卡小心别覆盖，丢了就用默认配。

3.3.7 U-Boot 移植到新板子要改什么

面试问"你移植 U-Boot 做了什么"，按这个清单回答，我在 i.MX6ULL 自定义板上的实际工作量：

  1. 复制参考板配置：以 mx6ull_14x14_evk 为蓝本，复制 board/freescale/mx6ullevk/ → 自己的板级目录，复制 configs/mx6ull_14x14_evk_defconfig → 自己的 defconfig，复制设备树 arch/arm/dts/imx6ull-14x14-evk.dts → 自己的 dts。
  2. DDR 参数（最关键，错了起不来）：原理图确认 DDR3 型号/容量/位宽，改 DCD 表里的 DDR 寄存器值，用 NXP DDR Stress Test 工具校准后回填。
  3. 时钟：确认外部晶振（i.MX6ULL 常用 24MHz），一般参考板一致不用动。
  4. MMC/SD：确认 SD/eMMC 挂在哪个 USDHC 控制器（usdhc1/usdhc2）、CD（卡检测）引脚、位宽（eMMC 8bit），改板级文件和 dts。
  5. 网口：PHY 芯片型号（如 LAN8720 vs KSZ8081）、RMII 引脚、复位 GPIO、PHY 地址——不同 PHY 要改驱动配置和 dts，不通时用 mii 命令排查。
  6. LCD：时序参数（分辨率、pixclock、sync 宽度）写进板级文件/环境变量 panel。
  7. 串口控制台：确认调试串口是 UART1，dts 里 stdout-path 指对。
  8. defconfig 裁剪：关掉用不到的功能（如 USB 键盘、视频logo）加快启动。

【记忆口诀】DDR 定生死，时钟串口先通；MMC 网口 LCD 跟上，defconfig 裁剪收尾。

3.4 Linux Kernel 编译与配置

3.4.1 获取源码与编译全流程

# 1. 下载（kernel.org 主线或厂商 BSP 内核）
wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.12.34.tar.xz
tar -xf linux-6.12.34.tar.xz && cd linux-6.12.34

# 2. 选 defconfig（arch/arm/configs/ 下，i.MX 系列用 imx_v6_v7_defconfig）
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- imx_v6_v7_defconfig

# 3. 图形化配置裁剪
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

# 4. 编译：zImage + 模块 + dtb 一把全编
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j8 zImage modules dtbs

# 产物：
#   arch/arm/boot/zImage                          内核镜像
#   arch/arm/boot/dts/nxp/imx/imx6ull-*.dtb       设备树二进制
#   各目录下的 *.ko                                内核模块

# 5. 安装模块到 rootfs（自动生成 /lib/modules/6.12.34/ 目录树）
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- \
     INSTALL_MOD_PATH=/home/book/nfs/rootfs modules_install

3.4.2 Kconfig / Makefile / .config 三剑客体系

内核有上万配置项，靠三件套组织：

  • Kconfig：每个目录一个，定义配置项的名字、类型（bool/tristate/string）、依赖（depends on）、默认值、帮助文本。menuconfig 界面就是它渲染出来的。tristate 三态：y=编进内核、m=编成模块、n=不要。
  • .config：配置的结果文件，存所有 CONFIG_XXX=y/m。defconfig 就是一份精简的 .config 模板。
  • Makefile：每个目录一个，写 obj-$(CONFIG_XXX) += xxx.o。CONFIG_XXX=y 时编进内核，=m 时编成 xxx.ko。

自己加驱动时标准三步：目录里写 xxx.c → Makefile 加 obj-$(CONFIG_XXX) += xxx.o → Kconfig 加 config XXX 条目——menuconfig 里就能选中了。

3.4.3 Image / zImage / uImage 区别（高频考点）

镜像 说明
Image 最原始的内核二进制，未压缩，体积大
zImage Image gzip 压缩 + 头部自带解压代码（piggy），自解压后运行。ARM 32 位最常用，U-Boot 用 bootz 启动
uImage zImage 外面再套一个 64 字节的 U-Boot 头部（记录加载地址、入口、CRC），给老 U-Boot 的 bootm 用。现代 U-Boot 直接 bootz 即可，不需要
bzImage x86 的"大 zImage"，跟 ARM 无关，别混淆

【记忆口诀】Image 是裸体，zImage 自解压，uImage 多顶 U-Boot 帽。bootz 配 zImage，bootm 配 uImage。

3.4.4 模块（.ko）的编译与使用

# 编成模块：menuconfig 里选 M，或驱动 Makefile obj-m
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules

# 板子上使用：
insmod hello.ko          # 手动加载（不解决依赖）
rmmod hello              # 卸载
lsmod                    # 列出已加载模块
modinfo hello.ko         # 看模块信息（vermagic 版本指纹！）
modprobe hello           # 智能加载：自动到 /lib/modules/$(uname -r)/ 找并解决依赖
depmod -a                # 重新生成模块依赖表 modules.dep

vermagic / modversions 大坑（我的真实踩坑）：内核模块与内核是强绑定的。modinfo 8189fs.ko 里有一行 vermagic: 6.12.34 ... modversions。如果内核配置开了 CONFIG_MODVERSIONS，每个导出符号都带一个 CRC 校验值，内核源码/配置哪怕只改了一个结构体字段重新编译，所有符号 CRC 就变了，旧 .ko 加载时报 disagrees about version of symbol xxx 拒绝加载。

所以结论（面试可直接讲）：8189fs.ko 这类第三方 WiFi 驱动，必须用它将要运行的那个内核的源码树、同一份 .config 重新编译，不能直接拿别的版本内核编出来的 .ko 用。批量验证：modinfo xxx.ko | grep vermagic 对比 uname -r。

3.4.5 内核裁剪思路

产品级内核要砍到又快又小，裁剪顺序：

  1. 架构级：defconfig 只保留自家 SoC 平台（menuconfig → System Type，关掉其他厂商 SoC）。
  2. 驱动级（大头）：Device Drivers 里把板子上没有的硬件驱动全关（用不到的网卡、声卡、USB 小工具、无线网卡……）。
  3. 文件系统：只留用的（ext4、FAT、NFS、proc/sysfs 必留）。
  4. 调试选项：量产版关 CONFIG_DEBUG_INFO、KALLSYMS 按需，体积立减几 MB。
  5. 验证方法：裁剪后跑一遍完整功能测试；boot 时间用 CONFIG_PRINTK_TIME 或 bootgraph 分析。

3.4.6 dts → dtb 与启动参数传递

  • 设备树源文件 .dts（板级）包含 .dtsi（SoC 级），由 dtc（Device Tree Compiler） 编译成 .dtb。
  • 内核 make 体系自动调用 dtc：make dtbs；也可手动：dtc -I dts -O dtb -o out.dtb in.dts。
  • 参数传递链：U-Boot 把 dtb 加载到 DDR（如 0x83000000）→ bootz kernel_addr - dtb_addr 把 dtb 地址通过寄存器 r2 传给内核 → 同时 U-Boot 把 bootargs 写进 dtb 的 chosen { bootargs = "..."; } 节点 → 内核解析 chosen 拿到命令行。

【记忆口诀】U-Boot 是快递员：dtb 装上车（r2），bootargs 塞 chosen，内核签收才开始。

3.5 Device Tree 设备树详解

3.5.1 为什么引入设备树

ARM 早期每个板子都在内核源码 arch/arm/mach-xxx/ 里写一堆 C 代码描述硬件（哪根引脚接了什么、外设地址多少），几千块板子把内核搞成垃圾场。Linus 名句："this whole ARM thing is a f*cking pain in the ass"。

解决方案：把"硬件描述"从内核代码里抽出来，变成一份独立的、树状的文本数据（DTS），编译成 DTB，启动时由 Bootloader 交给内核。内核同一套二进制 + 不同 dtb = 支持不同板子。

一句话面试答案：设备树解决的是"板级硬件信息与内核代码耦合"的问题，让内核镜像与具体板子解耦。

【记忆口诀】代码管驱动，设备树管描述；换板不换内核，只换 dtb。

3.5.2 DTS / DTB / DTC 与 dtsi 包含关系

  • DTS（Device Tree Source）：板级源文件，文本，人写人读。
  • DTSI（Device Tree Source Include）：被包含的公共部分。imx6ull.dtsi 描述 SoC 内部（CPU、各控制器寄存器地址）；imx6ull-14x14-evk.dts 描述板级（这板子用了哪些控制器、引脚怎么接）。芯片厂写 dtsi，板厂写 dts。
  • DTB：dts 编译后的二进制，内核只认它。
  • DTC：编译器，双向转换：
dtc -I dts -O dtb -o board.dtb board.dts    # 编译
dtc -I dtb -O dts -o reverse.dts board.dtb  # 反编译（拿到别人板子的 dtb 时可逆向参考）

包含关系：

imx6ull-myboard.dts          ← 你的板子（最后写，越具体越后）
  └─ #include "imx6ull-14x14-evk.dtsi"   ← 参考板公共部分（可选）
       └─ #include "imx6ull.dtsi"        ← SoC 级：NXP 提供

同名节点/属性，后包含的覆盖先包含的——板级 dts 靠 &i2c1 { status = "okay"; }; 这种引用式写法，改 SoC dtsi 里节点的属性。

3.5.3 语法与核心属性逐条讲

设备树就是一棵树：/ 根节点 → 子节点（cpus、soc、memory……）→ 属性是键值对。

/dts-v1/;                        /* 版本声明，必须有 */
#include "imx6ull.dtsi"

/ {                              /* 根节点 */
    model = "My i.MX6ULL Board"; /* 板子名字，dmesg 里可见 */
    compatible = "my,imx6ull-board", "fsl,imx6ull";  /* 匹配字符串，先具体后通用 */

    chosen {                     /* 启动参数节点：U-Boot 会往里写 bootargs */
        stdout-path = &uart1;    /* 早期打印走哪个串口 */
    };

    memory@80000000 {            /* DDR：起始地址 0x80000000，大小 512MB */
        reg = <0x80000000 0x20000000>;
    };

    led_gpio: led {              /* 自定义节点：一个 GPIO LED */
        compatible = "gpio-leds";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_led>;      /* 引用 pinctrl 节点配置引脚复用 */
        led0 {
            gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;  /* GPIO1_IO03，低电平点亮 */
            default-state = "on";
        };
    };
};

核心属性面试必背：

属性 作用
compatible 驱动匹配的钥匙。内核驱动里有 of_match_table，字符串匹配上才执行 probe。格式 "厂商,型号"
reg 设备的地址资源（寄存器基址+长度）。含义由父节点的 #address-cells/#size-cells 决定
#address-cells / #size-cells 子节点 reg 里用几个 u32 表示地址/长度。常见 <1 1>：reg = <0x0209c000 0x4000> 即基址 0x0209c000、长度 0x4000
status "okay" 启用 / "disabled" 禁用。SoC dtsi 默认全 disabled，板级 dts 按需 okay——设备树裁剪的本质就是改 status
interrupts 中断描述：<中断号 触发类型>，触发类型如 IRQ_TYPE_LEVEL_LOW。配合 interrupt-parent = <&gpc> 指到中断控制器
clocks 引用的时钟源：<&clks IMX6ULL_CLK_GPIO1>，驱动里 clk_get 拿到
gpios GPIO 描述符：<&gpio控制器 编号 有效电平>，驱动里 gpiod_get 拿到
pinctrl-0 + pinctrl-names 引脚复用配置，引用 iomuxc 里的引脚组节点
aliases 给节点起序号别名：serial0 = &uart1; → 内核里 uart1 注册为 ttymxc0。console=ttymxc0 的 0 就是从这来的
chosen 启动相关：bootargs、stdout-path、initrd 地址
memory 物理内存范围；保留内存用 reserved-memory 子节点 + no-map（给摄像头 CMA/TEE 预留，内核不碰）

3.5.4 pinctrl 引脚复用节点写法（i.MX6ULL 实例）

i.MX6ULL 每根引脚可复用成多种功能（ALT0~ALT8），由 IOMUXC 控制器配置。比如把 UART1 的 TX/RX 引脚配好：

&iomuxc {
    pinctrl-names = "default";

    pinctrl_uart1: uart1grp {
        fsl,pins = <
            MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX  0x1b0b1
            MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX  0x1b0b1
        >;
    };
};

&uart1 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_uart1>;   /* 引用上面的引脚组 */
    status = "okay";
};

解读：

  • MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 是一个宏（在 imx6ull-pinfunc.h 里），展开是 <mux_reg conf_reg input_reg mux_mode input_val> 五个寄存器值，表示"把这个 PAD 复用为 UART1_TX 功能"。
  • 0x1b0b1 是电气属性配置字：压摆率、驱动强度、上下拉、迟滞，按硬件设计填（串口常用 0x1b0b1，高速信号如 SD 卡用不同值）。

【记忆口诀】pinctrl 三步走：iomuxc 里定义组，设备节点来引用，status okay 才生效。

3.5.5 完整小实例逐行讲解（i.MX6ULL 板上 I2C 接传感器）

&i2c1 {                                        /* ① 引用 SoC dtsi 里的 i2c1 控制器节点 */
    clock-frequency = <100000>;                /* ② I2C 速率 100kHz，覆盖默认值 */
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_i2c1>;               /* ③ 引脚复用到 I2C1 的 SCL/SDA */
    status = "okay";                           /* ④ 启用该控制器（SoC 默认 disabled） */

    sht30: sht30@44 {                          /* ⑤ 子节点：挂在 i2c1 上的温湿度传感器 */
        compatible = "sensirion,sht30";        /* ⑥ 匹配内核里 sht3x.c 驱动 */
        reg = <0x44>;                          /* ⑦ I2C 从机地址 0x44（7位地址） */
    };
};

① 为什么能直接写 &i2c1？因为 imx6ull.dtsi 里定义了 i2c1: i2c@021a0000 { ... }，&标签 就是取该节点引用，在板级 dts 里"追加/覆盖"属性。
⑤ 节点名 sht30@44 的 @44 与 reg 对应，纯命名规范。
⑥ 内核启动时 i2c1 控制器驱动 probe 成功 → 扫描子节点 → 发现 compatible sensirion,sht30 → 匹配到 sht3x 驱动 → 自动注册传感器设备。整个过程中硬件信息零行 C 代码，这就是设备树的威力。

3.5.6 运行中查看设备树

# 板上直接看内核解析后的设备树（/proc/device-tree 是 dtb 的运行时映射）
ls /proc/device-tree/
cat /proc/device-tree/model                 # "My i.MX6ULL Board"
cat /proc/device-tree/chosen/bootargs; echo # 看内核实际拿到的启动参数
ls /proc/device-tree/soc/bus@2100000/i2c@21a0000/

# 属性是二进制，字符串类可 cat，数值类用 hexdump
hexdump -C /proc/device-tree/memory@80000000/reg

【记忆口诀】/proc/device-tree 照妖镜：dtb 进没进内核、参数对不对，一 cat 就知道。

3.6 根文件系统（RootFS）

3.6.1 rootfs 里有什么

内核启动的最后一步是挂载根文件系统并运行 1 号进程。一个最小 rootfs 的目录结构（面试要求能默画）：

rootfs/
├── bin/          # 基本命令：ls cp sh …（BusyBox 的软链接）
├── sbin/         # 系统管理命令：init ifconfig insmod reboot …
├── etc/          # 配置文件：inittab、fstab、profile、init.d/ 启动脚本
├── dev/          # 设备节点（devtmpfs 自动填充，或手工 mknod）
├── proc/         # procfs 挂载点：进程与内核信息（空目录，挂载后才有内容）
├── sys/          # sysfs 挂载点：设备模型信息
├── lib/          # 动态库：libc.so.6、ld-linux-armhf.so.3、/lib/modules 内核模块
├── usr/          # 用户程序与库：usr/bin usr/sbin usr/lib
├── tmp/ var/ run/ mnt/ media/   # 运行时目录（常挂 tmpfs）
├── linuxrc       # BusyBox init 的入口（或软链接到 bin/busybox）
└── root/ home/   # 用户目录

三大虚拟文件系统（不占 Flash，内核内存中生成，rcS 里挂载）：

  • procfs（/proc）：进程信息、cpuinfo、meminfo。
  • sysfs（/sys）：设备树、驱动、总线的对象视图，udev/mdev 的数据源。
  • devtmpfs/tmpfs（/dev）：设备节点自动生成。

3.6.2 BusyBox 是什么

BusyBox 把 300 多个 Unix 常用命令（ls、cp、sh、init、ifconfig……）全部集成进一个几百 KB ~ 2MB 的可执行文件。/bin/ls 其实只是指向 /bin/busybox 的软链接，BusyBox 靠 argv[0] 判断自己被当成谁调用。嵌入式 rootfs 的标配，被称为"嵌入式 Linux 的瑞士军刀"。

3.6.3 BusyBox 编译配置

wget https://busybox.net/downloads/busybox-1.36.1.tar.bz2
tar -xf busybox-1.36.1.tar.bz2 && cd busybox-1.36.1

make defconfig                          # 默认配置
make menuconfig                         # 图形化调整，关键项：
# Settings --->
#   [*] Build static binary (no shared libs)   # 静态编译（可选，做了就完全不依赖外部 libc）
#   (arm-linux-gnueabihf-) Cross Compiler prefix  # 填交叉工具链前缀！
# 按需勾选命令：Login/Passwords、init、httpd、udhcpc（自动获取IP）…

make -j8
make CONFIG_PREFIX=/home/book/nfs/rootfs install   # 安装到 rootfs 目录，自动建好软链接

装完后 rootfs 里 bin/ sbin/ linuxrc 都有了，但 etc/ dev/ lib/ proc/ sys/ 要手工创建——这是接下来最小 rootfs 步骤的重点。

3.6.4 init 启动链：init=/linuxrc → inittab → rcS → S99

内核启动 1 号进程的顺序（BusyBox init）：

内核 → 执行 bootargs 里 init= 指定的程序（默认依次尝试 /sbin/init、/etc/init、/bin/init、/bin/sh）
     → BusyBox init 读 /etc/inittab
     → inittab 指定执行 /etc/init.d/rcS
     → rcS 挂载文件系统、跑 /etc/init.d/S?? 开头的脚本（按数字升序）
     → 最后 inittab 在串口上拉起 getty/askfirst shell

/etc/inittab（格式：id:runlevels:action:process，BusyBox 忽略 runlevels）：

::sysinit:/etc/init.d/rcS            # 系统初始化第一个执行
console::askfirst:-/bin/sh           # 控制台启动 shell，按回车进入
::restart:/sbin/init                 # init 重启时执行
::shutdown:/bin/umount -a -r         # 关机时卸载文件系统

/etc/init.d/rcS（系统初始化总脚本）：

#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin

# ① 挂载虚拟文件系统（也可写进 fstab 用 mount -a）
mount -t proc     proc     /proc
mount -t sysfs    sysfs    /sys
mount -t devtmpfs devtmpfs /dev       # 内核自动填充设备节点
mount -t tmpfs    tmpfs    /tmp

# ② 主机名、网络
hostname -F /etc/hostname
ifconfig lo 127.0.0.1

# ③ 内核模块依赖表 & 按需加载
depmod -a

# ④ 依次执行 S 开头的自启动脚本
for i in /etc/init.d/S??* ; do
    [ -x "$i" ] && $i start
done

/etc/init.d/S99myapp（自启动脚本，命名规则：S + 两位数字 + 名字，数字小的先跑；K 开头的是关机脚本。S99 表示最后启动——等网络、驱动都好了再跑应用）：

#!/bin/sh
case "$1" in
  start)
    echo "Starting myapp..."
    export LD_LIBRARY_PATH=/app/lib
    /app/myapp &                      # 后台运行
    ;;
  stop)
    killall myapp
    ;;
esac

chmod +x /etc/init.d/S99myapp        # 必须加可执行权限，经典遗漏点

/etc/fstab（开机自动挂载表，mount -a 读取）：

#device       mount-point  type      options           dump  fsck
proc          /proc        proc      defaults          0     0
sysfs         /sys         sysfs     defaults          0     0
devtmpfs      /dev         devtmpfs  defaults          0     0
tmpfs         /tmp         tmpfs     defaults          0     0
/dev/mmcblk1p3 /data      ext4      defaults          0     2

/etc/profile（shell 登录时执行，设环境变量）：

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/app
export LD_LIBRARY_PATH=/lib:/usr/lib:/app/lib
export PS1='[\u@\h:\w]# '

【记忆口诀】init 先读 inittab，rcS 挂载跑 S 脚本；S 后数字定先后，99 压轴起应用。

3.6.5 最小 rootfs 制作完整步骤（可背版）

ROOTFS=~/nfs/rootfs
mkdir -p $ROOTFS && cd $ROOTFS

# ① BusyBox 安装（建好 bin/sbin/linuxrc，见 3.6.3）
make CONFIG_PREFIX=$ROOTFS install      # 在 busybox 源码目录执行

# ② 补目录
mkdir -p etc dev proc sys lib usr/lib tmp var run mnt media root home

# ③ 拷动态库（若 BusyBox 非静态，或你的 app 是动态链接的）
SYSROOT=$(arm-linux-gnueabihf-gcc -print-sysroot)
cp -a $SYSROOT/lib/ld-linux-armhf.so.3 lib/
cp -a $SYSROOT/lib/libc.so.6 lib/
cp -a $SYSROOT/lib/libm.so.6 lib/       # 按需
arm-linux-gnueabihf-strip lib/*.so*

# ④ 写 etc 配置：inittab、init.d/rcS、init.d/S99myapp、fstab、profile、hostname、passwd
#    （内容见 3.6.4）

# ⑤ 设备节点（用 devtmpfs 的话这步可省；纯手工则需要）
sudo mknod dev/console c 5 1
sudo mknod dev/null    c 1 3

# ⑥ 装内核模块
make -C ~/linux-6.12.34 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- \
     INSTALL_MOD_PATH=$ROOTFS modules_install

# ⑦ 放到 NFS 目录或打包成镜像（见 3.7 / 3.8）

验收标准：bootargs 指过来后，串口出现 Please press Enter to activate this console.，回车出 #——最小系统移植成功。

3.7 开发调试方式：TFTP + NFS（开发期效率神器）

开发期每次改内核/rootfs 都拔卡烧写太低效，标准方案：内核和 dtb 走 TFTP 下载，根文件系统整个走 NFS 网络挂载，板子的"硬盘"就是 PC 上的一个目录，改完立刻生效。

3.7.1 PC 端搭建（Ubuntu）

# TFTP 服务器
sudo apt install tftpd-hpa
# /etc/default/tftpd-hpa 里 TFTP_DIRECTORY="/home/book/tftpboot"
mkdir -p ~/tftpboot && chmod 777 ~/tftpboot
cp zImage imx6ull-myboard.dtb ~/tftpboot/
sudo systemctl restart tftpd-hpa

# NFS 服务器
sudo apt install nfs-kernel-server
mkdir -p ~/nfs/rootfs            # rootfs 内容就放这里
# /etc/exports 加一行：
# /home/book/nfs/rootfs *(rw,sync,no_root_squash,no_subtree_check)
sudo exportfs -rav
sudo systemctl restart nfs-kernel-server

no_root_squash 很关键：允许板子以 root 身份操作 NFS 目录，否则建设备节点、改权限全失败。

3.7.2 U-Boot 端配置（三连）

setenv ipaddr 192.168.1.50
setenv serverip 192.168.1.10
setenv gatewayip 192.168.1.1

# bootcmd：TFTP 拉内核 + dtb
setenv bootcmd 'tftp 0x80800000 zImage; \
                tftp 0x83000000 imx6ull-myboard.dtb; \
                bootz 0x80800000 - 0x83000000'

# bootargs：NFS 根文件系统
setenv bootargs 'console=ttymxc0,115200 root=/dev/nfs rw \
  nfsroot=192.168.1.10:/home/book/nfs/rootfs,v3,tcp \
  ip=192.168.1.50:192.168.1.10:192.168.1.1:255.255.255.0::eth0:off'
saveenv

nfsroot 字段拆解：nfsroot=服务器IP:rootfs路径,v3,tcp

  • v3 指定 NFSv3 协议（某些服务器 v4 协商有问题，写死 v3 最稳）；
  • tcp 强制 TCP 传输（默认 UDP 在某些网络下丢包卡死）。

ip 字段拆解：ip=板子IP:服务器IP:网关:子网掩码:主机名:网卡:autoconf

  • 末尾 off 表示不做 DHCP/BOOTP 自动配置，全用前面手填的值。

前提：内核要编上 CONFIG_NFS_FS、CONFIG_ROOT_NFS、CONFIG_IP_PNP（menuconfig 里 NFS client + root over NFS）。

3.7.3 串口终端与板上网络配置

# PC 端串口工具（三选一）
sudo minicom -D /dev/ttyUSB0 -b 115200
picocom -b 115200 /dev/ttyUSB0
sudo screen /dev/ttyUSB0 115200

# 板上手动配网（没用 NFS root 时）
ifconfig eth0 192.168.1.50 netmask 255.255.255.0 up
route add default gw 192.168.1.1
echo "nameserver 8.8.8.8" > /etc/resolv.conf
ping 192.168.1.10

# 或者用 ip 命令（BusyBox 也带）
ip addr add 192.168.1.50/24 dev eth0
ip link set eth0 up
ip route add default via 192.168.1.1

# DHCP 自动获取（BusyBox 自带 udhcpc）
udhcpc -i eth0

【记忆口诀】内核 dtb 走 TFTP，rootfs 走 NFS；改代码不用拔卡，重启板子就生效。

3.8 eMMC / SD 烧录部署

产品定型后要从"NFS 网络挂载"切到"eMMC 独立启动"——断网、拔线、上电就跑。

3.8.1 分区规划

典型 eMMC 分区方案（i.MX6ULL，以 8GB eMMC 为例）：

偏移 1KB:      u-boot.imx（裸写，不分区）
偏移 ~1MB:     U-Boot 环境变量区（裸扇区）
分区1 (p1):    FAT32, 64MB  → zImage + imx6ull-myboard.dtb（boot 分区）
分区2 (p2):    ext4, 剩余    → 完整 rootfs

PC 上用 fdisk/parted 给 SD 卡分区示范（eMMC 同理，在板子上或 USB 烧录时操作）：

sudo fdisk /dev/sdX
# n → p → 1 → 起始默认 → +64M      （boot 分区）
# n → p → 2 → 默认到结尾           （rootfs 分区）
# t → 1 → c                        （p1 类型改 W95 FAT32）
# w 保存
sudo mkfs.vfat  /dev/sdX1
sudo mkfs.ext4  /dev/sdX2

3.8.2 dd 命令与烧录

# 烧 U-Boot：i.MX6ULL 要求写在 1KB 偏移（跳过 MBR 区域，不破坏分区表）
sudo dd if=u-boot.imx of=/dev/sdX bs=1k seek=1 conv=fsync
#   bs=1k seek=1 → 输出定位到 1KB 处；conv=fsync 写完强制落盘

# 拷内核与 dtb 到 FAT 分区
sudo mount /dev/sdX1 /mnt && sudo cp zImage *.dtb /mnt && sync && sudo umount /mnt

# 灌 rootfs 到 ext4 分区
sudo mount /dev/sdX2 /mnt && sudo cp -a ~/nfs/rootfs/* /mnt && sync && sudo umount /mnt
# 注意是 cp -a 保留权限与软链接；rootfs 属主要是 root，用 sudo

整卡镜像做法（量产友好）：先做好一张母卡，然后 sudo dd if=/dev/sdX of=product.img bs=4M count=<刚好包住数据的量> 打成整卡镜像，产线直接 dd 刷写。

3.8.3 板上自烧录脚本思路（U-Boot 里烧 eMMC）

产线/远程升级常用：U-Boot 里 TFTP 下载镜像 → mmc write 写进 eMMC：

=> mmc dev 1                                # 切到 eMMC
=> tftp 0x80800000 u-boot.imx
=> mmc write 0x80800000 0x2 0x400           # 从块2(1KB)写起，0x400 块≈512KB
=> tftp 0x80800000 zImage
=> fatwrite mmc 1:1 0x80800000 zImage 0x...  # 或 ext4 分区用分区工具预先建好

脚本化思路：把上面命令存进 U-Boot 环境变量 setenv update '...; ...; ...'，或者内核起来后用 shell 脚本调 dd + mount 完成 A/B 分区升级。

3.8.4 从 NFS 切换到 eMMC 独立启动要改什么（面试高频）

只需改 U-Boot 两个变量（硬件、内核、rootfs 内容都不动）：

# ① bootcmd：从网络下载 → 改为从 eMMC 读
setenv bootcmd 'mmc dev 1; \
  fatload mmc 1:1 0x80800000 zImage; \
  fatload mmc 1:1 0x83000000 imx6ull-myboard.dtb; \
  bootz 0x80800000 - 0x83000000'

# ② bootargs：root=/dev/nfs → 改为 root=/dev/mmcblk1p2
setenv bootargs 'console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw'
saveenv

检查清单：

  • mmcblk1 还是 mmcblk0？看 eMMC 在内核里注册的序号（启动日志 mmc1: new high speed MMC card ... mmcblk1），NFS 调试时网卡正常不代表存储序号猜得对，写错直接 VFS panic。
  • rootfs 是否已完整灌进 p2 分区、权限是否保留（cp -a）。
  • rootwait 别忘，eMMC 初始化慢半拍。
  • 环境变量区是否在烧写过程中被覆盖。

【记忆口诀】切独立启动就两步：bootcmd 换读取源，bootargs 换 root；序号看清 mmcblk 几，rootwait 保平安。

3.9 Buildroot

3.9.1 是什么

手动移植（U-Boot + 内核 + BusyBox + 手工配 etc）灵活但繁琐、不可复现。Buildroot 是一个用 Makefile + Kconfig 搭起来的自动化构建系统：一条 make 自动下载源码、交叉编译工具链、U-Boot、内核、BusyBox、几百个可选软件包，最终直接产出可烧录的完整镜像。它把本篇 3.2~3.8 的手工流程全部自动化。

3.9.2 使用流程

wget https://buildroot.org/downloads/buildroot-2024.11.tar.gz
tar -xf buildroot-2024.11.tar.gz && cd buildroot-2024.11

# ① 选板子默认配置（自带很多主流板子）
make list-defconfigs | grep imx
make imx6ullevk_defconfig

# ② 图形化总配置（四套 menu 对应四大件）
make menuconfig
#   Toolchain          ---> 工具链：内部构建 or 外部工具链路径
#   Bootloaders        ---> U-Boot 版本、defconfig、是否 SPL
#   Kernel             ---> 内核版本/git 地址、defconfig、dtb 名字
#   Target packages    ---> 要的软件包：qt、sqlite、openssl、dropbear(SSH)…
#   Filesystem images  ---> rootfs 格式：ext4/squashfs/ubifs + 是否打 sdcard 整卡镜像

# ③ 一键构建（首次要现编工具链，30~60 分钟；之后增量很快）
make -j8

# ④ 单独重编某个包/内核（增量开发）
make linux-menuconfig        # 配内核
make linux-rebuild           # 重编内核
make busybox-menuconfig
make <pkg>-rebuild

3.9.3 产物：output/images

output/
├── host/        # 构建出的交叉工具链（内部工具链模式）
├── target/      # rootfs 的"散装"目录（可 NFS 挂来调试）
└── images/
    ├── u-boot.imx               # bootloader
    ├── zImage                   # 内核
    ├── imx6ull-*.dtb            # 设备树
    ├── rootfs.ext4              # 根文件系统镜像
    └── sdcard.img               # 整卡镜像：dd 直接刷卡即成品

make sdk 还能导出 SDK 给应用同事用（工具链 + sysroot + 库头文件打包）。

3.9.4 Buildroot vs 手动 BusyBox vs Yocto（面试常让对比）

维度 手动 BusyBox 移植 Buildroot Yocto
本质 纯手工，每步自己做 Makefile 自动化，一键出镜像 完整的"发行版构建框架"（层/配方/包管理思想）
学习曲线 陡峭但最能理解原理 平缓，一天上手 陡峭，数周起步
构建产物 散装目录 镜像文件 镜像 + 可安装的 ipk/rpm 软件包仓库
软件包数量 自己交叉编译移植 ~3000 个可选 海量（openembedded 生态）
可维护性/复现性 差（全靠人记） 好（defconfig 即文档） 最好（企业级、产线级）
适用 学习、极简系统 中小团队产品化（我司镜像构建用的就是它） 大厂、复杂产品线

一句话对比：Buildroot 追求的是"快速构建出一个固定的嵌入式系统"，Yocto 追求的是"构建一个可定制、可包管理的嵌入式 Linux 发行版"；手动 BusyBox 是理解前两者的必经之路。

【记忆口诀】手动练内功，Buildroot 出活快，Yocto 做发行版。

3.10 常见坑（每个都是血泪，面试说出来就是加分项）

坑 1：内核模块版本不匹配（modversions CRC 校验）——我的真实踩坑

现象：insmod 8189fs.ko 报错 disagrees about version of symbol xxx / Invalid module format。
原因：内核开了 CONFIG_MODVERSIONS 后，每个导出符号记录 CRC；重新编译内核（哪怕只改了一个配置或一个结构体）CRC 全变，旧 .ko 与新内核符号校验对不上。
排查：modinfo 8189fs.ko | grep -E 'vermagic|depends'，对比板上 uname -r。
解决：必须用目标内核同版本源码 + 同 .config 重编 WiFi 驱动。第三方驱动交付时要索取"可配内核源码编译"的形式而非现成 .ko。

坑 2：内核与 dtb 不匹配

现象：内核起不来、外设全灭、或卡在 earlycon 之后无输出。
原因：更新了内核但忘了更新 dtb（新版内核改了节点绑定/时钟名），或 bootcmd 里 dtb 加载地址写错加载了旧文件。
解决：zImage 和 dtb 永远成对更新；用 /proc/device-tree/model 确认当前加载的是哪份 dtb。

坑 3：根文件系统缺库 / 缺动态链接器

现象：shell 都进不去，或程序报 not found（文件明明在）。
排查：readelf -l app | grep interpreter 看解释器，readelf -d app | grep NEEDED 看依赖，进 rootfs 逐一对照。
根源三连：① 忘拷 ld-linux-armhf.so.3；② 只拷了实体库没拷软链接（要 cp -a）；③ 工具链是 gnueabihf 但拷了软浮点版本的库（ABI 不匹配，见 3.2.2）。

坑 4：bootargs 的 console 写错 → 内核"哑火"

现象：U-Boot 输出正常，bootz 之后串口再无一个字。
原因：console=ttymxc0 写成了 console=ttyS0，或波特率不对，或 dts 里 aliases { serial0 = &uart1; } 没配导致 ttymxc0 根本不存在。
排查口诀：console 名要和 dts aliases + 驱动注册名三方一致。可临时加 earlycon / earlyprintk 抓早期输出，加 ignore_loglevel 显示所有级别日志。

坑 5：大小端 / 架构 / ABI 与工具链不匹配

现象：程序一跑就 Illegal instruction 或直接 exec format error。
原因：拿 x86 编的程序上板（file 一看 x86-64）、32/64 位混用、或大小端搞错（ARM 默认小端；罕见的大端配置要专用工具链）。
排查：file ./app 永远第一步。记住 ARM Linux 惯例：ARM 默认小端，工具链名不带 "be" 的都是小端。

坑 6：rootwait 缺失与 mmcblk 序号漂移

内核起太早 eMMC 还没就绪 → VFS panic，加 rootwait；换板/换卡后 eMMC 从 mmcblk1 变 mmcblk0 → 用 root=PARTUUID=xxxx 按分区 UUID 挂载最稳。

坑 7：环境变量区被 dd 覆盖

整卡 dd 烧镜像把 saveenv 的区域抹了，启动后环境全变默认。对策：烧录脚本里跳过环境区，或烧完重新 saveenv。

3.11 面试高频问答

Q1：U-Boot 的作用是什么？两阶段启动为什么存在？
A：U-Boot 是 Bootloader，负责初始化 DDR/时钟/串口等硬件、加载内核与 dtb 到内存、通过 bootargs 传参并跳转内核。两阶段（SPL + proper）是因为 BootROM 只能把代码加载到片内小容量 SRAM，完整 U-Boot 放不下，先用几十 KB 的 SPL 初始化好 DDR，再把完整 U-Boot 读进 DDR 执行。

Q2：bootargs 各字段含义？
A：console=ttymxc0,115200 指定内核控制台串口与波特率；root= 指定根文件系统设备（eMMC 分区 /dev/mmcblk1p2 或网络 /dev/nfs）；rootwait 等存储就绪；rw 可读写挂载；init= 指定 1 号进程；mem= 指定内存大小；NFS 场景还有 nfsroot= 和 ip=。U-Boot 把它写进 dtb 的 chosen 节点交给内核。

Q3：设备树解决什么问题？
A：解决板级硬件信息与内核代码耦合的问题。以前每块板子的硬件描述硬编码在内核 C 代码里，内核臃肿难维护；设备树把硬件描述抽成独立数据文件（dts→dtb），同一份内核镜像配不同 dtb 即可支持不同板子，驱动通过 compatible 字符串与节点匹配。

Q4：zImage 和 dtb 谁传给谁？地址怎么传递？
A：都由 U-Boot 加载到 DDR。bootz <zImage地址> - <dtb地址>：内核地址作为跳转目标，dtb 地址通过 ARM 的 r2 寄存器传给内核（r0=0, r1=machine type 已废弃, r2=dtb 物理地址）。内核启动早期解析 dtb 获得内存布局与外设信息。

Q5：NFS 根文件系统怎么配？
A：三步：① PC 装 nfs-kernel-server，/etc/exports 导出 rootfs 目录（rw,no_root_squash）；② 内核开 CONFIG_NFS_FS + CONFIG_ROOT_NFS + CONFIG_IP_PNP；③ U-Boot 设 bootargs：root=/dev/nfs nfsroot=服务器IP:路径,v3,tcp ip=板子IP:服务器IP:网关:掩码::eth0:off，bootcmd 用 tftp 加载内核与 dtb。好处是 rootfs 在 PC 上可随意改，开发效率极高。

Q6：内核 panic 怎么排查？
A：先看 panic 信息定位阶段：① VFS: Unable to mount root fs → root= 设备错/没加 rootwait/文件系统损坏；② 挂在某个驱动 probe → 对照 dmesg 最后几行，检查 dtb 该节点配置；③ 完全无输出 → console 参数或 dtb 不匹配，加 earlycon、ignore_loglevel；④ 随机崩溃 → DDR 参数/供电。通用手段：开 CONFIG_DEBUG_INFO，用 addr2line / objdump 对崩溃地址反查代码行。

Q7：交叉编译是什么？为什么需要？arm-linux-gnueabihf-gcc 名字怎么拆？
A：在 x86 宿主机上编译出 ARM 目标机的可执行文件，因为板子性能太弱无法本地编译。名字四段：arm=目标架构，linux=目标系统，gnu=glibc，eabihf=EABI 硬浮点 ABI；hf 与软浮点库的 ABI 不兼容，混用必崩。

Q8：程序拷到板子上报 not found，但文件存在，为什么？
A：是动态链接器或依赖库缺失，不是程序本身缺失。用交叉版 readelf -l 看 interpreter（/lib/ld-linux-armhf.so.3），readelf -d 看 NEEDED，去工具链 sysroot 里 cp -a（保留软链接）补齐到 rootfs 的 /lib、/usr/lib，必要时设 LD_LIBRARY_PATH。

Q9：zImage、uImage、Image 区别？
A：Image 是未压缩原始内核；zImage 是带自解压头的压缩内核，ARM 32 位标配，用 bootz 启动；uImage 是 zImage 加 64 字节 U-Boot 头的旧格式，用 bootm 启动，现代流程已不需要。

Q10：环境变量 saveenv 存到哪？
A：存到存储介质的固定偏移裸扇区（由 CONFIG_ENV_OFFSET/SIZE 决定），带 CRC 校验；不是文件。烧卡 dd 时可能覆盖它；校验失败 U-Boot 回退到编译进镜像的默认环境。

Q11：BusyBox 是什么？最小 rootfs 怎么做？
A：BusyBox 把几百个 Unix 命令集成进单个可执行文件，命令以软链接形式存在，靠 argv[0] 区分。最小 rootfs 步骤：交叉编译 BusyBox 并 install 到目标目录 → 补 etc/dev/proc/sys/lib 等目录 → 拷动态库与链接器 → 写 inittab/rcS/fstab/profile → mknod console/null 或靠 devtmpfs → modules_install 装内核模块。

Q12：从 NFS 开发切换到 eMMC 独立启动改什么？
A：只改 U-Boot 两个变量：bootcmd 从 tftp 改为 fatload/ext4load mmc 读 zImage 和 dtb；bootargs 的 root 从 /dev/nfs 改为 /dev/mmcblkXpY 并加 rootwait。同时确认 eMMC 分区已灌好 rootfs、内核 dtb 已拷入 boot 分区、saveenv 保存。

Q13：加载 .ko 报 disagrees about version of symbol 怎么办？
A：modversions CRC 校验失败——.ko 与当前运行内核不是同一份源码+配置编出来的。第三方驱动（如 8189fs WiFi）必须用运行内核的同版本源码树和 .config 重新编译，不能跨版本复用 .ko。用 modinfo 看 vermagic 对比 uname -r 验证。

Q14：Buildroot 和手动移植、Yocto 的区别？
A：手动移植每一步自己做，最利于理解但不可复现；Buildroot 用一套 Makefile/Kconfig 自动化构建工具链+bootloader+内核+rootfs，一键出镜像，适合中小团队快速产品化；Yocto 是发行版级构建框架，支持包管理与分层定制，功能最强但学习成本最高，适合大型企业。

Q15：U-Boot 移植到新板子主要改什么？
A：以官方参考板为蓝本复制板级目录/defconfig/dts，然后按原理图逐项适配：DDR 参数（用 DDR 压力测试工具校准，最关键）、时钟晶振、MMC 控制器与位宽、网口 PHY 型号与复位引脚（mii 命令排查）、LCD 时序、调试串口，最后在 defconfig 里裁剪不需要的功能。

第 4 篇 Linux 内核驱动开发

本篇目标读者：写过单片机/STM32 但完全没碰过 Linux 内核的嵌入式工程师。读完本篇你应该能：徒手写出字符设备驱动骨架、讲清 platform + 设备树的匹配流程、看懂 I2C/SPI 传感器驱动、解释 IIO 和 regmap 存在的意义，并在面试中对答如流。

本篇所有"作者驱动练习"实例均来自一套真实的 i.MX6ULL 驱动代码包（目标内核 6.12.34），包含同一硬件的"简要版（misc 字符设备）"与"工程版（内核标准子系统）"双份实现：LED（misc / LED 子系统 / 完整 cdev 链三版）、SHTC3 温湿度（I2C misc / IIO+CRC）、AP3216C 光照接近（SMBus misc / IIO+regmap）、ICM-20608 六轴（SPI misc / IIO+SPI regmap 7 通道）、SSD1306 OLED。代码包中无 .dts 源文件、无 ioctl/pinctrl/中断实例，对应章节用标准范例讲解并单独注明。

4.1 驱动是什么

4.1.1 从 open() 到点亮一颗 LED：完整调用链

单片机里点灯是直接写寄存器；Linux 里应用程序运行在用户空间，没有权限直接碰硬件，必须通过内核。一次 write(fd, "1", 1) 点灯的完整链路：

用户空间  ┌─────────────────────────────────────────────┐
          │  app: fd=open("/dev/user_led") → write(fd,…) │
          └──────────────┬──────────────────────────────┘
                         │ 软中断/swidler 系统调用入口
═════════════════════════╪═══ 用户态/内核态分界线 ═══════
内核空间  ┌──────────────▼──────────────────────────────┐
          │ 系统调用层 sys_open / sys_write              │
          │ VFS 虚拟文件系统：按 /dev/user_led 找到      │
          │   inode → 主/次设备号 → 找到对应 cdev/misc   │
          │ 驱动层：file_operations 里的 .write()        │
          │   → gpiod_set_value() / i2c_transfer() …     │
          │ 硬件层：GPIO 控制器 / I2C 控制器寄存器       │
          └──────────────┬──────────────────────────────┘
硬件                     ▼  GPIO1_IO03 电平翻转，LED 亮

记住三个角色：VFS 把"一切皆是文件"落到设备号上；驱动用 file_operations 接住文件操作；总线/控制器驱动最终翻译为寄存器读写。面试让你"描述一次 read 的完整过程"，就是让你画这张图。

4.1.2 内核空间 vs 用户空间

维度 用户空间 内核空间
权限 受限（ring 3） 最高（ring 0），可访问全部内存与硬件
出错代价 进程被 kill 整个系统 panic
栈 默认 8MB 每线程仅 8~16KB，不能大数组/深递归
浮点 随意用 禁用（内核不保存 FPU 上下文），用定点/64 位整数代替
C 库 glibc 全套 没有 printf/malloc，用 printk/kmalloc
访问对方内存 不能直接读内核地址 不能直接解引用用户指针，必须 copy_to_user/copy_from_user

为什么要分得这么严？因为用户程序是不可信的、会犯错的、随时会被 kill 的；而内核是所有进程共享的地基，一个空指针解引用在用户态只是段错误，在内核态就是整机 oops/panic。驱动工程师的思维方式必须切换：你写的每行代码都运行在整个系统最高权限下，出错没有"程序崩溃"这个选项，只有"系统崩溃"。这也解释了后文反复强调的种种"繁文缛节"——copy_from_user、锁、错误码检查、devm 托管——它们都是给"不能崩"这三个字交的保险费。

作者 SHTC3 驱动练习里温度换算就是"禁浮点"的范例（02_shtc3/drv/drv.c）：

/* 不用浮点，用 64 位整数把结果放大成毫℃、毫%RH */
*temp_millic = (s32)(-45000LL + (175LL * temp_raw * 1000LL) / 65536LL);
*humi_millirh = (s32)((100LL * (u32)hum_raw * 1000LL) / 65536LL);

4.1.3 为什么驱动写成内核模块（.ko）

驱动可以静态编进内核（obj-y），也可以编译成可加载内核模块（.ko 文件，obj-m）。开发阶段一定用模块：改一行代码只需重新编译一个 .ko、rmmod 再 insmod，不用重烧整个内核。运行时动态加载也意味着内核镜像只带必备驱动，板子插上什么硬件再加载什么模块，是 Linux 支持海量硬件的可扩展性基础。模块三要素：

#include <linux/module.h>

static int __init xxx_init(void)   { /* 入口：insmod 时执行 */ return 0; }
static void __exit xxx_exit(void)  { /* 出口：rmmod 时执行 */ }

module_init(xxx_init);      /* 要素一：入口 */
module_exit(xxx_exit);      /* 要素二：出口 */
MODULE_LICENSE("GPL");      /* 要素三：许可证（不声明会污染内核 taint，且用不了 GPL-only 符号） */
MODULE_AUTHOR("zhaozhe");
MODULE_DESCRIPTION("xxx driver");

实际项目里入口/出口常由一行宏代劳：module_platform_driver()、module_i2c_driver()、module_spi_driver()——它们替你生成 module_init/exit，里面调用对应的 register/unregister。作者代码包中所有总线型驱动都用这种写法，比如 LED 驱动末尾就一行 module_platform_driver(led_driver);（00_dev_demo/drv/drv.c:141）。

还有一个常被追问的细节：__init/__exit 前缀是内存优化标记——__init 函数在初始化完成后其内存会被回收另作他用，__exit 函数在静态编译进内核时直接被丢弃（因为静态驱动永远不会被卸载）。对模块而言影响不大，但写上它们是好习惯，面试能解释清楚就是加分项。

4.1.4 模块操作命令与 printk

命令 作用
insmod led.ko 加载模块（不处理依赖）
modprobe led 加载模块并自动解决依赖（读 modules.dep）
rmmod led 卸载模块（注意：参数不带 .ko）
lsmod 列出已加载模块
modinfo led.ko 查看模块信息（作者、license、参数、alias）
dmesg -w 实时查看内核打印（驱动调试第一工具）
cat /proc/devices 查看已注册的字符/块设备主设备号

printk 是内核的 printf，带日志级别（数值越小越紧急）：

printk(KERN_ERR "write fail\n");
pr_err("write fail\n");          /* 推荐：封装宏，等价 */
pr_info("probe ok, major=%d\n", MAJOR(devno));
dev_info(dev, "probe ok\n");     /* 更推荐：自动带上设备名前缀 */

级别：KERN_EMERG(0) < ALERT < CRIT < ERR < WARNING < NOTICE < INFO < DEBUG(7)。低于控制台级别的消息不进串口但仍在 dmesg 环形缓冲区里。printk 还有两个实战注意点：一是它在中断/原子上下文里也能用（不像很多内核函数会睡眠），所以是调试一切上下文都安全的工具；二是高频路径里狂打日志会拖垮系统（printk 本身有锁和串口开销），量产代码要么降级到 pr_debug 用动态调试按需打开，要么用 ratelimit 版本（pr_err_ratelimited）限流。驱动版本信息、probe 关键参数（主设备号、GPIO 号、节点路径）值得用 dev_info 打出来——作者所有驱动的 probe 成功打印都遵循这个习惯，现场排查问题时一条 dmesg 就能看出驱动状态全貌。

【记忆口诀】
"入口 module_init，出口 module_exit，许可证 GPL 别忘记；insmod 上车 rmmod 下，dmesg 一看知端倪。"

4.2 字符设备驱动完整骨架

字符设备是面试的绝对高频区，必须能手写。本节骨架对应作者 01_led_misc_platform_e 驱动练习（全套代码中唯一演示完整 cdev 注册链的驱动）。

4.2.1 设备号：主设备号 + 次设备号

内核用 dev_t（32 位）标识一个字符设备：高 12 位主设备号（对应一类设备/一个驱动），低 20 位次设备号（对应同类中的第几个设备）。三个宏：

dev_t devno = MKDEV(major, minor);   /* 合成 */
MAJOR(devno);                        /* 取主设备号 */
MINOR(devno);                        /* 取次设备号 */

申请设备号两种方式：

/* 静态：指定主设备号，有冲突风险，仅老式驱动用 */
register_chrdev_region(MKDEV(200, 0), 1, "myled");
/* 动态：内核分配空闲主设备号，现代驱动一律用它 */
alloc_chrdev_region(&devno, 0, 1, "myled");
/* 释放 */
unregister_chrdev_region(devno, 1);

设备号在整条链路中的位置值得想清楚：用户 open("/dev/xxx") 时，VFS 从文件节点里读出设备号，按主设备号在全局字符设备表里找到你 cdev_add 进去的 cdev，再把 cdev.fops 挂到 file 结构上——之后的 read/write 才能路由到你的驱动函数。次设备号不参与找驱动，只在驱动内部用来区分第几路硬件。已注册的主设备号可以用 cat /proc/devices 查看（作者 led_misc_platform_e 的验证方式之一）。

4.2.2 cdev：把设备号绑上操作方法

struct cdev 是字符设备在内核中的抽象，注册链四步走（来自作者的 led_misc_platform_e 驱动练习，drv/drv.c:120-150）：

cdev_init(&ldev->cdev, &led_fops);        /* 1. cdev 绑定 file_operations */
ldev->cdev.owner = THIS_MODULE;
ret = cdev_add(&ldev->cdev, ldev->devno, 1); /* 2. 加入内核，此刻设备"活了" */

ldev->class = class_create(LED_DEV_NAME);    /* 3. 创建类（6.12 内核只需类名） */
ldev->device = device_create(ldev->class, dev, ldev->devno, NULL,
                             LED_DEV_NAME);  /* 4. 触发 udev/mdev 自动生成 /dev 节点 */

为什么需要第 3、4 步？cdev_add 只让内核"认识"这个设备，/dev 下的节点是用户空间的 udev/mdev 守护进程根据 class/device 在 sysfs 里产生的事件自动创建的。没有这两步就得手动 mknod /dev/xxx c major minor。

错误回滚铁律：按注册逆序 goto（作者代码原文结构）：

	ret = cdev_add(&ldev->cdev, ldev->devno, 1);
	if (ret)
		goto err_unregister_chrdev;
	ldev->class = class_create(LED_DEV_NAME);
	if (IS_ERR(ldev->class)) { ret = PTR_ERR(ldev->class); goto err_cdev_del; }
	...
err_class_destroy: class_destroy(ldev->class);
err_cdev_del:      cdev_del(&ldev->cdev);
err_unregister_chrdev: unregister_chrdev_region(ldev->devno, 1);

remove 里同样逆序，且先删 /dev 节点再注销 cdev——作者 remove 注释解释得很到位："先让 /dev 节点消失，再注销 cdev 与设备号，保证节点移除后不会再有新的 open/read/write 进入"：

device_destroy(ldev->class, ldev->devno);
class_destroy(ldev->class);
cdev_del(&ldev->cdev);
unregister_chrdev_region(ldev->devno, 1);

4.2.3 file_operations 逐项讲解

static const struct file_operations led_fops = {
	.owner   = THIS_MODULE,   /* 防止使用时模块被卸载，几乎永远写它 */
	.open    = led_open,      /* open() 时调用；常在此用 container_of 反推设备实例 */
	.release = led_release,   /* close() 最后一个 fd 关闭时调用 */
	.read    = led_read,      /* read() 时调用 */
	.write   = led_write,     /* write() 时调用 */
	.llseek  = default_llseek,/* lseek()；用内核默认实现即可 */
	.unlocked_ioctl = led_ioctl, /* ioctl()；自定义命令（设置参数等） */
	.poll    = led_poll,      /* poll/select/epoll 支持 */
};

要点速记：

  • open 反推实例：cdev 框架把 cdev 指针存在 inode->i_cdev，用 container_of 反推出你的设备结构体（作者 led_misc_platform_e, drv.c:49）：
static int led_open(struct inode *inode, struct file *filp)
{
	filp->private_data = container_of(inode->i_cdev, struct led_cdev_dev, cdev);
	return 0;
}

之后 read/write 直接从 filp->private_data 拿实例，这是"一个驱动管多个同类设备"的关键。

  • read/write 原型：ssize_t (*read)(struct file *, char __user *buf, size_t, loff_t *ppos)。__user 标记提醒：这是用户空间指针，禁止直接解引用。

  • llseek 别忽视：fops 不挂 llseek 时默认行为依内核版本而定，传感器"快照读取"模式依赖应用 lseek(fd, 0, SEEK_SET) 复位偏移，统一挂 .llseek = default_llseek（作者 SHTC3/AP3216C/ICM-20608 三个驱动都这样做，注释："允许 lseek 把偏移倒回 0，应用才能用同一个 fd 循环取新快照"）。

  • unlocked_ioctl 标准范例（作者代码包无 ioctl 实例，按标准写法补讲）：ioctl 是 read/write 之外的"自定义命令通道"，适合设置量程、滤波系数这类带参数的控制。命令号不要随手写魔数，用内核宏编码（方向 + 类型 + 序号 + 参数大小）：

#define XXX_MAGIC    'x'
#define XXX_SET_GAIN _IOW(XXX_MAGIC, 0, int)   /* 用户 → 内核，参数 int */
#define XXX_GET_GAIN _IOR(XXX_MAGIC, 1, int)   /* 内核 → 用户 */

static long xxx_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
	int val;
	switch (cmd) {
	case XXX_SET_GAIN:
		if (copy_from_user(&val, (int __user *)arg, sizeof(val)))
			return -EFAULT;
		/* …写寄存器… */
		break;
	case XXX_GET_GAIN:
		val = data->gain;
		if (copy_to_user((int __user *)arg, &val, sizeof(val)))
			return -EFAULT;
		break;
	default:
		return -ENOTTY;   /* 不认识的命令返回 -ENOTTY 是惯例 */
	}
	return 0;
}

4.2.4 用户内存拷贝：copy_to_user / copy_from_user / simple_read_from_buffer

内核直接读写用户指针可能因为缺页、地址非法而崩内核，必须用专用函数（成功返回 0，失败返回未拷贝的字节数）：

if (copy_from_user(&kbuf, buf, 1))     /* 用户 → 内核 */
	return -EFAULT;                /* 约定俗成返回 -EFAULT */

read 路径的最佳实践是 simple_read_from_buffer（作者全套驱动的统一做法）：它内部调用 copy_to_user，并自动处理文件偏移与 EOF——"读到末尾返回 0，cat 才不会死循环"（作者 user_led 驱动注释原话）：

static ssize_t led_read(struct file *filp, char __user *buf, size_t cnt, loff_t *offt)
{
	char kbuf[2];
	kbuf[0] = gpiod_get_value(ldev->gpiod) + '0';
	kbuf[1] = '\n';
	return simple_read_from_buffer(buf, cnt, offt, kbuf, 2);
}

配套技巧"快照 + llseek"（作者 SHTC3/AP3216C/ICM-20608 三个传感器驱动共用）：read 开头 if (*offt) return 0; 保证一次 open 出一份数据快照；fops 挂 .llseek = default_llseek，应用循环读前 lseek(fd, 0, SEEK_SET) 把偏移倒回 0，就能用同一个 fd 反复取新数据。

read/write 的返回值约定也要烂熟：返回实际读/写的字节数，0 表示 EOF（不是错误），负数才是错误码。copy_from_user 失败统一返回 -EFAULT（作者全套驱动的统一写法）。为什么 EOF 必须正确返回？因为 shell 的 cat 是"循环 read 直到返回 0"——驱动如果忘记处理偏移，cat 会无限循环刷屏，作者 user_led 驱动注释专门提醒过这一点。这些看似琐碎的语义恰恰是"驱动写得地不地道"的分水岭。

4.2.5 完整最小可编译示例

下面是一个去掉硬件操作、可独立编译验证的"虚拟字符设备"完整示例（骨架与作者的 led_misc_platform_e 一致，仅把 gpiod 换成内存缓冲区，方便在无开发板的 PC 上编译体验）：

// SPDX-License-Identifier: GPL-2.0
/* mini_chrdev.c —— 最小完整字符设备驱动（内存版，可在 PC 上 insmod 验证） */
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/uaccess.h>
#include <linux/slab.h>

#define DEV_NAME "mini_chrdev"
#define BUF_SIZE 128

static dev_t devno;
static struct cdev mini_cdev;
static struct class *mini_class;
static char kbuf[BUF_SIZE] = "hello kernel\n";

static ssize_t mini_read(struct file *filp, char __user *buf,
			 size_t cnt, loff_t *offt)
{
	return simple_read_from_buffer(buf, cnt, offt, kbuf, strlen(kbuf));
}

static ssize_t mini_write(struct file *filp, const char __user *buf,
			  size_t cnt, loff_t *offt)
{
	cnt = min(cnt, (size_t)BUF_SIZE - 1);
	if (copy_from_user(kbuf, buf, cnt))
		return -EFAULT;
	kbuf[cnt] = '\0';
	return cnt;
}

static const struct file_operations mini_fops = {
	.owner = THIS_MODULE,
	.open  = NULL,             /* 单实例可不写 open */
	.read  = mini_read,
	.write = mini_write,
	.llseek = default_llseek,
};

static int __init mini_init(void)
{
	int ret;
	ret = alloc_chrdev_region(&devno, 0, 1, DEV_NAME);
	if (ret)
		return ret;
	cdev_init(&mini_cdev, &mini_fops);
	mini_cdev.owner = THIS_MODULE;
	ret = cdev_add(&mini_cdev, devno, 1);
	if (ret)
		goto err_unregister;
	mini_class = class_create(DEV_NAME);
	if (IS_ERR(mini_class)) { ret = PTR_ERR(mini_class); goto err_cdev; }
	if (IS_ERR(device_create(mini_class, NULL, devno, NULL, DEV_NAME))) {
		ret = -ENODEV; goto err_class;
	}
	pr_info("mini_chrdev loaded, major=%d\n", MAJOR(devno));
	return 0;
err_class:  class_destroy(mini_class);
err_cdev:   cdev_del(&mini_cdev);
err_unregister: unregister_chrdev_region(devno, 1);
	return ret;
}

static void __exit mini_exit(void)
{
	device_destroy(mini_class, devno);
	class_destroy(mini_class);
	cdev_del(&mini_cdev);
	unregister_chrdev_region(devno, 1);
	pr_info("mini_chrdev unloaded\n");
}

module_init(mini_init);
module_exit(mini_exit);
MODULE_LICENSE("GPL");

配套用户态测试程序（交叉编译后与 .ko 一起部署，作者代码包中每个驱动都带一个 <模块名>_app）：

/* mini_chrdev_app.c */
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

int main(void)
{
	char buf[128];
	int fd = open("/dev/mini_chrdev", O_RDWR);
	if (fd < 0) { perror("open"); return 1; }
	write(fd, "embedded linux", 14);
	lseek(fd, 0, SEEK_SET);            /* 倒回偏移再读 */
	read(fd, buf, sizeof(buf) - 1);
	printf("read back: %s\n", buf);
	close(fd);
	return 0;
}

4.2.6 外部模块 Makefile（obj-m + M=）

驱动模块不参与内核源码树编译，用 KBuild 的外部模块机制。作者的 drv/Makefile 模板：

kerdir := /home/zhao/imx6ull/kernel/linux-imx      # 已编译/配置过的内核源码树
NFS_MOD := $(HOME)/nfs/rootfs/lib/modules/6.12.34  # NFS 根文件系统，install 直接上板
obj-m += $(modulename).o
$(modulename)-objs := drv.o        # 把 drv.o 打包成 <modulename>.ko，源码可保持 drv.c 不改名

all:
	$(MAKE) -C $(kerdir) M=$(CURDIR) modules
install: all
	cp $(modulename).ko $(NFS_MOD)/ -f
clean:
	$(MAKE) -C $(kerdir) M=$(CURDIR) modules clean

面试要点：obj-m 表示编成模块（obj-y 编进内核）；-C $(kerdir) 切到内核树用它的顶层 Makefile；M=$(CURDIR) 告诉内核"外部模块源码在这里"。交叉编译时再加 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-。

【记忆口诀】
"先申请号（alloc_chrdev_region），再注册 cdev（init 加 add），class 加 device，/dev 自动现；出错逆序 goto，remove 反着删。用户内存不直碰，copy 两个函数保平安。"

4.3 misc 杂项设备

4.3.1 为什么有 misc

完整 cdev 链四步注册稍显繁琐。对于"功能简单、只要一个次设备号"的小驱动，内核提供 misc（杂项）框架：主设备号固定为 10，次设备号由框架动态分配，一行 misc_register() 同时完成设备号分配、/dev 节点创建。可以把它理解成"内核官方封装好的 cdev 模板"——misc 子系统内部就是一套已经注册好的 cdev（主设备号 10），你的 misc_register 只是在这套 cdev 里登记一个次设备号和自己的 fops，open 时由 misc 的 open 转手调你的 open（这正是 filp->private_data 里预先放好 miscdevice 指针的原因）。看 /proc/devices 里 "10 misc" 一行可以验证这个理解。作者 LED 简要版（00_dev_demo/drv/drv.c:73-77）：

static struct miscdevice led_misc = {
	.minor = MISC_DYNAMIC_MINOR,   /* 动态次设备号 */
	.name  = "user_led",           /* → /dev/user_led 自动出现 */
	.fops  = &led_fops,
};
/* probe 里 */ misc_register(&led_misc);
/* remove 里 */ misc_deregister(&led_misc);

4.3.2 misc 的两个实战技巧（来自作者驱动练习）

  1. open 反推实例：misc 框架在调你的 open 前，把 miscdevice 指针放进 filp->private_data（作者 01_led_misc_platform, drv.c:32）：
static int led_open(struct inode *inode, struct file *filp)
{
	/* 反推包含 misc 成员的设备实例，支持一个驱动多颗 LED */
	filp->private_data = container_of(filp->private_data, struct led_dev, misc);
	return 0;
}
  1. 借 parent 找回总线设备：传感器驱动里常需要 i2c_client。作者 SHTC3 驱动（02_shtc3, drv.c:87）的做法：probe 时把 misc.parent = &client->dev，open 里 container_of(misc->parent, struct i2c_client, dev) 找回 client。

4.3.3 misc vs cdev 怎么选（面试常考）

misc cdev 完整链
注册代码量 一行 四步 + 回滚
主设备号 固定 10 独立分配
次设备号 通常只申请 1 个 可管理一整段
适用 简单小驱动、快速验证 正式产品接口、多实例、需自定义 ioctl/llseek/poll

作者 led_misc_platform_e 注释原话可作为面试答案的骨感版："misc 一行注册固然省事，但主设备号固定为 10、只有一个动态次设备号，扩展 ioctl、llseek、poll 等接口时也不直观。当驱动需要自定义 ioctl、管理多个次设备号、或作为正式产品接口长期维护时，应使用 alloc_chrdev_region + cdev + class_create + device_create 这套标准流程。"

【记忆口诀】
"misc 主号固定 10，一行注册节点生；open 反推 private_data，container_of 定乾坤；正式产品走 cdev，四步注册最正宗。"

4.4 platform 平台总线

4.4.1 总线-设备-驱动模型：为什么要有它

早期驱动把硬件信息（寄存器地址、GPIO 号、中断号）写死在代码里，换块板子就要改驱动。Linux 的解法是分层解耦：

  • bus（总线）：维护"设备链表"和"驱动链表"，提供 match 函数负责配对；
  • device（设备）：只描述硬件资源（地址、IRQ、设备树节点）；
  • driver（驱动）：只描述操作逻辑（probe/remove、fops），不含具体硬件参数。

GPIO、I2C 控制器这类"挂在 SoC 上、不隶属任何物理总线"的设备，内核虚拟出 platform 总线来安置它们。I2C/SPI 总线上的外设则走各自的 i2c_client/spi_device，但模型思想完全一致。

这套模型还带来一个面试常考的好处：延迟绑定与电源管理有了统一抓手。总线知道每个设备归哪个驱动管，才能做到按需 probe（依赖未就绪先挂起）、运行时挂起/恢复（suspend/resume 回调也挂在 driver 上）、以及 sysfs 里 /sys/bus/<总线>/devices 与 /sys/bus/<总线>/drivers 双向链接——调试时"这个节点被谁绑走了"一看便知。

4.4.2 platform_device 与 platform_driver

先补一段历史帮助理解：设备树普及之前（ARM Linux 3.x 以前），硬件信息写在内核源码的 board file 里，用 platform_device_register() 静态注册一个个 platform_device——每块开发板一份 C 文件，ARM 内核一度因此膨胀到被 Linus 公开批评。设备树接管"设备描述"这一半后，platform_device 由内核解析设备树节点自动生成（SoC 片上节点），驱动工程师 95% 的情况只需要写 platform_driver 这一半。面试被问"platform_device 在哪注册"，标准回答就是：老式代码在 board file 里手写注册，现代 ARM 平台由设备树节点自动生成。

驱动侧手写 platform_driver（作者 user_led 驱动练习，00_dev_demo/drv/drv.c:126-141）：

static const struct of_device_id led_of_match[] = {
	{ .compatible = "alientek,imx6ull-alpha-led" },
	{ /* 结束标记，必须有 */ }
};
MODULE_DEVICE_TABLE(of, led_of_match);   /* 导出别名，支持 udev 按 modalias 自动加载模块 */

static struct platform_driver led_driver = {
	.driver = {
		.name = "user_led",
		.of_match_table = led_of_match,   /* 设备树匹配表 */
	},
	.probe  = led_probe,
	.remove = led_remove,
};
module_platform_driver(led_driver);      /* 一行宏 = module_init/exit + register/unregister */

4.4.3 匹配与 probe 触发时机（面试必考）

设备树节点 (DTS)                platform_driver
┌─────────────────────┐        ┌──────────────────────────┐
│ led {               │        │ of_match_table:          │
│  compatible =       │ match  │  {"alientek,imx6ull-     │
│   "alientek,imx6ull │◄──────►│   alpha-led"}            │
│    -alpha-led";     │ 比对    │ 命中 → 调 probe(pdev)    │
│  led-gpios = <...>; │        │ rmmod/解绑 → 调 remove   │
│ };                  │        └──────────────────────────┘
└─────────────────────┘
   内核启动时 of_platform 子系统
   把节点转成 platform_device

probe 被调用的时机有三种：(1) 驱动注册时总线上已有匹配设备；(2) 设备注册时（设备树解析）总线上已有匹配驱动；(3) 模块后加载时（insmod 后总线遍历未配对设备逐一 match）。匹配优先级：of_match_table（设备树）→ id_table → driver.name 与设备名字符串相等。

remove 触发：rmmod、设备被移除（设备树覆盖层卸载）、或手动 unbind。probe 与 remove 在驱动生命周期里严格对称，写 remove 时对照 probe 逐条反问"这一步是否需要撤销"，就不会漏清理——这也是作者所有驱动 remove 都与 probe 严格逆序的原因。

4.4.4 probe 里干什么：取资源 + 注册接口

static int led_probe(struct platform_device *pdev)
{
	struct device *dev = &pdev->dev;
	/* 1. 从设备树取 GPIO（也可用 platform_get_resource 取 reg/irq） */
	led_gpio = of_get_named_gpio(dev->of_node, "led-gpios", 0);
	/* 2. 申请并配置资源 */
	gpio_request(led_gpio, LED_NAME);
	gpio_direction_output(led_gpio, 1);
	/* 3. 注册用户接口（misc / cdev / IIO / LED class…） */
	misc_register(&led_misc);
	/* 4. 保存实例供 remove 取回 */
	platform_set_drvdata(pdev, ldev);
	return 0;
}

platform_get_resource(pdev, IORESOURCE_MEM, 0) + devm_ioremap_resource() 用于寄存器映射；platform_get_irq() 取中断号。probe 失败的返回值有特殊语义：返回 -EPROBE_DEFER 表示"我依赖的东西还没就绪，稍后再 probe 我"（见 4.11）。

4.4.5 用 of_device_id.data 传递驱动数据

一张 of_match_table 兼容多个芯片型号时，把型号差异数据挂在 .data 上：

static const struct chip_cfg shtc3_cfg  = { .has_clock_stretch = false };
static const struct of_device_id xxx_of_match[] = {
	{ .compatible = "zhao,shtc3",      .data = &shtc3_cfg },
	{ .compatible = "sensirion,shtc3", .data = &shtc3_cfg },
	{ }
};
/* probe 里取回 */
const struct chip_cfg *cfg = of_device_get_match_data(dev);

【记忆口诀】
"总线当红娘，设备驱动两边忙；compatible 对上眼，probe 才把洞入房；insmod、开机、后加载，三种时机都call它。"

4.5 设备树在驱动中的角色

说明：作者代码包中没有 .dts 源文件，以下节点写法依据驱动源码注释记载 + 解析代码还原（标注处），格式为标准 DTS 语法，面试中照此回答即可。

设备树（Device Tree）是描述硬件的数据结构：.dts 源码经 dtc 编译成 .dtb，BootLoader 把它传给内核，内核启动时解析，为每个节点生成 device_node，platform/i2c/spi 子系统再据此创建设备。驱动从此不写死硬件参数。

理解设备树的一个好类比：它像一份"硬件清单配置文件"。SoC 厂商提供 .dtsi（描述芯片内部有哪些控制器），板级 .dts 用 &i2c1 { ... } 这种引用语法往里挂外设、改属性——驱动工程师日常改的基本都是板级 .dts。节点里 status = "okay" 才会生成设备，"disabled" 等于注释掉这个硬件。

4.5.1 常见属性实例（按作者驱动还原）

/* ① LED：platform 设备（注释记载：/led 节点，GPIO1_IO03，低电平点亮） */
/ {
	led {
		compatible = "alientek,imx6ull-alpha-led";
		led-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;   /* 极性标志会被 gpiod 自动处理 */
		status = "okay";
	};
};

/* ② I2C 设备：SHTC3（注释记载：I2C1，7bit 地址 0x70） */
&i2c1 {
	shtc3: shtc3@70 {
		compatible = "zhao,shtc3", "sensirion,shtc3";
		reg = <0x70>;                 /* I2C 从机地址，i2c 子系统据此创建 i2c_client */
	};
	oled@3c {                         /* SSD1306，节点名 my_oled@3c（注释记载） */
		compatible = "zhao,oled";
		reg = <0x3c>;
	};
};

/* ③ SPI 设备：ICM-20608（unbind 路径 spi2.0 可证在 SPI2、CS0） */
&ecspi2 {
	icm20608@0 {
		compatible = "invensense,icm20608d";
		reg = <0>;                    /* 片选编号 */
		spi-max-frequency = <8000000>;
		/* 片选极性、SPI 模式由控制器与节点属性决定，不在驱动里写死 */
	};
};

核心属性速记：compatible（匹配驱动的钥匙）、reg（I2C/SPI 的地址或片选；platform 的寄存器物理地址+长度）、xxx-gpios（GPIO 描述符，格式 <&gpio控制器 引脚号 极性标志>）、interrupts + interrupt-parent（中断）、status（okay/disabled）。

注意属性名与代码的对应关系，面试常在这里埋细节题：devm_gpiod_get(dev, "led", ...) 里的字符串 "led" 对应设备树属性名 led-gpios（框架自动拼 "-gpios" 后缀）；of_get_named_gpio(node, "led-gpios", 0) 则要写完整属性名，最后的 0 是索引——一个属性里有多个 GPIO 时按序号取。写错名字拿到的就是 -ENOENT，这类"驱动没问题、设备树差一个字符"的 bug 在实战中极其常见。

4.5.2 of 函数族：驱动里怎么读设备树

u32 val;
of_property_read_u32(node, "max-speed", &val);        /* 读 u32 属性 */
of_property_read_string(node, "label", &str);         /* 读字符串 */
of_get_named_gpio(node, "led-gpios", 0);              /* 取 GPIO 编号（老 API） */
/* 新 API 更省事：devm_gpiod_get(dev, "led", ...) 自动找 "led-gpios" 属性 */
of_device_get_match_data(dev);                        /* 取 of_match 条目 .data */

4.5.3 匹配优先级与一个真实坑

compatible 字符串列表按数组顺序逐项与驱动 of_match_table 比对，先命中先用。作者 SHTC3 驱动注释里有个实战坑：自定义的 "zhao,shtc3" 必须放 of_match_table 第一项（且设备树 compatible 列表里自定义串放前面），否则可能被内核里同芯片的通用驱动条目抢先匹配。同理，设备树里写 compatible = "zhao,shtc3", "sensirion,shtc3" 是"专有在前、兼容在后"的标准写法。

【记忆口诀】
"compatible 是红线，reg 报地址，gpios 报引脚，interrupts 报中断；专有在前通在后，匹配顺序莫搞反。"

4.6 GPIO 与 pinctrl

4.6.1 两代 GPIO API 对照（作者代码包真实呈现）

第一代：整编编号 API（gpio.h，作者 LED 简要版 00_dev_demo 使用）：

led_gpio = of_get_named_gpio(dev->of_node, "led-gpios", 0); /* 从设备树解析编号 */
ret = gpio_request(led_gpio, LED_NAME);                     /* 申请占用 */
gpio_direction_output(led_gpio, 1);                         /* 设为输出+初始电平 */
gpio_set_value(led_gpio, kbuf == '1' ? 0 : 1);              /* 写物理电平 */
val = gpio_get_value(led_gpio);                             /* 读物理电平 */
gpio_free(led_gpio);                                        /* remove 里释放 */

痛点：它操作的是物理电平。"低电平点亮"要驱动自己记住——作者简要版注释写着 "'1' 点亮（拉低）"，写 '1' 实际调 gpio_set_value(..., 0)，非常反直觉。

第二代：gpiod 描述符 API（gpio/consumer.h，作者工程版统一使用）：

/* 一步完成：解析设备树 led-gpios + 申请 + 设输出方向 + 初始逻辑电平。
 * 失败（含 GPIO 控制器未就绪返回 -EPROBE_DEFER）交给 dev_err_probe 处理 */
ldev->gpiod = devm_gpiod_get(dev, "led", GPIOD_OUT_HIGH);
if (IS_ERR(ldev->gpiod))
	return dev_err_probe(dev, PTR_ERR(ldev->gpiod), "获取 led-gpios 失败\n");

gpiod_set_value(ldev->gpiod, 1);   /* 逻辑 1 = 点亮，框架自动按 GPIO_ACTIVE_LOW 翻转 */
gpiod_set_value(ldev->gpiod, 0);   /* 逻辑 0 = 熄灭 */
/* 无需 free：devm_ 托管 */

工程版注释说得很清楚（作者 led_misc_platform_e, drv.c:81-84）："设备树标 GPIO_ACTIVE_LOW 后，gpiod_set_value(..., 1) 即点亮，框架自动翻转，不必像 gpio_set_value 那样自己记低电平点亮。"逻辑电平思维的价值在板级改版时最能体现：原理图把 LED 从低电平点亮改成高电平点亮，只需把设备树里的极性标志从 GPIO_ACTIVE_LOW 改成 GPIO_ACTIVE_HIGH，驱动代码一行不动——硬件细节留在设备树，驱动只管"点亮"这个语义。面试结论：新代码一律用 gpiod + devm，老代码维护时认识编号 API 即可。

4.6.2 pinctrl 子系统干什么

说明：作者代码包 11 个驱动均未显式配置 pinctrl，本节为标准范例讲解。

SoC 引脚数量远少于功能数量，一根引脚往往可复用为 GPIO/UART/I2C/PWM 等多种功能，pinctrl 子系统负责两件事：

  1. 引脚复用（pin mux）：把引脚切换到需要的功能；
  2. 电气属性（pin config）：上下拉、驱动能力、斜率、施密特触发等。

设备树里的典型写法（i.MX6ULL 风格）：

&iomuxc {
	pinctrl_led: ledgrp {
		fsl,pins = <
			/* 引脚  复用功能   电气属性 */
			MX6UL_PAD_GPIO1_IO03__GPIO1_IO03  0x10b0
		>;
	};
};

&i2c1 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_i2c1>;      /* 引用自己的引脚组 */
	...
};

驱动代码里通常什么都不用写：设备创建时内核按 pinctrl-names = "default" 自动应用 pinctrl-0 指定的引脚状态。只有当设备有多种状态（如 default/sleep）需要运行时切换时，才用 devm_pinctrl_get + pinctrl_select_state。

面试可以这样概括 pinctrl 与 GPIO 子系统的分工：pinctrl 负责"这根引脚是什么功能、电气特性如何"（复用+配置），GPIO 子系统负责"把这根已是 GPIO 的引脚拉高拉低"（数值操作）。一根引脚先经 pinctrl 复用成 GPIO 功能，之后 gpiod_set_value 才有意义。I2C/SPI 引脚则复用为控制器功能后由控制器驱动直接操作，驱动完全不碰。

【记忆口诀】
"老 API 数编号，物理电平自己恼；gpiod 按逻辑，极性框架包；pinctrl 管复用加电气，设备树里 pinctrl-0 一引就完事。"

4.7 I2C 驱动框架

4.7.1 框架三角色

  • i2c_adapter：SoC 的 I2C 控制器驱动（BSP 提供），掌握"怎么发波形"——起始位、地址、ACK、数据、停止位的电气时序全在 adapter 的 algorithm 里；
  • i2c_client：挂在总线上的一个从机（设备树 xxx@70 节点生成），包含 7 位地址、所属 adapter 指针；
  • i2c_driver：你写的驱动。probe 的第一个参数就是 i2c_client，之后的所有传输都通过它。

三者关系可以打个比方：adapter 是电话交换机，client 是分机号码，你的驱动是要打电话的人——每次 i2c_transfer 都是"通过 client 找到 adapter，让 adapter 拨号"。所以传输函数要的参数是 client->adapter 而不是 client 本身，这是初学者常卡壳的点。另外 probe 里的 client 不要全局变量保存，一个驱动理论上面向总线上多颗同型号芯片，正确做法是挂进设备私有结构体（i2c_set_clientdata 或塞进 iio_priv）。

static const struct of_device_id shtc3_of_match[] = {
	{ .compatible = "zhao,shtc3" },        /* 作者注释：必须放第一项否则匹配不上 */
	{ .compatible = "sensirion,shtc3" },
	{ /* sentinel */ }
};
static const struct i2c_device_id shtc3_id[] = { { "shtc3", 0 }, {} };  /* 传统匹配/去警告 */

static struct i2c_driver shtc3_driver = {
	.driver = { .name = "shtc3", .of_match_table = shtc3_of_match },
	.probe  = shtc3_probe,          /* int (*probe)(struct i2c_client *) */
	.remove = shtc3_remove,
	.id_table = shtc3_id,
};
module_i2c_driver(shtc3_driver);

双表并存是实战惯例（作者 SHTC3/ICM-20608 均如此）：of_match_table 负责设备树匹配，id_table 用于非 DT 场景并消除内核 "has no spi/i2c_device_id" 的匹配警告。

4.7.2 三种读写方式，按芯片选型

(1) 手写 i2c_msg + i2c_transfer——最原始、最灵活，适合"发 2 字节命令字、读 N 字节"这类非标准协议。作者 SHTC3 驱动（02_shtc3/drv/drv.c:27-40）：

static int shtc3_write_cmd(struct i2c_client *client, u16 cmd)
{
	u8 buf[2] = { cmd >> 8, cmd & 0xff };          /* 命令字大端发送 */
	struct i2c_msg msg = {
		.addr  = client->addr,
		.flags = 0,                               /* 0 = 写 */
		.buf   = buf,
		.len   = 2,
	};
	if (i2c_transfer(client->adapter, &msg, 1) != 1) /* 返回成功传输的 msg 数 */
		return -EIO;
	return 0;
}
/* 读数据：msg.flags = I2C_M_RD, len = 6，同样 i2c_transfer */

(2) SMBus 封装函数——芯片是"寄存器地址 + 数据"模型时（绝大多数传感器），内核提供现成封装，一行顶一次完整传输：

i2c_smbus_write_byte_data(client, reg, val);   /* 写 8 位寄存器 */
i2c_smbus_read_byte_data(client, reg);         /* 读 8 位寄存器 */
i2c_smbus_read_word_data(client, reg);         /* 读 16 位寄存器 */
i2c_smbus_read_i2c_block_data(client, reg, len, buf); /* 读块 */

作者 AP3216C 简要版（03_ap3216c/drv/drv.c）：probe 中 i2c_smbus_write_byte_data(client, 0x00, 0x04) 软复位 → msleep(50) → 再写 0x03 使能 ALS+PS+IR 三路；read 中三次 i2c_smbus_read_word_data() 读 IR/ALS/PS 寄存器。

(3) regmap——见 4.10，工程版首选。

辅助函数：i2c_check_functionality(client->adapter, I2C_FUNC_I2C) 在 probe 开头检查控制器能力，不支持就 -EOPNOTSUPP 拒绝（作者 ap3216c_e, drv.c:166）。

4.7.3 实例一：SHTC3 温湿度（无寄存器协议 + CRC）

SHTC3 没有寄存器概念，靠 16 位命令字驱动。作者 SHTC3 驱动完整测量时序（02_shtc3/drv/drv.c:42-80）：

shtc3_write_cmd(client, SHTC3_CMD_WAKEUP);      /* 0x3517 唤醒 */
msleep(10);
shtc3_write_cmd(client, SHTC3_CMD_MEAS_HFIRST); /* 0x58E0 湿度优先、正常精度 */
msleep(50);                                     /* 正常精度转换约 12ms，留足余量 */
shtc3_read_data(client, buf, 6);                /* 湿度2 + 湿度CRC + 温度2 + 温度CRC */
shtc3_write_cmd(client, SHTC3_CMD_SLEEP);       /* 0xB098 回睡眠省电 */

数据布局 buf[0..1]=湿度、buf[2]=湿度CRC、buf[3..4]=温度、buf[5]=温度CRC。工程版（02_shtc3_e）对每 2 字节做 CRC-8 校验（多项式 0x31、初值 0xFF），失败返回 -EIO——作者注释："数据不可信时报错而不是返回脏数据"。这是面试加分点：总线数据要校验。

这套"唤醒→测量→睡眠"的循环还体现了一个通用的低功耗设计思想：传感器大部分时间应待在微安级的睡眠态，只在采样瞬间唤醒。工程版的 remove 也在 mutex 保护下补发一次 SLEEP 命令，确保卸载驱动后芯片不空耗电流。电池供电产品里，这类细节直接决定待机时长，面试官若追问"驱动里怎么做功耗优化"，这就是现成答案。

4.7.4 实例二：AP3216C 光照/接近（寄存器协议 + 位解析）

AP3216C 是标准寄存器型芯片（作者 03_ap3216c/drv/drv.c:15-22）：SYS_CONFIG=0x00（0x04 软复位/0x03 使能三路）、IR_DATA=0x0a、ALS_DATA=0x0c、PS_DATA=0x0e。读出 16 位原始值后按数据手册做位拼接：

/* PS 数据只有 10 位，散布在两个寄存器的特定位置（drv.c:48-55） */
ps = ((ps_raw >> 4) & 0x3f0) | (ps_raw & 0x0f);
ir = ((ir_raw >> 6) & 0x3fc) | (ir_raw & 0x03);
als = als_raw;   /* ALS 全 16 位 */

简要版把结果格式化成 ASCII 方便 shell 直接 cat 调试：

cnt = scnprintf(kbuf, sizeof(kbuf), "als=%u ps=%u ir=%u\n", als, ps, ir);
return simple_read_from_buffer(buf, cnt, offt, kbuf, cnt);

4.7.5 实例三：SSD1306 OLED——I2C 不只是传感器（作者 05_oled 驱动练习）

SSD1306 是 128×64 单色 OLED 控制器，I2C 地址 0x3C（作者用 i2cdetect 实测，注释记载），设备树节点 my_oled@3c、compatible = "zhao,oled"。它展示了 I2C 上另一类协议形态——控制字节 + 数据流，而非寄存器或命令字：

  • 协议核心（drv.c:11-13 注释）：每个 I2C 传输的第一个字节是控制字节，0x00 表示后面是命令、0x40 表示后面是显存数据。发命令组 {0x00, cmd} 两字节 i2c_master_send；写显存组 {0x40, data...}，一次把整页 128 字节发出去（i2c_master_send 是"纯写一段 buf"的简化封装，比手写 i2c_msg 省事）。
  • 显存组织：8 页 × 128 列，每字节对应一列 8 个竖直像素；用三条命令设置光标：0xb0|page（页）、0x10|(col>>4)（列高 4 位）、0x00|(col&0xf)（列低 4 位）。
  • 初始化序列照抄数据手册（drv.c:159-175）：关显示 → 设时钟/复用率/偏移/起始行 → 段重映射与 COM 扫描方向（决定显示是否镜像颠倒）→ 对比度/预充电/VCOMH → 0x8d 0x14 使能充电泵（I2C 模块没有外部 VCC，不开充电泵屏不亮，这是最常见的"接线全对但黑屏"原因）→ 0xaf 开显示。
  • 用户接口是 misc 设备 /dev/oled：write 里 copy_from_user 拿字符串，查 8x16 ASCII 字库逐字渲染，处理换行、写满 4 行自动清屏；remove 时发 0xae 关显示，注释解释"避免屏幕保持最后一帧耗电"。

这个驱动面试中的价值在于说明：I2C 只是一种"按地址收发字节"的管道，上层协议完全由芯片定义——寄存器型（AP3216C）、命令字型（SHTC3）、控制字节流型（SSD1306）三种形态都要见识过，读任何新芯片的数据手册都能对号入座。

I2C 驱动面试一句话总结：双表匹配 → probe 拿 client → SMBus/i2c_transfer/regmap 读写 → 按手册换算，必要时 CRC 校验。

【记忆口诀】
"client 到手活好办：发命令 i2c_transfer，寄存器读写 SMBus 办，工程版本 regmap 换；能力先查 functionality，数据回来 CRC 验。"

4.8 SPI 驱动框架

4.8.1 框架与 I2C 同构

spi_driver ↔ spi_device，probe 拿 spi_device；匹配同样是 of_match_table + spi_device_id 双表。与 I2C 的区别：片选（CS）、时钟极性/相位（SPI 模式 0~3）、最高频率都由设备树节点指定（reg=<CS号>、spi-max-frequency），驱动不用也不该自己拉 CS——内核 SPI 核心在每次传输前后自动控制片选。

4.8.2 传输 API

  • spi_write(spi, buf, len)：单纯发数据；
  • spi_read(spi, buf, len)：单纯收数据；
  • spi_write_then_read(spi, tx, txlen, rx, rxlen)：半双工一次传输——先发地址，再在同一片选周期内读回数据（读寄存器的标准姿势）；
  • 底层：spi_message + spi_transfer 组装 + spi_sync() 同步发送。理解这对结构是面试底层题：一条 message 串多个 transfer，每个 transfer 可独立设置 tx/rx buffer、字长、速度、是否保持 CS（cs_change）。为什么需要 transfer 级粒度？因为像"发 1 字节地址 + 收 14 字节数据"这种操作本质是两个 transfer 组成的一次事务，而事务期间片选必须一直有效——message 就是"一次完整片选周期"的抽象。spi_write/spi_write_then_read 都是内核在 spi_message/spi_transfer 之上替你组好包的便利封装，日常驱动用封装即可，被追问底层时要能画出 message→transfer 的两层结构。

4.8.3 实例：ICM-20608 六轴 IMU（作者 04_icm-20608 驱动练习）

SPI 协议要点（drv.c:19-20）：寄存器地址最高位区分读写，读要或 0x80：

#define ICM20608_READ_FLAG 0x80

static int icm20608_read_regs(struct spi_device *spi, u8 reg, void *val, int len)
{
	reg |= ICM20608_READ_FLAG;
	return spi_write_then_read(spi, &reg, 1, val, len);  /* 半双工：发地址+读数据 */
}
static int icm20608_write_regs(struct spi_device *spi, u8 reg, u8 val)
{
	u8 buf[2] = { reg, val };                            /* 写不加 0x80 */
	return spi_write(spi, buf, 2);
}

初始化序列是"按数据手册做工程"的典范（drv.c:105-161，原厂例程顺序）：

icm20608_write_regs(spi, PWR_MGMT_1, 0x80);   /* 软复位 */
msleep(50);
icm20608_write_regs(spi, PWR_MGMT_1, 0x01);   /* 唤醒并选陀螺仪 PLL 时钟 */
msleep(20);                                   /* 注释：睡眠中写量程/滤波不生效 */
icm20608_read_regs(spi, WHO_AM_I, &id, 1);    /* 回读 ID 校验 0xaf/0xae（20608D 衍生型号） */
if (id != 0xaf && id != 0xae)
	return -ENODEV;                           /* 芯片不在，拒绝注册 */
icm20608_write_regs(spi, GYRO_CONFIG,  0x18); /* 陀螺仪 ±2000dps */
icm20608_write_regs(spi, ACCEL_CONFIG, 0x18); /* 加速度 ±16g */
icm20608_write_regs(spi, CONFIG,       0x04); /* 陀螺仪 LPF 20Hz */
icm20608_write_regs(spi, ACCEL_CONFIG2,0x04); /* 加速度 LPF 21.2Hz */
icm20608_write_regs(spi, SMPLRT_DIV,   0x00); /* 1kHz 输出速率 */
icm20608_write_regs(spi, PWR_MGMT_2,   0x00); /* 打开全部轴 */

三个面试可讲的工程细节：(1) 复位后必须 msleep 等芯片稳定；(2) 唤醒前配置不生效，顺序不能乱；(3) WHO_AM_I 回读自检，防"总线通但芯片不在"的假成功。

用户态解析也有讲究（作者 icm20608 app）：SPI 寄存器数据是大端的有符号 16 位，要 be16_to_s16() 拼完再换算——加速度 raw×16.0/32768.0（单位 g）、温度 raw/326.8+25（℃）、角速度 raw×2000.0/32768.0（dps）。嵌入式平台上字节序和符号位是最常见的"数据全是乱码"根源，先在应用层验证换算，再考虑搬进内核，是稳妥的调试顺序。

read 一次突发连读 14 字节（drv.c:67-85）：从 ACCEL_XOUT_H(0x3b)|0x80 起一次 spi_write_then_read 读出 accel xyz + temp + gyro xyz。注释解释了为什么不能分七次读："连读期间芯片内部采样保持，保证 7 个 16 位数据属于同一时刻"。

4.8.4 实战坑：和内核内置驱动抢节点

作者驱动注释记载的真实案例（04_icm-20608/drv/drv.c:7-10）：板端内核 .config 启用了 CONFIG_INV_MPU6050_SPI=y，内置的 inv-mpu6050-spi 驱动会抢先绑定这个 SPI 节点（一个设备只能绑一个驱动），你的模块 insmod 后 probe 根本不会执行。解法：

echo spi2.0 > /sys/bus/spi/drivers/inv-mpu6050-spi/unbind   # 先解绑内置驱动
insmod icm20608.ko                                           # 再加载自己的

遇到"模块加载了但 probe 没打印"时，排查顺序：dmesg → 设备树 compatible 是否一致 → ls /sys/bus/spi/devices/spi2.0/driver 看节点被谁占了。

【记忆口诀】
"SPI 读址或 0x80，write_then_read 一次妥；复位延时再唤醒，WHO_AM_I 验正身；十四字节突发读，同一时刻七数据；probe 不响查 unbind，内置驱动抢门口。"

4.9 IIO 子系统

4.9.1 为什么传感器要用 IIO 而不是手写字符设备

手写 misc/cdev 的问题：每个驱动一套私有 read 协议（有的返回二进制、有的返回 ASCII），应用程序要逐个适配，还没有统一的单位、量程、缓冲机制。看作者代码包的三份简要版 app 就能直观感受到：SHTC3 的 app 要按"两个 int32"解析、AP3216C 的 app 直接原样打印 ASCII、ICM-20608 的 app 要手工 be16_to_s16 再套三个不同公式——三颗传感器三种应用写法，全在和私有协议搏斗。IIO（Industrial I/O）是内核为传感器准备的标准子系统，把"通道 + 属性"抽象成统一的 sysfs 接口：

/sys/bus/iio/devices/iio:device0/
├── name                          # 芯片名
├── in_temp_input                 # PROCESSED 通道：直接是物理量（毫℃）
├── in_accel_x_raw                # RAW 通道：原始 ADC/寄存器值
├── in_accel_x_scale              # SCALE：每 LSB 对应的物理量
└── in_temp_offset                # OFFSET：换算偏移

应用只需 cat 这些文件，且物理量 = (raw + offset) × scale 是 IIO 的用户态约定（作者 icm20608_e app.c 注释）。改量程只改驱动 SCALE，应用不用动。

sysfs 属性名的生成规则也值得记住：in_<类型>[_<修饰符>]_<属性>——IIO_TEMP 出 in_temp_*，IIO_ACCEL + IIO_MOD_X 出 in_accel_x_*，IIO_INTENSITY + IIO_MOD_LIGHT_IR 出 in_intensity_ir_*；属性后缀由 info_mask 决定：RAW→_raw、SCALE→_scale、OFFSET→_offset、PROCESSED→_input。看名字就能反推通道声明，这在面试白板题里能帮你快速得分。除本文覆盖的 INDIO_DIRECT_MODE（直接读）外，IIO 还支持触发 buffer 模式（数据就绪中断/定时器触发，连续采样进 ring buffer，应用读 /dev/iio:deviceX），做振动、音频级采样率采集时才需要，了解概念即可。

4.9.2 IIO 驱动五件套（作者 _e 工程版通用骨架）

struct shtc3_data {
	struct i2c_client *client;
	struct mutex lock;
};

static int shtc3_probe(struct i2c_client *client)
{
	struct iio_dev *indio_dev;
	struct shtc3_data *data;

	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data)); /* ① 申请 iio_dev（连私有数据） */
	if (!indio_dev)
		return -ENOMEM;
	data = iio_priv(indio_dev);              /* ② 取私有数据指针 */
	data->client = client;
	mutex_init(&data->lock);
	/* …probe 先试测一次，失败拒绝注册（作者 shtc3_e drv.c:185-191）… */

	indio_dev->name = "shtc3";               /* ③ 填字段 */
	indio_dev->info = &shtc3_info;
	indio_dev->modes = INDIO_DIRECT_MODE;    /* 直接读取模式：无 buffer/trigger */
	indio_dev->channels = shtc3_channels;
	indio_dev->num_channels = ARRAY_SIZE(shtc3_channels);

	return devm_iio_device_register(&client->dev, indio_dev); /* ④ 注册（devm 托管） */
}

⑤ iio_info 只实现一个回调：

static const struct iio_info shtc3_info = { .read_raw = shtc3_read_raw };

4.9.3 iio_chan_spec 通道定义

通道声明三要素：.type（通道类型）→ 决定 sysfs 属性名前缀；.modified + .channel2（修饰符，如 X/Y/Z 轴、红外光）；.info_mask_separate（该通道暴露哪些属性）。作者三个工程版各代表一种用法：

/* SHTC3：PROCESSED 通道（02_shtc3_e/drv/drv.c:157-166）→ in_temp_input / in_humidityrelative_input */
static const struct iio_chan_spec shtc3_channels[] = {
	{ .type = IIO_TEMP,             .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), },
	{ .type = IIO_HUMIDITYRELATIVE, .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), },
};

/* AP3216C：RAW+SCALE 与 modified 通道（03_ap3216c_e/drv/drv.c:39-58）。
 * .address 直接放数据寄存器地址，read_raw 里用 channel->address 取，不用 switch */
	{ .type = IIO_LIGHT,     .address = AP3216C_REG_ALS_DATA_LOW,
	  .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE), },
	{ .type = IIO_PROXIMITY, .address = AP3216C_REG_PS_DATA_LOW,
	  .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), },
	{ .type = IIO_INTENSITY, .modified = 1, .channel2 = IIO_MOD_LIGHT_IR,   /* → in_intensity_ir_raw */
	  .address = AP3216C_REG_IR_DATA_LOW,
	  .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), },

/* ICM-20608：7 通道（04_icm-20608_e）：IIO_ACCEL×3（channel2 = IIO_MOD_X/Y/Z）、
 * IIO_ANGL_VEL×3、IIO_TEMP×1（多 BIT(IIO_CHAN_INFO_OFFSET)），
 * 对应 in_accel_x_raw、in_anglvel_z_scale、in_temp_offset 等 sysfs 属性 */

RAW vs PROCESSED 怎么选？作者 shtc3_e 注释给出判断标准：温度公式含 -45℃ 偏移，IIO 的 offset 只能表达整数，无法精确表达 -45000/65536 这类分数偏移，所以驱动内直接算成毫℃用 PROCESSED 输出；而 AP3216C/ICM-20608 的换算是线性 (raw+offset)*scale，交给 RAW+SCALE 更标准。

4.9.4 read_raw 与返回值约定

static int shtc3_read_raw(struct iio_dev *indio_dev,
			  struct iio_chan_spec const *chan,
			  int *val, int *val2, long mask)
{
	if (mask != IIO_CHAN_INFO_PROCESSED)
		return -EINVAL;
	mutex_lock(&data->lock);
	/* …整次测量，CRC 校验失败返回 -EIO… */
	switch (chan->type) {
	case IIO_TEMP:             *val = temp_millic; break;
	case IIO_HUMIDITYRELATIVE: *val = humi_millirh; break;
	default: mutex_unlock(&data->lock); return -EINVAL;
	}
	mutex_unlock(&data->lock);
	return IIO_VAL_INT;   /* 整数直接放在 *val */
}

返回值约定（面试常考）：IIO_VAL_INT → 值就是 *val；IIO_VAL_INT_PLUS_MICRO → 值 = val + val2/10⁶，用于表达小数 SCALE。作者 ap3216c_e 的固定光照系数（0.315 lx/LSB）：

*val = 0; *val2 = 315000;
return IIO_VAL_INT_PLUS_MICRO;   /* 即 0.315 */

4.9.5 用户态怎么用

# 找设备（名字比对，作者 _e 版 app 的统一做法）
cat /sys/bus/iio/devices/iio:device*/name
cat /sys/bus/iio/devices/iio:device0/in_temp_input        # → 25321 （毫℃）

板子上若装了 libiio 工具集，iio_info 一条命令就能列出每个 IIO 设备的全部通道、属性和当前值，是调试 IIO 驱动的首选工具；iio_readdev/generic_buffer 用于带触发 buffer 的连续采样场景。作者的 icm20608_e 测试程序展示了最规范的应用写法：先遍历 /sys/bus/iio/devices 按 name 找到设备，先读 scale 和 offset 存起来，循环里再读 raw 按 (raw + offset) × scale 换算——应用不写死任何换算系数，驱动以后改量程（比如加速度从 ±16g 调到 ±4g）只需改 SCALE，应用零改动。这就是标准化接口带来的解耦，也是"为什么选 IIO"最有说服力的论据。

【记忆口诀】
"IIO 五件记心间：alloc、priv、填字段、register、read_raw 圆；type 定名 modified 定向，RAW 配 SCALE、PROCESSED 直接上；小数就用 PLUS_MICRO，(raw+offset)×scale 别忘。"

4.10 Regmap

4.10.1 解决什么问题

传感器驱动 80% 的代码是"写寄存器 A、读寄存器 B"。I2C 走 SMBus、SPI 要地址或 0x80，同类芯片换个总线驱动就要重写一遍。regmap 把寄存器读写从总线细节中抽象出来：驱动只面对 regmap_read/write，底下是 I2C 还是 SPI 由初始化决定。它的另外几个好处面试也值得讲：

  1. 寄存器缓存：配置 cache_type 后，写操作先落缓存，掉电/挂起恢复时一键回写（cache_sync），音频编解码器这类几百个寄存器的芯片离开它几乎没法维护；
  2. 越界保护：max_register 设了之后，超出范围的寄存器访问直接报错，把"手滑写错地址打飞芯片配置"挡在 API 层；
  3. 统一调试：每个 regmap 自动在 debugfs 下生成寄存器 dump 接口，cat /sys/kernel/debug/regmap/.../registers 就能看全片寄存器当前值，调试阶段免写私有 dump 命令；
  4. regmap_update_bits 原子读-改-写：改寄存器某几位不用手工"读出-与或-写回"，避免并发下的丢更新。

4.10.2 用法（作者 AP3216C/ICM-20608 工程版）

/* I2C 版（03_ap3216c_e/drv/drv.c:32-36） */
static const struct regmap_config ap3216c_regmap_config = {
	.reg_bits = 8, .val_bits = 8, .max_register = 0x2d,
};
data->regmap = devm_regmap_init_i2c(client, &ap3216c_regmap_config);

/* SPI 版（04_icm-20608_e/drv/drv.c:45-56）——注释：这是和 I2C 模板最大的不同点 */
static const struct regmap_config icm20608_regmap_config = {
	.reg_bits = 8, .val_bits = 8,
	.read_flag_mask = 0x80,      /* SPI 读地址要或 0x80，不设的话读回永远是 0xff */
	.max_register = 0x7e,
};
data->regmap = devm_regmap_init_spi(spi, &icm20608_regmap_config);

之后的读写与总线无关：

regmap_write(data->regmap, AP3216C_REG_SYS_CONFIG, AP3216C_SYS_RESET);
regmap_read(data->regmap, AP3216C_REG_SYS_CONFIG, &value);
regmap_bulk_read(data->regmap, channel->address, raw, 2);            /* 读 16 位数据 */
regmap_update_bits(data->regmap, REG, MASK, NEW_VAL);                /* 读-改-写某些位 */

4.10.3 与 IIO 的搭配

作者工程版的标准组合：iio_chan_spec 的 .address 字段放寄存器地址，read_raw 里 regmap_bulk_read(regmap, channel->address, raw, 2)——7 个通道共用一段 read_raw 代码，不需要 switch-case。工程版还用它做硬件初始化回读确认（ap3216c_e, drv.c:121-157）：使能三路后 msleep(120) 再 regmap_read 回读模式位，(value & 0x07) != AP3216C_SYSTEM_ALS_PS_IR 就返回 -ENODEV——注释原话："避免总线可访问但芯片未真正启动的假成功"。

【记忆口诀】
"regmap 抽总线，I2C、SPI 一嘴脸；SPI 记住 read_flag_mask，0x80 不设全 0xff；read/write/update_bits 三兄弟，缓存 debugfs 白送你。"

4.11 内核资源与并发

4.11.1 devm_ 托管资源：为什么工程版 remove 可以是空的

传统写法的痛：probe 里依次申请 GPIO、内存、IRQ、注册设备，任何一步失败都要手工逆序释放，漏一个就泄漏。devm_（device resource managed）把资源挂在 struct device 上，probe 失败或 remove 返回后由内核自动释放，顺序自动保证正确。作者工程版全套使用：

托管函数 替代
devm_kzalloc kzalloc + kfree
devm_gpiod_get gpio_request + gpio_free
devm_iio_device_alloc/register iio_device_alloc + free/unregister
devm_regmap_init_i2c/spi regmap_init + regmap_exit
devm_request_threaded_irq request_irq + free_irq

作者 user_led_e 的 remove 只剩一行日志，注释自述："所有资源均为 devm_* 托管"。devm 还有个隐藏福利：释放顺序自动正确。手工写法里 remove 要小心翼翼地逆序释放，而 devm 资源挂在设备资源链表上，内核按注册的逆序自动回滚——和 probe 失败时中途退出的清理用的是同一条路径，两套场景一份保证。注意反例：cdev 链（alloc_chrdev_region/cdev_add/class_create/device_create）没有 devm 版本（因其生命周期语义不同），仍需手工逆序清理，所以作者 led_misc_platform_e 的 remove 里那四行 device_destroy/class_destroy/cdev_del/unregister_chrdev_region 一个都不能少。

4.11.2 dev_err_probe 与 -EPROBE_DEFER

驱动 probe 时，它依赖的 GPIO 控制器/时钟/电源可能还没就绪，此时获取资源的函数返回 -EPROBE_DEFER。正确做法是把它原样返回，内核会把设备挂入延迟队列，等依赖就绪后自动重新 probe。dev_err_probe() 一行搞定：是 DEFER 就静默推迟，是真错误才打日志（作者工程版统一用法）：

ldev->gpiod = devm_gpiod_get(dev, "led", GPIOD_OUT_HIGH);
if (IS_ERR(ldev->gpiod))
	return dev_err_probe(dev, PTR_ERR(ldev->gpiod), "获取 led-gpios 失败\n");

4.11.3 mutex 在驱动中的使用

多个进程可能同时 open 你的设备并发 read/write；传感器一次测量又涉及多笔总线传输，必须整笔互斥，否则两个进程的传输交错，数据就串了。作者工程版的统一模式：

struct xxx_data { struct mutex lock; ... };      /* probe: mutex_init(&data->lock); */

mutex_lock(&data->lock);          /* 可能睡眠，进程上下文才能用 */
/* …唤醒→测量→读回，整次操作… */
mutex_unlock(&data->lock);

规则：进程上下文用 mutex；中断上下文不能睡眠，用 spinlock；两者混用时上 spin_lock_irqsave。作者 led_misc_platform_e 注释的态度值得学习："本驱动只有一根 GPIO 作用有限，但多寄存器设备上 read/write 可能被多个进程并发调用，养成加锁习惯可避免日后扩展时引入竞态。"

4.11.4 内核里不能做的事（面试送分/送命题，逐条都要会解释原因）

  1. 不能用浮点：内核不保存 FPU 上下文。用定点数（作者 SHTC3 毫℃公式用 64 位整数）、IIO 的 val+val2 分数表示；
  2. 栈极小（8~16KB）：不能开大数组、不能深递归，大缓冲区用 kmalloc；
  3. 不能直接访问用户地址：必须 copy_to_user/copy_from_user/simple_read_from_buffer，否则缺页即 oops；
  4. 不能随便睡眠：持有自旋锁、中断上下文、原子上下文里禁止 msleep/mutex/copy_*_user，只能用 mdelay/自旋锁/GFP_ATOMIC；
  5. 没有 C 库：printf→printk，malloc→kmalloc/vmalloc，字符串函数内核有自己的一套。

【记忆口诀】
"devm 一挂不用还，probe 失败内核担；EPROBE_DEFER 别吃掉，dev_err_probe 再交还；互斥锁进程上下文，中断自旋莫睡眠；浮点大栈用户指针，内核三禁记心间。"

4.12 中断与其他机制

说明：作者代码包 11 个驱动均无中断实例（全部轮询读取，ICM-20608 工程版甚至显式写 INT_ENABLE=0x00 关闭数据就绪中断，注释："本驱动只轮询读数，不申请中断"）。本节为标准范例讲解。

4.12.1 中断上下半部与 request_threaded_irq

中断处理函数运行在中断上下文：不能睡眠、要快——因为你占着中断线，处理得越久，系统对其他中断的响应就越差，网络丢包、串口丢字节往往就是慢的中断处理函数害的。但传感器数据处理往往要 I2C/SPI 读寄存器（总线传输内部会睡眠等待完成）。矛盾由顶半部/底半部解决：顶半部（hard IRQ）只做最紧急的事（清中断标志），把慢活交给底半部。这是"中断快"与"干活慢"这对永恒矛盾的标准答案。现代内核最推荐的底半部形式是线程化中断：

static irqreturn_t xxx_irq_thread(int irq, void *data)
{
	/* 内核线程上下文：可以睡眠，可以 i2c_transfer */
	regmap_read(...);
	return IRQ_HANDLED;
}

ret = devm_request_threaded_irq(dev, irq,
	NULL,                /* 顶半部为 NULL → 默认只做唤醒线程 */
	xxx_irq_thread,      /* 底半部：线程化处理 */
	IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
	"xxx", data);

设备树配合：interrupt-parent = <&gpio1>; interrupts = <3 IRQ_TYPE_EDGE_FALLING>;，驱动里 irq = gpiod_to_irq(gpiod) 或 platform_get_irq(pdev, 0)。

4.12.2 其他常用机制速览

  • 工作队列（workqueue）：把活推迟到内核线程做，INIT_WORK(&work, fn) + schedule_work(&work)，工作函数运行在进程上下文、可以睡眠。与线程化中断的关系：线程化中断是"中断专属的工作队列"，新代码优先用它；tasklet/软中断则是更老的底半部机制，运行在中断上下文不能睡眠，维护老代码时认识即可，新驱动不要再用 tasklet；
  • 等待队列（wait queue）：阻塞读的核心。wait_event_interruptible(wq, flag) 睡到条件满足；数据到了在中断/线程里 wake_up(&wq)。阻塞式 read 的标准实现；
  • poll：实现 fops->poll，里面 poll_wait(filp, &wq, wait) 把进程挂到等待队列（注意 poll 本身不睡眠，它只是登记），然后按数据是否就绪返回 EPOLLIN|EPOLLRDNORM 等掩码，用户态 select/poll/epoll 即可用。poll 与等待队列是配套出现的：等待队列负责"睡与醒"，poll 负责"告诉用户态现在值不值得读"；
  • ioctl：设备私有命令通道（如设置量程）。约定用 _IOR/_IOW/_IOWR 宏生成命令号，驱动里 unlocked_ioctl 按 cmd switch，参数用 copy_from/to_user 搬运。

【记忆口诀】
"顶半部救火底半部搬家，线程化中断能睡觉；等待队列睡条件，wake_up 一声数据到；poll 挂队列返掩码，ioctl 命令 _IOR 造。"

4.13 驱动调试与验证

4.13.1 编译部署三级 Makefile（作者代码包实测结构）

作者每个驱动目录统一三级：顶层 Makefile（定 modulename/appname，分别进 drv/ 和 app/ 构建）→ drv/Makefile（obj-m 外挂模块，make -C 内核树 M=$PWD modules）→ app/Makefile（交叉编译测试程序，arm-linux-gnueabihf-gcc app.c -o <modulename>_app）。make install 把 .ko 和测试程序一起拷进 NFS 根文件系统 ~/nfs/rootfs/lib/modules/6.12.34，开发板通过 NFS 挂载根文件系统，改驱动→make install→板上 insmod，全程不用重烧固件。开发新驱动的流程：复制模板目录 → 改 modulename → 写 drv.c/app.c → make install 上板测。

NFS 根文件系统是驱动开发效率的分水岭，值得展开说：传统流程每次改代码都要重新打包烧写 rootfs（动辄几分钟），而 NFS 方式下 PC 上 make install 拷完文件，开发板那边立刻就能 insmod——一次迭代从分钟级压到秒级，一天下来多试几十轮。搭建方法属于移植篇内容（uboot 环境变量 bootargs 指定 root=/dev/nfs nfsroot=...），这里只需记住结论：驱动开发阶段，NFS 挂载根文件系统是标配。作者模板还有个贴心细节：drv/Makefile 里 $(modulename)-objs := drv.o，源码文件固定叫 drv.c 不用随模块改名，复制模板时只需改顶层 Makefile 的 modulename 一个变量。

4.13.2 加载验证标准流程

insmod user_led.ko                 # 1. 加载
dmesg | tail                       # 2. 看 probe 打印："probe ok, major=..., /dev/xxx"
cat /proc/devices                  # 3. cdev 版看主设备号是否注册成功
ls -l /dev/user_led                # 4. 设备节点是否自动生成
./user_led_app                     # 5. 用户态程序读写验证
rmmod user_led                     # 6. 卸载，dmesg 应看到 remove 打印（注意不带 .ko）

排错速查：insmod 报 "Invalid module format" → .ko 与板端内核版本不一致（作者 Makefile 里 NFS_MOD 路径带 6.12.34 就是为了版本对齐，modinfo 里的 vermagic 字段可核对）；没有 /dev 节点 → class_create/device_create 漏了或 mdev 没跑，可手工 mknod 临时验证；probe 没执行 → compatible 不匹配或节点被别人绑定（见下）。

卸载纪律同样重要：rmmod 之前确认没有进程占着设备（否则 refcnt 不为 0 卸不掉），remove 里把硬件恢复到安全状态——作者的 LED 驱动 remove 先关灯、OLED 驱动 remove 发关显示命令"避免屏幕保持最后一帧耗电"、SHTC3 工程版 remove 发 SLEEP 让芯片回低功耗。remove 是驱动工程素养的照妖镜：只写 probe 不写 remove 的驱动，在反复 insmod/rmmod 调试几轮之后资源泄漏、GPIO 状态混乱，问题会层出不穷。

4.13.3 实战案例：与内置驱动冲突的处理

作者 ICM-20608 的真实经历（04_icm-20608/drv/drv.c:7-10 注释）：板端内核开了 CONFIG_INV_MPU6050_SPI=y，内置驱动抢先绑定 SPI 节点。一个设备只能绑一个驱动，所以你的 probe 永远不被调用。处理：

# 查看节点当前绑定的驱动
ls -l /sys/bus/spi/devices/spi2.0/driver
# 解绑内置驱动
echo spi2.0 > /sys/bus/spi/drivers/inv-mpu6050-spi/unbind
# 再加载自己的模块
insmod icm20608.ko

一个设备只绑一个驱动这条规则还能解释面试题"probe 不执行的排查思路"：compatible 拼写、设备树 status、节点已被绑定、-EPROBE_DEFER 卡在依赖未就绪（cat /sys/kernel/debug/devices_deferred 可查看）。

4.13.4 其他顺手调试手段

  • ls /sys/bus/i2c/devices/、i2cdetect -y 1：确认 I2C 从机是否真的应答（作者 SSD1306 的 0x3C 地址就是 i2cdetect 实测出来的）；
  • cat /sys/kernel/debug/gpio：确认 GPIO 被谁申请、方向与电平；
  • 模块参数：module_param(debug, int, 0644) 给驱动加可调开关，insmod 时 insmod xxx.ko debug=1 控制日志量；
  • 动态调试：echo 'file drv.c +p' > /sys/kernel/debug/dynamic_debug/control 按文件打开 pr_debug，不用重编译。

4.13.5 IIO 设备验证

cat /sys/bus/iio/devices/iio:device*/name      # 逐个比对找自己的设备
cat /sys/bus/iio/devices/iio:device0/in_temp_input

作者 SHTC3 工程版 probe 成功打印 SHTC3 就绪：%d.%03d ℃, %d.%03d %%RH——probe 里先试测一次再注册的习惯，让"驱动加载成功"与"硬件真的能用"画上等号，这是值得在面试里主动讲的工程素养。

【记忆口诀】
"obj-m 外挂 M= 指路径，NFS 一拷免烧录；insmod、dmesg、/proc/devices、ls /dev、app 五步验；probe 不响先查谁绑定，unbind 让位再 insmod。"

4.14 面试高频问答

1. 字符设备驱动的完整注册流程是什么？
alloc_chrdev_region 动态申请设备号 → cdev_init 绑定 file_operations → cdev_add 注册进内核 → class_create 创建设备类 → device_create 触发 udev/mdev 自动生成 /dev 节点。每步失败按逆序 goto 回滚；remove 严格逆序：device_destroy → class_destroy → cdev_del → unregister_chrdev_region，且先删节点再注销 cdev，保证节点消失后没有新的 open 进来。

2. 主设备号和次设备号的作用？
主设备号标识"哪一类设备/哪个驱动"，内核按它从 inode 找到对应 cdev；次设备号标识同类中的第几个实例，驱动用它区分多路硬件。dev_t 高 12 位主、低 20 位次，用 MKDEV/MAJOR/MINOR 操作。

3. misc 设备和 cdev 完整框架怎么选？
misc 主设备号固定 10、一行 misc_register 同时完成设备号分配与节点创建，适合简单小驱动快速验证；但只有一个动态次设备号，扩展 ioctl/llseek/poll 不直观。正式产品接口、多实例、需自定义 ioctl 时用 alloc_chrdev_region + cdev 完整链（作者 led 驱动两版对照的设计初衷）。

4. platform 总线模型为什么存在？
解耦"硬件描述"与"驱动逻辑"：设备（或设备树节点）只描述资源，驱动只描述操作，总线负责 match 配对。换板子只改设备树不改驱动；同一驱动可匹配多个同类设备。没有物理总线的 SoC 片上设备挂在虚拟的 platform 总线上。

5. probe 什么时候被调用？
三个时机：驱动注册时总线上已有匹配设备；设备注册/设备树解析时已有匹配驱动；模块后加载时总线遍历未配对设备逐一 match。匹配按 of_match_table（设备树 compatible）→ id_table → name 字符串的优先级。返回 -EPROBE_DEFER 会在依赖就绪后被重新调用。

6. 设备树和驱动是怎么匹配上的？
内核启动时 dtc 编译出的 dtb 被解析，节点生成 device_node，platform/i2c/spi 子系统据此创建设备；总线 match 函数拿节点 compatible 字符串列表逐项与驱动 of_match_table 比对，专有在前兼容在后，先命中先匹配，命中即调 probe。MODULE_DEVICE_TABLE(of, ...) 导出别名供 udev 按 modalias 自动加载模块。

7. 为什么用设备树，而不是把硬件参数写在驱动里？
硬件参数（GPIO 号、寄存器地址、中断号、时钟）与板级相关、与驱动逻辑无关。写死在驱动里，换板子要改源码重新编译；放设备树里，内核同一镜像可支持多块板，只换 dtb。还避免驱动代码里到处是魔数。

8. devm_ 系列函数有什么好处？
资源托管到 struct device：probe 中途失败或 remove 返回后，内核自动按正确顺序释放，不用手写逆序清理，彻底消灭"漏 free"泄漏。工程版驱动的 remove 因此可以接近为空。注意 cdev 注册链没有 devm 版，仍需手工回滚。

9. -EPROBE_DEFER 是什么？怎么处理？
probe 时依赖的资源（GPIO 控制器、时钟、电源）尚未就绪，获取函数返回 -EPROBE_DEFER。驱动应原样返回它，内核把设备挂入延迟队列稍后重试 probe。用 dev_err_probe() 打印日志：DEFER 静默处理，真错误才输出，避免刷假错误日志。

10. copy_to_user 为什么不能直接 memcpy？
用户空间指针在内核中不可信：可能非法、可能未映射（缺页）、可能被换出。直接 memcpy 会触发内核 oops 甚至提权漏洞。copy_to_user/copy_from_user 会做地址校验并安全处理缺页，失败返回 -EFAULT。read 路径推荐 simple_read_from_buffer，它顺带处理文件偏移与 EOF 语义。

11. 传感器驱动用 IIO 还是手写字符设备？
标准是 IIO：统一 sysfs 接口（in_xxx_raw/scale/offset/input），应用按 (raw+offset)×scale 换算，不用适配每个驱动的私有协议，还白得缓冲、触发、校准生态。手写 misc/cdev 适合教学和极简单的执行器（如单颗 LED）。换算含无法整数表达的偏移时（如 SHTC3 的 -45℃）用 PROCESSED 通道直接输出物理量。

12. regmap 的作用是什么？
把寄存器读写从总线细节抽象出来：regmap_init_i2c/spi 之后统一 regmap_read/write/update_bits，驱动不关心底下是 SMBus 还是 SPI（SPI 记得设 read_flag_mask=0x80）。附带寄存器缓存、max_register 越界检查、debugfs dump。与 IIO 搭配时把寄存器地址放进 iio_chan_spec.address，多通道共用一段 read_raw。

13. 内核里为什么不能用浮点？怎么替代？
内核切换任务时不保存 FPU 寄存器，内核态用浮点会破坏用户态 FPU 状态。替代：定点数（结果放大 1000 倍用 64 位整数算，如毫℃、毫%RH）、IIO 的 IIO_VAL_INT_PLUS_MICRO 分数表示。用户态 app 拿到整数再除以 1000.0 显示。

14. 中断的顶半部和底半部是什么？现在推荐怎么做？
顶半部（hard IRQ）在中断上下文执行，不能睡眠，只做清中断标志等紧急操作；慢活（如 I2C/SPI 读数据）交底半部。传统底半部有软中断/tasklet/工作队列，现代驱动推荐线程化中断 devm_request_threaded_irq：处理函数运行在内核线程上下文，可以睡眠、可以直接做总线传输，还能被调度器正常管理优先级。

15. insmod 后 probe 没有执行，怎么排查？
按序排查：① dmesg 看有没有匹配失败或 dev_err_probe 日志；② 设备树 compatible 与 of_match_table 是否逐字符一致、status 是否 okay；③ ls /sys/bus/<bus>/devices/<dev>/driver 看节点是否已被内置驱动绑定——一个设备只绑一个驱动，被占就 echo <dev> > .../unbind 再加载（作者 ICM-20608 被 inv-mpu6050-spi 抢占的真实案例）；④ cat /sys/kernel/debug/devices_deferred 看是否因依赖未就绪挂在延迟队列。

本篇小结

驱动开发的全部心法可以压缩成一条主线：硬件信息交给设备树，驱动只写匹配表和操作逻辑；注册接口按设备类型选 misc/cdev/IIO/LED class，能借内核标准子系统就不自造轮子；资源一律 devm 托管、错误一律检查、并发一律加锁、硬件一律自检（WHO_AM_I/回读/CRC）。作者这套"简要版 vs 工程版"对照代码就是最好的学习路径：先用 misc 版把最短路径跑通建立信心，再对照工程版理解每一层抽象（gpiod、regmap、IIO、devm）究竟解决了什么具体痛点——知其然且知其所以然，面试自然水到渠成。

第5篇 硬件总线与通信协议（UART / I2C / SPI / CAN）

本篇定位：嵌入式面试"协议拷打"的弹药库。假设你连"CAN 是什么"都没听说过，我们从"两根线上怎么把 0 和 1 送过去"讲起，一路讲到面试官追问 CAN Bus-off 状态机也不慌。文中大量结合作者的智能车项目（MQTT→Linux→SocketCAN 500kbps→STM32F407→电机主链路，UART 串口终端与 ESP8266，I2C 挂 SHTC3/AP3216C/SSD1306，SPI 挂 ICM20608），请把这些当成你简历上能讲的故事。

5.1 串行通信总览

5.1.1 串行 vs 并行：一根线排队过 vs 八根线并排过

想象搬 8 箱水过一扇门：

  • 并行通信：开 8 扇门，8 个人一人一箱同时过——一次传 8 位。快，但要 8 根数据线，线间还会互相串扰，距离稍长就"有人先到有人后到"（时钟偏移 skew），老打印机并口就是这么被淘汰的。
  • 串行通信：只开 1 扇门，8 箱水排队一箱一箱过——一次传 1 位，8 次传完一个字节。省线、抗干扰、能跑远，现代高速接口（USB、PCIe、SATA）反而全是串行，因为把单根线的速度做上去比把 8 根线对齐容易得多。

嵌入式世界里，UART/I2C/SPI/CAN 全部是串行总线，它们的区别只在"几根线、怎么同步、谁能说话"。

【记忆口诀】并行怕不齐，串行靠提速；线少跑得远，嵌入皆串行。

5.1.2 单工 / 半双工 / 全双工

用对讲机和电话来记：

模式 生活类比 数据流向 典型代表
单工（Simplex） 收音机、广播 永远只有一个方向 老式红外遥控、广播
半双工（Half-Duplex） 对讲机："说完请回答，over" 双向但同一时刻只能一方说 RS485、I2C、CAN
全双工（Full-Duplex） 打电话：可以同时互相喊 双向同时进行 UART（TX/RX 分开）、SPI（MOSI/MISO 分开）

注意一个面试陷阱：SPI 是全双工（MOSI、MISO 各一根线，收发同时），而 I2C 是半双工（只有一根 SDA，主从轮流用）。CAN 也是半双工——同一时刻总线上只有一帧在飞。

【记忆口诀】对讲半双工，电话全双工，广播是单工；SPI 双车道，I2C 独木桥。

5.1.3 同步 vs 异步：有没有专门的"节拍线"

  • 同步通信：有一条专门的时钟线，接收方跟着时钟沿采样数据。I2C 的 SCL、SPI 的 SCLK 就是时钟线。像军训走方阵：教官喊"一二一"（时钟），大家踩着点迈步（数据）。
  • 异步通信：没有时钟线，双方事先约定好速度（波特率），靠数据帧里的"起始位"来对表。UART、CAN 都是异步（CAN 靠位填充+再同步维持节拍，见 5.6）。像两个人约好"每秒击掌一次"，但其中一人要先拍手示意"开始了"。

【记忆口诀】同步带钟表（SCL/SCLK），异步先约好（波特率+起始位）。

5.1.4 波特率与比特率

  • 比特率（bit rate）：每秒传多少个二进制位，单位 bps。
  • 波特率（baud rate）：每秒传多少个"符号"。若一个符号只表示 1 位（UART 就是这样），波特率 = 比特率；若用调制技术一个符号携带多位（如 QAM），两者不等。

嵌入式面试里 99% 的场景二者相等，所以常混用。但要会算"有效吞吐量"：UART 传 1 字节实际要发 10 位（1 起始位 + 8 数据位 + 1 停止位），所以 115200 bps 的实际字节率约 11520 B/s ≈ 11.5 KB/s，一个字节约 87 µs。面试常考。

【记忆口诀】波特是符号，比特是位数；UART 一符一位，两率相等；一字节十位走，吞吐打八折。

5.1.5 TTL / RS232 / RS485 电平对比（表格必背）

同样的 UART 波形，用不同电压表示 0/1，就是不同的"电气标准"：

特性 TTL（UART 裸电平） RS232 RS485
逻辑 1 电平 3.3V/5V（高电平） -3V ~ -15V（负电压表示 1！） A-B 压差 -2V ~ -6V
逻辑 0 电平 0V +3V ~ +15V A-B 压差 +2V ~ +6V
信号形式 单端（对地） 单端（对地） 差分（A、B 两线压差）
传输距离 板内，< 1 米 约 15 米 可达 1200 米
速率 常用 115200，可到几 Mbps 通常 ≤ 115200 最高约 10 Mbps（距离换速率）
组网 点对点 点对点 总线式多机（最多 32/128 节点）
双工 全双工（TX/RX 分开） 全双工 半双工（需方向控制）
抗干扰 弱 一般 强（差分抵消共模干扰）

三个要点：

  1. RS232 是负逻辑：1 用负电压表示，和 TTL 正好反相，所以 TTL 直连 RS232 必须过 MAX3232 之类电平转换芯片，否则不仅读反，±12V 还可能烧 MCU。
  2. RS485 只是电气层标准，上面跑的通常还是 UART 帧（最常见是 Modbus-RTU 协议）。
  3. 差分抗干扰原理：干扰同时加到 A、B 两根线上（共模干扰），接收端只看差值，干扰被抵消。CAN 用差分也是同理。

【记忆口诀】TTL 板内跑，二三二负逻辑十五米，四八五差分半双工、千米总线挂一片。

5.2 UART：最简单也最常被拷打的异步串口

5.2.1 是什么

UART（Universal Asynchronous Receiver/Transmitter，通用异步收发器）是 MCU 上最古老、最百搭的外设：两根线（TX 发、RX 收，交叉连接），共地，双方事先约好波特率，就能互相发字节。作者的智能车项目里，UART 有两个典型用途：一是接 USB 转串口做调试终端（printf 重定向、shell），二是接 ESP8266 WiFi 模块发 AT 指令上云。

它常被称为"串口"，但注意"串口"是俗称，严格说 UART 是异步串行协议的一种。

5.2.2 帧结构：逐位解剖

UART 空闲时线路保持高电平。发送一个字节的完整过程（以 8-N-1 为例）：

空闲    ┌─────┐
        │起始位│ D0  D1  D2  D3  D4  D5  D6  D7 ┌──────┐
────────┘(低) └──┴──┴──┴──┴──┴──┴──┴──┘ 停止位 └────────
        告诉对方"开始了"   8 个数据位（LSB 先发）   (高)回到空闲

逐位讲解：

  1. 空闲位：线路默认高电平。这个"默认高"很关键——它是后面起始位能被识别的前提。
  2. 起始位（Start Bit）：发送方把线拉低 1 个位时间。接收方检测到"高→低"跳变，就知道一帧开始了，从此刻开始按约定波特率计时，在每个位的中间时刻采样。起始位就是异步通信里唯一的"对表信号"。
  3. 数据位（Data Bits）：5~9 位，最常用 8 位。低位在前（LSB first）——比如发 0x55（0101 0101），线上先发的是 bit0=1。面试画波形题千万别画反。
  4. 校验位（Parity，可选）：1 位，用于检错。奇校验=让"数据位+校验位"中 1 的个数为奇数；偶校验=为偶数。只能发现奇数个位翻转，检错能力很弱，所以实际项目里常选 N（无校验），把校验交给上层协议。
  5. 停止位（Stop Bit）：1 位（或 1.5/2 位）高电平，表示一帧结束，给双方喘息时间，也让线路回到"空闲高"，为下一帧的起始位下降沿做准备。

115200-8-N-1 的含义：波特率 115200，8 个数据位，No parity 无校验，1 个停止位。这是嵌入式世界的事实标准配置，调试终端、ESP8266 AT、GPS 模块默认几乎都是它。

【记忆口诀】空闲挂高电，拉低是起点；数据低位先，校验可加检；拉高来收尾，一帧十位整。

5.2.3 波特率误差容忍：为什么双方差一点也能通

UART 没有时钟线，双方各自用自己的时钟分频出"波特率"。如果一边实际 115200、另一边实际 116000，误差会不会积累到读错？

分析：接收方在起始位下降沿对表，之后在每位中点采样。一帧 10 位，误差积累到最后一个数据位采样时约为 9.5 个位时间的偏差。只要采样点没偏出"半个位"，就不会读错。所以单端允许误差约 ±2%~±2.5%，两端加起来（两边都有误差）要求总误差 < 4%~5%。

工程结论：用内部 RC 振荡器（如 STM32 的 HSI，温漂大）跑高波特率有风险，正式产品用外部晶振（HSE）；115200 及以下一般没问题。

【记忆口诀】起点对一次表，十步之内别跑偏；单边容差百分之二，晶振不稳波特难。

5.2.4 硬件流控 RTS/CTS

问题：发送方发得飞快，接收方缓冲区满了来不及处理，数据就丢了。怎么办？

硬件流控用两根额外的线（除了 TX/RX/GND）：

  • RTS（Request To Send，请求发送）：本方输出，"我这边的缓冲区还有空，你可以发"。
  • CTS（Clear To Send，允许发送）：本方输入，看到对方拉高才发。

接法同样是交叉：A 的 RTS 接 B 的 CTS。接收方快满时拉低自己的 RTS，对方 CTS 变低就暂停发送。与之对应的是软件流控（XON/XOFF，用 0x11/0x13 字符在线内控制，容易和二进制数据冲突）。实际项目里多数场景速率不高、协议层有应答，流控常省略，但面试要会说。

【记忆口诀】R 是"我准收"，C 是"你准发"；缓冲区要满，拉低喊停它。

5.2.5 RS485 的差分与方向控制

RS485 在 UART 之上只换了电气层：UART 的 TX/RX 经过 MAX485 这类收发器变成 A/B 差分对。两个新增考点：

  1. 方向控制：RS485 半双工，收发器有 DE（发送使能）和 /RE（接收使能）引脚。MCU 要发数据前先拉高 DE（发完拉低回到接收态）。切方向的时机是经典 bug 源：最后一个字节还没完全移出就拉低 DE，帧尾被截断。正确做法是等"发送完成中断（TC）"而不是"数据寄存器空中断（TXE）"再切方向。
  2. 多机总线与终端匹配：一条 485 总线可挂几十个节点，靠地址字节区分（Modbus 从机地址）。长距离时两端加 120Ω 终端电阻防反射——和 CAN 的终端电阻是同一个道理（见 5.6）。

【记忆口诀】四八五，差分线；先使能，再发言；发完等 TC，方向再还原；总线两头，电阻一百二。

5.2.6 Linux 串口编程：termios 完整示例

Linux 下串口是设备文件 /dev/ttyS*（板载）、/dev/ttyUSB*（USB 转串口）、/dev/ttyAMA*//dev/ttymxc*（ARM 板）。配置全靠 termios 结构体，面试可能让你口述流程：open → tcgetattr 取旧配置 → 改 → tcsetattr 生效 → read/write。

/* uart_demo.c — Linux termios 串口配置完整示例 */
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <termios.h>

int uart_open_115200_8N1(const char *dev)
{
    /* O_NOCTTY: 不把串口变成本进程的控制终端；O_NDELAY/阻塞模式按需求选 */
    int fd = open(dev, O_RDWR | O_NOCTTY);
    if (fd < 0) { perror("open"); return -1; }

    struct termios opt;
    tcgetattr(fd, &opt);            /* 1. 先读出当前配置，在其基础上改 */

    cfsetispeed(&opt, B115200);     /* 2. 输入波特率 */
    cfsetospeed(&opt, B115200);     /*    输出波特率 */

    /* 3. 控制标志：8 数据位、无校验、1 停止位、无硬件流控 */
    opt.c_cflag &= ~CSIZE;
    opt.c_cflag |= CS8;             /* 8 位数据 */
    opt.c_cflag &= ~PARENB;         /* 无校验 */
    opt.c_cflag &= ~CSTOPB;         /* 1 位停止位 */
    opt.c_cflag &= ~CRTSCTS;        /* 关闭 RTS/CTS 硬件流控 */
    opt.c_cflag |= (CLOCAL | CREAD);/* 忽略 modem 控制线 + 使能接收 */

    /* 4. 原始模式：关闭回显、规范模式、信号字符、软件流控 */
    opt.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
    opt.c_iflag &= ~(IXON | IXOFF | IXANY);
    opt.c_iflag &= ~(ICRNL | INLCR | IGNCR);  /* 不做回车换行转换 */
    opt.c_oflag &= ~OPOST;          /* 输出不做处理 */

    /* 5. 读超时控制：VMIN=0, VTIME=1 → 最多等 0.1s，收不到就返回 */
    opt.c_cc[VMIN]  = 0;
    opt.c_cc[VTIME] = 1;

    tcflush(fd, TCIFLUSH);          /* 清掉残留输入 */
    tcsetattr(fd, TCSANOW, &opt);   /* 6. 立即生效 */
    return fd;
}

int main(void)
{
    int fd = uart_open_115200_8N1("/dev/ttyUSB0");
    if (fd < 0) return 1;

    /* ESP8266 AT 指令测试：发 "AT\r\n"，应回 "OK" */
    write(fd, "AT\r\n", 4);

    char buf[128];
    int n = read(fd, buf, sizeof(buf) - 1);
    if (n > 0) { buf[n] = '\0'; printf("recv: %s\n", buf); }

    close(fd);
    return 0;
}

要点口述版：tcgetattr 拿旧属性、cfsetispeed/cfsetospeed 设波特率、c_cflag 里用 CS8/PARENB/CSTOPB/CRTSCTS 拼帧格式、c_lflag 关回显和规范模式进 raw、VMIN/VTIME 控制 read 阻塞行为、最后 tcsetattr(TCSANOW) 生效。记不住全部没关系，能讲出"先读后改再生效"的结构和 8N1 怎么拼就够过面试。

【记忆口诀】先 get 后 set，标志位里拼 8N1；raw 模式关回显，VMIN VTIME 管超时。

5.2.7 调试工具：minicom / screen

作者在 Linux 开发板上调 ESP8266 和串口终端时的日常命令：

# screen：最轻量，参数直接是 设备 波特率
screen /dev/ttyUSB0 115200
# 退出：先按 Ctrl+A，松开，再按 K，确认 y（面试常问"screen 怎么退出"）

# minicom：功能全，-D 指定设备 -b 指定波特率
minicom -D /dev/ttyUSB0 -b 115200
# 退出：Ctrl+A 再按 X；进设置菜单：Ctrl+A 再按 O

# 纯命令行快速看数据（无需交互工具）
cat /dev/ttyUSB0 &
echo -e "AT\r" > /dev/ttyUSB0

权限问题：串口属 dialout 组，普通用户先 sudo usermod -aG dialout $USER 重新登录，免去每次 sudo。

5.2.8 ESP8266 AT 指令简介

ESP8266 是经典 WiFi 模块，MCU 通过 UART 发文本指令控制它联网，指令集叫 AT 指令（AT 即 Attention，源自调制解调器时代）。流程类比"发短信指挥一个帮你上网的小弟"：

AT                          → 握手测试，回 OK（不通就查线/波特率）
AT+GMR                      → 查固件版本
AT+CWMODE=1                 → 设 Station 模式（连别人家路由器）
AT+CWJAP="ssid","password"  → 连 WiFi，回 WIFI CONNECTED / GOT IP
AT+CIPSTART="TCP","broker地址",1883 → 建立 TCP 连接（比如连 MQTT 代理）
AT+CIPSEND=4                → 准备发 4 字节，收到 ">" 后吐数据
AT+CIPCLOSE                 → 关闭连接

三条面试要点：① 指令以 \r\n 结尾，模块回复也以 \r\n 包裹；② 智能车项目里可以让 STM32 或 Linux 通过 AT 指令把传感器数据经 TCP/MQTT 推上云；③ 透传模式（AT+CIPMODE=1 + AT+CIPSEND）后串口变成"透明管道"，MCU 无需逐条发指令。

【记忆口诀】AT 先问好，MODE 选角色，JAP 连路由，START 建连接，SEND 吐数据。

5.3 I2C：两根线的"总线制"通信

5.3.1 是什么：靠"地址"找人的对讲系统

I2C（Inter-Integrated Circuit，读作 "I-squared-C"）是 Philips 提出的板级芯片间总线。只用两根线就能挂一整排芯片，靠"地址"区分彼此——像一个大办公室只装一部对讲机，每个人喊话前先喊对方工号（地址），被叫到的人才回应（ACK）。作者的智能车项目里，同一条 I2C 总线上挂了三个从机：SHTC3 温湿度传感器、AP3216C 光照/接近传感器、SSD1306 OLED 屏，它们地址不同，互不干扰。

两根线：SDA（串行数据线，传数据）+ SCL（串行时钟线，主机产生）。I2C 是同步、半双工、多主多从、总线式结构。

5.3.2 物理层：开漏 + 上拉，为什么？

I2C 所有器件的 SDA/SCL 引脚都是开漏（Open-Drain）输出：内部只有一个接地的 NMOS，器件要么"把线拉低到 0"，要么"松手不管（高阻）"——它自己永远无法输出高电平。高电平全靠总线上的一对上拉电阻（典型 4.7kΩ，接 3.3V/5V）把线"吊"上去。

为什么这样设计？三个层层递进的理由，面试常连环追问：

  1. 防短路：如果都用推挽输出，一个器件输出高、另一个输出低，两管直通，大电流烧片。开漏结构下谁都不可能"主动推高"，冲突不存在。
  2. 线与（Wired-AND）：线上任何一个器件拉低，整条线就是低；只有所有器件都松手，线才被上拉为高。逻辑上 = 所有器件输出的"与"。这个特性是 I2C 两大高级功能的物理基础：
    • ACK 应答：主机发完数据松手，从机在第 9 个时钟把 SDA 拉低表示"收到"；
    • 多主仲裁：两个主机同时发，谁发了 1 却读到 0，就知道"有人和我抢"，自动退出（见 5.3.7）。
  3. 电平兼容：上拉电阻接到哪个电压，总线高电平就是哪个电压，3.3V 主机和 5V 器件可以挂同一条总线（配上拉电平选择或电平转换）。

【记忆口诀】开漏只会拉低，上拉负责吊高；你低我低大家低（线与），全松手才是高；不怕撞车能应答，还能现场来仲裁。

上拉电阻取值也是考点：太大会导致上升沿慢（RC 充电，总线电容大时波形变成斜坡，高速下出错）；太小则灌电流大、功耗高。400kHz 常用 2.2k~4.7kΩ。

5.3.3 器件地址：7 位与 10 位

  • 7 位地址（主流）：器件出厂固化部分 + 部分引脚可配。比如 SHTC3 固定 0x70；AP3216C 固定 0x1E；SSD1306 常见 0x3C/0x3D（一根引脚选）。挂总线时地址不能撞车。
  • 线上实际传的是 1 个字节 = 7 位地址 + 1 位方向位（0=写 W，1=读 R）。所以"SHTC3 的写地址 0xE0、读地址 0xE1"这种说法，本质是 0x70<<1 | W/R。面试问"7 位地址最大多少个从机"：理论 128 个，扣掉保留地址约 112 个可用。
  • 10 位地址：地址不够用时扩展，用两个字节装地址，实际项目很少见，知道有这回事即可。

【记忆口诀】七位工号一位向，左移一位带上读写；0x70 是工号，0xE0 写、0xE1 读。

5.3.4 起始/停止条件与数据有效性

四条基本规则，是看懂一切 I2C 波形的地基：

  1. 起始条件 START（S）：SCL 高电平期间，SDA 从高跳变到低。——"上课铃响"。
  2. 停止条件 STOP（P）：SCL 高电平期间，SDA 从低跳变到高。——"下课铃响"。
  3. 数据有效性：SCL 低电平期间 SDA 才允许变化（发送方摆好数据），SCL 高电平期间 SDA 必须稳定（接收方采样）。即"低电平换数据，高电平读数据"。
  4. START 和 STOP 是仅有的两个"SCL 高时 SDA 变化"的合法场景，所以它们永远不会和数据位混淆。

【记忆口诀】时钟高时数据稳，时钟低时数据换；高时 SDA 往下跳是上课（START），往上跳是下课（STOP）。

5.3.5 ACK / NACK：每个字节都要有回音

每传完 8 位，第 9 个时钟周期是应答位：

  • 发送方（无论主从）在第 9 拍前释放 SDA；
  • 接收方若想应答，就把 SDA 拉低 = ACK（我收到了，继续）；
  • 若接收方不动，SDA 被上拉为高 = NACK（没收到/别再发了）。

NACK 的三个常见场景：① 主机读最后一个字节后故意 NACK，告诉从机"够了别发了"；② 总线上根本没有这个地址的器件（没人拉低，i2cdetect 扫不到设备的根因）；③ 从机忙不过来。

时钟拉伸（Clock Stretching）：从机处理不过来时，可以把 SCL 拉低不放，强制主机等待——因为 SCL 也是开漏+上拉，线与特性让从机有"按住时钟"的权力。主机必须每拍检查 SCL 是否真的变高。这是 I2C 给慢速从机的"喘息机制"，用软件模拟 I2C（bit-banging）时最容易漏掉的一步。

【记忆口诀】八位之后第九拍，拉低 ACK 放高 NACK；从机太忙拽时钟，主机耐心等松开。

5.3.6 完整时序：一次"写寄存器"和一次"读寄存器"

几乎所有 I2C 传感器/芯片的操作都是"读写内部寄存器"，把下面两个流程背到能默画，I2C 面试就过了大半。

写寄存器（主机向 SHTC3 这类器件的某寄存器写 1 字节）：

S → [器件地址+W] → ACK → [寄存器地址] → ACK → [数据] → ACK → P

逐拍走一遍：

  1. 主机发 START（SCL 高时拉低 SDA）；
  2. 主机发 7 位器件地址 + W(0)，共 8 位。注意 I2C 是 MSB 先发（和 UART 的 LSB 先发正好相反，画波形题别搞混）；
  3. 第 9 拍主机释放 SDA，对应地址的从机拉低 SDA 回 ACK；
  4. 主机发 8 位寄存器地址（要操作哪个寄存器），从机 ACK；
  5. 主机发 8 位数据，从机 ACK；
  6. 主机发 STOP，结束。

读寄存器：先"假装写"告诉从机我要读哪个寄存器，再用**重复起始（Repeated Start）**掉头读：

S → [器件地址+W] → ACK → [寄存器地址] → ACK →
Sr → [器件地址+R] → ACK → (从机发数据) → 主机 ACK → … → 最后一字节后主机 NACK → P

要点：

  • Sr（重复起始）：不发 STOP 直接再发一次 START。作用是把总线方向从"写"无缝切成"读"，同时不让出总线（若中间发 STOP，多主环境下别的主机可能插进来）。面试必问"为什么读操作要 Repeated Start"。
  • 方向切换后，数据由从机发、主机收：前 n-1 个字节主机回 ACK 让从机继续，最后一个字节主机回 NACK（告诉从机停止），然后 STOP。

【记忆口诀】写：S 地写 寄存器 数据 P；读：先写地址再掉头，Sr 换向不发停，最后一字节 NACK 再下课。

5.3.7 多主仲裁：靠"线与"现场比武

I2C 允许多个主机。两个主机同时 START 怎么办？靠 5.3.2 的线与特性做非破坏性仲裁：

  • 每个主机边发边回读 SDA；
  • 只要"我发的是 1，读回来却是 0"，说明总线上有别人在发 0（低电平赢了），我就立刻退出、转入监听；
  • 发 0 的一方毫无感知，继续传完——赢家的数据一个位都没被破坏，所以叫"非破坏性"。

结果：谁先发 0 谁赢，即地址/数据越小优先级越高。这个思想和 CAN 的逐位仲裁一脉相承（5.6.4），面试常被拿来对比。

5.3.8 速率档位

模式 速率 说明
标准模式 Sm 100 kbps 最通用，传感器默认
快速模式 Fm 400 kbps OLED 刷屏常用
快速模式+ Fm+ 1 Mbps 需驱动能力更强
高速模式 Hs 3.4 Mbps 需主机支持，少见

【记忆口诀】一百起步四百常，一加三减是高档；线长容大往上拉，速率越快阻越小。

5.3.9 Linux 侧调试：i2c-tools 命令实例

作者调 SHTC3/AP3216C/SSD1306 时的实战命令（I2C 总线挂在 i2c-1）：

# 1. 扫描总线上的从机地址（看到 0x1e / 0x3c / 0x70 三兄弟就全齐了）
i2cdetect -y 1
#      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
# 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e --
# 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- --
# 70: 70 -- -- -- -- -- -- --

# 2. 读 AP3216C(0x1E) 的 0x0C 寄存器（ALS 数据低字节）
i2cget -y 1 0x1e 0x0c

# 3. 向 0x1E 的 0x00 寄存器写 0x04（使能 ALS+PS 功能）
i2cset -y 1 0x1e 0x00 0x04

# 4. 一口气 dump 全部寄存器（看芯片状态/定位配置错误）
i2cdump -y 1 0x1e

排障套路：先 i2cdetect 看人在不在（不在 → 查接线/上拉/电源/地址），再 i2cdump 看寄存器默认值对不对，最后 i2cset/i2cget 按手册读写。若程序用 /dev/i2c-1 设备节点 + ioctl(I2C_SLAVE) 指定从机地址后 read/write，内核 I2C 子系统自动帮你生成 START/ACK/STOP 时序。

5.4 SPI：四根线的"高速公路"

5.4.1 是什么：专人专线、全双工、速度优先

SPI（Serial Peripheral Interface）是 Motorola 提出的同步串行总线，定位是板内高速、点对点为主的场景：Flash、TFT 屏、ADC、传感器。作者项目里的 **ICM20608 六轴惯性传感器（陀螺仪+加速度计）**就挂在 SPI 上——姿态数据量又大又急，SPI 的高速度正合适。

四根线（一主一从）：

信号 别名 方向 作用
SCLK SCK 主→从 时钟，主机产生
MOSI SDI（从机视角） 主→从 主机发、从机收
MISO SDO（从机视角） 从→主 从机发、主机收
CS/SS NSS、CE 主→从 片选，低电平选中（多数器件）

MOSI/MISO 各走各路，所以 SPI 是全双工：每个时钟沿两边同时移出一位、移入一位——本质是两个移位寄存器首尾相接成环，主从"交换"数据。所以 SPI 没有"只读"：你想读从机 1 字节，主机也必须同时发 1 字节（通常是 0x00 或 0xFF 占位）。

【记忆口诀】S 时钟 M 对 M（MOSI/MISO），C 片选；主出从入叫 MOSI，主入从出叫 MISO；想读也得发，交换是本质。

5.4.2 四种模式：CPOL/CPHA 组合表（面试必考）

SPI 协议本身没规定"时钟空闲是高还是低、哪个沿采样"，于是用两个参数组合出 4 种模式：

  • CPOL（Clock Polarity，时钟极性）：空闲时 SCLK 电平。0=空闲低，1=空闲高。
  • CPHA（Clock Phase，时钟相位）：在第几个时钟沿采样数据。0=每个周期的第一个沿采样，1=第二个沿采样。
模式 CPOL CPHA 空闲电平 采样沿（以 CPOL=0 记：上升沿在前）
Mode 0 0 0 低 第 1 个沿（上升沿）采样，下降沿换数据
Mode 1 0 1 低 第 2 个沿（下降沿）采样，上升沿换数据
Mode 2 1 0 高 第 1 个沿（下降沿）采样，上升沿换数据
Mode 3 1 1 高 第 2 个沿（上升沿）采样，下降沿换数据

怎么选？ 三步：① 查从机数据手册的时序图（看它空闲时 SCLK 是高是低、数据在哪个沿有效）；② 手册会直接写 "supports SPI mode 0 and mode 3" 之类；③ 主从两边模式必须一致。经验上 Mode 0 最常见（ICM20608 支持 Mode 0/3）。分不清时记一个口诀：

【记忆口诀】CPOL 定空闲（0 低 1 高），CPHA 定第几沿（0 先 1 后）；主从模式要一致，手册时序说了算；Mode 0 和 Mode 3，占掉市面一大半。

5.4.3 一主多从：独立片选 vs 菊花链

SPI 没有地址概念（对比 I2C），选谁全靠片选。两种接法：

接法一：独立 CS（最常用）

        ┌── CS1 ──► 从机1
主机 ───┼── CS2 ──► 从机2     SCLK/MOSI/MISO 全部并联
        └── CS3 ──► 从机3

SCLK、MOSI、MISO 所有从机并联，每个从机独占一根 CS。想和谁通信就把谁的 CS 拉低（其他人保持高，MISO 进入高阻态让出总线）。缺点：N 个从机占 N+3 根线。

接法二：菊花链（Daisy-Chain）

主机 MOSI → 从机1(MOSI→MISO) → 从机2(MOSI→MISO) → 从机3 → 回主机 MISO
                所有 CS 并联为一根

数据像击鼓传花一样穿过所有芯片，一根 CS 搞定全部。适合移位寄存器、多路 DAC/LED 驱动级联；缺点是必须按链长整体读写，不能单独访问某个芯片。

【记忆口诀】独立片选线换省芯，菊花链省线费字节；要挑人，多根 CS；要穿糖葫芦，菊链一线牵。

5.4.4 速率与优缺点

SPI 没有标准速率上限，由器件能力决定，几 MHz 到几十 MHz 很常见（比 I2C 的 100k/400k 快一两个数量级），所以屏、Flash、高速 ADC 都选它。

优点：全双工、速率高、协议极简（无地址无 ACK 无仲裁）、硬件实现便宜。
缺点：线多（每加一个从机多一根 CS）、无应答机制（发出去不知道对方收没收到）、无标准协议层（每个芯片的寄存器/命令格式各自为政）、通常一主、距离短。

【记忆口诀】快是真快，线是真多；无地址无应答，全双工没协议；速度换复杂，板内短途王。

5.4.5 Linux spidev 简介

Linux 用户态通过 spidev 驱动操作 SPI：设备节点 /dev/spidev<总线>.<片选>，如 /dev/spidev0.0。用 ioctl 配置模式、位数、速度，再用 SPI_IOC_MESSAGE 发起全双工传输：

/* spidev_demo.c — 读 ICM20608 的 WHO_AM_I 寄存器(0x75)，应返回 0xAF */
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/ioctl.h>
#include <linux/spi/spidev.h>

int main(void)
{
    int fd = open("/dev/spidev0.0", O_RDWR);
    uint8_t mode = SPI_MODE_0, bits = 8;
    uint32_t speed = 1000000;              /* 1MHz */
    ioctl(fd, SPI_IOC_WR_MODE, &mode);
    ioctl(fd, SPI_IOC_WR_BITS_PER_WORD, &bits);
    ioctl(fd, SPI_IOC_WR_MAX_SPEED_HZ, &speed);

    /* ICM20608 读寄存器：首字节 = 寄存器地址 | 0x80，后跟 dummy 字节收数据 */
    uint8_t tx[2] = {0x75 | 0x80, 0x00}, rx[2] = {0};
    struct spi_ioc_transfer tr = {
        .tx_buf = (unsigned long)tx,
        .rx_buf = (unsigned long)rx,
        .len = 2,
        .speed_hz = speed,
        .bits_per_word = bits,
    };
    ioctl(fd, SPI_IOC_MESSAGE(1), &tr);    /* 一次全双工传输 */
    printf("WHO_AM_I = 0x%02X\n", rx[1]);  /* 期望 0xAF */
    close(fd);
    return 0;
}

注意 .tx_buf/.rx_buf 同时给出——再次印证"SPI 本质是交换"。

5.5 UART / I2C / SPI / CAN 对比与选型

维度 UART I2C SPI CAN
线数 2（TX/RX）+ 地 2（SDA/SCL） 3 + N×CS 2（CAN_H/L，差分）
同步方式 异步（约定波特率） 同步（SCL） 同步（SCLK） 异步（位时序+再同步）
双工 全双工 半双工 全双工 半双工
拓扑 点对点 多主多从总线（靠地址） 一主多从（靠片选） 多主多从总线（靠 ID 仲裁）
寻址 无 7/10 位地址 无（CS 选人） 11/29 位 ID（标识消息，非节点地址）
典型速率 115200 bps 100k/400k/1M bps 1M~50M+ bps 125k/250k/500k/1M bps
应答/检错 可选奇偶校验 每字节 ACK 无 CRC + ACK + 错误帧，最强
距离/抗干扰 板内 板内 板内 千米级、差分抗干扰、工业级
典型用途 调试终端、模块对接 传感器、EEPROM、OLED Flash、屏、IMU 汽车、工业现场、多节点控制

【记忆口诀】I2C 两根线，地址加应答；SPI 四根线，片选挑从机；CAN 靠 ID，越小越优先；UART 最简单，点对点对好波特率。

面试题"如何选型"的标准答法

按场景四连问：

  1. 距离远不远、环境脏不脏？ 跨板/车载/工厂、电磁干扰大 → CAN（或 RS485）；板内芯片间 → I2C/SPI。
  2. 数据急不急？ 刷 Flash、刷屏、高频采样 IMU → SPI；慢速传感器、EEPROM → I2C。
  3. 挂几个设备、引脚够不够？ 设备多、引脚紧张 → I2C（2 线挂一片，靠地址区分）；引脚宽裕、设备少但要快 → SPI。
  4. 是不是调试/对接现成模块？ 日志终端、GPS、ESP8266、蓝牙模块 → UART，最省事。

用作者项目串一遍就是满分答案："我的智能车主链路跨 Linux 板和 STM32、且电机控制要求可靠，用 CAN 500kbps；SHTC3/AP3216C/SSD1306 是低速器件且要省引脚，挂一条 I2C；ICM20608 六轴数据量大，用 SPI；调试日志和 ESP8266 上云用 UART。"

5.6 CAN 总线超详解（本篇最重）

5.6.1 是什么：汽车里的"会议室广播系统"

先讲生活例子。一辆现代汽车里有几十个 ECU（电子控制单元）：发动机、刹车、车窗、仪表、雷达……它们要互相说话。如果像 UART 那样两两点对点拉线，几十个点要拉几百对线，车重和故障率都不可接受。于是 Bosch 在 1986 年提出 CAN（Controller Area Network，控制器局域网）：全车只拉一对双绞线，所有 ECU 都挂上去，谁要说话就对着总线广播，大家各取所需。

把它想成一间会议室：

  • 所有人共用一根"空气信道"（总线），谁都可以发言（多主），发言所有人都能听见（广播）；
  • 发言不喊"张三你听好"，而是喊"关于 XX 事项"（消息带 ID，标识的是消息内容，不是收件人地址），关心这个事项的人自己记笔记（接收过滤）；
  • 两个人同时开口时有个规矩：职位高的先说（ID 越小优先级越高），职位低的听到有人说话立刻住口，而高职位者的发言一个字都没被打断（非破坏性仲裁）；
  • 还有严格的会议纪律：发言格式固定（帧结构）、有人听错了全场纠错（错误帧）、一个设备老是捣乱会被禁言（错误被动/Bus-off）。

这四条恰好对应 CAN 的四大特性：多主、广播、ID 仲裁、完善的错误处理。这也是为什么 CAN 能成为汽车（ISO 11898）和工业现场的标准总线。

作者智能车项目的主链路：MQTT 指令 → Linux 网关解析 → SocketCAN 以 500kbps 发到 can0 → STM32F407 的 bxCAN 外设接收 → 驱动电机。下面每一节都会落到这条链上。

【记忆口诀】CAN 是会议广播制：多主同挂一对线，消息带号（ID）不带名，号小优先不打架，错了全场帮你喊。

5.6.2 物理层：显性 0 与隐性 1，差分双线

CAN 用一对双绞线 CAN_H 和 CAN_L，传输差分信号（高速 CAN，ISO 11898-2）：

状态 逻辑值 CAN_H CAN_L 压差
隐性（Recessive） 1 ≈2.5V ≈2.5V ≈0V
显性（Dominant） 0 ≈3.5V ≈1.5V ≈2V

为什么抗干扰？外界电磁干扰会同时、同向地耦合到双绞线上（共模干扰），而接收器只看 H 减 L 的压差——两根线一起抖，差值不变。再加上双绞线自身抵消磁场，CAN 才能在发动机舱这种电磁地狱里稳定工作。

"显性覆盖隐性"（线与特性）：总线空闲是隐性（1）。任何一个节点发显性（0），总线就是显性——像 I2C 的开漏线与，0 永远赢 1。这个特性是仲裁（5.6.4）和 ACK 的物理基础。记忆：显性=0=强势=赢；隐性=1=弱势=让。

120Ω 终端电阻，为什么两端各一个？ 信号在导线里跑到尽头会像水波撞到池壁一样反射回来，和后续信号叠加造成波形畸变。解决办法是在总线物理两端各并一个 120Ω 电阻，等于双绞线的特征阻抗，让波到达末端时被"吸收"掉。两个 120Ω 并联，所以断电后用万用表量 CAN_H 与 CAN_L 之间约 60Ω——这是排查 CAN 硬件故障的第一招（量到 120Ω 说明有一端没接/断线，量到无穷大说明两个都没接）。注意是"两端各一个"而不是每个节点都挂：中间节点挂高阻接入。

【记忆口诀】显性为 0 压差 2，隐性为 1 两边齐（都 2.5V）；共模干扰双绞挡，压差相减自然消；一百二电阻两头站，量得六十心里安。

5.6.3 帧结构逐字段：把一帧拆成零件

CAN 有四种帧：数据帧（干活的主力）、遥控帧/远程帧（请求别人发数据）、错误帧（报错）、过载帧（喊"慢点"）。重点掌握数据帧。标准数据帧（CAN 2.0A，11 位 ID）逐字段：

[SOF][  ID(11位)  ][RTR][IDE][r0][DLC(4位)][ 数据0~8字节 ][ CRC(15)+del ][ACK槽+del][EOF(7位)]

逐字段讲解：

  1. SOF（Start Of Frame，1 位，显性）：帧起始。总线空闲（隐性）后出现的第一个显性位，所有节点靠这个下降沿对齐时钟（硬同步）。
  2. ID（标识符，11 位标准 / 29 位扩展）：消息的"内容编号"，同时决定优先级（越小越高）。注意它不是节点地址——CAN 里"谁是收件人"由各节点的过滤器自己决定。
  3. RTR（Remote Transmission Request，1 位）：区分数据帧（显性 0）还是遥控帧（隐性 1）。所以 ID 相同时数据帧赢遥控帧。
  4. IDE（Identifier Extension，1 位）：显性=标准帧（11 位 ID），隐性=扩展帧。扩展帧（CAN 2.0B）在 IDE 后面再跟 18 位 ID，共 29 位，另有 SRR 位（隐性，保证标准帧优先于同号扩展帧）。
  5. r0（保留位，1 位）：发显性，留给未来。
  6. DLC（Data Length Code，4 位）：数据段字节数，0~8。经典 CAN 一帧最多 8 字节——这是经典 CAN 最"抠门"也最常考的限制。
  7. 数据段（0~8 字节）：真正的载荷。比如智能车的速度命令帧把左右轮目标速度两个 int16 塞进 4 个字节。
  8. CRC 段（15 位 CRC + 1 位隐性界定符）：对 SOF 到数据结束做循环冗余校验，接收方算出来不一致就报错。
  9. ACK 段（ACK 槽 1 位 + 界定符 1 位）：发送方在 ACK 槽发隐性，任何一个正确收到帧的节点把它拉成显性=应答。发送方读回显性就知道"至少一个节点收到了"。ACK 为隐性（无人应答）会触发 ACK 错误——总线上只有一个节点时发帧会一直报错的根因。
  10. EOF（End Of Frame，7 位隐性）：帧结束。之后再有 3 位帧间间隔（IFS），总线恢复空闲。

位填充（Bit Stuffing）：发送方发现连续出现 5 个相同电平的位，就自动插入 1 个相反电平；接收方对应地删除。作用：CAN 是异步总线，节点靠电平跳变沿维持同步，长时间不跳变时钟会漂走——填充强制制造跳变。副作用是同 ID 同数据的帧实际长度会略变。填充错误（该插没插/读回 6 个相同位）是五种错误之一。

四种帧一句话：

  • 数据帧：我广播 XX 消息，内容在这 8 字节里。
  • 遥控帧：谁有 XX 消息？发一帧给我。（DLC 填期望长度，无数据段）
  • 错误帧：任何节点发现错误，立刻发 6 个连续显性位（故意违反填充规则），全场作废当前帧，发送方稍后自动重发。
  • 过载帧：接收方处理不过来，请求下一帧晚点来（现代控制器很少用）。

【记忆口诀】SOF 一声开会，ID 报上议题，RTR 分讲还是要，IDE 长短号，DLC 数字节，数据最多八个，CRC 来验货，ACK 有人应，EOF 七位散会；五个相同必塞一（位填充）。

5.6.4 仲裁机制：非破坏性逐位仲裁，ID 越小越优先

这是 CAN 面试的第一高频题。规则一句话：多个节点同时发帧时，在 ID 段逐位比拼，谁先发出隐性（1）却读回显性（0），谁就立刻退出发送、转为接收；坚持到最后的节点继续发完，数据完好无损。

能这样玩的物理基础就是 5.6.2 的"显性覆盖隐性"（线与）：发 0 的一方看不到任何异常，发 1 的一方立刻发现"线被压低了，有人比我横"。

逐位推演三个节点同时发帧（ID 分别是 0x181、0x182、0x700）：

节点A  ID=0x181 = 001 1000 0001b
节点B  ID=0x182 = 001 1000 0010b
节点C  ID=0x700 = 111 0000 0000b
          ↑逐位从高位比
第1位：A=0 B=0 C=1 → C 发1读回0，C 退出
...
第9位：A=0 B=1      → B 退出
赢家：A（0x181，ID 最小），继续发完整帧，A 完全没察觉发生过争抢

三个要点：

  1. 非破坏性：赢家不需要重发，一微秒都没浪费——对比以太网 CSMA/CD 冲突后双方都要退避重发，这是 CAN 在实时性上的杀手锏。
  2. ID = 优先级：协议设计时把越紧急的消息配越小的 ID。作者智能车项目里急停帧 ID=0x060、故障帧 0x080 是总线上最小的两个 ID，速度命令 0x100、轮速上报 0x180、心跳 0x700/0x701——急停永远第一时间上总线，哪怕总线正在堵。
  3. 仲裁只发生在 ID+RTR 段，数据段不会有竞争；输家在总线空闲后自动重发（控制器硬件完成），最终所有消息都会发出去，只是排队。

【记忆口诀】边发边听逐位比，发 1 见 0 就让席；号小位高先开口，赢家无损不重来；急停编号最小，堵住也能插队。

5.6.5 位时序与波特率：500kbps 是怎么算出来的

CAN 没有时钟线，每个节点靠自己的时钟把 1 个位时间切成若干时间份额 Tq（Time Quantum），并约定好内部结构：

|<------------------ 1 个位时间 = N × Tq ------------------>|
[ SYNC_SEG ][ PROP_SEG ][ PHASE_SEG1 ][ PHASE_SEG2 ]
   1 Tq      传播补偿      采样点之前      采样点之后
                            ↑
                         采样点（读电平的时刻）
  • SYNC_SEG（同步段，固定 1 Tq）：电平跳变沿应落在这段内，用于全体对齐。
  • PROP_SEG（传播段）：补偿信号在总线上的物理传播延迟和收发器延迟。
  • PHASE_SEG1 / PHASE_SEG2（相位缓冲段 1/2）：采样点就在两段之间。两者可微调，用于"再同步"。
  • SJW（Synchronization Jump Width，再同步跳跃宽度，1~4 Tq）：当检测到跳变沿比预期早/晚时，允许把 PHASE_SEG1 拉长或 PHASE_SEG2 缩短的最大 Tq 数，把采样点"拽"回正确位置。SJW 越大抗时钟漂移能力越强，但会牺牲最大波特率。

采样点百分比 = (SYNC_SEG + PROP_SEG + PHASE_SEG1) / 总 Tq，常用 75%~87.5%。

波特率公式：

波特率 = CAN外设时钟 / ( 分频系数 Prescaler × 每位总Tq数 )

实战演算（作者项目 STM32F407，bxCAN 挂在 APB1=42MHz，目标 500kbps）：

需要：42MHz / (Prescaler × Tq总数) = 500kHz
取 Prescaler = 6，则 Tq 时钟 = 42/6 = 7MHz
需要 Tq 总数 = 7M / 500k = 14
分配：SYNC_SEG=1，BS1=11 Tq，BS2=2 Tq（合计 14）
采样点 = (1+11)/14 ≈ 85.7%  ✓ 在推荐区间
SJW 取 1

对应 HAL 库就是 Prescaler=6, TimeSeg1=CAN_BS1_11TQ, TimeSeg2=CAN_BS2_2TQ, SyncJumpWidth=CAN_SJW_1TQ。面试官追问"500kbps 怎么配"，能把"外设时钟 ÷ 分频 ÷ 总 Tq"这条链讲清楚即可。另记一条物理约束：波特率 × 总线长度 ≈ 常数，1Mbps 约 40 米，500kbps 约 100 米，125kbps 可到 500 米，距离越长速率越低（传播延迟要把采样点挤没了）。

【记忆口诀】一位切成若干 Tq，同步传播两相位；采样点坐中间线，SJW 管拽回；波特率 = 时钟 ÷ 分频 ÷ Tq 数；率乘距，是个定数。

5.6.6 错误处理：五种错误、两个计数器、三个状态

CAN 的可靠性口碑就来自这一节，面试第二层高频。

五种错误类型：

错误 谁发现 含义
位错误（Bit Error） 发送方 发出的位和读回的总线电平不一致（仲裁段、ACK 槽除外——那里发 1 读回 0 是正常的）
填充错误（Stuff Error） 接收方 出现 6 个连续相同电平，违反位填充规则
CRC 错误 接收方 自己算的 CRC 与帧内 CRC 不符
格式错误（Form Error） 接收方 固定位（如 CRC 界定符、EOF）出现非法电平
ACK 错误 发送方 ACK 槽没被任何节点拉低（没人应答）

任何节点发现错误 → 立刻发错误帧（6 个显性位，故意违反填充规则）→ 全场丢弃当前帧 → 发送方稍后自动重发。

错误计数器 TEC/REC：每个节点内置发送错误计数器 TEC 和接收错误计数器 REC。发/收出错就加（通常 +8，错误帧引发的重罚），成功收发就减（-1），即"犯错重罚、表现好减刑"。

三态状态机（必背）：

   TEC<128 且 REC<128          TEC 或 REC ≥128              TEC > 255
┌──────────┐  错误累计   ┌──────────┐   错误再累计   ┌──────────┐
│ 主动错误  │ ────────► │ 被动错误  │ ────────────► │ Bus-off  │
│(Error-   │            │(Error-   │               │(总线关闭) │
│ Active)  │ ◄──────── │ Passive) │               │ 脱离总线  │
└──────────┘  计数回落   └──────────┘                └──────────┘
 可发主动错误帧              只能发被动错误帧              需恢复流程
 (6个显性位，全场可见)      (6个隐性位，不干扰总线)
  • 主动错误：正常节点，发现错误就广播主动错误帧（全场立刻作废当前帧）。
  • 被动错误：节点"嫌疑大"（错误计数超 128），只准发隐性错误帧（不干扰总线），且发帧前要额外等待——相当于"留职查看"。
  • Bus-off：TEC 超过 255，控制器硬件强制节点脱离总线，只读不写（防止一个坏节点把整条总线刷瘫——这就是"老捣乱被禁言"）。

Bus-off 怎么恢复？ 标准流程：节点监测到总线上出现 128 次 × 11 个连续隐性位（即总线持续空闲足够久），TEC/REC 清零，回到主动错误态。工程上由 MCU 软件触发恢复（STM32 可开 AutoBusOff 自动恢复，也可在 Bus-off 中断里手动 HAL_CAN_ResetError/重新初始化），恢复后建议记录日志并做限流，避免"恢复-再爆-再关"振荡。

【记忆口诀】五错：位填 C 格 A；发错加八、成功减一；一二八转被动，二五五关禁闭（Bus-off）；一百二十八回十一连隐，刑满释放。

5.6.7 CAN 2.0A / 2.0B / CAN FD 一句话区别

  • CAN 2.0A：标准帧，11 位 ID，最多 8 字节数据。
  • CAN 2.0B：兼容扩展帧，29 位 ID，最多 8 字节数据（"B"=Both，可收标准+扩展）。
  • CAN FD（Flexible Data-rate）：一帧最多 64 字节数据；仲裁段仍按原速（保兼容），数据段可切换到最高约 5~8Mbps；CRC 加强。一句话：FD = 更长的数据 + 数据段提速。经典 CAN 节点不能和 FD 帧混跑（需 FD 控制器）。

【记忆口诀】A 短号、B 长短通吃，FD 六十四个字节两段速。

5.6.8 STM32 bxCAN 外设：邮箱、FIFO、过滤器

STM32F407 的 bxCAN（basic extended CAN）控制器三大件：

  1. 3 个发送邮箱（Tx Mailboxes）：发帧 = 把 ID/DLC/数据写进一个空邮箱，硬件负责排队、仲裁、重发。多个邮箱非空时按配置按 ID 或先存先发调度。应用层用 HAL_CAN_AddTxMessage() 投递，发送完成走中断回调。
  2. 2 个接收 FIFO（FIFO0/FIFO1），各 3 级深度：收到的帧存进 FIFO，满或来帧触发中断（HAL_CAN_RxFifo0MsgPendingCallback），应用层尽快 HAL_CAN_GetRxMessage() 取走，否则溢出丢帧。
  3. 过滤器组（Filter Banks，F407 的 CAN1/CAN2 共享 28 组）：CAN 是广播总线，节点会收到总线上所有帧，过滤器的职责就是"只把我要的 ID 放进 FIFO"，减轻 CPU 负担。两种模式：
    • 掩码模式（Mask Mode）：命中 = (收到ID & 掩码) == (期望ID & 掩码)——掩码位为 1 的位才参与比较。例：想收 0x100~0x1FF 一整段，期望 ID 设 0x100、掩码设 0x700（只比高三位）。
    • 列表模式（List Mode）：写死 1~2 个精确 ID，完全相等才收。适合只关心两三个固定 ID（如作者项目原计划用列表模式只收急停帧 0x060 + 速度命令 0x100，后因过滤器上电不一致回退为掩码全收+软件过滤，见第9篇 bug 案例）。

配置思路（HAL 库伪代码级，面试口述用）：

/* bxcan_init.c — STM32F407 bxCAN 500kbps + 过滤器配置思路 */
CAN_HandleTypeDef hcan1;
CAN_FilterTypeDef filt;

void can_init(void)
{
    hcan1.Instance = CAN1;
    hcan1.Init.Prescaler     = 6;                 /* 42MHz/6=7MHz */
    hcan1.Init.Mode          = CAN_MODE_NORMAL;   /* 另有 LOOPBACK 自测模式 */
    hcan1.Init.SyncJumpWidth = CAN_SJW_1TQ;
    hcan1.Init.TimeSeg1      = CAN_BS1_11TQ;      /* 1+11+2=14Tq → 500kbps */
    hcan1.Init.TimeSeg2      = CAN_BS2_2TQ;
    hcan1.Init.AutoBusOff    = ENABLE;            /* Bus-off 自动恢复 */
    hcan1.Init.AutoRetransmission = ENABLE;       /* 仲裁失败/出错自动重发 */
    HAL_CAN_Init(&hcan1);

    /* 过滤器0：掩码模式，收 0x100~0x1FF 段进 FIFO0 */
    filt.FilterBank           = 0;
    filt.FilterMode           = CAN_FILTERMODE_IDMASK;  /* 掩码模式 */
    filt.FilterScale          = CAN_FILTERSCALE_32BIT;  /* 32位尺度 */
    filt.FilterIdHigh         = 0x100 << 5;   /* 标准ID左移5位对齐寄存器 */
    filt.FilterIdLow          = 0;
    filt.FilterMaskIdHigh     = 0x700 << 5;   /* 只比高三位 */
    filt.FilterMaskIdLow      = 0;
    filt.FilterFIFOAssignment = CAN_RX_FIFO0; /* 命中进 FIFO0 */
    filt.FilterActivation     = ENABLE;
    HAL_CAN_ConfigFilter(&hcan1, &filt);

    HAL_CAN_Start(&hcan1);                                  /* 启动 */
    HAL_CAN_ActivateNotification(&hcan1, CAN_IT_RX_FIFO0_MSG_PENDING); /* 开来帧中断 */
}

/* 中断回调：FIFO0 来帧 */
void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan)
{
    CAN_RxHeaderTypeDef rxh;
    uint8_t data[8];
    HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rxh, data);
    if (rxh.StdId == 0x100) motor_set_speed(data);   /* CMD_VEL 速度命令帧 */
    if (rxh.StdId == 0x060) motor_emergency_stop();  /* EMERGENCY_CMD 急停帧 */
}

调试口诀：回环模式（CAN_MODE_LOOPBACK）无总线也能自测收发；AutoRetransmission 一定打开；接收回调里别做重活，取帧入队就走。

【记忆口诀】三邮箱管发，双 FIFO 管收，过滤器当门卫；掩码成段收，列表点名收；先配滤波再 Start，中断取帧别恋战。

5.6.9 Linux SocketCAN：把 CAN 当网卡用

传统做法是给每款 CAN 卡写私有驱动，应用各写各的。Linux 的 SocketCAN（内核 CAN 子系统）把 CAN 抽象成网络设备：can0、can1 和 eth0 一样是网口，应用层用标准 socket API（socket(AF_CAN, SOCK_RAW, CAN_RAW)）收发 struct can_frame——所以说"CAN 像网卡一样用"。作者项目里 Linux 网关正是用 SocketCAN 把 MQTT 指令翻译成 CAN 帧发到 can0。

配置与调试命令（can-utils 全家桶，面试可报菜名）：

# 1. 配置并启动 can0，500kbps（和 STM32 侧波特率必须一致！）
sudo ip link set can0 up type can bitrate 500000
#    采样点/时段也能配：... bitrate 500000 sample-point 0.875
sudo ip -details link show can0        # 查看状态、波特率、错误计数

# 2. 收：抓总线上所有帧
candump can0
#   can0  180  [8]  F4 01 F4 01 00 00 00 00   ← ID=0x180 轮速帧，DLC=8，四轮 int16 小端
candump can0,100:7FF                 # 只看 ID 0x100（CMD_VEL）

# 3. 发：速度命令帧 ID=0x100（CMD_VEL：线速度 i16 + 角速度 i16 + seq + flags）
cansend can0 100#F401000001000200
#   格式：ID#数据（十六进制），扩展帧用 8 位 ID；RTR 帧用 100#R

# 4. 造流量压测：每 10ms 发一帧 ID=0x123 的 8 字节随机数据
cangen can0 -g 10 -I 123 -L 8 -D r

# 5. 按 ID 归组实时刷新显示（看哪些 ID 在动、变化频率）
cansniffer can0

C 代码侧（用户态）：

/* socketcan_demo.c — SocketCAN 收发骨架 */
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <net/if.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <linux/can.h>
#include <linux/can/raw.h>

int main(void)
{
    int s = socket(PF_CAN, SOCK_RAW, CAN_RAW);   /* ① 建 CAN socket */
    struct ifreq ifr;
    strcpy(ifr.ifr_name, "can0");
    ioctl(s, SIOCGIFINDEX, &ifr);                /* ② 拿接口序号 */

    struct sockaddr_can addr = {
        .can_family  = AF_CAN,
        .can_ifindex = ifr.ifr_ifindex,
    };
    bind(s, (struct sockaddr *)&addr, sizeof(addr)); /* ③ 绑定 can0 */

    /* ④ 发速度命令帧：ID=0x100（CMD_VEL：线速度500mm/s，角速度0，seq=1，flags=remote） */
    struct can_frame tx = {
        .can_id  = 0x100,
        .can_dlc = 8,
        .data    = {0xF4, 0x01, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00}, /* i16 小端 */
    };
    write(s, &tx, sizeof(tx));

    /* ⑤ 阻塞收一帧（轮速上报） */
    struct can_frame rx;
    read(s, &rx, sizeof(rx));
    printf("ID=0x%03X DLC=%d data=%02X %02X...\n",
           rx.can_id, rx.can_dlc, rx.data[0], rx.data[1]);

    close(s);
    return 0;
}

流程类比 socket 编程：socket→bind→read/write，连结构体名都像。收发还能用 setsockopt(CAN_RAW_FILTER) 在内核层按 ID 过滤——和 STM32 的硬件过滤器思想一致，只是实现位置不同。

【记忆口诀】ip 拉起来，bitrate 先对齐；candump 收、cansend 发、cangen 造、cansniffer 看变化；socket 一 bind，CAN 帧像 UDP。

5.6.10 应用层协议设计：给智能车定一套 CAN 报文

裸 CAN 只保证"帧能可靠送达"，ID 怎么分、8 个字节怎么摆，是应用层协议的事。面试问"你怎么设计 CAN 报文"，用作者智能车项目这套作答：

设计原则：

  1. ID 按优先级分配：越紧急越小。控制类 > 状态上报类 > 日志心跳类。
  2. 数据段紧凑编码：定点数代替浮点（int16 表示 mm/s），小端对齐，DLC 用满但不浪费。
  3. 每帧职责单一，保留扩展字节；关键帧带计数器和校验。
  4. 周期帧 + 事件帧结合：状态周期上报，急停事件触发。

实例报文表：

帧 ID 方向 周期 字节布局（全部多字节小端）
EMERGENCY_CMD 急停 0x060（总线最小 ID，最高优先级） Linux→STM32 事件 B0=action(0解除/1急停)，B1=reason(1远程/2障碍/3MQTT失联/4心跳超时)，B2-3=seq
FAULT_EVENT 故障 0x080 STM32→Linux 事件（故障位上升沿） B0=fault code(1看门狗超时/2障碍/3低电/4极低电/5bus-off/6Linux心跳超时/7电机)，B1=detail，B2-3=seq
CMD_VEL 速度命令 0x100 Linux→STM32 50~100ms B0-1=线速度(i16, mm/s)，B2-3=角速度(i16, mrad/s)，B4-5=seq(u16 去重+刷看门狗)，B6=flags(bit0-1模式/bit2急停中)
WHEEL_SPEED 轮速 0x180 STM32→Linux 20ms 四轮 i16 mm/s：0-1左前/2-3右前/4-5左后/6-7右后
SENSOR_STATE 传感 0x200 STM32→Linux 50ms B0-1=超声距离(u16 mm, 0xFFFF无效)，B2=舵机角度，B3-4=电池(u16 mV)，B5=flags(bit0障碍/bit1低电/bit2极低电)
PARAM_SET 参数 0x300 Linux→STM32 事件 B0=参数号(1kp/2ki/3kd/4max_speed)，B2-5=value(i32 定点×1000)，B6-7=seq
LINUX_HEARTBEAT 0x700 Linux→STM32 500ms B0=state(0boot/1正常/2降级)，B1-2=counter，B3=error bits(bit0 MQTT离线等)
MCU_HEARTBEAT 0x701（优先级最低） STM32→Linux 500ms B0=mode(0boot/1idle/2remote/4safe_stop/5fault)，B1-2=counter，B3=error bits

讲解亮点（面试加分）：

  • 急停为什么是 0x060？ 仲裁时 ID 小者胜，急停与故障（0x060/0x080）是全总线最小的两个 ID，必须压倒一切正在发送的帧（见 5.6.4）；软件侧还有独立高优先级发送邮箱 mb_can_tx_hi，can_tx 线程每拍先清空高优先级队列再发普通帧——总线仲裁 + 软件队列双保险。
  • 心跳帧的用途：双向心跳——STM32 500ms 收不到 0x700 Linux 心跳 → 命令看门狗停车；Linux 1.5s 收不到 0x701 MCU 心跳 → 标记 MCU 离线、拒绝下发速度命令并 MQTT 上报故障。counter 滚动可以区分"对端死了"和"总线卡了同一帧"。
  • CMD_VEL 带 seq：STM32 新 seq 接受并刷新 500ms 命令看门狗，重复 seq 不重复执行，明显旧 seq 丢弃并统计——一箭三雕：去重、看门狗续命、乱序检测。
  • PARAM_SET 用定点数：i32 ×1000 表示浮点（kp=0.8 传 800），嵌入式链路上杜绝浮点歧义。
  • 提到工业界现成方案一句话：汽车柴油机/卡车用 J1939（基于 29 位扩展 ID，定义 PGN）；运动控制/机器人常用 CANopen（CiA 301，节点 ID + PDO 实时数据/SDO 参数读写）；汽车诊断用 UDS（ISO 14229）。自定义小项目按上面原则设计即可，量产产品尽量站在标准肩膀上。

【记忆口诀】急停号最小，命令带计数，上报凑满八字节，心跳滚号保平安；J1939 跑卡车，CANopen 控关节。

5.7 其他常见接口速览

GPIO（通用输入输出）

MCU 上最基础的引脚，软件可配成输入或输出。输入可带上拉/下拉电阻（避免浮空乱抖），输出分推挽（能主动输出高低，驱动能力强）和开漏（只能拉低，需外部上拉，可实现线——和 I2C 一个原理）。按键检测、LED、继电器控制都是 GPIO 的活。面试点：浮空输入为什么不靠谱、开漏与推挽的区别、中断沿触发（EXTI）。

【记忆口诀】推挽能推又能拉，开漏只会往下压；输入莫浮空，上下拉安家。

PWM（脉冲宽度调制）

用固定频率的方波、改变占空比（高电平时间占比）来等效输出"平均电压"。调 LED 亮度（占空比大则亮）、直流电机调速（智能车电机驱动器就吃 PWM+方向脚）、舵机角度（50Hz、脉宽 0.5~2.5ms 对应 0~180°）。两个参数：频率决定每秒多少个周期，占空比决定"力度"。MCU 用定时器（TIM）的捕获/比较单元产生。

【记忆口诀】频率定快慢，占空定力道；电机舵机小灯带，一脉冲全摆好。

ADC（模数转换）

把模拟电压变成数字量。三要素：分辨率（12 位 ADC 把量程分成 4096 格）、参考电压（Vref=3.3V 时每格约 0.8mV）、采样率。电池电压检测、电位器、模拟传感器（如麦克风、光敏电阻）都靠它。注意输入阻抗、采样保持时间和多次采样取平均去噪。反向概念是 DAC（数模转换）。

【记忆口诀】参考电压分格子，位数越多格越细；采样多次取平均，噪声见了把头低。

USB / 以太网（一句话版）

USB：主从结构的高速差分串行总线，枚举、端点、四种传输类型（控制/中断/批量/同步），MCU 常做 Device（虚拟串口 CDC 类最常用）。以太网：MAC+PHY 分层，MCU 外挂 PHY 芯片跑 TCP/IP 或 EtherCAT。两者协议栈都很厚，面试知道定位和一句话原理即可，本篇不展开。

5.8 面试高频问答（15 条）

Q1：I2C 为什么必须加上拉电阻？
因为 I2C 器件引脚全是开漏输出——只能把线拉低，自己输出不了高电平，必须靠上拉电阻把线"吊"到高电平。好处有三：防止推挽输出高低对撞短路；实现"线与"（任一器件拉低则全线为低），这是 ACK 应答和多主仲裁的物理基础；上拉接不同电源还能做电平兼容。阻值权衡：太大上升沿慢跑不了高速，太小灌电流大，常用 2.2k~4.7kΩ。

Q2：UART 的 TTL、RS232、RS485 有什么区别？
同一份 UART 帧用三种电气标准跑：TTL 是板内 3.3V/5V 逻辑，距离小于 1 米；RS232 用 ±3~15V 且负逻辑（1 是负电压），点到点约 15 米，需 MAX3232 转换；RS485 用 A/B 差分，半双工需 DE 方向控制，可达 1200 米、可挂多节点，上面常跑 Modbus-RTU。

Q3："115200-8-N-1"什么意思？一秒钟实际能传多少字节？
波特率 115200、8 数据位、无校验、1 停止位。每字节在线上要占 10 位（1 起始+8 数据+1 停止），所以实际约 11520 B/s ≈ 11.3KB/s，一个字节约 87µs。

Q4：UART 双方波特率不完全一致会怎样？能容忍多少误差？
接收方在起始位下降沿对表，之后每 1 个位时间采一次样，误差逐位积累。单边误差一般要求小于 ±2%，两端合计不超过约 4%~5%，否则积累到后半帧采样点偏出位边界，出现帧错误或乱码。所以高波特率建议用外部晶振而非内部 RC。

Q5：SPI 的四种模式怎么确定？
由 CPOL（空闲时钟电平）和 CPHA（第几个沿采样）组合出 Mode 0~3。确定方法：查从机数据手册的时序图，看它空闲时 SCLK 高低和数据有效沿；主从必须配成同一模式。Mode 0（CPOL=0、CPHA=0，空闲低、第一个上升沿采样）最常见，ICM20608 这类器件多支持 Mode 0/3。

Q6：I2C 读操作为什么要 Repeated Start（重复起始）？
读寄存器要先"写"寄存器地址再"读"数据，中间需要把总线方向从写切成读。直接发 STOP 再 START 也能切，但 STOP 会释放总线——多主环境下别的主机可能插队，而且部分从机要求事务原子性。Repeated Start 不发 STOP 直接再发一次 START，既换方向又保持总线占用。

Q7：I2C 和 SPI 怎么选型？
低速、多器件、引脚紧张选 I2C（2 线靠地址挂一片，有 ACK 应答，典型 100k/400k）；高速、大数据量、点对点选 SPI（全双工几 M~几十 MHz，但每加一个从机多一根 CS，且无应答机制）。实例：SHTC3/AP3216C/SSD1306 挂 I2C，ICM20608 六轴走 SPI。

Q8：CAN 的仲裁过程是怎样的？为什么说非破坏性？
多节点同时发帧时在 ID 段逐位竞争：每个节点边发边回读总线，由于显性（0）覆盖隐性（1），发出 1 却读到 0 的节点立即退出发送转接收。ID 最小的节点一路赢到底，它的帧没有任何位被破坏、无需重发——这就是"非破坏性"。输家在总线空闲后由硬件自动重发。

Q9：CAN 总线两端为什么各接一个 120Ω 电阻？
匹配双绞线特征阻抗、吸收末端信号反射，防止波形畸变。两个 120Ω 并联，断电测量 CAN_H 与 CAN_L 间应约 60Ω；量出 120Ω 说明一端缺失或断线。注意只在物理两端接，中间节点高阻挂入。

Q10：CAN 和 UART 有什么区别？
UART 是点对点全双工、无地址无仲裁、检错只有奇偶校验，适合板内/短距调试与模块对接；CAN 是多主广播总线、差分抗干扰、ID 逐位仲裁、CRC+ACK+错误帧+故障隔离（Bus-off）一整套可靠性机制，适合车载/工业多节点实时控制。一个像打电话，一个像纪律严明的会议室。

Q11：CAN Bus-off 是什么？怎么恢复？
节点发送错误计数器 TEC 超过 255 时，控制器强制该节点脱离总线（只收不发），防止故障节点拖垮整条总线。恢复条件：监测到总线上出现 128 次 11 个连续隐性位后 TEC/REC 清零，回到主动错误态。STM32 可开 AutoBusOff 自动恢复，或在 Bus-off 中断里软件复位 CAN；工程上恢复后应记日志、查根因，避免反复振荡。

Q12：为什么 CAN 特别适合汽车？
四点：① 差分双线+双绞，抗发动机舱强电磁干扰；② 多主广播+非破坏性仲裁，紧急消息（刹车、急停）靠小 ID 实时插队，延迟可预期；③ CRC/ACK/错误帧+TEC/REC 故障隔离，单个 ECU 坏了不拖垮全车网络；④ 一线挂全车，线束减重降成本。所以 1986 年 Bosch 为汽车而生，至今是车载主干。

Q13：经典 CAN 一帧最多多少数据？ID 越小越优先的本质是什么？
最多 8 字节（DLC 0~8），CAN FD 可到 64 字节。ID 越小越优先的本质是线与仲裁：ID 高位先发送，发 0（显性）压过发 1（隐性），逐位比较时数值小的 ID 先出现 0 的位更早"压住"对手，因此数值小=优先级高。设计协议时把急停等紧急帧分配最小 ID。

Q14：开漏输出为什么能实现"线与"？
开漏管的输出级只有一个下拉到地的 MOS，只能输出低电平或高阻。多个开漏输出并到一根线上配一个上拉电阻：任何一个器件导通拉低，全线就是低；只有全部截止，线才被上拉为高。这正是"与"逻辑（全 1 才为 1）。I2C 的 ACK、多主仲裁，CAN 的显性覆盖隐性（收发器等效实现），都建立在这一结构上。

Q15：Linux 上调试 CAN 的常用命令？（SocketCAN）
ip link set can0 up type can bitrate 500000 配置启动；candump can0 抓帧；cansend can0 101#F401F401 发帧；cangen can0 -g 10 -I 123 -L 8 造流量压测；cansniffer can0 按 ID 分组看变化；ip -details link show can0 看波特率和错误计数。应用层用 socket(AF_CAN, SOCK_RAW, CAN_RAW) 编程，"CAN 像网卡一样用"。

【全篇总口诀】UART 两根线对好波特率，I2C 两根线地址加应答，SPI 四根线片选挑从机，CAN 一对差分 ID 定江山；开漏上拉能线与，显性盖隐可仲裁，终端一百二，Bus-off 一百二十八回十一家。

第 6 篇 网络与应用层协议（TCP/UDP/HTTP/MQTT/SocketCAN 编程）

本篇是全手册的重点篇。通信方向面试几乎必问 TCP 三次握手、粘包、MQTT QoS 与 LWT，而嵌入式岗位还会加问 CAN 总线与 SocketCAN 编程。本篇全部知识点配合作者真实项目 smartcar_linux_v2（i.MX6ULL 智能车：云端 MQTT → Linux 板 robotd → SocketCAN → STM32 电机控制）讲解，代码均来自或改写自项目源码（app/mqttc/mqtt_if.c、app/canbus/can_if.c、app/canbus/thread_can_rx.c、app/webd/webd.c 等）。

6.1 网络基础：先把"分层"这件事想明白

6.1.1 OSI 七层 vs TCP/IP 四层

网络协议栈是"分层协作"的：每一层只跟自己的对端"逻辑对话"，把数据交给下一层去真正传输。面试要能默写这张对照表，并能说出每层干什么：

OSI 七层 TCP/IP 四层 典型协议/设备 一句话职责
7 应用层 应用层 HTTP、MQTT、FTP、DNS 应用程序之间约好的"语言"
6 表示层 应用层 JSON、TLS 加密、压缩 数据格式与加解密
5 会话层 应用层 会话建立/断连管理 维持"这次对话"的上下文
4 传输层 传输层 TCP、UDP 端到端、进程到进程（端口）
3 网络层 网络层 IP、ICMP、路由器 跨网段寻址与路由
2 数据链路层 网络接口层 以太网、MAC、ARP、交换机、CAN 同一链路内两节点之间传帧
1 物理层 网络接口层 网线、电平、CAN 收发器 比特流怎么变成电信号

在作者的项目里这条链是真实可见的：浏览器发 HTTP（应用层）→ TCP（传输层）→ IP（网络层）→ WiFi/以太网（链路+物理层）到开发板；开发板 robotd 再把命令编码成 CAN 帧（应用层字节布局约定）经 SocketCAN → bxCAN 控制器（链路层仲裁）→ TJA1042 收发器（物理层差分电平）发给 STM32。

【记忆口诀】
七层从下往上背："物链网、传会表用"；四层从下往上："接口、网络、传输、应用"。TCP/IP 把上面三层揉成一团叫应用层，把下面两层揉成一团叫网络接口层。

6.1.2 IP、端口、MAC 各管什么

这是面试最爱考的"三者分工"问题，用寄快递类比一次讲清：

  • IP 地址（网络层）：管"哪台主机"，跨网段全球（或局域网内）唯一寻址，相当于快递的"城市+街道+门牌号"。路由器根据目的 IP 决定下一跳往哪转发。
  • MAC 地址（链路层）：管"同一条链路上的下一块网卡"，相当于"当前这一站交给哪个快递员"。IP 包每经过一跳，以太帧头的源/目的 MAC 都会被重写（ARP 协议负责"知道 IP 问 MAC"）。
  • 端口（传输层）：管"主机上的哪个进程"，相当于门牌号里的"几号房间"。一台机器 80 端口是 webd 的 HTTP 控制台，1883 端口可能是 MQTT Broker，互不干扰。

项目实例：作者开发板同时跑着 webd（80 端口 HTTP 控制台）和 wifid（AP 配网模式下也用 80），两者靠读取 /dev/shm/wifi_status.json 错峰占用 80 端口——wifid 只在 AP 配网模式监听，webd 只在 mode=="connected" 时 bind，模式切换时主动 shutdown() 断开视频流客户端把端口还回去。这个"两个进程抢一个端口"的协调设计，面试讲出来非常加分。

6.1.3 子网掩码与网段：作者踩过的"同网段双接口"大坑

IPv4 地址 32 位，子网掩码用来划分"网络位"和"主机位"。192.168.4.1/24 表示前 24 位是网络位（掩码 255.255.255.0），本网段范围是 192.168.4.0 ~ 192.168.4.255。两台主机 IP 与掩码按位与后相等，就是同一网段，可以直接通信；不同网段必须经网关（默认路由）转发。

作者实机 bug（docs/调试问题记录 案例 8）：开发板 eth0 有线网段是 192.168.1.0/24，最初把 WiFi AP 热点也配在 192.168.1.0/24（AP 地址 192.168.1.1）。结果手机连上热点后浏览器访问 192.168.1.1，TCP 握手永远失败。根因：一块板子的两个接口在同一网段，内核路由表认为 192.168.1.0/24 从 eth0 直达，手机的回包错走了 eth0 而不是 wlan0，握手包有来无回。修复：AP 网段固定改为 192.168.4.0/24，刻意避开有线网段。

面试答法：一条铁律——同一台设备的多个接口不要配同一网段，否则路由表歧义，回包可能走错接口。诊断思路：手机侧 SYN 发出无回包 → 板子 tcpdump 发现 SYN 从 wlan0 进、SYN-ACK 从 eth0 出。

6.1.4 网关与 DNS

  • 默认网关：本网段以外的包都扔给它（通常是路由器的 LAN 口 IP，如 192.168.1.1）。配置里就一条默认路由 default via 192.168.1.1。
  • DNS：把域名翻译成 IP（UDP 53 端口查询，大响应用 TCP）。嵌入式板子通常在 /etc/resolv.conf 里写 nameserver 223.5.5.5。项目中 robotd 直连 Broker IP tcp://47.109.91.11:1883 不依赖 DNS——嵌入式设备直连 IP 是常见做法，省掉 DNS 故障点。

6.1.5 常用排查命令（要会背输出含义）

ping 192.168.1.1          # ICMP 回显，测通断与往返时延
ifconfig / ip addr show   # 看各接口 IP/掩码/MAC
ip route show             # 看路由表与默认网关
ss -tlnp                  # 看哪些进程在监听 TCP 端口（比 netstat 快）
netstat -anp              # 老系统上用，看连接状态（TIME_WAIT 等）

【记忆口诀】
"IP 管主机，MAC 管一跳，端口管进程；掩码划网段，网关出村口，DNS 查电话簿。"

6.1.6 一次完整的嵌入式网络排查实战

把本节知识串成一条排查流水线——以"开发板上 robotd 连不上云端 MQTT Broker"为例，面试被问"网络不通你怎么查"就按这个顺序答：

# 第1步: 本机协议栈与接口——IP 拿到没有?
ip addr show wlan0            # 没有 inet 行 → DHCP/配网问题(找 wifid 日志)
# 第2步: 本网段通不通?
ping 192.168.1.1              # 网关都不通 → WiFi 没真正连上(wpa_state?)
# 第3步: 出网路由对不对?
ip route show                 # 有没有 default via ...? 缺默认路由包出不了村
ping 47.109.91.11             # 通 → 链路 OK; 不通 → 上游路由/运营商问题
# 第4步: 域名解析(本项目直连 IP 可跳过)
nslookup broker.example.com   # 或 ping 域名, 失败查 /etc/resolv.conf
# 第5步: 端口通不通?
ss -tlnp | grep 1883          # 服务端视角: 有没有在监听
nc -zv 47.109.91.11 1883      # 客户端视角: TCP 能否握手(三次握手失败=防火墙/端口未开)
# 第6步: 应用层——Broker 认证对不对?
mosquitto_sub -h 47.109.91.11 -u robot -P 'xxx' -t '#' -v

这套"自下而上、逐层二分"的方法论就是 6.1.1 分层模型的实战价值：每一层只验证自己那层的功能，通了就往上走一层，哪层断了问题就在哪层。作者项目里 wifid 的状态机日志（STA_CONNECTING/STA_OK/AP_MODE 三态）正好对应第 1、2 步；而 6.1.3 那个"回包错走 eth0"的坑，用第 2 步 ping 网关 能通、第 5 步 TCP 握手却失败的反差就能定位到路由层。

【记忆口诀】
"查网六步层层升：接口、网关、出村路、域名、端口、应用认。"

6.2 TCP 详解

6.2.1 三大特性

TCP（Transmission Control Protocol）是传输层协议，面试第一句话先答三大特性：

  1. 面向连接：通信前先三次握手建立连接，通信后四次挥手释放，连接是"全双工"的逻辑通道。
  2. 可靠传输：每个字节有序号，接收方 ACK 确认，丢包超时重传，乱序重排，重复丢弃，还有流量控制（滑动窗口）与拥塞控制。
  3. 字节流：TCP 不关心应用层"消息"边界，只保证字节流按序无错到达——这是后面"粘包"问题的根源。

6.2.2 三次握手逐包图解

客户端 (CLOSED)                        服务端 (LISTEN)
     │ ──① SYN, seq=x ──────────────▶ │  "我能连你吗？我序号从x开始"
     │   (SYN_SENT)                   │   (SYN_RCVD)
     │ ◀─② SYN+ACK, seq=y, ack=x+1 ── │  "可以，我序号从y开始，你x我收到了"
     │ ──③ ACK, seq=x+1, ack=y+1 ───▶ │  "好，你的y我也收到了"
     │   (ESTABLISHED)                │   (ESTABLISHED)
  • ① 客户端发 SYN（同步序号），携带自己的初始序号 ISN=x，进入 SYN_SENT。
  • ② 服务端回 SYN+ACK：自己的 ISN=y，确认号 ack=x+1（"x 及之前的都收到了"），进入 SYN_RCVD。
  • ③ 客户端回 ACK，ack=y+1，双方进入 ESTABLISHED。

为什么是三次而不是两次？（面试第一高频）核心两点：

  1. 双向确认序号：TCP 是全双工，双方都要让对方确认自己的初始序号。②让客户端确认了"服务端收到了我的 x"，③让服务端确认了"客户端收到了我的 y"。两次握手服务端无法确认客户端收到自己的序号。
  2. 防止历史失效连接复活：若客户端旧 SYN 因网络延迟绕了一圈才到服务端，两次握手下服务端直接建立连接傻等，浪费资源；三次握手中客户端发现这不是自己当前发起的连接，回 RST 拒绝。

【记忆口诀】
"三次握手建连接：我问你答再确认；两次不行防旧包，序号双向都要认。"

6.2.3 四次挥手逐包图解

主动关闭方                             被动关闭方
     │ ──① FIN, seq=u ─────────────▶ │  "我没数据要发了"  (FIN_WAIT_1)
     │ ◀─② ACK, ack=u+1 ──────────── │  "知道了"          (CLOSE_WAIT)
     │    (FIN_WAIT_2)               │   ← 被动方还有数据可继续发
     │ ◀─③ FIN, seq=w ────────────── │  "我也发完了"      (LAST_ACK)
     │ ──④ ACK, ack=w+1 ───────────▶ │                    (CLOSED)
     │    (TIME_WAIT, 等 2MSL 后 CLOSED)

为什么是四次？ TCP 全双工，两个方向的关闭互相独立。被动方收到 FIN 时，可能还有数据没发完，只能先回 ACK（②），等应用层处理完再发自己的 FIN（③），所以 ACK 和 FIN 拆成了两步，比握手多一次。

TIME_WAIT（主动关闭方最后等 2MSL，MSL 约 30s~2min）：

  • 保证最后一个 ACK 若丢失，对端重发 FIN 时自己还在，能再 ACK 一次；
  • 让本连接的"迷路报文"在 2MSL 内全部消亡，防止串到下一个同四元组的新连接。
  • 高并发服务器大量 TIME_WAIT 会占用端口资源，可用 SO_REUSEADDR 复用监听端口（注意：它复用的是 bind 地址，对出站连接的 TIME_WAIT 另有 tcp_tw_reuse）。

CLOSE_WAIT（被动关闭方）：收到对方 FIN 并已 ACK，但本端应用还没 close()。服务器上堆积大量 CLOSE_WAIT，九成是代码漏 close socket 或业务线程卡住——这是个排查信号。

【记忆口诀】
"四次挥手道再见：你 FIN 我 ACK，我 FIN 你 ACK；主动方等 2MSL 叫 TIME_WAIT，被动方忘了关堆 CLOSE_WAIT。"

6.2.4 可靠传输机制（概念级）

  • 序号与确认（seq/ACK）：每个字节有编号，ACK=n 表示"n 之前的全收到了，下次从 n 开始发"（累计确认）。
  • 超时重传：发出后 RTO 时间内没收到 ACK 就重发；还有快速重传（收到 3 个重复 ACK 立即重发不等超时）。
  • 滑动窗口（流量控制）：接收方在 ACK 里通告 rwnd（接收窗口），告诉发送方"我缓冲区还能装多少"，发送方未确认数据不超过窗口，防止撑爆接收方。
  • 拥塞控制：慢启动（窗口指数增长）→ 拥塞避免（线性增长）→ 丢包则窗口减半（或更快算法如 CUBIC），防止撑爆网络。流量控制管"对端"，拥塞控制管"链路"。

6.2.5 粘包问题：成因与三种解法

成因：TCP 是字节流，没有消息边界。应用层 send("AB")、send("CD") 两次，接收方可能一次 read 收到 "ABCD"（粘包），也可能先收 "A" 再收 "BCD"（拆包）——取决于发送缓冲、MSS 分段、Nagle 算法、接收时机，完全不可预测。

三种主流解法（面试要能全说出来）：

  1. 定长消息：每条消息固定 N 字节，读满 N 字节处理一条。简单但浪费带宽。
  2. 分隔符：消息尾加特殊标记（如 HTTP 头部的 \r\n\r\n、行文本协议的 \n），按标记切分。缺点是载荷里出现分隔符要转义。
  3. 长度前缀：包头固定字段带 body 长度（如 [4字节长度][body]），先读头再按长度读 body。最通用，二进制协议几乎都用它。MQTT 报文就是"固定头+剩余长度字段"的变长结构；作者项目的 CAN 协议则是"DLC 自带长度"——CAN 帧天生有边界，不存在粘包，这也是 CAN 与 TCP 的一个有趣对比。

【记忆口诀】
"TCP 是流水不分家，粘包拆包全靠应用自己划：定长、分隔、长度前缀三选一加。"

6.2.6 TCP 编程完整示例（C 语言）

服务端——socket → bind → listen → accept → read/write → close：

/* tcp_server.c —— 回声服务器：收到什么原样发回 */
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>

int main(void)
{
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);   /* IPv4 TCP */

    int on = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

    struct sockaddr_in addr = {0};
    addr.sin_family      = AF_INET;
    addr.sin_port        = htons(8080);                /* 主机序→网络序(大端) */
    addr.sin_addr.s_addr = htonl(INADDR_ANY);          /* 监听所有接口 */
    bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr));

    listen(listen_fd, 8);                              /* 未完成+已完成连接队列 */
    printf("listening on :8080\n");

    for (;;) {
        int conn = accept(listen_fd, NULL, NULL);      /* 取一个已握手连接 */
        char buf[512];
        ssize_t n;
        while ((n = read(conn, buf, sizeof(buf))) > 0)
            write(conn, buf, n);                       /* 回声 */
        close(conn);                                   /* 漏这步 → CLOSE_WAIT 堆积 */
    }
    return 0;
}

客户端——socket → connect → write/read：

/* tcp_client.c */
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>

int main(void)
{
    int fd = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in srv = {0};
    srv.sin_family = AF_INET;
    srv.sin_port   = htons(8080);
    inet_pton(AF_INET, "127.0.0.1", &srv.sin_addr);

    if (connect(fd, (struct sockaddr *)&srv, sizeof(srv)) < 0) {
        perror("connect");           /* 三次握手在此完成 */
        return 1;
    }
    write(fd, "hello", 5);
    char buf[64] = {0};
    ssize_t n = read(fd, buf, sizeof(buf));
    printf("echo: %.*s\n", (int)n, buf);
    close(fd);
    return 0;
}

要点：htons/htonl 做字节序转换（网络字节序是大端）；SO_REUSEADDR 让重启的服务端能立刻 bind 处于 TIME_WAIT 的旧地址；服务端每个连接处理完必须 close。作者项目的 webd/wifid 的 HTTP 服务器本质上就是这个骨架，只是把 read/write 循环换成了 HTTP 报文解析（见 6.4）。

6.2.7 TCP 状态流转与实战排查

把握手挥手串起来，TCP 连接的状态机是：CLOSED → (SYN_SENT) → ESTABLISHED → (FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT) → CLOSED；服务端侧：LISTEN → SYN_RCVD → ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED。排查命令组合：

ss -tan state time-wait   # 看 TIME_WAIT 数量(高并发服务重点关注)
ss -tan state close-wait  # 看 CLOSE_WAIT(堆积=应用漏 close)
ss -tlnp                  # 看监听端口与所属进程

面试追问"挥手能不能是三次？"——可以：当被动方收到 FIN 时恰好也没有数据要发，ACK 和 FIN 可以合并成一包发送，四次就退化成三次。所以"四次挥手"的准确说法是"通常四次，ACK 与 FIN 可合并时为三次"。再追问"为什么要等 2MSL 而不是 1MSL"——最后一个 ACK 最多活 1MSL 到达对端，若丢失对端重发的 FIN 又要活 1MSL 回来，一来一回正好 2MSL。

【记忆口诀】
"TIME_WAIT 等两倍，一去一回防迷路；CLOSE_WAIT 堆成山，准是代码忘了关。"

6.3 UDP

6.3.1 特性与适用场景

UDP（User Datagram Protocol）几乎是"裸 IP + 端口"：

  • 无连接：不握手不挥手，拿到地址就能发；
  • 保留报文边界：一次 sendto 就是一个数据报，接收方一次 recvfrom 收一个完整报文——没有粘包问题；
  • 不保证可靠：可能丢包、乱序、重复，协议栈不重传，可靠性要应用层自己做；
  • 开销小、延迟低：头部仅 8 字节（源端口/目的端口/长度/校验和），TCP 头至少 20 字节。

适用场景：实时性高于可靠性的场合——音视频通话/直播（丢一帧无所谓，卡着重传更糟）、DNS 查询、DHCP、NTP、局域网设备发现广播。作者项目的 MJPEG 视频流走的是 TCP 上的 HTTP（局域网带宽够、要兼容性），但若做 FPV 低延迟图传，UDP/RTP 是更典型的选择。

6.3.2 代码示例（C 语言）

/* udp_server.c —— 绑定端口收数据报 */
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>

int main(void)
{
    int fd = socket(AF_INET, SOCK_DGRAM, 0);          /* SOCK_DGRAM = UDP */

    struct sockaddr_in addr = {0};
    addr.sin_family      = AF_INET;
    addr.sin_port        = htons(9000);
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    bind(fd, (struct sockaddr *)&addr, sizeof(addr));

    for (;;) {
        char buf[512];
        struct sockaddr_in from;
        socklen_t flen = sizeof(from);
        /* 一次 recvfrom 收一个完整数据报, 同时拿到来源地址 */
        ssize_t n = recvfrom(fd, buf, sizeof(buf) - 1, 0,
                             (struct sockaddr *)&from, &flen);
        if (n > 0) {
            buf[n] = '\0';
            printf("from %s: %s\n", inet_ntoa(from.sin_addr), buf);
            sendto(fd, buf, n, 0, (struct sockaddr *)&from, flen);  /* 回声 */
        }
    }
    return 0;
}

客户端连 bind/listen/accept 都不需要，socket 后直接 sendto 即可。

6.3.3 TCP vs UDP 对比表（面试必背）

维度 TCP UDP
连接 面向连接（三次握手） 无连接
可靠性 确认/重传/排序，可靠 不保证，可能丢包乱序
数据边界 字节流，有粘包 保留报文边界
传输方式 单播 单播/广播/组播
头部开销 ≥20 字节 8 字节
流量/拥塞控制 有 无
典型应用 HTTP、MQTT、文件传输 音视频、DNS、DHCP

【记忆口诀】
"TCP 可靠要握手，UDP 快糙不回头；流式粘包报文界，面试对比表背熟。"

6.4 HTTP：文本协议之王

6.4.1 请求报文逐行拆解

HTTP 是应用层、基于 TCP、纯文本的请求-响应协议。一个 GET 请求长这样：

GET /config HTTP/1.1        ← 请求行：方法 路径 协议版本
Host: 192.168.4.1           ← 首部行：每行一个 "键: 值"
User-Agent: curl/7.68.0
Accept: */*
                              ← 空行(\r\n)：首部结束
                              ← GET 一般没有 body

POST 则在空行后带 body，并用 Content-Length 标明长度（这其实就是"长度前缀"式粘包解法在文本协议里的体现）：

POST /wifi/set HTTP/1.1
Host: 192.168.4.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 23

ssid=mywifi&psk=12345678

6.4.2 响应报文与状态码

HTTP/1.1 200 OK             ← 状态行：版本 状态码 短语
Content-Type: text/html
Content-Length: 1234

<html>...(body)...</html>

状态码按百位分类（面试常考）：

类别 含义 常见值
2xx 成功 200 OK、204 No Content
3xx 重定向 301 永久、302 临时、304 缓存未修改
4xx 客户端错误 400 坏请求、401 未认证、403 禁止、404 不存在
5xx 服务端错误 500 内部错误、502 网关错误、503 不可用

GET 与 POST 的区别：GET 语义是"取"（幂等、参数在 URL、可被缓存/收藏），POST 语义是"提交/改"（参数在 body、不缓存）。面试别只说"一个参数在 URL 一个在 body"，先答语义。

HTTP/1.1 keep-alive：默认 Connection: keep-alive，一次 TCP 连接可串行复用多个请求-响应，省掉反复三次握手的开销；HTTP/1.0 默认短连接需显式声明。嵌入式手写服务器为了简单常用短连接——作者 wifid 的配网门户就是"单请求-响应即关"：select 非阻塞集成在主循环里，每 2s tick 最多处理 8 个连接，处理完就 close，状态极简。

6.4.3 嵌入式上的 HTTP 服务器：作者 webd 实战

作者用 2431 行纯 C（libc + libjpeg + pthread，不依赖 nginx/lighttpd）在 i.MX6ULL 上写了完整 Web 控制台（app/webd/webd.c，docs/WEB_CONSOLE.md）：

  • GET / 状态页：读 /dev/shm/robotd_hmi.json，渲染轮速/电池/MQTT/CAN 状态，3 秒 meta refresh 自动刷新；
  • GET /config 配置页 + POST /wifi/set：改 WiFi 配置，写 conf 后创建触发文件 /dev/shm/wifi_reconfigure，wifid 下个 tick 发现即重连；
  • GET /stream MJPEG 视频流——面试亮点，原理展开讲：

MJPEG over HTTP（multipart/x-mixed-replace）：视频本质是一串 JPEG 帧。服务端保持这一个 HTTP 连接不关，响应头声明

Content-Type: multipart/x-mixed-replace; boundary=frame

然后每产出一帧 JPEG 就往这条 TCP 连接里追加一段：

--frame
Content-Type: image/jpeg
Content-Length: 18342

<二进制JPEG数据>

x-mixed-replace 的语义是"后一个数据段替换前一个"——浏览器每收到一个 --frame 分段就用新 JPEG 替换画面，于是 标签直接变成视频。不用任何播放器插件、不用 WebSocket，这是嵌入式摄像头 Web 预览的经典方案。实现要点：每个客户端连接起一个 detached 发送线程（最多 4 路），所有客户端共享同一份最新帧缓冲（mutex+条件变量+帧序号），JPEG 编码只做一次；摄像头打不开时 /stream 回 503——一个真实的状态码应用。

HTTPS/TLS 一句话：HTTPS = HTTP 跑在 TLS 加密通道上（TCP 443），TLS 握手用证书验证服务器身份并协商出对称会话密钥，之后 HTTP 报文全程加密，防窃听防篡改。

6.4.4 手写 HTTP 服务器的工程要点（作者经验浓缩）

在嵌入式上自己撸 HTTP 服务器（而非移植 nginx），作者的 webd/wifid 踩出几条通用经验，面试可直接讲：

  1. 解析止于够用：只解析请求行（方法+路径）和少数头部（Content-Length、Content-Type），其余跳过——嵌入式场景客户端是自己家的浏览器/脚本，不需要完整 RFC 兼容；但路径必须做安全校验，webd 的文件下载端点用白名单 [A-Za-z0-9_.-] 且拒绝含 .. 的文件名，防目录穿越读到 /etc/passwd。
  2. 并发模型按场景选：wifid 配网门户流量极小，用 select 非阻塞单线程集成在主循环里，每 tick 最多处理 8 个连接，零额外线程；webd 视频流是长连接且要并发 4 路，用每连接一个 detached 线程 + 共享帧缓冲（mutex+条件变量+帧序号），编码只做一次。没有银弹，负载形态决定模型。
  3. 端口是稀缺资源：80 端口 wifid（AP 配网）与 webd（STA 模式）互斥占用，靠 /dev/shm 状态文件门控 + SO_REUSEADDR + 主动 shutdown() 断流让位——嵌入式上"谁在用这个端口"要靠设计保证，不能靠运气。
  4. POST 体要按 Content-Length 读：不能假设一次 read 收全（粘包/拆包就在身边），循环读到够长为止——这就是 6.2.5 长度前缀解法的实战。

【记忆口诀】
"手写服务器四件事：解析够用、模型看负载、端口要协调、body 按长读。"

【记忆口诀】
"请求行加头部，空行之后是 body；2 成功 3 跳转，4 客错 5 服错；MJPEG 流一长连，replace 一段换一帧。"

6.5 MQTT 超详解（嵌入式物联网面试核心）

6.5.1 发布/订阅模型 vs 请求/响应

HTTP 是请求/响应：客户端直连服务器，一问一答，双方必须同时在线且互相知道地址。MQTT 是发布/订阅（Pub/Sub）：所有设备只连一个中间人 Broker（消息代理），发消息的人（Publisher）把消息投到某个 Topic（主题），Broker 转发给所有订阅了该 Topic 的人（Subscriber）。发布者和订阅者互不认识、不需要同时在线，天然解耦，且一对多广播免费。

三角色一句话：Broker 是邮局，Topic 是信箱编号，Client 既可以是寄信人也可以是取信人。

【记忆口诀】
"HTTP 打电话你问我答，MQTT 贴布告栏：发的不管谁看，看的不管谁发。"

6.5.2 Topic 层级与通配符

Topic 用 / 分层，像文件路径。作者项目（docs/MQTT_PROTOCOL.md）统一前缀 robot/v1/{robot_id}/...，实体车 car01，为多车车队预留：

Topic 方向 QoS Retain 说明
robot/v1/car01/cmd/velocity PC→车 1 禁止 速度控制
robot/v1/car01/cmd/control PC→车 1 禁止 start/stop/emergency/模式切换
robot/v1/car01/config/set PC→车 1 否 PID 参数配置
robot/v1/car01/state/motion 车→PC 0 否 轮速/车速/模式，200ms
robot/v1/car01/state/sensor 车→PC 0 否 超声/电池，500ms
robot/v1/car01/state/system 车→PC 0 否 CPU/内存/链路统计，2s
robot/v1/car01/event/fault 车→PC 1 否 故障事件
robot/v1/car01/status 车→PC 1 是 online/offline + LWT

通配符两个：

  • + 匹配单层：订阅 robot/v1/+/state/motion 可同时收所有车的运动状态；
  • # 匹配多层、只能在末尾：robot/v1/car01/# 收该车全部消息。

设计经验：层级里带上版本号（v1）和设备 ID，将来协议升级和多设备扩容不打架。

6.5.3 QoS 0/1/2 逐级讲（面试必考）

QoS（Quality of Service）是消息的投递等级，发布端与订阅端各自声明，实际生效取两者较小值：

  • QoS 0 最多一次（At most once）：发完就忘，不重传不确认。可能丢，绝不重复。适合周期状态——丢了一帧 200ms 后下一帧就来。项目里 state/motion、state/sensor、state/system 全用 QoS 0。
  • QoS 1 至少一次（At least once）：发送方存消息，没收到接收方的 PUBACK 就重发，直到确认。保证到达，但可能重复（ACK 丢了就会重发同一条）。项目里所有命令（cmd/velocity、cmd/control、config/set）和故障事件用 QoS 1——命令绝不能丢。
  • QoS 2 恰好一次（Exactly once）：PUBREC/PUBREL/PUBCOMP 四步握手去重，保证不丢不重，但往返多、开销大，实际项目很少用。

关键推论（面试官就等你这句）：QoS 1 的"至少一次"意味着应用层必须自己处理重复——这就是作者项目做 seq 去重的原因（详见 6.5.8）。

【记忆口诀】
"QoS0 最多到一次丢了算，QoS1 至少到一次可能重，QoS2 恰好一次四步慢；QoS1 至少到，seq 去重防重跑。"

6.5.4 Retain 标志：为什么运动控制命令绝对不能 retain

Retained 消息：Broker 会为每个 Topic 保存最新一条 retained 消息，任何新订阅者一订阅立刻收到它——"布告栏上最后那张告示"。适合状态类（status: online），新打开的上位机马上知道车是否在线。

但运动控制命令禁止 retain：设想车辆断网重连 Broker，重新订阅 cmd/velocity，Broker 立刻把一小时前 retain 的"全速前进"塞给它——车会无故窜出去。作者在 Topic 表中把 cmd/velocity、cmd/control 明确标为"禁止 retain"，这是项目分层安全的第 5 层："重连后绝不执行历史命令"。

6.5.5 LWT 遗嘱机制

LWT（Last Will and Testament，遗嘱消息）：客户端 CONNECT 时预先把一条消息"寄存"在 Broker；如果客户端异常掉线（网络断、进程被杀、没来得及发 DISCONNECT），Broker 就代为发布这条遗嘱。正常断开则遗嘱作废。

作者 robotd 的用法（app/mqttc/mqtt_if.c 的 mqtt_if_connect()）：

/* C —— paho 遗嘱配置 */
MQTTClient_willOptions will = MQTTClient_willOptions_initializer;
will.topicName = "robot/v1/car01/status";
will.message   = "offline";
will.qos       = 1;
will.retained  = 1;            /* retained: 新订阅者立即看到 offline */
opts.will = &will;

效果：kill -9 robotd 后，Broker 按 keepalive 10s 的约 1.5 倍时间判定其死亡，代发 retained "offline"，上位机状态灯变灰。正常退出时代码主动先发 retained "offline" 再 DISCONNECT，与 LWT 语义保持一致。

6.5.6 Keep Alive 与报文流程

Keep Alive：客户端 CONNECT 时声明的秒数（项目用 10s），约定客户端最长沉默时间；Broker 超过 1.5×KeepAlive 没收到任何报文（含 PINGREQ 心跳）就判定掉线并触发 LWT。

MQTT 是二进制协议，主要报文（面试能画出流程即可）：

Client                        Broker
  │ ── CONNECT(账号/遗嘱/keepalive) ─▶ │
  │ ◀────── CONNACK(连接确认) ──────── │
  │ ── SUBSCRIBE("cmd/velocity",1) ──▶ │
  │ ◀────────── SUBACK ────────────── │
  │ ── PUBLISH("state/motion",QoS0) ─▶ │
  │ ◀─ PUBLISH("cmd/velocity",QoS1) ── │  (有人发布了命令, Broker 转发)
  │ ─────────── PUBACK ─────────────▶ │  (QoS1 必须回执)
  │ ◀───────── PINGREQ ─────────────  │  (双向保活)
  │ ────────── PINGRESP ────────────▶ │

认证：CONNECT 报文可携带 username/password。项目云端 Broker 为 Mosquitto tcp://47.109.91.11:1883，配置用户名密码后匿名连接被拒绝；代码里 opts.username/password 按配置设置，配置为空串则不设置以兼容本地匿名开发 Broker；启动日志密码脱敏打印 mqtt_pass=***——"日志脱敏"是面试加分细节。TLS 一句话：生产环境用 8883 端口 MQTT over TLS，证书校验 Broker 身份并加密链路，防密码与指令被明文嗅探。

6.5.7 mosquitto 搭建与命令行实操

# 安装并启动 broker（Debian/Ubuntu）
sudo apt install mosquitto mosquitto-clients
sudo systemctl start mosquitto

# 账号密码认证（项目云端配置方式）
sudo mosquitto_passwd -c /etc/mosquitto/passwd robot
# 配置文件加: allow_anonymous false / password_file /etc/mosquitto/passwd

# 终端订阅全车消息（-u/-P 传账号, -t 主题, -v 显示主题名）
mosquitto_sub -h 47.109.91.11 -u robot -P 'xxx' -t 'robot/v1/car01/#' -v

# 终端发布一条速度命令（QoS1）
mosquitto_pub -h 47.109.91.11 -u robot -P 'xxx' \
  -t 'robot/v1/car01/cmd/velocity' -q 1 \
  -m '{"version":1,"robot_id":"car01","seq":1001,"timestamp_ms":1735689600000,
       "ttl_ms":500,"linear_v":0.5,"angular_w":0.3,"task_id":0}'

mosquitto_sub/mosquitto_pub 是联调神器：不用写一行代码就能验证 broker、认证、Topic、QoS 是否通。

6.5.8 paho MQTT C 客户端编程（项目真实代码骨架）

作者用 Eclipse paho.mqtt.c（链接 -lpaho-mqtt3c），同步客户端 API 五步曲（摘自 app/mqttc/mqtt_if.c）：

/* C —— paho 客户端最小骨架 */
#include <MQTTClient.h>

MQTTClient client;

/* ① 创建: 地址 + clientID(同 clientID 会互踢! 项目曾因此 768 次重连) */
MQTTClient_create(&client, "tcp://47.109.91.11:1883", "car01",
                  MQTTCLIENT_PERSISTENCE_NONE, NULL);

/* ② 注册回调: 断链回调 + 消息到达回调(跑在 paho 内部线程) */
MQTTClient_setCallbacks(client, NULL, on_connection_lost, on_message, NULL);

/* ③ 连接: keepAlive=10s, cleansession=1, 遗嘱 + 用户名密码 */
MQTTClient_connectOptions opts = MQTTClient_connectOptions_initializer;
opts.keepAliveInterval = 10;
opts.cleansession      = 1;
opts.connectTimeout    = 5;
opts.username          = "robot";
opts.password          = "***";
opts.will              = &will;                 /* 见 6.5.5 */
MQTTClient_connect(client, &opts);

/* ④ 订阅命令 Topic (QoS1) */
MQTTClient_subscribe(client, "robot/v1/car01/cmd/velocity", 1);

/* ⑤ 发布 */
MQTTClient_message msg = MQTTClient_message_initializer;
msg.payload    = (void *)"online";
msg.payloadlen = 6;
msg.qos = 1;  msg.retained = 1;
MQTTClient_deliveryToken token;
MQTTClient_publishMessage(client, "robot/v1/car01/status", &msg, &token);
MQTTClient_waitForCompletion(client, token, 1000);  /* QoS1 限时等回执 */

两个回调的职责划分是工程重点：

/* C —— 断链回调: 只置标志, 重连由主循环做(见下) */
static void on_connection_lost(void *ctx, char *cause)
{
    atomic_store(&g_health.mqtt_online, 0);   /* 通知全系统"MQTT 离线" */
}

/* 消息到达回调: 跑在 paho 内部线程, 只做"解析+投邮箱"快速返回,
 * 绝不在回调里执行控制逻辑或阻塞操作 */
static int on_message(void *ctx, char *topic, int len,
                      MQTTClient_message *m)
{
    /* 拷贝 payload → 解析 JSON → mailbox_send 投给 command_thread */
    MQTTClient_freeMessage(&m);   /* 必须释放, 否则内存泄漏 */
    MQTTClient_free(topic);
    return 1;
}

自动重连（app/mqttc/thread_mqtt.c）：mqtt_thread 主循环发现 MQTTClient_isConnected() 为假，按 3 秒周期（MQTT_RECONNECT_MS 3000）重新 connect + 重新订阅 + 发 retained "online"，重连计数 mqtt_reconnect_count+1 供监控页显示。长稳测试实测：每 10 分钟重启一次 mosquitto 做故障注入，2 小时 11 次断链全部自动恢复。

6.5.9 应用层可靠性设计四件套（项目精华，面试大杀器）

MQTT 协议层保证"消息到 Broker/到订阅者"，但到不了"业务正确执行"。作者 robotd 在应用层补了四道闸（mqtt_if.c parse_common() + thread_command.c validate_cmd()）：

  1. seq 去重：每条命令带递增 seq 字段，robotd 只接受 cmd->seq > last_mqtt_seq，否则记 reject_dup_seq 丢弃。QoS 1 重发时 seq 相同，正好被挡掉——QoS1 的重复由应用层 seq 吸收。真实 bug 反例：Web 遥控台页面 seq 从 1 开始，小于 robotd 记忆的上次 seq（测试用到 41 万），全量被拒——后改用 Date.now() 做 seq 基数。
  2. timestamp + TTL 过期拒绝：命令带 timestamp_ms 与 ttl_ms:500，robotd 校时后若 age > ttl_ms 则 reject_expired——500ms 前发的"前进"现在才到，说明链路堵过，这种命令执行了就是安全隐患；未校时时（板子没 NTP）跳过 TTL 检查，是合理的降级。
  3. robot_id 校验：parse_common() 强制 robot_id 匹配本车，不匹配直接丢弃并计 mqtt_reject_count——Broker 上有多辆车/多个人时，防误控别人（或被别人误控）的车。
  4. 重连不恢复旧命令：MQTT 断链 → command_thread 立即停止刷新 CAN CMD_VEL → STM32 500ms 命令看门狗超时停车；重连成功后必须等新命令才动，绝不自动续跑断线前的速度。配合 6.5.4 的"控制 Topic 禁止 retain"，构成"任何链路异常都导向停车"的 fail-safe 设计。

安全门控还有两条：STM32 心跳超时（1.5s）时拒绝速度命令（reject_mcu_offline）；急停状态下除 clear_emergency 外全部拒绝（reject_emergency）。每种拒绝都有独立计数器，上位机能看到"为什么我的命令没执行"——可观测性是协议设计的一部分。

【记忆口诀】
"MQTT 四件套保平安：seq 去重防重跑，TTL 过期不执行，robot_id 对不上直接扔，重连之后等命令。"

6.5.10 MQTT 工程踩坑实录（面试讲故事素材）

理论背完还要有"血淋淋"的案例，以下全部出自作者项目调试记录：

坑 1：同 clientID 互踢，768 次重连。 MQTT 协议规定同一 clientID 后连者踢掉先连者。开发时板端 robotd 与宿主机测试 robotd 都用 car01 做 clientID，两个进程被 Broker 反复踢下线，监控页重连计数飙到 768。现象是"两台机器各自单独跑都正常，一起跑就都掉线"。修复：测试实例改独立 clientID。教训：clientID 全局唯一，多实例部署时把实例编号拼进去。

坑 2：seq 基数不一致，Web 遥控台全失效。 Web 遥控台页面的 seq 从 1 开始，而 robotd 记忆的上次 seq 已被 Python 压力测试刷到 41 万——所有命令都被 reject_dup_seq 拒绝，现象是"控制全无效、车模式恒 SAFE_STOP"。修复：网页 seq 改用 Date.now() 毫秒时间戳做基数，天然单调递增。教训：去重机制要把"新会话如何取得合法 seq 起点"也设计进去（时间戳做 seq、或服务端下发起始 seq、或带会话重置标志）。

坑 3：LWT 生效时间的预期管理。 测试 kill -9 robotd 后，上位机不是立刻看到 offline，而是等了约 15 秒——这是 KeepAlive=10s × 1.5 的协议规定判定时间，不是 bug。面试若被问"LWT 是实时的吗"，答案：不是，最坏延迟约 1.5 倍 KeepAlive；想更快就把 KeepAlive 调小，代价是心跳流量增大、弱网误判率上升，这是实时性与开销的权衡。

坑 4：匿名连接被拒的排查路径。 云端 Broker 配置 allow_anonymous false 后，旧脚本没填账号全部连不上。排查套路：先 mosquitto_sub 手工验证账号密码通不通 → 再查代码里 username/password 是否真的设进了 connectOptions → 最后抓 Broker 日志看拒绝原因（Connection Refused: not authorised）。项目代码特意做了兼容：配置空串则不设置认证字段，本地匿名开发 Broker 与云端认证 Broker 用同一份代码。

坑 5：TLS 与明文混布。 项目生产链路当前是 1883 明文 + 账号密码，密码与速度指令可被同网段嗅探，属已知风险（文档明确记录）；Web 遥控台走 9001 端口 MQTT over WebSocket 供浏览器直连。面试被问安全加固，标准答案：8883 端口 MQTT over TLS（服务端证书校验 + 链路加密），更进一步做客户端证书双向认证与 ACL（限定 car01 只能 pub/sub robot/v1/car01/#）。

【记忆口诀】
"clientID 撞车互踢惨，seq 起点归零全被拒；LWT 延迟一点五倍心跳，明文上云迟早换 TLS。"

6.6 SocketCAN 编程详解（Linux 下 CAN 开发的正确答案）

6.6.1 CAN 为什么能当"网卡"用

传统做法是用 USB-CAN 适配器走串口协议，各厂家 API 互不兼容。Linux 的答案是 SocketCAN：内核把 CAN 控制器纳入网络子系统，can0 和 eth0 一样是一张"网卡"，有自己的协议族 PF_CAN。应用层用熟悉的 socket API 收发 CAN 帧，驱动无关、可复用 socket 生态（poll/epoll/过滤器/多进程共享）。这正是作者 robotd 的方案（app/canbus/can_if.c），所有面试 SocketCAN 问题都围绕这份代码。

回忆一下 CAN 总线本身（详见第 5 篇）：多主、差分、基于 ID 仲裁（ID 越小优先级越高）、标准帧 11 位 ID、每帧最多 8 字节数据、自带 CRC 与 ACK、错误严重会 bus-off（节点自我隔离）。

6.6.2 打开 socket：四步流程

/* C —— 摘自 can_if.c 的 can_if_open() */
#include <linux/can.h>
#include <linux/can/raw.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <sys/socket.h>

int fd = socket(PF_CAN, SOCK_RAW, CAN_RAW);      /* ① 创建: CAN 协议族原始帧 */

/* ② setsockopt 三组选项(见 6.6.3) */

struct ifreq ifr = {0};
snprintf(ifr.ifr_name, sizeof(ifr.ifr_name), "%s", "can0");
ioctl(fd, SIOCGIFINDEX, &ifr);                   /* ③ 接口名 → 内核索引 */

struct sockaddr_can addr = {0};
addr.can_family  = AF_CAN;
addr.can_ifindex = ifr.ifr_ifindex;
bind(fd, (struct sockaddr *)&addr, sizeof(addr)); /* ④ 绑定到 can0 */

对比 TCP：TCP bind 绑的是"IP+端口"，CAN bind 绑的是"接口索引"——CAN 没有 IP 和端口概念，寻址单位是整张总线上的帧 ID。

6.6.3 struct can_frame 与三组 setsockopt

一帧就是一个结构体（<linux/can.h>）：

/* C —— 内核定义(简化) */
struct can_frame {
    canid_t can_id;   /* 帧 ID, 高位是标志: EFF(扩展帧)/RTR(远程帧)/ERR(错误帧) */
    __u8    can_dlc;  /* 数据长度 0~8 */
    __u8    data[8];  /* 载荷 */
};

发一帧 CMD_VEL（500mm/s + 200mrad/s + seq=1，小端，对应 candump 实捕 100 [8] F4 01 C8 00 26 00 02 00）：

/* C —— 摘自 can_if_send() */
struct can_frame cf = {0};
cf.can_id  = 0x100;                 /* CMD_VEL */
cf.can_dlc = 8;
cf.data[0] = 0xF4; cf.data[1] = 0x01;   /* linear_v = 500, 小端 */
cf.data[2] = 0xC8; cf.data[3] = 0x00;   /* angular_w = 200, 小端 */
cf.data[4] = 0x02; cf.data[5] = 0x00;   /* seq = 2 */
cf.data[6] = 0x02;                       /* flags: remote 模式 */
ssize_t n = write(fd, &cf, sizeof(cf));  /* 整帧原子写入 */

三组 setsockopt（创建后、bind 前设置）：

/* C —— 摘自 can_if_open() */
/* ① 接收过滤器: 精确匹配, 只收 4 个上行 ID(0x080/0x180/0x200/0x701) */
struct can_filter filter[4];
for (int i = 0; i < 4; i++) {
    filter[i].can_id   = g_rx_ids[i];
    filter[i].can_mask = CAN_SFF_MASK;      /* 掩码全 1 = ID 每一位都要相等 */
}
setsockopt(fd, SOL_CAN_RAW, CAN_RAW_FILTER, filter, sizeof(filter));

/* ② 错误帧过滤: CAN_ERR_MASK 使能错误帧接收, 用于 bus-off 与错误统计 */
can_err_mask_t err_mask = CAN_ERR_MASK;
setsockopt(fd, SOL_CAN_RAW, CAN_RAW_ERR_FILTER, &err_mask, sizeof(err_mask));

/* ③ 不回环: 本 socket 不收到自己发的帧(默认 SocketCAN 会回环给所有监听者) */
int recv_own = 0;
setsockopt(fd, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS, &recv_own, sizeof(recv_own));

过滤器逻辑：收到的ID & mask == can_id & mask 才放行。掩码全 1 即精确匹配；想收一段 ID 就把低位掩码清 0。内核级过滤比应用层 if 判断省 CPU——高帧率总线（本项目 STM32 上行约 70 帧/s）上很重要。

6.6.4 poll 非阻塞 drain 收帧（can_rx_thread 主循环）

作者把 fd 设为 O_NONBLOCK，用 poll + 一次唤醒内循环读完（drain）（app/canbus/thread_can_rx.c）：

/* C —— 摘自 thread_can_rx() 主循环 */
struct pollfd pfd = { .fd = fd, .events = POLLIN };

int prc = poll(&pfd, 1, 500);        /* 500ms 超时, 顺便当线程心跳节拍 */
if (prc == 0) continue;               /* 超时: 回循环刷心跳 */
if (prc < 0) {
    if (errno == EINTR) continue;     /* 被信号打断, 重试 */
    /* 真错误: 关闭接口, 外层 2s 周期重新 setup+open */
}

/* drain: 一次唤醒内读到空, 防止高帧率下"读一帧 poll 一次"积压 */
for (;;) {
    struct can_frame cf;
    ssize_t n = read(fd, &cf, sizeof(cf));
    if (n == (ssize_t)sizeof(cf)) {
        if (cf.can_id & CAN_ERR_FLAG)
            handle_error_frame(&cf);  /* 错误帧: 见 6.6.6 */
        else
            handle_data_frame(&cf);   /* 按 ID 分发解码 */
        continue;
    }
    if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK))
        break;                        /* 读空了, 回 poll */
    /* 其他错误: 关 fd 走重开流程 */
}

为什么要 drain 而不是读一帧就回 poll？一次总线突发可能同时到多帧，poll 是电平触发还好，但若改成 epoll 边沿触发（ET），不读完就再也不会被唤醒——drain 写法两种模式都安全，是网络编程通用范式。

常规配置 CAN 用命令：

sudo ip link set can0 down
sudo ip link set can0 type can bitrate 500000
sudo ip link set can0 up

但作者的开发板跑 BusyBox，其 ip 命令不支持 CAN 子命令，system("ip link ...") 直接失败；而且 shell out 依赖外部命令、错误处理粗糙、还要拼字符串。于是 robotd 用 rtnetlink（路由 netlink，内核网络配置的编程接口，等价于 ip 命令背后做的事）自己组报文（can_if.c 的 can_if_rtnl_config()）：

/* C —— 摘自 can_if_rtnl_config(), 嵌套属性结构:
 * RTM_NEWLINK { IFLA_LINKINFO { IFLA_INFO_KIND="can",
 *              IFLA_INFO_DATA { IFLA_CAN_BITTIMING, IFLA_CAN_CTRLMODE } } } */
int nl = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);

nl_req_t req = {0};
req.n.nlmsg_len   = NLMSG_LENGTH(sizeof(struct ifinfomsg));
req.n.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;   /* 要求内核回 ACK */
req.n.nlmsg_type  = RTM_NEWLINK;
req.i.ifi_family  = AF_UNSPEC;
req.i.ifi_index   = if_nametoindex("can0");

struct rtattr *linkinfo = addattr_nest(&req, IFLA_LINKINFO);
addattr_l(&req, IFLA_INFO_KIND, "can", 4);       /* 告诉内核这是 CAN 接口 */
struct rtattr *infodata = addattr_nest(&req, IFLA_INFO_DATA);

struct can_bittiming bt = {0};
bt.bitrate = 500000;                             /* 500 kbps */
addattr_l(&req, IFLA_CAN_BITTIMING, &bt, sizeof(bt));

struct can_ctrlmode cm = {0};                    /* -L 自测时: 控制器本地回环 */
cm.mask = cm.flags = CAN_CTRLMODE_LOOPBACK;
addattr_l(&req, IFLA_CAN_CTRLMODE, &cm, sizeof(cm));

addattr_nest_end(&req, infodata);                /* 回填嵌套长度 */
addattr_nest_end(&req, linkinfo);

send(nl, &req, req.n.nlmsg_len, 0);
/* 等 NLMSG_ERROR 型 ACK: err->error == 0 即成功 */

netlink 报文是"头 + 一串 rtattr 属性"，属性可嵌套，addattr_l/addattr_nest/addattr_nest_end 这三个小工具就是手工拼嵌套 TLV。面试讲清三点即可：① RTM_NEWLINK 是"修改链路"消息；② CAN 专属参数藏在 IFLA_LINKINFO→IFLA_INFO_DATA 两层嵌套里；③ NLM_F_ACK 让内核回执确认结果。完整流程是：SIOCSIFFLAGS 置 down → rtnetlink 配置 → 置 up，且各步失败仅告警（无权限或外部已配置过仍能继续尝试打开）——嵌入式部署环境多样，这种"尽力而为"的容错很实用。LOOPBACK 模式用于无 STM32 时链路自测：控制器自己发自己收，帧不上物理总线，candump 可观测。

6.6.6 错误帧与 bus-off 处理

设置了 CAN_RAW_ERR_FILTER 后，总线错误会以"错误帧"（can_id 带 CAN_ERR_FLAG）形式送到 socket。作者的处理（thread_can_rx.c 的 handle_error_frame()）：

/* C —— 错误帧处理 */
if (cf->can_id & CAN_ERR_BUSOFF) {
    g_health.can_busoff_count++;
    if (!g_health.can_bus_error) {
        g_health.can_bus_error = 1;
        push_can_event(FAULT_CAN_BUS_OFF, 0);   /* 上报故障事件 code=5 */
    }
    return;
}
/* 其他错误类(CRC/ACK/位错误等)只计数, 由 monitor 统计速率 */

bus-off 是什么：CAN 控制器发送错误计数到 255 就自我隔离（不再收发），防止故障节点拖垮总线。恢复策略两端配合：Linux 侧收到 bus-off 错误帧置位告警、上报 MQTT 故障；STM32 侧开了 AutoBusOff=ENABLE 自动恢复，且 CanBsp_Tick() 周期性检查 ESR 的 BOFF 位，必要时 Stop→Start 重新初始化。注意一个物理层常识（验证记录提到）：生产模式下总线若无其他节点，发出的帧收不到 ACK 会持续重发并计错误——这不是 bug，是 CAN 的预期行为，排查时先确认总线上有没有第二个节点。

6.6.7 虚拟 vcan：无硬件联调

宿主机开发没有 CAN 硬件？内核提供 vcan（虚拟 CAN），纯软件回环总线：

sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

candump vcan0                              # 抓帧观察
cansend vcan0 100#F401000001000000         # 手工发一帧 CMD_VEL

作者项目宿主机全链路联调就靠它：robotd -c vcan0 + STM32 模拟器 stm32_sim vcan0 + 本机 mosquitto，e2e 脚本 20 项断言全过。调试小贴士（项目 FAQ）：模拟器固件有 seq 去重，手工 cansend 首帧 seq 要从 1 开始——seq=0 与固件初始值撞车会被当成重复帧丢弃，曾让人误以为链路不通。

【记忆口诀】
"PF_CAN 建套接，SIOCGIFINDEX 绑接口；过滤、错误、不回环，三组 setsockopt 记心头；poll 等帧 drain 读完，rtnetlink 配波特不求 ip；vcan 无硬件也能调全楼。"

6.6.8 CAN 物理层与链路层速览（SocketCAN 面试的"前菜"）

问 SocketCAN 之前，面试官常先问 CAN 本身，用一页纸的篇幅补齐：

  • 物理层：双绞线差分信号（CAN_H/CAN_L），抗共模干扰；总线两端各一个 120Ω 终端电阻匹配阻抗，少了会波形反射、误码飙升。项目 STM32 侧用 TJA1042 收发器。
  • 多主与仲裁：没有主从之分，谁都能发；多节点同时发时按帧 ID 逐位仲裁——显性电平（0）压过隐性电平（1），ID 越小优先级越高，发小 ID 的节点继续发，其他的自动退让无损重试。这就是"急停用最小 ID 0x060"的物理依据。
  • 帧结构（标准数据帧）：帧起始 + 11 位仲裁 ID + RTR + 控制段（含 4 位 DLC）+ 0~8 字节数据 + CRC + ACK 槽 + 帧结束。ACK 槽由接收节点拉低应答——所以总线上只有发送者一个节点时永远收不到 ACK，会持续重发并计错误（6.6.6 提到的"无节点报错是预期行为"根源在此）。
  • 波特率与位时间：500kbps 即每位 2µs；STM32 bxCAN 配置为 42MHz APB1 / Prescaler 6 / 14 TQ（BS1=11、BS2=2、SJW=1）= 500k。总线上所有节点波特率必须一致，否则满总线错误帧——新手联调第一检查项。
  • 错误处理与 bus-off：每个节点维护发送/接收错误计数，出错加分、成功减分；计数超阈值依次进入"错误主动→错误被动→bus-off（发送错误计数 >255，节点离线自锁）"。这是 CAN 的自我保护：坏节点自动退出，不拖垮整网。

SocketCAN 与 TCP socket 差异再强调一遍（面试高频追问）：TCP socket 面向连接、字节流、有 IP+端口四元组、内核帮你重传；SocketCAN 无连接、以定长 can_frame 为单位（天然报文边界）、寻址靠帧 ID、内核不重传（CAN 控制器硬件层有一次性重发机制，但应用层拿到错误帧要自己决策）。相同点是 API 骨架一致——会 TCP socket 的人半小时就能上手 SocketCAN，这正是 Linux 把它收进网络子系统的意义。

vcan 之外的两个调试命令（宿主机或板端通用）：candump can0 实时打印总线上每一帧（can0 100 [8] F4 01 C8 00 26 00 02 00 这种格式：接口、ID、DLC、数据）；cansend can0 100#0102 手工发帧。作者在实车台架上就是靠 candump 实捕到 100 [8] F4 01 C8 00 ... 确认"500mm/s + 200mrad/s + remote 模式"的下行链路完全正确，再对比 STM32 串口日志确认逐帧到达——链路调通的标准动作：分段抓包、逐段对比。

【记忆口诀】
"差分双线一百二，ID 越小越抢先；ACK 要别人给，bus-off 自隔离；candump 分段抓，链路逐段验。"

6.7 应用层协议设计方法论：用作者的两套真实协议当范例

面试问"如果让你设计一套私有通信协议，你会考虑什么？"——用作者项目的 CAN 8 帧表 + MQTT Topic 表做完整范例，逐条讲设计理由。

6.7.1 帧 ID / Topic 规划：语义分段 + 优先级编号

作者的 CAN 应用层协议（docs/CAN_PROTOCOL.md，500kbps、标准帧、两端唯一协议依据）共 8 个帧 ID：

ID 名称 方向 类型/周期 设计理由
0x060 EMERGENCY_CMD Linux→STM32 事件 总线最小 ID = 仲裁最高优先级，急停永远抢得过任何帧
0x080 FAULT_EVENT STM32→Linux 事件 故障次之，也用很小的 ID
0x100 CMD_VEL Linux→STM32 100ms 刷新 控制命令优先级高于一切状态上报
0x180 WHEEL_SPEED STM32→Linux 20ms 高频状态放中段
0x200 SENSOR_STATE STM32→Linux 50ms 中频状态
0x300 PARAM_SET Linux→STM32 事件 参数下发，偶发，优先级无所谓
0x700 LINUX_HEARTBEAT Linux→STM32 500ms 心跳最低优先级，丢了无所谓下拍还有
0x701 MCU_HEARTBEAT STM32→Linux 500ms 同上，0x7xx 段约定为"心跳/管理段"

方法论三条：① 编号分段：0x0xx 安全事件段、0x1xx 控制段、0x2xx 传感段、0x3xx 参数段、0x7xx 心跳段——看到 ID 高位就知道语义；② CAN ID 即优先级：总线仲裁 ID 小者胜，安全关键帧必须给最小 ID，这是 CAN 协议设计与普通串口协议最大的不同；③ 事件帧与周期帧分开，事件帧带 seq 防重防丢可统计。

MQTT 侧同理（6.5.2 的 Topic 表）：cmd/ 下行命令、state/ 周期状态、event/ 不可丢事件、config/ 配置、status 在线状态——按"方向 + 语义 + QoS 需求"分层，命令 QoS1、状态 QoS0 的分级与 CAN 侧"命令高优先级、心跳低优先级"是同一哲学的两套表达。

6.7.2 字节布局：大端小端必须写进协议文档

CAN 帧只有 8 字节，每个字节都要抠。以 CMD_VEL（0x100）为例：

字节 字段 说明
0~1 linear_v i16 目标线速度 mm/s，小端
2~3 angular_w i16 目标角速度 mrad/s，小端
4~5 seq u16 逐帧递增，STM32 据此刷新命令看门狗并去重
6 flags bit0~1 模式，bit2 急停中
7 保留 0

设计要点：① 显式约定端序——项目规定"全部多字节标量小端序"写死在文档里（ARM/x86 都是小端，省去转换，但文档必须写明，否则换个 MIPS 大端平台就出鬼故事）；② 用定点数不用浮点——mm/s、mrad/s 的 i16 整数，跨语言跨平台无精度歧义（参数下发更极致：定点 ×1000，kp=0.8 → 800）；③ 保留字节置 0——将来扩展字段不破坏兼容；④ 单位写进协议——"linear_v 单位 mm/s"，多少项目事故源于两边单位理解不一致。单元测试 test_can_proto 对全部 9 种帧的字节布局逐位核对（含负值小端、位掩码），协议即测试。

6.7.3 可靠性三件套：seq / timestamp+TTL / 超时心跳

把 6.5.9 的四件套推广到任何私有协议：

  • seq（帧序号）：接收方记住上次 seq，重复丢弃（防重）、跳号统计（感知丢）。CAN 侧 Linux 所有下行帧共用一个递增计数器；STM32"新 seq 接受并刷新看门狗，重复 seq 不重复执行，明显旧 seq 丢弃并统计"。
  • timestamp + TTL：消息带出生时间与有效期，接收方算 age，过期拒绝执行——控制类命令尤其需要，状态类可省。
  • 超时参数成倍数设计：项目的数字非常值得背——CMD_VEL 刷新 100ms，STM32 命令看门狗 500ms（≈5 拍，容忍连续丢 4 帧）；Linux 心跳 500ms，STM32 判 Linux 离线 1500ms（=3 拍）；STM32 心跳 500ms，Linux 判 STM32 离线 1500ms。超时取周期的 3~5 倍：太短抖动误判，太长故障响应慢。

6.7.4 优先级分配：软件也要配合硬件

CAN 的硬件仲裁只解决"总线上谁先走"，软件还要保证"急停帧先到发送口"。作者做法：急停走独立高优先级邮箱 mb_can_tx_hi，can_tx_thread 每 20ms 节拍先清空高优先级队列再发普通帧，且普通队列每节拍最多发 8 帧防突发流量挤占急停。即"总线仲裁（0x060 最小 ID）+ 发送队列（hi 邮箱）+ 流量整形（每拍 8 帧）"三级保障，这就是"端到端优先级"的完整答案。

【记忆口诀】
"设计协议五步走：ID 分段定语义，小 ID 保安全；端序定点写进文档；seq 去重 TTL 拒旧；心跳超时三五倍；硬件仲裁软件排队两头顾。"

6.7.5 一张表总结"两套协议如何咬合"

MQTT 与 CAN 在作者项目里不是孤立的，而是一条链上的两段翻译。面试被问"你的系统 MQTT 和 CAN 什么关系"，照这张表答：

环节 MQTT 段（云↔板） CAN 段（板↔STM32） 翻译点
速度命令 cmd/velocity，QoS1，JSON，linear_v 单位 m/s 0x100 CMD_VEL，二进制，i16 单位 mm/s command_thread 单位换算 ×1000 浮点转定点
去重 MQTT seq 单调递增校验 CAN seq 逐帧递增（独立计数器，与 MQTT seq 无关） 两套 seq 各自成体系，robotd 是边界
时效 ttl_ms=500 + timestamp 过期拒绝 STM32 500ms 命令看门狗 一个管"消息新不新"，一个管"链路活不活"
离线安全 断链停刷 + 重连不恢复旧命令 看门狗超时 SAFE_STOP 停车 任一环节失效都导向停车（fail-safe）
参数下发 config/set {"param":"kp","value":0.8} 0x300 PARAM_SET 定点 ×1000 → 800 e2e 实测：MQTT 浮点进、CAN 整数出
故障上报 event/fault QoS1（不可丢） 0x080 FAULT_EVENT 上升沿触发 can_rx 收帧 → 邮箱 → state_thread → MQTT

这张表的深层逻辑是**"每一段链路用最适合自己的协议，边界处做严格翻译与校验"**：云端侧要可读、跨语言、易调试 → JSON+MQTT；控制侧要确定时延、高可靠、省资源 → 二进制+CAN。robotd 作为边缘网关，把两种协议的单位、序号、时效语义一一对齐——这就是"网关"二字在嵌入式通信里的真实含义。

6.8 JSON 数据交换

6.8.1 为什么嵌入式也爱用 JSON

JSON 是文本键值对格式：{"linear_v":0.5,"angular_w":0.3}。对比二进制协议（CAN 帧），它体积大、解析慢，但人可读、自描述、增删字段不破坏兼容、任何语言都有库——所以适合低频、人机交互、跨语言的场合：MQTT 载荷、配置文件、Web API、进程间状态导出。高频硬实时链路（CAN 上 20ms 的轮速帧）则必须用紧凑二进制。作者的选型就是范本：云端↔板子用 JSON over MQTT，板子↔STM32 用二进制 CAN 帧。

6.8.2 手写极简解析 vs cJSON

资源受限或不想引第三方库时，可以写"极简 JSON 取值器"：不做完整语法树，只在文本里定位 "key" 再按类型取值。作者的 app/common/jsonmini.c 就是这个思路，配套 test_jsonmini 覆盖字符串/整数/浮点/布尔取值、子串键防误中（找 "seq" 不能误中 "seq2"，要找带引号和冒号的 "seq":）、畸形输入不越界。够用、零依赖、几十行。

功能需求复杂（嵌套对象、数组、生成 JSON）就用 cJSON——单文件库（cJSON.c + cJSON.h 两个文件直接拖进工程），API 直观：

/* C —— cJSON 解析与生成示例 */
#include "cJSON.h"

cJSON *root = cJSON_Parse("{\"robot_id\":\"car01\",\"seq\":1001}");
const cJSON *id  = cJSON_GetObjectItemCaseSensitive(root, "robot_id");
const cJSON *seq = cJSON_GetObjectItemCaseSensitive(root, "seq");
if (cJSON_IsString(id) && cJSON_IsNumber(seq))
    printf("%s %d\n", id->valuestring, (int)seq->valuedouble);
cJSON_Delete(root);                    /* 必须释放, 防内存泄漏 */

cJSON *out = cJSON_CreateObject();     /* 生成 */
cJSON_AddStringToObject(out, "status", "online");
cJSON_AddNumberToObject(out, "battery_mv", 8040);
char *text = cJSON_PrintUnformatted(out);
/* ... 使用后 ... */
cJSON_free(text);
cJSON_Delete(out);

6.8.3 项目实战：/dev/shm JSON 进程间协作

作者板上四个进程（robotd/wifid/webd/robotd_hmi）不走 socket 也不用 DBus，而是通过 /dev/shm 下的 JSON 文件协作：

  • robotd 每 300ms 把 30+ 字段状态原子写到 /dev/shm/robotd_hmi.json（先写 .tmp 再 rename()，读者永远读到完整文件，不会读到写一半的）；
  • wifid 每 2s 写 /dev/shm/wifi_status.json，webd 据此做 80 端口门控，HMI 据此显示 WiFi 状态；
  • webd 需要 wifid 重连时，创建空文件 /dev/shm/wifi_reconfigure 当"触发器"，wifid 下个 tick 发现即 unlink 并重连。

为什么用 /dev/shm？它是 tmpfs 内存文件系统，读写纯内存无 SD 卡磨损；文件即接口，任何进程（包括 shell 脚本、调试时人手工 cat）都能读，可观测性拉满。这套"生产者原子写 JSON、消费者只读轮询"的模式，是嵌入式多进程协作的一个轻量而可靠的范式。

【记忆口诀】
"低频跨语 JSON，高频实时二进制；shm 内存当黑板，tmp 写完 rename 原子替。"

6.9 面试高频问答（15 条）

1. 三次握手为什么不是两次？
两个原因：① TCP 全双工，双方都要确认对方的初始序号，第二次握手只确认了客户端→服务端方向的序号，第三次才能确认服务端→客户端方向；② 防止历史失效连接——延迟的旧 SYN 到达时，两次握手会让服务端白白建立连接等待，三次握手中客户端会回 RST 拒绝。

2. 四次挥手为什么比握手多一次？TIME_WAIT 是什么？
TCP 全双工，两个方向独立关闭。被动方收到 FIN 时可能还有数据没发完，只能先回 ACK，稍后再发自己的 FIN，所以 ACK 与 FIN 拆成两步共四次。主动关闭方最后进入 TIME_WAIT 等 2MSL：一是保证最后一个 ACK 丢失时能对端重传 FIN 再确认，二是让旧连接的迷路报文消亡，防止污染同四元组的新连接。

3. 服务器大量 CLOSE_WAIT 说明什么？
CLOSE_WAIT 是被动关闭方收到 FIN 回了 ACK 但自己还没 close()。堆积几乎都是应用 bug：连接处理完忘了 close，或业务线程阻塞没走到 close。排查 ss -tan | grep CLOSE_WAIT 定位进程，检查代码路径。

4. TCP 粘包怎么产生、怎么解决？
TCP 是字节流协议，没有消息边界，多次 send 的字节可能被合并或拆分到任意 read 里。解法三种：定长消息、特殊分隔符、长度前缀（最通用，包头带 body 长度，先读头再按长读体）。注意 UDP 保留报文边界，无粘包。

5. TCP 靠什么保证可靠？
序号+累计确认（ACK）、超时重传与快速重传（3 个重复 ACK）、乱序重排去重、校验和、滑动窗口流量控制（管对端缓冲）、慢启动/拥塞避免等拥塞控制（管链路）。

6. TCP 和 UDP 怎么选？
要可靠、要顺序、要连接语义选 TCP（HTTP、MQTT、文件传输）；要极低延迟、容忍丢包、要广播组播选 UDP（音视频、DNS、DHCP、设备发现）。一句话：TCP 可靠但重传会引入延迟抖动，实时流宁可丢帧不愿等重传。

7. MQTT 的 QoS 0/1/2 区别？实际项目怎么用？
QoS0 最多一次（发完就忘，可能丢）；QoS1 至少一次（PUBACK 确认，未确认重发，可能重复）；QoS2 恰好一次（四步握手，开销大很少用）。我项目里命令/故障用 QoS1 保证必达，周期状态用 QoS0——丢一帧 200ms 后还有新帧；QoS1 的重复由应用层 seq 去重吸收。

8. MQTT 为什么还要自己做 seq 去重？
因为 QoS1 的语义是"至少一次"，ACK 丢失会导致 Broker 重发同一消息，协议层不去重。应用层给每条命令带递增 seq，接收方只接受 seq 大于上次值的，重复的直接拒绝计数——项目实测曾抓到 QoS1 重发被 reject_dup_seq 正确拦截。

9. LWT 遗嘱消息是干什么的？
客户端连接时预存在 Broker 的一条消息，客户端异常掉线（超 1.5×KeepAlive 无报文）时 Broker 代发。我项目 robotd 设 status/offline、QoS1、retained：进程被 kill -9 后约 15 秒上位机就能看到车离线；正常退出则主动发 retained offline 再断开，语义一致。

10. Retain 标志为什么不能用于运动控制命令？
Retained 消息会被 Broker 保存，新订阅者一订阅立即收到。若速度命令被 retain，车辆断线重连重新订阅时会立刻收到一条历史速度命令并执行——车会无故启动。我项目 Topic 表明确禁止控制类 retain，这是分层安全的一层；retain 只适合 status 这类状态位。

11. MQTT 断线后系统应该怎么行为？
协议层：KeepAlive 判定 + 周期重连（我项目 3s 一次，重连成功重新订阅）。业务层要 fail-safe：断链立即停止下发控制命令（我项目停刷 CAN CMD_VEL，STM32 500ms 看门狗超时自动停车），重连后绝不恢复旧命令，等远端重新下发。任何一环失效都导向安全状态。

12. HTTP 的 GET 和 POST 区别？状态码分类？
语义上 GET 是获取（幂等、可缓存、参数在 URL），POST 是提交/修改（参数在 body、不缓存）。状态码：2xx 成功（200）、3xx 重定向（301/302/304）、4xx 客户端错（400/401/403/404）、5xx 服务端错（500/502/503）。

13. MJPEG 视频流（multipart/x-mixed-replace）什么原理？
一条 HTTP 长连接，Content-Type 声明 multipart/x-mixed-replace 和 boundary；服务端每产出一帧 JPEG 就往连接追加一个 boundary 分段，浏览器收到新分段就替换旧画面，img 标签直接变视频。我项目 webd 用它实现车载摄像头预览：多客户端共享同一份最新帧缓冲、JPEG 只编码一次，每连接一个 detached 发送线程。

14. SocketCAN 和普通 socket 编程的异同？
同：同一套 socket API——socket/setsockopt/bind/read/write/poll，都是 fd。异：① 协议族 PF_CAN/SOCK_RAW/CAN_RAW 而非 AF_INET/SOCK_STREAM；② bind 绑接口索引（SIOCGIFINDEX 查 can0）而非 IP+端口；③ 收发单位是定长 struct can_frame（can_id+dlc+data[8]），帧天然有边界无粘包；④ 有 CAN 专属选项（CAN_RAW_FILTER/ERR_FILTER/RECV_OWN_MSGS）；⑤ 无连接、无重传，错误以错误帧上报（bus-off 处理）。我项目 robotd 用它收发 8 种帧 ID 与 STM32 通信。

15. vcan 有什么用？rtnetlink 干什么？
vcan 是内核虚拟 CAN 接口（modprobe vcan; ip link add dev vcan0 type vcan），无 CAN 硬件也能在开发机上全链路联调——我项目宿主机 robotd + STM32 模拟器 + mosquitto 的 e2e 测试就跑在 vcan0 上。rtnetlink 是内核网络配置的编程接口（NETLINK_ROUTE 套接字发 RTM_NEWLINK），用于代码里配置 CAN 波特率/工作模式——板端 BusyBox 的 ip 命令不支持 CAN，shell out 不可靠，所以项目手写 netlink 报文（IFLA_LINKINFO 嵌套 IFLA_CAN_BITTIMING）把 can0 配成 500kbps。

本篇小结：网络分层是地图，TCP/UDP 是两条主干道，HTTP/MQTT 是跑在路上的两辆车，SocketCAN 是嵌入式特有的匝道，JSON 是车上的通用货箱。学习顺序建议：先背熟三次握手/四次挥手与粘包三解法这两块"敲门砖"，再把 MQTT 的 QoS/LWT/Retain 与项目四件套（seq 去重、TTL 过期、robot_id 校验、重连不恢复旧命令）吃透，最后动手在宿主机上用 vcan + mosquitto 把作者这套链路原样跑一遍——跑过一次，面试时每个知识点都自带画面感。把每个知识点都落到一个真实项目细节上（Topic 表、8 帧 ID 表、poll drain、rtnetlink 嵌套属性），就从"背八股"升级成"讲经验"，而这正是通信方向面试拉开差距的地方。

第7篇 STM32 与 FreeRTOS 实时控制

本篇是全手册的重点篇。作者的真实项目就是用 STM32F407 + FreeRTOS 做 10ms 级实时运动控制：四路 TB6612 电机 PWM、编码器测速、四轮 PID 闭环、SG90 舵机带动 HC-SR04 超声波做多角度非阻塞测距、ADC 采集电池电压、bxCAN 周期上报轮速/距离/电量/故障/心跳、500ms 收不到 Linux 速度命令就看门狗停车。同时也用 CubeMX/HAL 开发过 STM32F103。本篇把这条链路上每个知识点拆开讲透，零基础读者读完应能从容应对 MCU/RTOS 方向面试。

7.1 MCU 基础：先搞懂这块芯片是什么

7.1.1 单片机（MCU）是什么

单片机（Micro Controller Unit，微控制器）是把 CPU、存储器（Flash/SRAM）、各种外设（GPIO、定时器、串口、ADC、CAN……）全部集成在一颗芯片上 的微型计算机。和 PC 上的 CPU 相比：

对比项 PC 的 CPU（如 x86） 单片机（如 STM32F407）
主频 GHz 级 几十~几百 MHz（F407 为 168MHz）
内存 GB 级外接 DDR 片内 KB 级 SRAM（F407 为 192KB）
程序存储 硬盘/SSD 片内 Flash（F407 为 1MB）
操作系统 Windows/Linux 裸机或 RTOS（如 FreeRTOS）
定位 通用计算 专用控制：电机、传感器、实时响应

一句话：MCU 是为"控制"而生的计算机，它最大的价值是片上外设和确定的实时性，而不是算力。我们的运动控制项目正是如此：168MHz 的主频不算快，但它能在确定的 10ms 周期里完成四轮 PID 运算和 CAN 上报，这种"确定性"才是实时控制的命根子。

7.1.2 ARM Cortex-M 家族

ARM 公司不自己造芯片，而是把 CPU 内核 IP 授权给 ST、NXP 等厂商。面向微控制器的是 Cortex-M 系列（对应还有面向应用处理器的 Cortex-A、面向高实时场景的 Cortex-R）：

  • Cortex-M0/M0+：最低功耗、最小面积，用于低成本小家电、传感器节点。
  • Cortex-M3：主流入门级 32 位内核，STM32F103 用的就是它，72MHz。
  • Cortex-M4：在 M3 基础上增加 硬件 FPU（单精度浮点单元） 和 DSP 指令（SIMD、单周期乘加 MAC），STM32F407 用的就是它，168MHz。
  • Cortex-M7：更高端，双发射流水线、带 Cache，如 STM32H7 系列。

M3 与 M4 的区别是高频面试题：

  1. FPU：M4 有单精度硬件浮点单元，一条 VADD.F32 就能完成浮点加法；M3 没有 FPU，浮点运算要靠编译器的软件浮点库模拟，慢几十倍。做 PID、滤波、姿态解算这类大量浮点运算的场景，M4 是明显更优的选择——这正是项目选 F407 的原因之一（四轮 PID 每 10ms 算一次，全浮点运算）。
  2. DSP 指令集：M4 支持单周期 32×32 乘加（MAC）、饱和运算、SIMD（一条指令并行处理两个 16 位数据），适合 FIR/IIR 滤波、FFT 等数字信号处理。
  3. 两者都是 哈佛总线架构、三级流水线、Thumb-2 指令集、NVIC 中断控制器，软件层面基本兼容。

7.1.3 STM32F103 与 F407 的定位

  • STM32F103（Cortex-M3，72MHz，Flash 64KB~512KB）：国民级入门 MCU，价格极低，教程满天飞，适合学习和简单控制。作者用它配合 CubeMX/HAL 做常规外设开发。
  • STM32F407（Cortex-M4，168MHz，Flash 1MB，SRAM 192KB）：带 FPU/DSP、高级定时器、bxCAN、以太网 MAC 等丰富外设，适合电机控制、音频处理等中高端场景。作者用它跑 FreeRTOS 做运动控制。

选型逻辑一句话：简单控制选 F103，要浮点算力、要 CAN、要高级定时器就选 F407 及以上。

7.1.4 存储映射：Flash 和 SRAM 在哪

Cortex-M 采用统一编址，4GB 地址空间有固定规划。F407 最关键的两个区域：

  • Flash（程序存储器）：起始地址 0x0800 0000，存放代码和只读常量。上电后 CPU 从这里取指运行。
  • SRAM（数据存储器）：起始地址 0x2000 0000，存放全局变量、栈、堆。F407 有 112KB 主 SRAM + 64KB CCM（只能被 CPU 访问，DMA 够不着，面试可能被问到）。

程序编译后各段的去向：

  • .text（代码）、.rodata（只读常量）→ Flash
  • .data（已初始化全局变量）：初值存 Flash，运行时拷到 SRAM（启动文件负责拷贝）
  • .bss（未初始化/零初始化全局变量）→ SRAM，启动文件负责清零
  • 栈（局部变量、函数调用）和堆（malloc/FreeRTOS 任务栈）→ SRAM

7.1.5 启动文件 startup_stm32f407xx.s 干了什么

启动文件是一段汇编，是芯片复位后执行的第一段代码，链接脚本把它放在 Flash 开头。它做四件事：

  1. 建立向量表：Flash 起始处（0x0800 0000）是一张函数指针表，第一个字是初始栈顶指针（MSP 初值），第二个字是 Reset_Handler 入口地址，后面依次是 NMI、HardFault、各外设中断的入口。上电时硬件自动把向量表前两个字装入 SP 和 PC，程序就此跑起来。
  2. Reset_Handler 里拷贝 .data、清零 .bss：把全局变量的初值从 Flash 搬到 SRAM，把 .bss 段清零——这就是为什么 C 语言能保证"未初始化全局变量为 0"，是启动代码帮标准库兑现的承诺。
  3. 调用 SystemInit()：配置时钟（把 PLL 拉起来，切到 168MHz 主频）和 FPU 使能（M4 的 CPACR 寄存器）。
  4. 跳转到 __main（或 _start），最终进入我们熟悉的 main()。

【记忆口诀】
"栈顶复位打头阵，data 搬家 bss 清零，时钟配好进 main" —— 向量表前两字是栈顶和复位入口，Reset_Handler 干完初始化和时钟，最后跳进 main。

7.1.6 时钟树 RCC：HSE/HSI/PLL 怎么配到 72M/168M

STM32 的时钟像一棵大树，根是时钟源，枝叶是各总线和外设，由 RCC（Reset and Clock Control）外设统一管理。四个基本时钟源：

  • HSI（High Speed Internal）：片内 RC 振荡器，8MHz（F1）/16MHz（F4）。不要外部元件但精度差（±1% 量级），适合临时或低成本场景。
  • HSE（High Speed External）：外部晶振，常用 8MHz（F103 板子）或 25MHz/8MHz（F407 板子）。精度高（±20ppm），做 CAN、USB、精确定时必须用它。
  • LSI/LSE：低速内部（约 40kHz，给独立看门狗）和低速外部（32.768kHz，给 RTC）。
  • PLL（锁相环）：倍频器，把低频源倍频成高频系统时钟。

F103 配 72MHz 的典型路径：HSE 8MHz → PLL 9 倍频 → SYSCLK 72MHz → AHB 不分频 72MHz；APB1 二分频 36MHz（APB1 上限就是 36MHz，但挂在 APB1 上的定时器时钟会自动 ×2 回到 72MHz，这是 F1 的经典坑点）；APB2 不分频 72MHz。

F407 配 168MHz 的典型路径：HSE 8MHz → PLL 分频 M=8 得到 1MHz → 倍频 N=336 得到 336MHz → 分频 P=2 得到 168MHz（SYSCLK）；Q=7 分频出 48MHz 给 USB/SDIO。AHB 168MHz，APB1 四分频 42MHz（定时器 ×2 为 84MHz），APB2 二分频 84MHz（定时器 ×2 为 168MHz）。

【记忆口诀】
"M 分频，N 倍频，P 出主频，Q 出 48" —— F4 的 PLL 公式 VCO = HSE/M×N，SYSCLK = VCO/P，USB 时钟 = VCO/Q。

另一个必背："APB 分频若不为 1，定时器时钟乘 2"。

用 CubeMX 时这些不用手算：在 Clock Configuration 页填好 HSE 值，直接在 HCLK 框输入 168 回车，工具自动求解 PLL 参数；超规格的路径会标红。生成的 SystemClock_Config() 函数就是这套配置的代码体现。

7.2 开发方式演进：寄存器 → 标准库 → HAL/LL → CubeMX

7.2.1 四种方式对比

1. 直接操作寄存器：通过指针读写外设寄存器，例如 GPIOC->ODR |= (1<<13); 点灯。优点：代码最精简、执行最快、对硬件理解最深刻；缺点：寄存器成百上千位，开发慢、易错、移植性差。适合学习原理和极致优化，不适合快速开发。

2. 标准外设库（SPL，Standard Peripheral Library）：ST 早期提供的 C 库，如 GPIO_SetBits(GPIOC, GPIO_Pin_13);。把寄存器操作封装成函数，开发效率大幅提升。缺点：F4 之后停止维护，已被 HAL 取代；但大量老项目和教程仍是标准库，看得懂很有必要。

3. HAL 库 + LL 库：

  • HAL（Hardware Abstraction Layer，硬件抽象层）：高度抽象、跨系列移植性好、与 CubeMX 深度集成；代价是代码体积大、执行效率略低、层层封装让新手"知其然不知其所以然"。
  • LL（Low Layer，低层库）：轻量级内联函数，几乎贴近寄存器，效率高，适合对时序敏感的场景（如精确的位操作）。HAL 和 LL 可以在同一工程混用。

4. CubeMX 图形化配置生成代码：在界面上点选引脚功能、填时钟树、配外设参数、开 FreeRTOS，一键生成完整工程。优点：引脚冲突自动检查、时钟树自动求解、几分钟搭好项目骨架，是现代 STM32 开发的主流起点；缺点：生成代码风格臃肿，不理解原理时改不动、出问题不会调。所以正确姿势是：用 CubeMX 提效，用寄存器级理解排错。

7.2.2 CubeMX 生成 Makefile 工程的目录结构

CubeMX 可以生成 Makefile/CMake 工程（方便脱离 IDE、用 GCC 编译，也方便和 Linux 侧统一构建风格），典型结构：

project/
├── Makefile                # 顶层构建脚本：源文件列表、编译选项、链接脚本
├── startup_stm32f407xx.s   # 启动文件（向量表 + Reset_Handler）
├── STM32F407ZGTx_FLASH.ld  # 链接脚本：定义 Flash/SRAM 布局与各段位置
├── Core/
│   ├── Inc/  main.h, gpio.h, tim.h, can.h, freertos.h ...   # 自己的头文件
│   └── Src/  main.c, gpio.c, tim.c, can.c, freertos.c,
│             stm32f4xx_it.c（中断服务函数）, system_stm32f4xx.c
├── Drivers/
│   ├── STM32F4xx_HAL_Driver/   # HAL/LL 库源码
│   └── CMSIS/                  # ARM 内核标准接口（core_cm4.h、寄存器定义）
├── Middlewares/
│   └── Third_Party/FreeRTOS/   # CubeMX 勾选 FreeRTOS 后集成在此
└── build/                      # make 产物：.o、.elf、.hex、.bin

理解这个结构对面试很有用：Core 是"我"的代码，Drivers 是芯片厂商的代码，Middlewares 是第三方中间件，Makefile 把三者串起来。移植工程、排查编译错误、裁剪体积都要在这三层里定位。

7.2.3 HAL 库设计思想：句柄与 API 规律

HAL 的核心抽象是句柄（Handle）：每个外设实例对应一个结构体，集中保存该外设的寄存器基地址、配置参数、运行状态、DMA 关联、回调指针。例如：

TIM_HandleTypeDef  htim1;   // 定时器1 句柄
UART_HandleTypeDef huart1;  // 串口1 句柄
CAN_HandleTypeDef  hcan1;   // CAN1 句柄
ADC_HandleTypeDef  hadc1;   // ADC1 句柄

htim1.Instance = TIM1; 指向硬件，htim1.Init.Prescaler / .Period 存配置，HAL_TIM_PWM_Init(&htim1) 把配置写进寄存器。

API 命名有严格规律：HAL_外设_动作。掌握规律后没见过的函数也能猜个八九不离十：

规律 示例
初始化/反初始化 HAL_TIM_Init() / HAL_GPIO_DeInit()
阻塞式读写 HAL_UART_Transmit() / HAL_UART_Receive()
中断式（非阻塞） HAL_UART_Transmit_IT() / HAL_UART_Receive_IT()
DMA 式（非阻塞+零拷贝） HAL_ADC_Start_DMA() / HAL_UART_Transmit_DMA()
外设子功能 HAL_TIM_PWM_Start() / HAL_TIM_IC_Start_IT()
底层宏（不进函数，直接改寄存器） __HAL_TIM_SetCompare() / __HAL_GPIO_SET_PIN()

回调机制：中断式/DMA 式操作完成后，HAL 在对应中断里调用弱定义的回调函数，用户重写它来处理结果，如 HAL_UART_RxCpltCallback()、HAL_TIM_IC_CaptureCallback()、HAL_CAN_RxFifo0MsgPendingCallback()。这构成了 HAL 事件驱动编程的骨架——我们的项目里 CAN 收速度命令、编码器溢出计数、超声波 Echo 捕获都走这条回调路径。

【记忆口诀】
"句柄一托三：硬件、配置、状态；API 三段式：HAL_外设_动作；_IT 进中断，_DMA 过搬运，Cplt 回调收结果。"

7.3 GPIO：芯片的手和脚

7.3.1 八种模式

STM32F4 的每个 GPIO 引脚可配置为以下模式（F1 的八种分类稍有不同，面试按功能理解即可）：

输入类：

  1. 浮空输入：引脚电平完全由外部决定，内部不加上下拉。用于外部已有确定驱动的信号（如有源按键、数字传感器输出）。缺点是悬空时电平不确定。
  2. 上拉输入：内部接约 40kΩ 上拉电阻，默认读到高电平。常用于低电平有效的按键。
  3. 下拉输入：内部接下拉电阻，默认读到低电平。
  4. 模拟输入：完全断开数字电路，信号直接进 ADC。ADC 采集必须配成这个模式，否则数字缓冲器会干扰采样。

输出类：
5. 推挽输出（Push-Pull）：两个 MOS 管一推一拉，能输出强劲的高电平和低电平，驱动能力强（可点亮 LED、驱动数字电路）。最常用。
6. 开漏输出（Open-Drain）：只有下拉 NMOS，能主动输出低电平，高电平靠外部上拉电阻实现。两大用途：电平转换（3.3V 芯片开漏+上拉到 5V 即可驱动 5V 逻辑）和线与（多个开漏输出接同一根线，任何一个拉低则线为低——I2C 的 SDA/SCL 必须开漏的原因）。
7. 复用推挽输出：输出信号不由 ODR 寄存器控制，而是交给片上外设（定时器 PWM、串口 TX、SPI SCK 等），电气特性为推挽。
8. 复用开漏输出：同理，信号交给外设，电气特性为开漏（如 I2C）。

【记忆口诀】
"推挽两边都能顶，开漏只会往下拉；上拉下拉防悬空，模拟输入喂 ADC；复用就是把引脚外包给外设。"

7.3.2 HAL 操作 GPIO

/* 以 PC13 板载 LED 为例（CubeMX 已生成 MX_GPIO_Init()） */
HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET);    // 输出高
HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);  // 输出低
HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);                 // 翻转（心跳灯常用）
GPIO_PinState s = HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0);  // 读输入

手写初始化也不复杂，核心是填 GPIO_InitTypeDef 再调用 HAL_GPIO_Init：

GPIO_InitTypeDef gpio = {0};
__HAL_RCC_GPIOC_CLK_ENABLE();          // 第一步永远是开时钟！
gpio.Pin   = GPIO_PIN_13;
gpio.Mode  = GPIO_MODE_OUTPUT_PP;      // 推挽输出
gpio.Pull  = GPIO_NOPULL;
gpio.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOC, &gpio);

新手第一大坑：忘了开时钟。STM32 所有外设默认时钟关闭以省电，不配 __HAL_RCC_GPIOx_CLK_ENABLE()，寄存器写进去全是空气。

7.3.3 外部中断 EXTI 与 NVIC

按键、传感器就绪信号这类"突发事件"不该用轮询，要用外部中断 EXTI（External Interrupt）。链路是：GPIO 引脚 → EXTI 线（产生边沿触发）→ NVIC（中断控制器，裁决优先级）→ CPU（跳转 ISR）。

配置要点：引脚配成 GPIO_MODE_IT_RISING / _FALLING / _RISING_FALLING（上升沿/下降沿/双边沿触发），然后使能 NVIC 通道并设优先级：

HAL_NVIC_SetPriority(EXTI15_10_IRQn, 5, 0);  // 抢占优先级5，子优先级0
HAL_NVIC_EnableIRQ(EXTI15_10_IRQn);

NVIC 优先级分组与抢占/响应优先级（必考）：

  • Cortex-M 每个中断有"抢占优先级（Preemption Priority）"和"响应优先级/子优先级（Subpriority）"两个属性，优先级寄存器只有 4 位有效（STM32），这 4 位怎么分配给两者由优先级分组决定。NVIC_PRIORITYGROUP_4 表示 4 位全给抢占优先级（16 级，0~15），子优先级恒 0；NVIC_PRIORITYGROUP_2 表示各 2 位（各 4 级）。
  • 数值越小优先级越高（注意与 FreeRTOS 任务优先级相反！）。
  • 规则：抢占优先级高的中断可以打断正在执行的低抢占优先级中断（嵌套）；抢占相同、同时到来时，响应优先级小的先执行；都相同则按中断号。响应优先级不能造成嵌套，只决定排队顺序。
  • FreeRTOS 项目里：凡是调用 xxxFromISR() 的中断，其数值优先级必须 ≥ configMAX_SYSCALL_INTERRUPT_PRIORITY（即逻辑优先级更低），否则会触发断言——这是 RTOS 中断配置的第一大坑。

HAL 的 EXTI 中断处理流程（以 PC13 按键为例）：

引脚边沿 → 硬件挂起 EXTI 挂起位 → 跳转向量表 EXTI15_10_IRQHandler
  → HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_13)   // HAL 统一入口：判断挂起位、清挂起位
    → HAL_GPIO_EXTI_Callback(GPIO_PIN_13)   // 弱定义回调，用户重写实现业务

/* stm32f4xx_it.c 中： */
void EXTI15_10_IRQHandler(void) { HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_13); }

/* main.c 中重写回调： */
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {
    if (GPIO_Pin == GPIO_PIN_13) {
        /* 中断里只做最轻的事：置标志、发队列、给信号量，赶紧返回 */
        BaseType_t hpw = pdFALSE;
        xSemaphoreGiveFromISR(xKeySem, &hpw);
        portYIELD_FROM_ISR(hpw);
    }
}

黄金法则：中断服务函数要短平快。耗时操作（打印、延时、复杂计算）一律移到任务里做，ISR 只负责"接报"和"唤醒"。

7.4 定时器全家桶

7.4.1 三类定时器的区别

类型 F407 上的成员 特点 典型用途
基本定时器 TIM6、TIM7 只有计数+溢出中断，没有输入输出引脚 定时触发（如 DAC 触发、软件节拍）
通用定时器 TIM2TIM5、TIM9TIM14 4 路输入捕获/输出比较/PWM、编码器接口 PWM、捕获、编码器测速
高级定时器 TIM1、TIM8 在通用基础上加互补输出+死区插入+刹车输入 三相电机（BLDC/FOC）、H 桥安全驱动

我们项目用 4 路通用定时器通道出电机 PWM，再用两个定时器的编码器接口读编码器——通用定时器已是主力；若上无刷电机换高级定时器。

7.4.2 计数原理：PSC + ARR

定时器本质是一台可编程计数器。三个核心寄存器：

  • PSC（Prescaler，预分频器）：把定时器时钟分频。计数频率 = 定时器时钟 / (PSC + 1)。注意寄存器值 = 分频系数 - 1。
  • ARR（Auto-Reload Register，自动重装载值）：计数器从 0 数到 ARR 后产生更新事件并归 0。溢出周期 = (ARR + 1) 个计数周期。同样实际周期 = ARR + 1。
  • CNT（Counter）：当前计数值，实时递增。

溢出频率公式：

溢出频率 = 定时器时钟 / ((PSC + 1) × (ARR + 1))
溢出周期 = ((PSC + 1) × (ARR + 1)) / 定时器时钟

经典例题：定时器时钟 84MHz，要 1MHz 计数频率怎么配？

计数频率 = 84MHz / (PSC+1) = 1MHz → PSC = 83（即分频系数 84）。此时 CNT 每 1µs 加 1。若再要 1ms 溢出一次（1kHz 中断）：ARR = 1000 - 1 = 999。

这个"PSC=83 得 1µs 计数"的配置非常常用：HC-SR04 测距用微秒计时、输入捕获测频率，都靠它。

【记忆口诀】
"PSC 分频 ARR 定周期，占空比交给 CCR；记得两个 +1：分频 +1，重载 +1。"

7.4.3 输入捕获：测频率和脉宽

输入捕获（Input Capture）让定时器在引脚电平跳变时把当前 CNT 值锁存到 CCR 寄存器并可触发中断。测频率的方法：

  1. 定时器配成 1MHz 计数（1µs 分辨率），通道配上升沿捕获。
  2. 第一次捕获记 C1，第二次捕获记 C2，则信号周期 T = (C2 - C1) × 1µs，频率 f = 1/T。若中间有溢出，还要累加溢出次数 × (ARR+1)。
  3. 测脉宽：先捕获上升沿，再改配下降沿捕获，两次之差即高电平时间——HC-SR04 的 Echo 就是这么测的（见 7.8）。
void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim) {
    if (htim->Channel == HAL_TIM_ACTIVE_CHANNEL_1) {
        uint32_t now = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1);
        uint32_t period = (now >= last) ? (now - last)
                                        : (0xFFFF - last + now + 1);
        freq_hz = 1000000.0f / period;   // 1MHz 计数下
        last = now;
    }
}

7.4.4 输出比较

输出比较（Output Compare）：CNT 与 CCR 比较，相等时对引脚执行"置高/置低/翻转"。用途：产生精确的单次脉冲、定时翻转引脚生成任意波形。PWM 本质就是输出比较的一种特例（PWM 模式下 CNT<CCR 输出有效电平，否则输出无效电平）。

7.5 PWM 与电机驱动

7.5.1 PWM 基础：占空比与频率

PWM（Pulse Width Modulation，脉宽调制）是周期固定、高电平宽度可变的方波。占空比 = 高电平时间 / 周期，等效平均电压 = 占空比 × 电源电压。电机是感性负载，PWM 经电机电感天然滤波后等效为平滑直流，所以调占空比就是调电机平均电压、调转速。

频率怎么选：太低（<100Hz）电机抖动可闻；在人耳敏感区（20Hz~20kHz）会产生刺耳啸叫；太高则开关损耗增大、H 桥 MOS 发热、PWM 分辨率下降（同频率下 ARR 变小）。直流有刷电机常用 10~20kHz，恰好避过人耳上限，是经验上的甜点。我们项目取 16kHz 左右：APB 定时器时钟 84MHz，PSC=0，ARR=5249，频率 = 84MHz/5250 = 16kHz，占空比分辨率 5250 级，绰绰有余。

7.5.2 H 桥原理与 TB6612

直流电机要正反转，就得能切换两端电压的极性，经典电路是 H 桥：四个开关管摆成 H 形，电机是横杠。对角导通（Q1+Q4）电流正转；换一对角（Q2+Q3）反转；同侧两个绝不能同时开，否则电源直通短路（俗称"炸管"），高级定时器的"死区+刹车"就是为防这个。

TB6612FNG 是把两个 H 桥和控制逻辑集成好的芯片，比老式 L298N 效率高、体积小。每一路电机（A 路）的控制引脚：

引脚 作用
PWMA 接定时器 PWM 输出，占空比决定速度
AIN1、AIN2 方向控制，见真值表
STBY 待机控制，高电平芯片工作，低电平整机待机（常接高或 MCU 控制实现急停）
AO1、AO2 接电机两端
VM/VCC/GND 电机电源/逻辑电源/地（逻辑和功率地要共地！）

真值表（STBY=1 时）：

AIN1 AIN2 PWMA 电机状态
0 0 X 停止（滑行）
0 1 PWM 正转（速度∝占空比）
1 0 PWM 反转
1 1 X 刹车（短接制动）

【记忆口诀】
"TB6612 三件套：PWM 给速度，IN1IN2 给方向，STBY 是总闸；IN 相反就转，IN 相同就停。"

四路电机就用 TIM 的 4 个通道（如 TIM1 的 CH1~CH4）出 4 路 PWM，8 个 GPIO 当方向脚，STBY 统一拉高，急停时拉低 STBY 整机断电滑行——项目的看门狗停车就是这样硬保底的。

7.5.3 HAL 调速与正反转代码

/* CubeMX 配好 TIM1：PSC=0, ARR=5249, 4 通道 PWM 模式1 */
#define PWM_ARR 5249

void Motor_Init(void) {
    HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_1);  // 四路 PWM 全部启动
    HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_2);
    HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_3);
    HAL_TIM_PWM_Start(&htim1, TIM_CHANNEL_4);
    HAL_GPIO_WritePin(STBY_GPIO_Port, STBY_Pin, GPIO_PIN_SET); // 退出待机
}

/* speed: -1000 ~ +1000，符号表方向，绝对值表油门 */
void Motor_Set(uint8_t id, int16_t speed) {
    GPIO_TypeDef *in1_port; uint16_t in1_pin, in2_pin;
    uint32_t channel;
    /* 按 id 选出该电机的方向引脚和 PWM 通道（查表）……此处略去映射 */
    uint32_t ccr = (speed < 0 ? -speed : speed) * (PWM_ARR + 1) / 1000;
    if (speed > 0) {          /* 正转：IN1=1, IN2=0 */
        HAL_GPIO_WritePin(in1_port, in1_pin, GPIO_PIN_SET);
        HAL_GPIO_WritePin(in1_port, in2_pin, GPIO_PIN_RESET);
    } else if (speed < 0) {   /* 反转：IN1=0, IN2=1 */
        HAL_GPIO_WritePin(in1_port, in1_pin, GPIO_PIN_RESET);
        HAL_GPIO_WritePin(in1_port, in2_pin, GPIO_PIN_SET);
    } else {                  /* 刹车：IN1=IN2=1 */
        HAL_GPIO_WritePin(in1_port, in1_pin, GPIO_PIN_SET);
        HAL_GPIO_WritePin(in1_port, in2_pin, GPIO_PIN_SET);
    }
    __HAL_TIM_SetCompare(&htim1, channel, ccr);  /* 改占空比，立即生效 */
}

要点：HAL_TIM_PWM_Start 每路通道各调一次；运行中调速用 __HAL_TIM_SetCompare 宏直接写 CCR，无函数调用开销，PID 任务每 10ms 调一次非常合适。

7.6 编码器测速

7.6.1 增量式编码器与 A/B 相

增量式光电/霍尔编码器输出两路方波 A 相和 B 相，相位差 90°：

  • 测速：单位时间内脉冲数 ∝ 转速。
  • 判向：正转时 A 相超前 B 相 90°，反转时 B 超前 A 90°。看"A 上升沿时刻 B 的电平"即可判向。
  • 四倍频：如果对 A、B 两相的上升沿和下降沿都计数，一圈的计数是单相单沿的 4 倍，分辨率翻 4 倍。如 13 线编码器，减速比 30，四倍频后每圈输出轴脉冲 = 13 × 30 × 4 = 1560。

7.6.2 定时器编码器接口模式

通用定时器（TIM2~TIM5 等）内置编码器接口模式：CH1 接 A 相、CH2 接 B 相，硬件自动根据两相相位关系让 CNT 增/减计数——方向判断和计数全由硬件完成，CPU 零负担，这是软件外部中断计数方案无法比拟的优势（高速时中断计数会丢脉冲、拖垮 CPU）。

/* CubeMX 选 Encoder Mode TI1 and TI2（四倍频），ARR 设 0xFFFF */
TIM_Encoder_InitTypeDef enc = {0};
enc.EncoderMode  = TIM_ENCODERMODE_TI12;   // 双相四倍频
enc.IC1Polarity  = TIM_ICPOLARITY_RISING;
enc.IC2Polarity  = TIM_ICPOLARITY_RISING;
HAL_TIM_Encoder_Init(&htim3, &enc);
HAL_TIM_Encoder_Start(&htim3, TIM_CHANNEL_ALL);

之后 __HAL_TIM_GetCounter(&htim3) 读到的就是累计脉冲数（带方向，可把 CNT 当 int16 读出正负）。10ms 控制周期里读两次计数做差，就是这个周期的位移——这是 M 法测速的直接数据源。

7.6.3 M 法 / T 法 / MT 法（高频面试题）

  • M 法（频率法）：固定时间窗口 T 内数脉冲个数 m₁，速度 n = m₁ / (T × N)，N 为每圈脉冲数。高速准：窗口内脉冲多，量化误差小；低速差：窗口内可能只有 1~2 个脉冲，±1 的量化误差直接带来巨大速度跳变。
  • T 法（周期法）：测两个相邻脉冲之间的时间间隔（用高频时钟计数 m₂），n = f_clk / (m₂ × N)。低速准：脉冲间隔长，计时分辨率高；高速差：间隔太短，来不及精确测量。
  • MT 法（M/T 法）：兼顾两者——以固定时间为基准，但测量窗口对齐到整数个脉冲沿，既数脉冲个数又测精确时间，全速度范围精度都不错，代价是实现复杂。

【记忆口诀】
"M 法数个数，快的时候准；T 法量间隔，慢的时候准；MT 法两头占，实现麻烦点。"

项目实践：10ms 控制周期下轮速范围中等，用 M 法足够。核心代码：

#define CONTROL_DT      0.01f      /* 10ms 控制周期 */
#define PPR             1560.0f    /* 四倍频后每圈脉冲数 */
#define GEAR_RATIO      1.0f

float Encoder_GetSpeedRPS(void) {
    static int16_t last_cnt = 0;
    int16_t now = (int16_t)__HAL_TIM_GetCounter(&htim3);  /* 16位有符号读法，溢出自动回绕 */
    int16_t delta = now - last;      /* 有符号减法天然处理回绕和方向 */
    last = now;
    return (float)delta / (PPR * CONTROL_DT);   /* 转/秒，正转正值 */
}

关键技巧：把计数器读成 int16_t 再做减法，ARR=0xFFFF 时溢出回绕被 C 语言的有符号回绕语义自然消化，不用写任何边界判断——面试说出来是加分项。

7.7 PID 闭环控制

开环控制（给固定 PWM）遇到负载变化、电池掉压、地面摩擦差异，速度就飘了。闭环控制用编码器反馈实际速度，与目标速度比较出误差，用 PID 算出 PWM 修正量，让车速钉死在目标值上。

7.7.1 P/I/D 三项：用开车打比方

设误差 e(t) = 目标速度 - 实际速度：

  • P（比例）管"现在"：误差越大，油门踩得越狠。P 大响应快，但太大会来回超调振荡（新手司机猛踩猛刹）；只有 P 时会有稳态误差（像定速巡航遇到上坡，差一点速度就是追不上，因为误差一小 P 的输出就不够克服阻力了）。
  • I（积分）管"过去"：把历史误差累积起来，只要误差没清零就持续加码，专门消灭稳态误差。但积分过猛会"秋后算账算过头"，造成大的超调。
  • D（微分）管"未来"：看误差的变化趋势，误差涨得快就提前收油门，抑制超调、增加阻尼。但对噪声极敏感（编码器测速噪声会被微分放大），实际常用不完全微分或干脆速度环只上 PI。

【记忆口诀】
"PID：比例管现在，积分管过去，微分管未来。"
"P 追快慢，I 消残差，D 压超调。"

7.7.2 位置式 vs 增量式

位置式 PID：直接算输出量的绝对值：

u(k) = Kp·e(k) + Ki·Σe(i) + Kd·[e(k) - e(k-1)]

特点：输出与执行机构位置一一对应（适合舵机角度、阀门开度）；积分是历史全量累加，计算量小但要防积分饱和；输出突变时执行器冲击大。

增量式 PID：算输出的变化量 Δu(k)：

Δu(k) = Kp·[e(k) - e(k-1)] + Ki·e(k) + Kd·[e(k) - 2e(k-1) + e(k-2)]
u(k)  = u(k-1) + Δu(k)

推导：把 k 和 k-1 两个时刻的位置式相减即得。特点：只与最近三次误差有关，无需累加积分，天然抗积分饱和；输出是增量，配合"先算增量、再累加、再限幅"的流程，故障时易做安全处理；电机调速几乎标配增量式（PWM 本身就是累加调节的概念）。

7.7.3 完整增量式 PID 代码并逐行讲解

/* ---------- pid.h ---------- */
typedef struct {
    float Kp, Ki, Kd;        /* 三参数 */
    float err;               /* e(k)   当前误差   */
    float err_last;          /* e(k-1) 上次误差   */
    float err_prev;          /* e(k-2) 上上次误差 */
    float out;               /* u(k)   累计输出（如 PWM 占空比 -1000~1000） */
    float out_max, out_min;  /* 输出限幅 */
    float deadband;          /* 误差死区：小于它认为已到位，不再调节 */
} PID_t;

/* ---------- pid.c ---------- */
/* 初始化：清零历史误差与输出，填入参数 */
void PID_Init(PID_t *p, float kp, float ki, float kd,
              float min, float max, float deadband) {
    p->Kp = kp; p->Ki = ki; p->Kd = kd;
    p->err = p->err_last = p->err_prev = 0.0f;
    p->out = 0.0f;
    p->out_min = min; p->out_max = max;
    p->deadband = deadband;
}

/* 每 10ms 调一次：target 目标速度，measure 编码器实测速度，返回新 PWM */
float PID_Inc_Calc(PID_t *p, float target, float measure) {
    p->err = target - measure;                       /* ① 求当前误差 e(k) */

    if (fabsf(p->err) < p->deadband) p->err = 0.0f;  /* ② 死区：微小误差不调，
                                                        防止电机在目标值附近颤抖 */

    float d_out = p->Kp * (p->err - p->err_last)     /* ③ 比例项：误差的增量 */
                + p->Ki * p->err                     /* ④ 积分项：当前误差（增量式里
                                                        Ki 直接乘误差，累加交给了 out） */
                + p->Kd * (p->err - 2*p->err_last + p->err_prev); /* ⑤ 微分项：
                                                        误差的二阶差分，预判趋势 */

    p->out += d_out;                                 /* ⑥ 增量累加成新输出 */

    if (p->out > p->out_max) p->out = p->out_max;    /* ⑦ 输出限幅：PWM 有物理上限，
    if (p->out < p->out_min) p->out = p->out_min;       限幅同时也就限制了积分增长 */

    p->err_prev = p->err_last;                       /* ⑧ 误差历史顺移一位 */
    p->err_last = p->err;
    return p->out;
}

逐行串讲：①② 处理误差（死区防抖）；③④⑤ 是增量式公式的三行直译，注意积分项在这里就是 Ki × e(k)，"积分"的效果由 ⑥ 的累加完成——这正是增量式"积分天然有界"的原因：误差为 0 时增量为 0，输出自动停住，不会像位置式那样积分项越滚越大；⑦ 限幅把输出锁在 PWM 物理范围内，这也是最朴素有效的抗积分饱和手段；⑧ 更新历史，为下一拍做准备。

积分饱和与抗饱和（补充）：位置式 PID 在目标突变或电机堵转时，误差长时间为正，积分项越积越大，等误差回头时输出严重过冲——这就是积分饱和。常用对策：①积分分离（误差大于阈值时撤掉积分）；②抗饱和算法（输出到限幅值且误差同向时停止积分）；③直接用增量式+输出限幅。项目用的就是第③种，简单可靠。

7.7.4 四轮独立 PID 结构

四个轮子各配一个 PID_t 实例，互不干扰：

PID_t pid[4];   /* 左前、右前、左后、右后 */

void Control_Task(void *arg) {                    /* FreeRTOS 任务，10ms 周期 */
    TickType_t last = xTaskGetTickCount();
    for (;;) {
        for (int i = 0; i < 4; i++) {
            float speed = Encoder_GetSpeedRPS(i); /* M 法测速 */
            float pwm = PID_Inc_Calc(&pid[i], target_rps[i], speed);
            Motor_Set(i, (int16_t)pwm);           /* 写 TB6612 */
        }
        vTaskDelayUntil(&last, pdMS_TO_TICKS(10)); /* 严格 10ms 节拍 */
    }
}

为什么要四轮独立：麦克纳姆轮/四驱底盘每个轮子负载、摩擦、电机个体差都不同，统一一个 PID 调不平；独立闭环后，上位机只需给整车运动学解算出的四个目标轮速，底层保证每个轮子各自到位。

调参步骤（高频面试题，口诀先给）：

【记忆口诀】
"先 P 后 I 再 D，P 到将振未振，I 慢慢消静差，D 轻点压超调。"

  1. Ki、Kd 置 0，从小往大加 Kp，直到响应变快、出现轻微振荡，回退一点（到"将振未振"的 6~7 成）。
  2. 加 Ki，从小到大，观察稳态误差被消除、且超调可接受即可。积分太强会让速度"冲过头再回来"。
  3. 需要时加少量 Kd 抑制超调；电机速度环噪声大，很多时候 PI 就够，D 宁小勿大。
  4. 全程串口/CAN 打印"目标-实际"曲线看响应：上升时间、超调量、稳态误差三个指标说话。

串级 PID 概念：单级 PID 只控一个量；串级是外环输出作为内环目标，层层嵌套。如"位置环 → 速度环 → 电流环"：位置环算出该跑多快，速度环算出该给多大电流/电压，内环响应远快于外环。我们项目的上位机路径跟踪（给整车速度）+ STM32 四轮速度闭环，本质就是一个两级串级结构。

7.8 执行器与传感器实战

7.8.1 SG90 舵机

SG90 是模拟舵机，控制信号是周期 20ms（50Hz）的 PWM，脉宽 0.5ms~2.5ms 对应 0°~180°（中位 1.5ms 对应 90°）。内部有电位器反馈，自己闭环，MCU 只需给脉宽。

定时器配置：定时器时钟 84MHz，PSC=83（1µs 计数），ARR=19999（20ms 周期），则 CCR 值 = 脉宽微秒数，0°→500，180°→2500，角度换算 ccr = 500 + angle * 2000 / 180。用一路 HAL_TIM_PWM_Start + __HAL_TIM_SetCompare 即可。项目里舵机托着 HC-SR04 旋转，实现"单雷达多方向扫描"，比装多个超声波省钱省引脚。

【记忆口诀】
"50Hz 是心跳，0.5 到 2.5 毫秒摆角度，1.5 居中莫忘记。"

7.8.2 HC-SR04 超声波：为什么不能死等

工作原理：Trig 引脚给 ≥10µs 高电平触发；模块发出 8 个 40kHz 声波后，Echo 引脚输出高电平，高电平宽度 = 声波往返时间。距离公式：

距离(cm) = Echo高电平时间(µs) × 340(m/s) / 2 / 10000 ≈ 时间(µs) / 58

最远距离约 4m 对应 Echo 脉宽约 23ms。

新手写法（错误示范）：触发后 while(HAL_GPIO_ReadPin(Echo)==0); 死等 Echo 变高，再死等变低并计时。问题致命：前方无障碍时 Echo 高电平要等 23ms+，这期间 CPU 全被占死，10ms 控制周期直接崩盘，电机失控。RTOS 里一个任务死等还会拖累同优先级任务；中断里死等更是大忌（中断里死等会阻塞所有同级/低级中断）。

正确做法：输入捕获 + 状态机，全程非阻塞。Echo 引脚接定时器输入捕获通道，双边沿触发：

typedef enum { US_IDLE, US_WAIT_RISE, US_WAIT_FALL } US_State_t;
US_State_t us_state = US_IDLE;
uint32_t t_rise; float distance_cm;

/* 每 60ms 由软件定时器/任务触发一次 */
void Sonar_Trigger(void) {
    if (us_state != US_IDLE) return;            /* 上次没测完，跳过 */
    us_state = US_WAIT_RISE;
    HAL_GPIO_WritePin(Trig_GPIO_Port, Trig_Pin, GPIO_PIN_SET);
    delay_us(12);                                /* 短延时可用定时器/DWT */
    HAL_GPIO_WritePin(Trig_GPIO_Port, Trig_Pin, GPIO_PIN_RESET);
}

void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim) {  /* Echo 捕获中断 */
    uint32_t now = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_2);
    if (us_state == US_WAIT_RISE) {              /* 捕获到上升沿：开始计时 */
        t_rise = now;
        __HAL_TIM_SET_CAPTUREPOLARITY(htim, TIM_CHANNEL_2, TIM_INPUTCHANNELPOLARITY_FALLING);
        us_state = US_WAIT_FALL;
    } else if (us_state == US_WAIT_FALL) {       /* 捕获到下降沿：算距离 */
        uint32_t width = (now >= t_rise) ? (now - t_rise) : (0xFFFF - t_rise + now);
        distance_cm = width / 58.0f;
        __HAL_TIM_SET_CAPTUREPOLARITY(htim, TIM_CHANNEL_2, TIM_INPUTCHANNELPOLARITY_RISING);
        us_state = US_IDLE;
        /* 通知扫描任务：该方向测距完成，舵机转下一角度 */
        BaseType_t hpw = pdFALSE;
        xTaskNotifyFromISR(scan_task, 0, eNoAction, &hpw);
        portYIELD_FROM_ISR(hpw);
    }
}

配合舵机的扫描状态机：任务把舵机转到 0°→等稳定→触发测距→等捕获完成通知→记录该角度距离→转 45°→……扫完 0/45/90/135/180° 一圈上报。整个过程没有任何阻塞等待，控制任务照常 10ms 跑。"中断里不能死等"是面试必考点，这套状态机就是标准答案。

7.8.3 ADC 采集电池电压

F407 的 ADC 是 12 位逐次逼近型，分辨率 4096，参考电压 3.3V，单次转换微秒级。测 12V 电池必须先分压：用 10kΩ+1kΩ 电阻分压（11:1），电池满电 12.6V 分压后约 1.15V，安全落在 3.3V 以内。换算公式：

V_bat = ADC值 / 4096 × 3.3V × (R1+R2)/R2 = ADC值 / 4096 × 3.3 × 11

DMA 连续采集：ADC 规则组配连续转换模式 + DMA 循环模式，转换结果自动搬进内存数组，CPU 完全不管，需要时读数组（可做多点平均滤波）：

uint16_t adc_buf[32];
HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_buf, 32);   /* 启动后硬件自动循环采 */

float Battery_Voltage(void) {
    uint32_t sum = 0;
    for (int i = 0; i < 32; i++) sum += adc_buf[i];   /* 平均滤波去毛刺 */
    return sum / 32.0f / 4096.0f * 3.3f * 11.0f;      /* 换算回电池电压 */
}

DMA 的优势在这里体现得淋漓尽致：采样是高频重复劳动，交给 DMA 这个"搬运工"，CPU 专注控制算法。电量低于阈值时通过 CAN 上报低电压故障并限制功率——这就是项目里"ADC 采集电池电压+故障上报"的完整链路。

7.9 STM32 的 bxCAN 外设

STM32F4 集成的 bxCAN（Basic Extended CAN） 是 CAN 2.0A/B 控制器（注意：CAN 收发器如 TJA1050/SN65HVD230 需外接，MCU 的 CAN_TX/CAN_RX 是逻辑电平，收发器负责转成总线差分电平 CAN_H/CAN_L）。

7.9.1 三大硬件资源

  1. 3 个发送邮箱（Tx Mailboxes）：发送时把报文装进空闲邮箱，硬件自动仲裁、自动重发、发完发中断。3 个邮箱意味着最多 3 帧排队在发。
  2. 2 个接收 FIFO（FIFO0/FIFO1）：各 3 级深度，收到的报文硬件自动入 FIFO，可取走一帧再取下一帧。两个 FIFO 可按 ID 分类（如控制命令进 FIFO0、诊断进 FIFO1）。
  3. 过滤器组（Filter Banks）：F407 单 CAN 有 14 组（CAN1/CAN2 共享 28 组）。两种模式：
    • 掩码模式：指定"ID 的哪些位必须匹配"（掩码位为 1 的位要求与 ID 完全一致）。如只收 ID 0x100~0x10F：ID 设 0x100、掩码设 0x7F0。
    • 列表模式：精确列出若干完整 ID，命中即收。
      过滤的意义：总线上报文成百上千，不过滤 CPU 会被无关中断淹没；硬件过滤零开销。

7.9.2 位时序配置：500kbps 怎么算

CAN 每位由同步段（1tq）+ BS1 + BS2 组成，位时间 = (1 + BS1 + BS2) × tq，tq = (BRP) × T_pclk。F407 的 CAN1 挂 APB1（42MHz），配 500kbps 的一组常用参数：

BRP（Prescaler）= 6 → tq = 6/42MHz ≈ 142.9ns
BS1 = 11tq，BS2 = 2tq → 位时间 = (1+11+2)×tq = 14tq
波特率 = 42MHz / (6 × 14) = 500kbps ✓
采样点 = (1+11)/14 ≈ 85.7%（CAN 推荐 75%~87.5% 之间）

CubeMX 里填 Prescaler=6、Time Seg1=11、Time Seg2=2 即可。SJW（再同步跳转宽度）常设 1tq。

【记忆口诀】
"PCLK 除以分频再除以段位和，就是波特率；BS1 长采样点后移抗干扰。"

7.9.3 HAL 收发流程

/* 初始化后必须：配过滤器 + 启动 + 开中断 */
CAN_FilterTypeDef filt = {0};
filt.FilterBank = 0;
filt.FilterMode = CAN_FILTERMODE_IDMASK;
filt.FilterScale = CAN_FILTERSCALE_32BIT;
filt.FilterIdHigh = 0x0000;  filt.FilterMaskIdHigh = 0x0000;  /* 全通（教学用） */
filt.FilterFIFOAssignment = CAN_RX_FIFO0;
filt.FilterActivation = ENABLE;
HAL_CAN_ConfigFilter(&hcan1, &filt);
HAL_CAN_Start(&hcan1);
HAL_CAN_ActivateNotification(&hcan1, CAN_IT_RX_FIFO0_MSG_PENDING);

/* 发送：填头 + 调 AddTxMessage，硬件自动排队发送（0x180 轮速帧，STM32→Linux，20ms） */
void CAN_ReportWheelSpeed(const int16_t wheel_mm_s[4]) {
    CAN_TxHeaderTypeDef hdr = { .StdId = 0x180, .IDE = CAN_ID_STD,
                                .RTR = CAN_RTR_DATA, .DLC = 8 };
    uint8_t data[8];
    for (int i = 0; i < 4; i++) {                /* 四轮 i16 mm/s 小端排布 */
        data[i*2]   = wheel_mm_s[i] & 0xFF;
        data[i*2+1] = wheel_mm_s[i] >> 8;
    }
    uint32_t mailbox;
    if (HAL_CAN_GetTxMailboxesFreeLevel(&hcan1) > 0)
        HAL_CAN_AddTxMessage(&hcan1, &hdr, data, &mailbox);
}

/* 接收：FIFO0 中断 → 回调里取报文入队 → can 任务里喂看门狗 + 解速度命令（0x100 CMD_VEL） */
void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) {
    CAN_RxHeaderTypeDef hdr; uint8_t data[8];
    HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &hdr, data);
    if (hdr.StdId == 0x100 && hdr.DLC == 8) {
        cmd_tick = xTaskGetTickCountFromISR();   /* 刷新命令到达时间戳（喂命令看门狗） */
        int16_t linear_v  = data[0] | (data[1] << 8);  /* 线速度 mm/s，小端 */
        int16_t angular_w = data[2] | (data[3] << 8);  /* 角速度 mrad/s */
        uint16_t seq      = data[4] | (data[5] << 8);  /* seq：去重 + 乱序检测 */
        /* ……seq 校验 → 差速解算 → 更新四轮目标速度（发队列给控制任务） */
    }
}

中断接收流程：报文通过过滤器入 FIFO0 → 硬件置挂起位 → 进中断 → HAL 回调 → HAL_CAN_GetRxMessage 取走 → 处理或转发给任务。注意回调里不要处理耗时业务，重活发队列给任务做。

7.9.4 周期上报与心跳设计（项目实践）

作者智能车项目 STM32 侧的真实上报表（完整 8 帧协议见 5.6.10）：

报文 ID 周期 内容
轮速上报 WHEEL_SPEED 0x180 20ms 四轮速度 i16 mm/s 小端（左前/右前/左后/右后）
传感上报 SENSOR_STATE 0x200 50ms 超声距离(u16 mm)+舵机角度+电池电压(u16 mV)+障碍/低电标志位
故障上报 FAULT_EVENT 0x080 事件（故障位上升沿） fault code(看门狗超时/障碍/低电/bus-off/电机故障)+detail+seq
心跳 MCU_HEARTBEAT 0x701 500ms mode(boot/idle/remote/safe_stop/fault)+counter+error bits，证明节点活着

心跳是分布式系统的"我还活着"声明：Linux 侧 1.5s 收不到 0x701 心跳就判定 MCU 掉线（标记离线、拒绝下发速度命令、MQTT 上报故障）；反过来 MCU 侧也有命令看门狗——500ms 收不到 ID 0x100 的 CMD_VEL 速度命令（比较当前 tick 与 cmd_tick），立即四轮目标清零 + 拉低 STBY 停车；同时 STM32 还监听 0x700 Linux 心跳。双向健康监控是机器人系统的基本功，面试讲出这套设计很加分。

7.10 FreeRTOS

7.10.1 为什么需要 RTOS

裸机开发是"大循环 + 中断"（前后台系统）：main 里 while(1) 顺序执行各功能，中断处理紧急事件。功能一多就出问题：

  • 各功能互相拖时间：显示刷新慢会拖慢控制周期；
  • 周期难以保证：while 一圈的时间不可控；
  • 无优先级：紧急任务无法插队；
  • 代码耦合严重，越写越乱。

RTOS（实时操作系统）把程序拆成多个任务（Task），由调度器按优先级分配 CPU，每个任务像独占 CPU 一样写代码。我们项目拆成：控制任务（10ms，最高优先级）、CAN 通信任务、超声波扫描任务、故障监控任务、idle 钩子喂狗——各干各的，互不阻塞，这就是 RTOS 的价值。

7.10.2 任务：创建、优先级、四种状态

xTaskCreate(Control_Task,          /* 任务函数 */
            "ctrl",                /* 名字（调试用） */
            512,                   /* 栈深度，单位是字（word），512字=2KB */
            NULL,                  /* 参数 */
            tskIDLE_PRIORITY + 3,  /* 优先级：数值越大越高（与 NVIC 中断相反！） */
            &ctrl_handle);         /* 句柄，用于通知/删除 */
vTaskStartScheduler();             /* 启动调度器，之后 CPU 归调度器管 */

任务四种状态（状态机是面试常客）：

        创建                     抢到CPU(最高优先级就绪任务)
  ─────────────→ Ready(就绪) ─────────────────────→ Running(运行)
                     ↑                                  │
        等待的事件/队列/信号量到来                       │ 调 vTaskDelay / xQueueReceive 阻塞等待
                     │                                  ↓
                     └────────────── Blocked(阻塞) ←────┘
   Suspended(挂起)：vTaskSuspend() 进入，只能被 vTaskResume() 救出，
                   不会自己醒来，也不参与调度

一句话：Running 在跑，Ready 排队等 CPU，Blocked 在等事件（有时限），Suspended 被人工冻结。

7.10.3 调度器：抢占 + 时间片

configUSE_PREEMPTION = 1 时调度策略：

  • 抢占式：高优先级任务一旦就绪（中断里发了信号量、延时到期），立刻打断当前运行的低优先级任务。这保证了实时性——10ms 控制任务永远是第一时间跑。
  • 同优先级时间片轮转：configUSE_TIME_SLICING = 1 时，同优先级任务每个 Tick 切换一次。

7.10.4 vTaskDelay vs vTaskDelayUntil（必考）

  • vTaskDelay(n)：相对延时，从调用这一刻起阻塞 n 个 Tick。如果任务本身执行花了 x ms，实际周期 = x + n，周期会漂移、不精确。
  • vTaskDelayUntil(&last, n)：绝对周期，以上次唤醒点为基准对齐到固定节拍，自动扣除任务执行时间，周期严格等于 n。10ms 控制环必须用它（见 7.7.4 的代码）。

【记忆口诀】
"Delay 是闹钟从现在定，DelayUntil 是班车按点发——控制环坐班车。"

7.10.5 Tick 与 10ms 控制周期

FreeRTOS 的节拍由 SysTick（或定时器）中断产生，频率 configTICK_RATE_HZ，常设 1000Hz（1ms/Tick）。10ms 周期 = pdMS_TO_TICKS(10) = 10 个 Tick。注意 Tick 分辨率就是延时精度的下限：vTaskDelay(1) 实际阻塞 0~1 个 Tick 之间（最坏情况不到 1ms），因为调用时刻可能刚错过一个节拍。要更细的节拍就提高 TICK 频率，代价是 Tick 中断开销变大。

7.10.6 任务间通信与同步全家桶

1. 队列（Queue）：任务/中断间传递数据的 FIFO，存拷贝。CAN 任务把解析出的速度命令发给控制任务：

QueueHandle_t q = xQueueCreate(8, sizeof(Cmd_t));     /* 8格深 */
Cmd_t c = {vx, wz};
xQueueSend(q, &c, 0);                                  /* 任务里发 */
xQueueReceive(q, &c, pdMS_TO_TICKS(10));               /* 任务里收，最多等10ms */
/* 中断里用 ISR 版本： */
BaseType_t hpw = pdFALSE;
xQueueSendFromISR(q, &c, &hpw);
portYIELD_FROM_ISR(hpw);

2. 二值信号量（Binary Semaphore）：容量为 1 的信号量，只做"事件通知"，不带数据。典型场景：中断发生 → xSemaphoreGiveFromISR → 阻塞等待的任务被唤醒处理（中断与任务同步的标准姿势）。

3. 计数信号量（Counting Semaphore）：容量 N，管理"N 个同类资源"（如 3 个发送邮箱、连接池），Give 计数+1、Take 计数-1，减到 0 后 Take 阻塞。

4. 互斥量（Mutex）与优先级继承（必考）：保护共享资源（串口、全局变量、外设），xSemaphoreTake(mutex, ...) 进入临界区、xSemaphoreGive 退出。互斥量 vs 二值信号量的三大区别：

互斥量 二值信号量
用途 保护共享资源（谁拿谁还） 事件同步（中断给、任务拿，跨上下文）
优先级继承 有 无
递归获取 支持递归互斥量 不支持

优先级反转（连环考点）：低优先级任务 L 持有互斥量时被中优先级任务 M 抢占，高优先级任务 H 又来等互斥量——结果 H 实际在等 L，而 L 被 M 压着跑不了，H 变相排在 M 后面，优先级"反转"了。FreeRTOS 的解法是优先级继承：H 等待期间，把持有互斥量的 L 临时提升到 H 的优先级，L 得以尽快跑完释放锁，H 恢复后自己拿锁。二值信号量没有此机制，所以保护资源必须用互斥量。更彻底的方案还有优先级天花板协议（把资源优先级定为其所有使用者中的最高优先级）。

5. 事件组（Event Group）：一组 24 个标志位，任务可等待"任意一位/全部位"就绪。适合多事件组合：如"CAN 在线 AND 电压正常 AND 无堵转"三个条件都满足才允许上电。比堆多个信号量优雅。

6. 软件定时器（Software Timer）：由守护任务统一执行的定时回调，分一次性/周期性。适合轻量周期事务（如 1s 上报电量、60ms 触发超声波）。回调在守护任务上下文执行，禁止阻塞，重活照样转给任务。

7. 任务通知（Task Notification）：直接通知到任务句柄，速度比信号量快约 45%、不占队列 RAM，一个任务一个 32 位通知值，可模拟二值/计数信号量、事件组、轻量邮箱。缺点：只能一对一（一个任务收）。超声波捕获完成通知扫描任务（7.8.2）用的就是它。

【记忆口诀】
"队列运数据，二值传令箭，计数管资源，互斥保平安（带继承防反转），事件组等组合，软定时跑轻活，任务通知最快最省。"

7.10.7 临界区与 FromISR

临界区保护极短的共享数据访问，比互斥量轻：

taskENTER_CRITICAL();      /* 关调度（实际是关可管理的中断） */
shared_var++;              /* 极短操作 */
taskEXIT_CRITICAL();       /* 恢复 */

规则：临界区必须极短（几条指令），期间不能调 API、不能阻塞；长临界区会让中断延迟飙升、实时性崩溃。时间稍长的互斥保护请用互斥量。

中断里调 FreeRTOS API 的三条铁律：

  1. 只能用 xxxFromISR() 版本（普通版本会调用可能引起调度的代码，中断上下文不允许）；
  2. 该中断的 NVIC 优先级数值必须 ≥ configMAX_SYSCALL_INTERRUPT_PRIORITY（F4 默认 5，即可配置 5~15），否则临界区保护失效、系统断言崩溃；
  3. 传 xHigherPriorityTaskWoken 出参：API 若唤醒了更高优先级任务会把它置 pdTRUE，中断返回前 portYIELD_FROM_ISR(hpw) 立即请求上下文切换，让被唤醒的高优先级任务第一时间跑，而不是等下一个 Tick——这是实时性的关键细节。

7.10.8 内存与栈：heap_4、栈溢出检测、空闲任务

heap_4：FreeRTOS 提供 5 种堆实现，CubeMX 默认 heap_4——首次适应算法 + 相邻空闲块合并（缓解碎片），支持任意顺序分配释放。configTOTAL_HEAP_SIZE 划定一块静态大数组，所有 xTaskCreate 的任务栈、队列、信号量都从这里切。和 C 库 malloc 的区别：heap_4 可预测、可配栈越界检查，碎片问题靠合并缓解但长时间运行仍需注意；有的项目干脆全静态创建（xTaskCreateStatic）彻底避开堆。

栈溢出检测（项目排障救命功能）：

#define configCHECK_FOR_STACK_OVERFLOW  2   /* FreeRTOSConfig.h 中开启 */

void vApplicationStackOverflowHook(TaskHandle_t t, char *name) {
    /* 哪个任务栈溢出一目了然，立刻CAN上报故障+停车 */
    Error_Handler();
}

方法 2 在任务栈填充 0xA5 模式，切换时检查栈底模式是否被改写。任务栈给多少合适？跑起来后用 uxTaskGetStackHighWaterMark() 看历史最小剩余量，再留 50% 余量。局部大数组、printf 家族、深递归是栈杀手。

空闲任务与钩子：优先级 0 的 Idle 任务在无人可跑时运行，负责回收被删除任务的内存。可挂钩子 vApplicationIdleHook() 放低优先级杂务（如喂独立看门狗、统计 CPU 利用率、进入低功耗）——钩子里禁止阻塞，否则内存回收会被拖死。

【记忆口诀】
"中断三铁律：FromISR 打头，优先级设对，Woken 别忘 Yield；临界区要短，互斥量管长；heap_4 防碎片，栈水印量余量。"

7.11 软硬件协同调试

ST-Link 是 ST 官方的调试/烧录器，通过 SWD（Serial Wire Debug，串行线调试） 与 MCU 通信，只需 4 根线（比 JTAG 的 20 针精简得多）：

ST-Link MCU 说明
SWDIO PA13 双向数据线
SWCLK PA14 时钟线
GND GND 必须共地（新手最常犯的错）
3.3V VCC（可选） 给目标板供电或仅做电平参考

烧录用 STM32CubeProgrammer 或 st-flash write app.bin 0x8000000；调试可单步、断点、看变量、看外设寄存器（SFR 视图是排查"配置没生效"的神器）。注意：SWD 引脚若被代码复用成 GPIO 会导致下不进程序，需复位状态下连接（connect under reset）。

7.11.2 OpenOCD + GDB：开源调试链

不想用商业 IDE 时，Linux 下用 OpenOCD（片上调试器）+ arm-none-eabi-gdb 搭建全开源调试环境：

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg   # 起 GDB Server（3333端口）
arm-none-eabi-gdb build/app.elf
(gdb) target extended-remote localhost:3333
(gdb) monitor reset halt          # 复位并停住
(gdb) load                        # 烧录
(gdb) break Control_Task          # 打断点
(gdb) continue / step / print pid[0].err

还能 dump 内存、看 FreeRTOS 任务列表（装 OpenOCD 的 rtos 感知插件后 info threads 直接显示任务名）。Makefile 工程 + OpenOCD + GDB，是与 Linux 侧开发体验最统一的组合。

7.11.3 串口日志：最便宜也最有用的调试手段

printf 重定向到 UART（重写 _write/fputc），在关键路径打日志：PID 的目标/实际速度、CAN 收发计数、任务栈水印。注意事项：

  • 中断里不要 printf（见问答 Q6）：慢、可能重入、可能死锁。
  • 高频日志（10ms 一条）会拖垮系统，可用环形缓冲 + DMA 发送，或降频打印。
  • 发行版保留 CAN 上报通道做"远程日志"——我们的项目就是把关键状态通过 CAN 周期上报，Linux 侧统一记录。

7.11.4 用 STM32 模拟器做 Linux 侧协议联调

机器人项目常见痛点：Linux 上位机和 STM32 固件是两个人/两条时间线开发的，硬件不在手边时上位机没法测。解法：写一个"STM32 模拟器"——在 Linux 上按双方约定的 CAN/串口协议，模拟 STM32 的行为（收到速度命令回 ACK、周期发轮速/距离/电量/心跳、超时主动发故障帧），上位机程序接虚拟 CAN（SocketCAN 的 vcan0）或伪终端串口即可联调。

思路要点：

  1. 协议先行：CAN ID 表、字节序、定点化系数、超时规则先写成文档，双方各自对着文档开发。
  2. 模拟器行为可控：能注入异常（停发心跳、回报低电压、回复乱序帧），验证上位机的容错和看门狗逻辑。
  3. 回归测试：把模拟器接进 CI，每次改协议或上位机代码自动跑一遍收发用例。

这套"虚拟节点联调"的思路在汽车行业（CANoe 仿真节点）是标准做法，面试主动讲出来是明显加分项。

【记忆口诀】
"调硬件：SWD 四线共地打头阵；调软件：日志环形缓冲不阻塞；调系统：协议先行造模拟器，没硬件也能联调。"

7.12 面试高频问答（15 条）

Q1：任务（Task）和 Linux 线程有什么区别？

任务跑在 RTOS 上：无 MMU、所有任务共享同一地址空间、由 RTOS 调度器按优先级抢占调度、每个任务栈大小创建时定死；线程跑在 Linux 上：有 MMU 虚拟内存隔离、由 CFS/EEVDF 等调度器调度、默认追求公平而非实时。关键差异：实时确定性——RTOS 高优先级任务获得 CPU 的延迟是可预测的微秒级；Linux 普通线程的调度延迟不可保证（除非 PREEMPT_RT 补丁）。另外任务间通信（队列/信号量）开销远小于 Linux 的 IPC。

Q2：互斥量和二值信号量有什么区别？

三点：①用途不同——互斥量保护共享资源（谁持有谁释放），二值信号量做事件同步（常是中断给、任务拿）；②互斥量有优先级继承，能缓解优先级反转，二值信号量没有；③互斥量支持递归获取（同一任务多次 Take），二值信号量不行。所以：保护资源用互斥量，中断同步用二值信号量。

Q3：什么是优先级反转？怎么解决？

高优先级任务 H 等低优先级任务 L 持有的锁，L 又被中优先级任务 M 抢占，导致 H 实际排在 M 后面运行，优先级"倒挂"。解法：①优先级继承（FreeRTOS 互斥量自带）：H 等待期间把 L 临时提到 H 的优先级，让 L 尽快释放锁；②优先级天花板协议：把锁的优先级定为所有使用者中的最高者，持锁即提升；③工程上缩短临界区、能用任务通知/消息传递就不用锁。

Q4：PID 怎么调参？

口诀"先 P 后 I 再 D"：①I、D 置 0，从小到大加 P 到系统响应快且将振未振，回退两三成；②慢慢加 I，消除稳态误差又不引入大超调；③需要抑超调再加少量 D，电机速度环噪声大时 PI 常已够用。评价三指标：上升时间、超调量、稳态误差。上位机画"目标-实际"曲线边调边看。还要做输出限幅（抗积分饱和）和死区（防目标值附近颤抖）。

Q5：编码器 M 法和 T 法测速有什么区别？

M 法（频率法）：固定时间窗口数脉冲个数，高速精度好（脉冲多量化误差小），低速差（窗口内脉冲稀少）；T 法（周期法）：测相邻脉冲的时间间隔，低速精度好，高速来不及测。MT 法结合两者：测量窗口对齐整数个脉冲沿，同时数脉冲和测时间，全速域精度均衡但实现复杂。STM32 上常用定时器编码器接口计数 + 固定周期读差值实现 M 法；T 法用输入捕获测脉宽实现。

Q6：中断里能 printf 吗？为什么？

不能（或强烈不建议）。原因：①printf 内部要做格式解析、字符串处理，执行时间几十到几百微秒，中断里久占 CPU 会让同级/低级中断延迟甚至丢失，实时性崩溃；②串口发送若用阻塞方式更是灾难；③printf 通常不可重入，若主程序也在用，中断里再打会破坏输出甚至死锁（HAL 的串口句柄锁在中断上下文拿不到锁）。正确姿势：中断里只置标志/发队列/给信号量/写环形缓冲，由任务统一打印。

Q7：vTaskDelay 的精度是多少？为什么不准？

精度是一个 Tick（如 1kHz 时为 1ms），且 vTaskDelay(1) 实际阻塞在 0~1 个 Tick 之间：因为调用时刻距下一个 Tick 中断的时间不确定，可能刚调完就来节拍被唤醒。要保证严格周期用 vTaskDelayUntil；要亚毫秒精度提高 configTICK_RATE_HZ 或用硬件定时器中断；RTOS 延时本来就不该当精密定时器用。

Q8：为什么 FreeRTOS 里中断优先级数值必须 ≥ configMAX_SYSCALL_INTERRUPT_PRIORITY？

FreeRTOS 的临界区通过屏蔽"可管理的中断"实现（BASEPRI 寄存器），只有数值 ≥ 该阈值（逻辑优先级更低）的中断才会被屏蔽，才能安全调用 FromISR API——否则中断可能在临界区内打进来执行内核 API，破坏内核链表一致性，直接断言/死机。F4 默认阈值 5：调 API 的中断配 5~15，不调 API 的（如纯硬件触发）可以配 0~4 享受零延迟。

Q9：位置式 PID 和增量式 PID 怎么选？

执行机构是"位置型"（舵机角度、阀门开度、机械臂）用位置式，输出即位置；执行机构是"增量型/速度型"（电机 PWM 调速）用增量式：只依赖最近三次误差、无需积分累加、天然抗积分饱和、输出变化平滑、故障时易做安全限幅。我们的四轮电机速度环就是增量式 + 输出限幅。

Q10：PWM 频率选多少？为什么电机常用 10~20kHz？

人耳听觉上限约 20kHz，低于它电机会发出可闻啸叫；高于它则 MOS 管开关损耗增大、发热严重，且同主频下 ARR 变小导致占空比分辨率下降。10~20kHz 是安静与效率的折中。例：84MHz 时钟、ARR=4199 得 20kHz，分辨率 4200 级。

Q11：CAN 报文发送失败可能有哪些原因？

①没接收发器或收发器没供电（bxCAN 只是控制器）；②总线上没有其他节点 ACK——CAN 规定发送必须收到至少一个节点的应答位，单机自测要用环回（Loopback）模式；③波特率两边不一致；④终端电阻缺失（总线两端各 120Ω）；⑤过滤器把回环自收的帧滤掉了导致误判；⑥发送邮箱满且未做重试。排查顺序：环回自测 → 波特率/位时序 → 收发器/接线/终端电阻 → 示波器/逻辑分析仪看波形。

Q12：定时器 1MHz 计数怎么配？溢出 1ms 一次呢？

假设定时器时钟 84MHz：PSC = 84 - 1 = 83，即 84 分频得 1MHz（1µs/计数）；要 1ms 溢出再令 ARR = 1000 - 1 = 999。通用公式：分频系数 = 定时器时钟/目标计数频率，PSC 和 ARR 寄存器值都要再减 1。F1 上注意 APB1 分频不为 1 时定时器时钟自动 ×2。

Q13：队列、信号量、互斥量、任务通知分别什么时候用？

传数据用队列（多对多、带缓冲）；中断通知任务用二值信号量或任务通知（一对一且要最快最省 RAM 用任务通知）；管理 N 个同类资源用计数信号量；保护共享资源用互斥量（要优先级继承）；等多事件组合用事件组。项目实例：CAN 命令→队列，超声波捕获完成→任务通知，串口打印口→互斥量。

Q14：FreeRTOS 任务栈大小怎么确定？栈溢出怎么查？

先按经验给（512~2048 字），跑起来后用 uxTaskGetStackHighWaterMark() 读历史最小剩余，留 50% 余量后收敛。排查：开 configCHECK_FOR_STACK_OVERFLOW = 2 并实现 vApplicationStackOverflowHook，溢出时钩子函数拿到任务名，直接定位元凶。常见栈杀手：函数内大数组、printf/sprintf、深递归、HAL 某些库函数的局部缓冲。

Q15：裸机开发和 RTOS 开发怎么选？

功能单一、时序简单（一个传感器读数+一个显示）：裸机前后台足够，资源占用最小、启动最快。多任务并发、周期要求严格、通信协议复杂（如我们的底盘：10ms 控制环 + CAN 协议栈 + 多传感器扫描 + 故障监控同时跑）：必须 RTOS，否则周期互相干扰、代码无法维护。判据一句话：有几个独立的"周期/事件节奏"就该有几个任务，节奏一多裸机大循环必然崩盘。

本篇小结：从 MCU 的存储与时钟讲起，经 GPIO/定时器/PWM/编码器/PID 搭起电机控制链路，再到舵机、超声波、ADC 的传感器实战，CAN 通信与 FreeRTOS 系统组织，最后落到协同调试方法论——这正是作者 STM32F407 + FreeRTOS 运动控制项目的完整技术栈。建议配合本篇逐行敲一遍 PID 与非阻塞超声波代码，面试时这两段是最常被要求手写的内容。

第8篇 数据存储、显示与调试工具链

嵌入式项目做到最后，比的往往不是"功能能不能跑"，而是"出了问题能不能查"。本篇把一条完整的工程链路串起来：数据怎么存（SQLite）、图像怎么采（V4L2）、屏幕怎么画（framebuffer + LVGL），再到工程师吃饭的家伙——Git、GDB、can-utils、i2c-tools、tcpdump/Wireshark、ST-Link/OpenOCD、示波器与逻辑分析仪。全文结合作者的智能物流 AGV 项目（Linux 主控 robotd/webd/robotd_hmi + STM32 下位机），所有例子都是真实可运行的工程代码风格。

8.1 SQLite3 嵌入式数据库

8.1.1 为什么嵌入式选 SQLite

面试第一问："嵌入式设备上存数据，为什么不用 MySQL？"

答案记住四个词：零配置、单文件、无服务器、事务安全。

  • 零配置：没有安装、没有初始化脚本，sqlite3_open() 一调用就有数据库。
  • 单文件：整个数据库就是一个 .db 文件，备份 = cp，拷到 PC 上直接用 sqlite3 命令行分析。
  • 无服务器：没有独立的数据库进程，SQLite 是一个 C 库，直接链接进你的程序，跨进程靠文件锁协调。
  • 事务安全（ACID）：写一半掉电不会得到半个数据库——这对靠电池/会断电的嵌入式设备是刚需。

对比：MySQL/PostgreSQL 需要跑一个常驻服务进程，吃几百 MB 内存，A7 单核小板跑不动也没必要；纯写文件（CSV/日志）没有索引、没有事务、查询全靠 grep。SQLite 正好卡在中间：比文件强，比服务器轻。作者项目 robotd 的数据落盘就用的 SQLite，库文件也就几百 KB。

【记忆口诀】零配置、单文件、无服务、有事务——嵌入式数据库四张牌。

8.1.2 SQL 基础 CRUD 速成

CRUD = Create / Read / Update / Delete。零基础读者只需掌握下面八句，面试足够：

-- 建表：IF NOT EXISTS 防止重复建表报错
CREATE TABLE IF NOT EXISTS cmd_log (
    id INTEGER PRIMARY KEY AUTOINCREMENT,  -- 自增主键
    monotonic_ts INTEGER,                  -- 单调时间戳(ms)
    wall_ts INTEGER,                       -- 墙上时间(Unix秒)
    source TEXT,
    target_v REAL,
    result TEXT
);

-- C: 插入
INSERT INTO cmd_log(monotonic_ts, wall_ts, source, target_v, result)
VALUES (123456, 1700000000, 'mqtt', 0.5, 'ok');

-- R: 查询（WHERE 过滤、ORDER BY 排序、LIMIT 限量，三板斧）
SELECT id, source, target_v FROM cmd_log
WHERE result = 'ok'
ORDER BY id DESC
LIMIT 10;

-- U: 更新（千万别忘 WHERE，否则全表被改！）
UPDATE cmd_log SET result = 'timeout' WHERE id = 42;

-- D: 删除（同样别忘 WHERE）
DELETE FROM cmd_log WHERE monotonic_ts < 100000;

要点提示：

  • INTEGER PRIMARY KEY AUTOINCREMENT 是 SQLite 里自增 ID 的标准写法。
  • WHERE 是 DELETE/UPDATE 的生命线，面试可以主动提"忘加 WHERE 全表完蛋"这个经典事故。
  • SQLite 类型是"弱类型亲和"：常用 INTEGER / REAL / TEXT / BLOB 四种足够。

8.1.3 C API 完整示例

SQLite 的 C API 面试必背七个函数，按调用顺序：

  1. sqlite3_open(path, &db) — 打开/创建数据库文件
  2. sqlite3_prepare_v2(db, sql, -1, &stmt, NULL) — 把 SQL 编译成语句对象（预编译，防止 SQL 注入，且可重复执行）
  3. sqlite3_bind_xxx(stmt, 序号, 值) — 给 SQL 里的 ? 占位符填值（1 起始）
  4. sqlite3_step(stmt) — 执行一步；查询时返回 SQLITE_ROW 表示还有行，SQLITE_DONE 表示结束
  5. sqlite3_column_xxx(stmt, 列号) — 取当前行第 N 列的值（0 起始）
  6. sqlite3_finalize(stmt) — 销毁语句对象
  7. sqlite3_close(db) — 关闭数据库
#include <sqlite3.h>
#include <stdio.h>

int demo_insert_and_query(sqlite3 *db, double v, const char *src)
{
    /* ---- 写：prepare + bind + step ---- */
    sqlite3_stmt *stmt = NULL;
    const char *sql =
        "INSERT INTO cmd_log(monotonic_ts, source, target_v, result)"
        " VALUES(?,?,?,?);";
    if (sqlite3_prepare_v2(db, sql, -1, &stmt, NULL) != SQLITE_OK) {
        fprintf(stderr, "prepare: %s\n", sqlite3_errmsg(db));
        return -1;
    }
    sqlite3_bind_int64(stmt, 1, 123456);        /* 第1个? = 时间戳 */
    sqlite3_bind_text(stmt, 2, src, -1, SQLITE_TRANSIENT);
    sqlite3_bind_double(stmt, 3, v);
    sqlite3_bind_text(stmt, 4, "ok", -1, SQLITE_TRANSIENT);
    if (sqlite3_step(stmt) != SQLITE_DONE)
        fprintf(stderr, "step: %s\n", sqlite3_errmsg(db));
    sqlite3_finalize(stmt);

    /* ---- 读：prepare + step 循环 + column ---- */
    sqlite3_prepare_v2(db,
        "SELECT id, target_v FROM cmd_log ORDER BY id DESC LIMIT 5;",
        -1, &stmt, NULL);
    while (sqlite3_step(stmt) == SQLITE_ROW) {
        int id      = sqlite3_column_int(stmt, 0);    /* 列号从0开始 */
        double tv   = sqlite3_column_double(stmt, 1);
        printf("id=%d v=%.2f\n", id, tv);
    }
    sqlite3_finalize(stmt);
    return 0;
}

int main(void)
{
    sqlite3 *db = NULL;
    if (sqlite3_open("/root/data/robot.db", &db) != SQLITE_OK)
        return 1;
    sqlite3_exec(db,
        "CREATE TABLE IF NOT EXISTS cmd_log("
        " id INTEGER PRIMARY KEY AUTOINCREMENT,"
        " monotonic_ts INTEGER, source TEXT, target_v REAL, result TEXT);",
        NULL, NULL, NULL);
    demo_insert_and_query(db, 0.5, "mqtt");
    sqlite3_close(db);
    return 0;
}

几个高频细节：

  • bind 序号从 1 开始，column 序号从 0 开始——经典易错点。
  • SQLITE_TRANSIENT 表示让 SQLite 自己拷贝字符串，调用方的临时缓冲可以马上释放。
  • 不用 bind 直接拼字符串构造 SQL，既慢又有 SQL 注入风险；预编译语句 + bind 是工程标准做法，而且 prepare 一次可以反复 sqlite3_reset + bind + step 复用。

【记忆口诀】"开-备-绑-步-取-毁-关"：open、prepare、bind、step、column、finalize、close。

8.1.4 事务、WAL 与攒批：为什么快 100 倍

面试高频题：为什么攒批写比逐条写快这么多？

答案在提交（commit）成本上。SQLite 每条 INSERT 如果单独执行，默认每条都是一个独立事务，提交时要：

  1. 把脏页写入 journal/WAL；
  2. fsync() 强制刷到存储介质——这是一次毫秒级的物理操作，eMMC/SD 卡上常常 1~10ms。

逐条写 = 每条都付一次 fsync 的钱；攒批 32 条放一个事务里 = 32 条只付一次 fsync。瓶颈从"每条 1 次刷盘"变成"每批 1 次刷盘"，吞吐轻松提升一两个数量级。作者项目 thread_storage 线程就是这么做的：攒满 32 条或者距上次写入超过 200ms（两个条件先到先触发），就 BEGIN IMMEDIATE; ... COMMIT; 单事务落盘（代码里 #define STORE_BATCH_MAX 32 / STORE_BATCH_MS 200）。200ms 兜底保证数据延迟不会无限大——掉电最多丢 200ms 的数据。

三个配套 PRAGMA（作者项目 storage_db.c 原样）：

sqlite3_exec(g_db, "PRAGMA journal_mode=WAL;",   NULL, NULL, NULL);
sqlite3_exec(g_db, "PRAGMA synchronous=NORMAL;", NULL, NULL, NULL);
sqlite3_exec(g_db, "PRAGMA busy_timeout=2000;",  NULL, NULL, NULL);
  • WAL（Write-Ahead Logging，预写日志）：写操作先追加到 -wal 日志文件，读操作继续读主库旧快照——读写不互斥，并发好；传统 rollback journal 模式下写会挡住所有读。WAL 还能让崩溃恢复更简单，掉电不损库。
  • synchronous=NORMAL：WAL 模式下 NORMAL 只在 checkpoint 时同步，比 FULL（每次提交都 fsync）快很多，掉电最多丢最后一个事务但库文件不会损坏——嵌入式场景的经典折中。代码注释原话："WAL + NORMAL：嵌入式场景常用折中，写性能好且掉电不损库"。
  • busy_timeout=2000：SQLite 同一时刻只允许一个写者。多线程/多进程抢库时，拿到 SQLITE_BUSY 不要立刻报错，让 SQLite 内部自旋等待最多 2000ms，多数竞争都能自然消化。

【记忆口诀】"攒批省 fsync，WAL 读写并行，NORMAL 折中，busy 等两秒。"

8.1.5 五表设计赏析：从日志到强化学习数据集

作者项目（详见详细设计 10.3 节，storage_db.c）建了五张表，各司其职，这是面试时展示"数据思维"的绝佳素材：

表 职责 关键字段
cmd_log 指令留痕：谁、何时、发了什么运动指令、执行结果 monotonic_ts/wall_ts、mqtt_seq、source、target_v/target_w、control_mode、can_seq、result
state_log 车体状态周期快照（遥测回放） 四轮转速 wheel_1~4、整车 v/w、超声角度/距离、电池电压、vehicle_mode
event_log 离散事件（报警、模式切换、故障码） level、module、code、detail
perf_log 系统性能体检 MQTT 重连次数/指令时延、CAN 收发速率、邮箱深度、CPU 百分比、RSS 内存
rl_transition_raw 强化学习原始转移样本 episode_id、task_id、robot_id、state_ts/action_ts/next_state_ts、action_v/w/mode、state_json、next_state_json

前四表是"运维思维"：出了事能回放现场（指令 → 状态 → 事件 → 性能四维对时间戳）。第五张表是"算法思维"，值得展开讲：

强化学习/模仿学习的数据单元是 transition（转移）：(s, a, s', r) ——在状态 s 下执行动作 a，到达下一状态 s'。作者的做法：

  • state_ts 关联 state_log 里该时刻的状态快照（车轮速度、超声距离、电量），序列化成 state_json 存入；
  • action_ts 关联 cmd_log 里下发的动作（target_v/w、控制模式）；
  • next_state_ts 取动作生效后的下一帧状态，存 next_state_json；
  • episode_id 标记一次完整任务回合，event_flags 记录期间发生了什么事件（可折算奖励信号）。

这样落盘的 rl_transition_raw 就是一个离线强化学习（Offline RL）/行为克隆（Behavior Cloning）数据集：Behavior Cloning 直接学"状态 → 动作"的映射（把人类/规则控制器的操作当监督学习标签）；Offline RL 则利用 (s, a, s') 三元组加奖励离线训练价值网络，不需要真车在线试错——对真实机器人极其重要，因为在线探索成本太高、太危险。面试被问"你项目数据存储有什么亮点"，把"日志表按时间关联出状态-动作-下一状态，为模仿学习和离线 RL 留数据集"讲出来，直接和普通 CRUD 选手拉开差距。

【记忆口诀】"指令、状态、事件、性能四本账，第五本账留给 AI 做样本。"

8.1.6 sqlite3 命令行常用命令

把 .db 文件从板子上 scp 回来，或者直接在板子上分析：

sqlite3 /root/data/robot.db

进入交互模式后：

.tables                          -- 列出所有表
.schema cmd_log                  -- 看建表语句
.headers on                      -- 查询显示列名
.mode column                     -- 列对齐显示
SELECT COUNT(*) FROM state_log;  -- 行数
SELECT * FROM event_log WHERE level='error' ORDER BY id DESC LIMIT 20;
.quit                            -- 退出

非交互一把梭（脚本里用）：sqlite3 robot.db "SELECT * FROM cmd_log LIMIT 5;"，加 -csv 可直接导出 CSV 喂给 Python 分析。

8.2 V4L2 视频采集

8.2.1 V4L2 是什么

V4L2（Video for Linux 2）是 Linux 内核的视频设备框架：摄像头（MIPI-CSI/并口/USB UVC）、编码器、TV 调谐器在内核里统一抽象成 /dev/videoN 字符设备，用户态通过一组 ioctl 命令字控制它。你不用关心具体传感器是 OV5640 还是 IMX219——驱动对上屏蔽差异，应用只面对 V4L2 接口。作者项目 webd 就是打开 /dev/video0（OV5640，CSI capture）采集 640x480 UYVY 帧。

8.2.2 采集五步曲（完整代码骨架）

记住流程，面试能默写：

  1. open 打开设备；
  2. VIDIOC_QUERYCAP 查能力（确认这是个采集设备）；
  3. VIDIOC_S_FMT 设置格式（分辨率 + 像素格式，驱动会"回填"它实际给的参数，必须读回来核对）；
  4. VIDIOC_REQBUFS + VIDIOC_QUERYBUF + mmap 申请并映射内核缓冲区（MMAP 模式）；
  5. VIDIOC_QBUF 全部入队 → VIDIOC_STREAMON 开流 → poll 等帧 → VIDIOC_DQBUF 取帧 → 用完再 QBUF 循环；结束 VIDIOC_STREAMOFF。
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <poll.h>
#include <linux/videodev2.h>

struct buffer { void *start; size_t length; };
static struct buffer g_bufs[4];
static int g_nbufs;

int camera_init(const char *dev, int w, int h)
{
    /* 1. 打开 */
    int fd = open(dev, O_RDWR | O_NONBLOCK);

    /* 2. 查能力 */
    struct v4l2_capability cap;
    ioctl(fd, VIDIOC_QUERYCAP, &cap);
    if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) return -1;

    /* 3. 设格式：请求 640x480 UYVY，驱动回填实际值 */
    struct v4l2_format fmt = {0};
    fmt.type                = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    fmt.fmt.pix.width       = w;
    fmt.fmt.pix.height      = h;
    fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_UYVY;
    fmt.fmt.pix.field       = V4L2_FIELD_ANY;
    if (ioctl(fd, VIDIOC_S_FMT, &fmt) < 0) return -1;
    /* 关键：S_FMT 后必须读回核对！驱动可能给了别的分辨率/格式 */
    if (fmt.fmt.pix.pixelformat != V4L2_PIX_FMT_UYVY) { /* 兜底处理 */ }

    /* 4. 申请内核缓冲并 mmap 到用户态 */
    struct v4l2_requestbuffers req = {0};
    req.count  = 4;
    req.type   = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    req.memory = V4L2_MEMORY_MMAP;
    if (ioctl(fd, VIDIOC_REQBUFS, &req) < 0 || req.count < 2) return -1;
    for (g_nbufs = 0; g_nbufs < (int)req.count; g_nbufs++) {
        struct v4l2_buffer buf = {0};
        buf.type   = V4L2_BUF_TYPE_VIDEO_CAPTURE;
        buf.memory = V4L2_MEMORY_MMAP;
        buf.index  = g_nbufs;
        ioctl(fd, VIDIOC_QUERYBUF, &buf);          /* 查偏移和长度 */
        g_bufs[g_nbufs].length = buf.length;
        g_bufs[g_nbufs].start  = mmap(NULL, buf.length,
                                      PROT_READ | PROT_WRITE,
                                      MAP_SHARED, fd, buf.m.offset);
    }

    /* 5. 全部入队 + 开流 */
    for (int i = 0; i < g_nbufs; i++) {
        struct v4l2_buffer buf = {0};
        buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
        buf.memory = V4L2_MEMORY_MMAP;
        buf.index = i;
        ioctl(fd, VIDIOC_QBUF, &buf);              /* 缓冲区还给驱动 */
    }
    enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    ioctl(fd, VIDIOC_STREAMON, &type);
    return fd;
}

/* 取帧循环：poll 等可读 → DQBUF 出队 → 使用 → QBUF 再入队 */
int capture_loop(int fd)
{
    for (;;) {
        struct pollfd pfd = { .fd = fd, .events = POLLIN };
        if (poll(&pfd, 1, 2000) <= 0) continue;    /* 等一帧到来 */

        struct v4l2_buffer buf = {0};
        buf.type   = V4L2_BUF_TYPE_VIDEO_CAPTURE;
        buf.memory = V4L2_MEMORY_MMAP;
        if (ioctl(fd, VIDIOC_DQBUF, &buf) < 0) continue;  /* 取出装好帧的缓冲 */

        process_frame(g_bufs[buf.index].start, buf.bytesused); /* UYVY→RGB→JPEG */

        ioctl(fd, VIDIOC_QBUF, &buf);              /* 用完归还，继续装下一帧 */
    }
    /* 结束：enum v4l2_buf_type t = V4L2_BUF_TYPE_VIDEO_CAPTURE;
       ioctl(fd, VIDIOC_STREAMOFF, &t); 然后 munmap + close */
}

缓冲队列模型是 V4L2 的灵魂：内核维护一个缓冲队列，驱动往空缓冲里 DMA 装帧，用户 DQBUF 取走"装满的"，用完 QBUF 归还"空的"——生产者/消费者模型，4 个缓冲轮转。这正是作者 webd 的做法（MMAP 4 缓冲）。

【记忆口诀】"开门设格式，申请缓冲做映射，入队开流，poll 到就 DQ，用完再 Q。"

8.2.3 像素格式：UYVY vs RGB vs JPEG

  • RGB：每个像素 3 字节（R/G/B 各 8bit），人屏显示、算法处理都方便，但传感器原生一般不直接吐 RGB。
  • YUV（UYVY）：Y 是亮度，U/V 是色度。人眼对亮度敏感对色度不敏感，所以 YUV4:2:2 让两个相邻像素共享一对 U/V：4 字节 [U Y0 V Y1] 装 2 个像素，比 RGB 省 1/3 带宽。OV5640 这类传感器 CSI 输出的就是 UYVY。
  • JPEG/MJPEG：压缩格式。MJPEG = 一串独立 JPEG 帧，每帧可单独解码（不像 H.264 有帧间依赖），丢帧不坏流，天然适合局域网低延迟预览。

UYVY→RGB 用 BT.601 公式的整数运算版本（作者项目就是这么做的：浮点在 A7 上太贵，全程定点移位），宏像素按 [U Y0 V Y1] 拆出两个像素。

8.2.4 MJPEG over HTTP：multipart/x-mixed-replace

单核 A7 没有硬件 VPU（视频处理单元），H.264 硬编不存在，软件 x264 一帧都算不动。唯一现实的选择就是 libjpeg-turbo 软编 MJPEG：libjpeg-turbo 用 SIMD 指令加速，640x480、quality 70 一帧几毫秒，整机实测跑到 7~9fps——这数字面试可以大方讲："无 VPU 单核软编，7-9fps 够监控预览，要更高帧率得上硬编或者降分辨率"。

HTTP 推流不用 WebSocket 也不用 RTSP，用最朴素的 MJPEG over HTTP：

HTTP/1.1 200 OK
Content-Type: multipart/x-mixed-replace; boundary=frame

--frame
Content-Type: image/jpeg
Content-Length: 23456

<JPEG数据>
--frame
Content-Type: image/jpeg
...

原理一句话：服务器永远不结束这个响应，每来一帧就追加一段 multipart，浏览器 <img> 标签天然支持逐段刷新显示。零 JS、零插件，写 HTML <img src="/stream"> 就有视频。作者 webd 每个连接起一个 detached 发送线程，最多 4 路并发观看。

8.2.5 拍照、录 AVI、旋转与降采样

  • 拍照：/snapshot 直接把当前 JPEG 帧落盘成 .jpg——白捡的功能，因为流本来就是 JPEG。
  • 录像：MJPEG-AVI。AVI 是 RIFF 容器，作者纯手写 RIFF 头：写 RIFF/AVI /LIST hdrl/avih/strl/LIST movi，每帧一个 00dc chunk，索引 idx1 记录偏移；文件头里有几个"大小字段"在录像开始前不知道，结束停止时统一 seek 回去 patch（代码里的 riff_size 等偏移记录）。讲出"手写 RIFF 头 + 结束时回填长度字段"，面试官知道你是真写过。
  • 软件旋转 180°：摄像头倒装。优先尝试传感器 hflip+vflip 硬件翻转（零 CPU），驱动不支持就对 UYVY 整帧软件旋转——注意 UYVY 是宏像素打包格式，翻转时要成对搬运 4 字节（[U Y0 V Y1] 两个像素一起倒序），不能按单像素翻。
  • 软降采样：2x2 盒式降采样（640x480→320x240），网络差或 CPU 紧张时减半数据量；同样要按宏像素处理，U/V 直接相邻宏像素平均即可。

8.2.6 v4l2-ctl 命令实例

v4l2-utils 包里的 v4l2-ctl 是摄像头排障第一工具，不写代码就能验证驱动：

v4l2-ctl --list-devices                    # 列出所有 /dev/videoN 及对应驱动名
v4l2-ctl -d /dev/video0 --list-formats-ext # 该设备支持哪些格式/分辨率/帧率
v4l2-ctl -d /dev/video0 --all              # 当前格式、控件、能力一览
# 抓 100 帧测实际帧率（mmap 模式，640x480）：
v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=UYVY \
         --stream-mmap=4 --stream-count=100 --stream-to=- >/dev/null
# 设曝光/增益等控件：
v4l2-ctl -d /dev/video0 --set-ctrl=exposure_auto=1

--stream-mmap 打印的实际 fps 是排查"驱动说好的 30fps 怎么只有 8fps"的第一手证据。作者项目还在 STREAMON 后用 VIDIOC_S_PARM 把传感器帧率限制到 15fps，给 DDR 带宽留余量——帧率太高 CPU 编码跟不上，源头限流比下游丢帧优雅。

【记忆口诀】"list 看设备，formats 看格式，stream 测帧率，ctrl 调参数。"

8.3 framebuffer 与 LVGL

8.3.1 /dev/fb0：最朴素的显示设备

framebuffer 是 Linux 对显示内存的直接抽象：/dev/fb0 里存的就是屏幕上每个像素的颜色值。它没有 GPU、没有窗口系统、没有画图 API——就是一块"像素数组"。画一个点 = 往对应偏移写颜色值：

#include <fcntl.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <linux/fb.h>

int fb = open("/dev/fb0", O_RDWR);
struct fb_var_screeninfo vinfo;           /* 可变信息：分辨率、色深 */
struct fb_fix_screeninfo finfo;           /* 固定信息：行长、显存大小 */
ioctl(fb, FBIOGET_VSCREENINFO, &vinfo);   /* 例如 800x480, 32bpp */
ioctl(fb, FBIOGET_FSCREENINFO, &finfo);

size_t size = finfo.line_length * vinfo.yres_virtual;
unsigned char *fbp = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fb, 0);

/* 在 (x,y) 画一个蓝色像素（32bpp BGRA 布局） */
int x = 100, y = 100;
long off = y * finfo.line_length + x * vinfo.bits_per_pixel / 8;
*(unsigned int *)(fbp + off) = 0x00FF0000;

要点：mmap 把显存映射进进程地址空间，写内存 = 写屏幕，零拷贝。fb_var_screeninfo 拿到 xres/yres/bits_per_pixel（常见 16bpp RGB565 或 32bpp BGRA），fb_fix_screeninfo.line_length 是一行字节数（可能含 padding，不能简单用 xres*bpp 算偏移）。fbset、cat /dev/urandom > /dev/fb0（满屏雪花，验证显示链路）是常用验证手段。

【记忆口诀】"fb0 就是一块像素内存，mmap 之后写哪亮哪。"

8.3.2 LVGL 简介与移植三要素

LVGL（Light and Versatile Graphics Library）是最流行的轻量级开源嵌入式 GUI 库：纯 C 写的控件库（按钮/标签/图表/滑条/列表……），带事件系统、动画、主题，几十 KB RAM 就能跑，MIT 协议。它自己不碰硬件，移植时你只需要提供三样东西——移植三要素：

  1. 显示驱动（flush 回调）：LVGL 把一块区域画进你的 draw buffer，调你的 flush 函数，你把这块像素搬到屏幕。framebuffer 场景就是一次 memcpy 到 fb0 对应偏移：
void my_flush(lv_display_t *disp, const lv_area_t *area, uint8_t *px_map)
{
    /* 把 px_map 这块矩形拷贝到 framebuffer 对应位置 */
    for (int y = area->y1; y <= area->y2; y++)
        memcpy(fbp + y * line_length + area->x1 * 4,
               px_map + (y - area->y1) * w * 4, w * 4);
    lv_display_flush_ready(disp);   /* 必须调！告诉 LVGL 可以画下一块 */
}
  1. 输入设备（indev）：触摸屏走 evdev（Linux 输入子系统 /dev/input/eventN）。作者项目用 FT5x06 电容触摸芯片，内核驱动把它变成 evdev 设备，LVGL 的 evdev indev 驱动直接读出坐标和按下状态，lv_indev_set_type(INDEV_TYPE_POINTER) 挂上即可。
  2. tick（心跳）：LVGL 内部动画/超时都靠毫秒时钟，你要周期性调 lv_tick_inc(5)（或注册 tick_get_cb 返回 clock_gettime 的毫秒），主循环里周期性 lv_timer_handler() 让它干活。

【记忆口诀】"LVGL 三要素：flush 搬像素，indev 收触摸，tick 供心跳。"

8.3.3 对象模型与事件

LVGL 一切皆 lv_obj_t，父子树形组织（子对象随父对象移动/删除），控件就是带特定行为的 obj：

lv_obj_t *btn = lv_btn_create(parent);             /* 按钮 */
lv_obj_t *lbl = lv_label_create(btn);              /* 按钮上的文字 */
lv_label_set_text(lbl, "START");
lv_obj_set_size(btn, 120, 50);
lv_obj_align(btn, LV_ALIGN_CENTER, 0, 0);
lv_obj_set_style_bg_color(btn, lv_color_hex(0x2ECC71), 0);

/* 事件回调：点击按钮触发 */
lv_obj_add_event_cb(btn, on_click, LV_EVENT_CLICKED, user_data);

常用控件 lv_label（文本）、lv_btn（按钮）、lv_bar（进度条）、lv_chart（曲线图）、lv_tabview（标签页）。样式用 lv_obj_set_style_xxx 按"部件 + 状态"设置。事件模型是回调式：LV_EVENT_CLICKED/VALUE_CHANGED/GESTURE 等，回调里刷新数据或切页面。

8.3.4 项目实战：robotd_hmi 六页监控界面

作者 hmi/robotd_hmi.c 是一个可以直接搬进简历讲的设计：

  • 布局：顶部固定状态栏（标题 + MQTT/CAN/STM32/WiFi 四个状态点 + 运行时间），下面 lv_tabview 六个可触摸切换的页面：总览（模式/目标速度）、CAN 通信、STM32 传感器、MQTT/网络、性能、系统。配色走深色卡片风（lv_color_hex(0x101418) 背景 + 状态绿/红/黄点）。
  • 数据流（面试亮点）：界面数据来自 robotd 每 300ms 原子导出的 /dev/shm/robotd_hmi.json（tmpfs 内存文件，写时先写临时文件再 rename 保证读者永远读到完整 JSON），WiFi 状态来自 wifid 每 2 秒原子更新的 /dev/shm/wifi_status.json。HMI 进程只读消费这些 JSON，完全不参与控制闭环——HMI 崩了/卡了不影响小车运动控制，显示与控制解耦。被问"你的 HMI 和控制怎么通信"时，"共享内存 JSON 单向只读，控制闭环零依赖显示端"这个答案非常加分。
  • 容错设计：触摸走 FT5x06 evdev；检测到触摸不可用（设备打不开/读失败）时，页面每 8 秒自动轮播——工业现场触摸屏排线松了，界面退化成自动翻页的"展板"，信息依然可读。这种"传感器失效优雅降级"的思路是面试官爱听的工程细节。
  • 刷新节奏：定时器周期读 JSON → 解析 → lv_label_set_text / 更新状态点颜色，LVGL 自身做脏区域重绘，framebuffer 上流畅无压力。

【记忆口诀】"数据走 shm JSON 只读看，触摸挂 evdev，挂了自动翻页。"

8.4 版本管理 Git

8.4.1 核心命令一张表

Git 是分布式版本管理，每个开发者本地都有完整仓库历史。必背命令：

git init                      # 本地新建仓库
git clone <url>               # 克隆远程仓库
git status                    # 看工作区/暂存区状态（最常用）
git add file.c / git add .    # 工作区 → 暂存区
git commit -m "fix can rx"    # 暂存区 → 本地仓库（一次快照）
git push origin main          # 本地 → 远程
git pull                      # 远程 → 本地（= fetch + merge）
git log --oneline --graph     # 看提交历史
git diff                      # 看未暂存的改动

三区模型要背：工作区（写代码）→ 暂存区（add 后）→ 版本库（commit 后），push 才到远程。

8.4.2 分支、合并与冲突

git branch feature_can        # 建分支
git checkout feature_can      # 切分支（新写法 git switch）
git checkout -b fix_imu       # 建并切换
git merge feature_can         # 把 feature_can 合进当前分支
git rebase main               # 把当前分支的提交"搬"到 main 最新之后
  • merge vs rebase（面试经典）：merge 保留真实历史、产生一个合并提交，图上有分叉；rebase 把你的提交摘下来重新贴到目标分支最新点上，历史变成一条直线，干净但改写了历史——铁律：已经 push 出去的公共提交不要 rebase，只 rebase 自己本地的分支。
  • 解决冲突：pull/merge 报 conflict 时，打开冲突文件，找到 <<<<<<< HEAD / ======= / >>>>>>> 标记，人工改成正确内容，删掉标记，git add 该文件，然后 git commit（rebase 则是 git rebase --continue）。

8.4.3 后悔药与小工具

git reset --soft HEAD~1       # 撤销上次commit，改动留在暂存区（改错提交信息时用）
git reset --mixed HEAD~1      # 撤销commit+add，改动回工作区（默认）
git reset --hard HEAD~1       # 撤销commit且丢弃改动！危险，不可恢复
git stash                     # 临时把未提交改动收起来（要去改别的bug时）
git stash pop                 # 取回stash

.gitignore 文件告诉 Git 哪些文件不跟踪：嵌入式项目必加 build/、*.o、*.bin、*.elf、.cache/、编译产物。远程仓库：GitHub/Gitee/GitLab，git remote add origin <url> 绑定，SSH key 免密。

团队开发流程一句话：主分支保持可发布，功能开 feature 分支开发，完成后 merge/rebase 回主分支，pull 先于 push，冲突本地解决再推。

【记忆口诀】"三区：工作、暂存、仓库；merge 留历史，rebase 拉直线；stash 收破烂，hard 要人命。"

8.5 GDB 调试

8.5.1 编译带调试信息 + 常用命令

GDB 的前提是编译时加 -g（保留符号表，优化别超 -O1，否则变量被优化掉）：

gcc -g -O0 main.c -o main
gdb ./main

GDB 内必背九条：

(gdb) break main              # b 函数名/文件名:行号 打断点
(gdb) run                     # r 运行到断点
(gdb) next                    # n 单步：不进入函数（过）
(gdb) step                    # s 单步：进入函数（进）
(gdb) print var               # p 打印变量/表达式，p *ptr@len 看数组
(gdb) backtrace               # bt 打印调用栈（崩溃现场第一动作！）
(gdb) info locals             # 看当前栈帧所有局部变量
(gdb) watch g_count           # 监视点：变量被修改时停下来（抓野写）
(gdb) continue                # c 继续跑到下个断点

8.5.2 core dump 调试

程序段错误直接退出、来不及 attach？让内核把"死亡现场"存成 core 文件，事后尸检：

ulimit -c unlimited                                  # 解除core大小限制（默认0=不生成）
echo '/root/core.%e.%p' > /proc/sys/kernel/core_pattern   # core文件命名
./robotd                                             # 崩溃，生成 core
gdb ./robotd core.robotd.1234                        # 事后加载
(gdb) bt                                             # 直接看到崩在哪一行

bt 看到调用栈 → frame N 切栈帧 → info locals + p 指针 看数据 → 大概率是空指针/野指针/数组越界。

8.5.3 gdbserver 交叉调试开发板

板子上 GDB 装不下/跑不动？用 gdbserver：板上跑"调试代理"，宿主机跑全功能 GDB，串口/网口相连：

# 开发板（被调试端，ARM）：
gdbserver :2345 ./robotd            # 监听2345端口运行robotd

# 宿主机（PC，用交叉工具链的gdb才能看懂ARM符号）：
arm-linux-gnueabihf-gdb ./robotd    # 同一个带-g的可执行文件
(gdb) target remote 192.168.1.10:2345
(gdb) b thread_can.c:120
(gdb) c

效果等于在板子上本地调试：断点、单步、查内存全都有。作者调 CAN 线程偶发挂死就是这么干的。

8.5.4 段错误排查思路（面试标准答案）

  1. 先复现，拿到 core 或 GDB 直接跑；
  2. bt 定位崩溃行，看是不是解引用 NULL/野指针（p 指针 一看 0x0 或 0xdeadbeef 类值就明白了）；
  3. 崩在库函数里（如 strcpy/memcpy）→ 八成是调用方传了坏指针或越界，沿栈帧往上翻找真凶；
  4. 崩溃点随机/栈被踩坏 → 栈溢出或数组越界写，上 watch 监视被踩的变量，或用 -fsanitize=address（ASan）重新编译，越界写当场现形；
  5. 多线程偶发 → 加日志缩小范围，怀疑竞态就检查锁的配对。

【记忆口诀】"-g 编译、bt 看栈、watch 抓野写、core 能尸检、gdbserver 远程连。"

8.6 总线与外设调试命令

8.6.1 can-utils 全家桶

SocketCAN 把 CAN 抽象成网络接口（can0），can-utils 是它的瑞士军刀：

ip link set can0 up type can bitrate 500000   # 先配波特率起接口（500kbps）
candump can0                    # 抓所有CAN帧：can0 123 [2] 01 02
cansend can0 123#0102           # 发一帧：ID=0x123，数据01 02
cansend can0 1F334455#8300AA    # 扩展帧也支持
cangen can0 -g 10 -v            # 每10ms发一帧随机数据，压测用
cansniffer can0                 # 按ID聚合显示，变化字节高亮——盯哪个字节在动
candump -l can0                 # 录成.log文件
canplayer -I candump-2024.log   # 按原时间戳回放！重现现场的神器

作者项目排"STM32 心跳帧偶发丢失"就是 candump -l 录一晚，canplayer 回放 + 脚本分析时间间隔定位的。candump 录播 + canplayer 回放这套"现场录制、实验室重现"流程面试必讲。

8.6.2 i2c-tools

i2cdetect -l                    # 列出系统里所有I2C总线
i2cdetect -y 0                  # 扫描0号总线：7位地址表，挂上的设备地址会显示
i2cget -y 0 0x50 0x00           # 读从机0x50的寄存器0x00
i2cset -y 0 0x50 0x10 0xAB      # 写寄存器0x10 = 0xAB
i2cdump -y 0 0x50               # 把整个寄存器空间dump出来

新接一个 I2C 传感器，第一步永远是 i2cdetect -y 0 看地址在不在——不在就是接线/上拉电阻/电源问题，不用看代码。

8.6.3 SPI、串口与内核日志

  • spidev_test：内核源码 tools/spi/ 下的小工具（很多发行版直接带），spidev_test -D /dev/spidev0.0 -s 1000000 发默认数据并回读，MOSI 接 MISO 环回测试验证 SPI 控制器和引脚配置。
  • 串口：minicom -D /dev/ttyUSB0 -b 115200 或 screen /dev/ttyUSB0 115200（退出 Ctrl+A 再按 K），STM32 的 printf 日志全靠它看。
  • dmesg：dmesg | tail -30 看内核日志——驱动 probe 失败、设备树报错、内核 oops 全在这。dmesg -w 实时跟随，插拔 USB 设备看识别过程。驱动加载不上先 dmesg，别先怀疑人生。

【记忆口诀】"CAN 录播回放，I2C 先扫地址，SPI 环回自测，串口看 printf，驱动不行 dmesg。"

8.7 网络抓包

8.7.1 tcpdump 常用过滤

tcpdump 是命令行抓包器，板子上没有图形界面就靠它：

tcpdump -i any port 1883            # 抓MQTT流量（作者项目MQTT Broker在1883）
tcpdump -i any host 192.168.1.100   # 只抓和某主机的通信
tcpdump -i any tcp port 80          # 只看TCP 80
tcpdump -i wlan0 -nn -v             # -nn 不解析域名/服务名（快），-v 详细
tcpdump -i any port 1883 -w mqtt.pcap   # 保存成pcap文件

板子上 tcpdump -w 录 pcap，scp 回 PC 用 Wireshark 打开分析——嵌入式网络排障标准动作。

8.7.2 Wireshark 图形分析

  • 过滤表达式（和 tcpdump 语法不同！）：mqtt、tcp.port == 1883、ip.addr == 192.168.1.10、tcp.flags.syn == 1（只看握手 SYN）。
  • 看 MQTT 报文：Wireshark 内置 MQTT 解码，CONNECT/PUBLISH/SUBSCRIBE 的 topic 和 payload 一目了然——作者验证 robotd 上报遥测的 topic/qos 就是这么对的。
  • 看 TCP 握手：三连包 SYN / SYN-ACK / ACK，连不上时先看握手卡在哪一步：没 SYN-ACK = 对端没监听/被防火墙丢；握手成功马上 RST = 应用层拒绝。
  • CAN 也能抓：SocketCAN 接口在 Wireshark 接口列表里，can0 选上直接解码 CAN 帧， candump 之外的图形化选择。

【记忆口诀】"板上 tcpdump 录 pcap，拿回 Wireshark 慢慢看；MQTT 直接解，握手三步先查。"

8.8 MCU 烧录调试

STM32 用 SWD（Serial Wire Debug） 接口调试烧录，最少只要两根信号线 + 地：

  • SWDIO（数据）、SWCLK（时钟）、GND 必接，VCC 一般只作电平参考，NRST（复位）可选但建议接。
  • ST-Link 仿真器一头 USB 插 PC，一头杜邦线接板子的 SWD 排针。

Linux 下开源工具 stlink：

st-flash write build/stm32f103.bin 0x8000000    # 烧录bin到Flash起始地址
st-flash erase                                   # 全片擦除
st-info --probe                                  # 探测芯片：型号/Flash大小
st-util                                          # 起GDB server（默认4242端口）
# 另开终端：arm-none-eabi-gdb firmware.elf
# (gdb) target extended-remote localhost:4242 → 单步调试STM32！

8.8.2 OpenOCD

OpenOCD（Open On-Chip Debugger）是更通用的开源调试桥，支持 ST-Link/J-Link/CMSIS-DAP 各种仿真器 + 各种芯片，配置文件两级（仿真器 cfg + 芯片 cfg）：

# 一条命令：ST-Link + STM32F1 起调试服务
openocd -f interface/stlink.cfg -f target/stm32f1x.cfg
# 另开终端连上烧录：
telnet localhost 4444
> halt                      # 停住CPU
> flash write_image erase build/firmware.elf   # 擦除并烧录
> reset run                 # 复位运行
# 或 GDB 连 localhost:3333 源码级调试

J-Link 一句话：SEGGER 出品的商业仿真器，配套 J-Flash/J-Link GDB Server 软件稳定好用，企业常见，用法和 ST-Link 类似（SWD 接线 + GDB server），价格贵但省心。

8.8.3 串口日志验证

烧完先看活没活：作者 STM32 工程启动日志带统一前缀标记——[BOOT]（启动信息：时钟/版本）、[INIT]（外设初始化逐项 OK/FAIL）、运行期 [CAN]/[CTRL] 分类。串口 115200 接上，看到 [BOOT] 说明时钟起来了、[INIT] can ok 说明 CAN 初始化成功——日志标记规范 = 盲调也能定位初始化死在哪一步。

【记忆口诀】"SWD 两根线：SWDIO 加 SWCLK；st-flash 烧 bin，OpenOCD 两 cfg；烧完看 [BOOT]。"

8.9 硬件仪器

8.9.1 万用表

最便宜的仪器，最先拿起来的仪器：

  • 测电压：查供电链——3.3V 稳压输出对不对、电池电量、模块 VCC 到没到。设备不工作先量电，一半"玄学故障"是供电。
  • 蜂鸣档测通断：查断线、虚焊、短路。板子不上电时量 VCC-GND 之间通不通，先排除短路再上电，保命。
  • 电阻档/二极管档：量上拉电阻在不在（I2C 必须 4.7k 上拉！）、二极管方向。

8.9.2 示波器：看模拟波形与时序

示波器看的是电压随时间的真实曲线，回答"信号质量好不好"：

  • 量 PWM：探头接 PWM 引脚，直接读出频率、占空比对不对（电机驱动排查必做）；
  • 量 UART：探头接 TX，触发设下降沿（起始位），一格一格数波特率对不对、电平是 3.3V 还是 5V；
  • 量 I2C：看 SCL/SDA 上升沿是不是太缓（上拉太弱）、有没有毛刺、ACK 位（第 9 个时钟 SDA 被拉低）在不在——没 ACK = 从机没应答，地址或硬件问题；
  • 还能看电源纹波、复位时序、晶振起振。

8.9.3 逻辑分析仪：看数字协议

逻辑分析仪（如几十块的 8 通道 USB 款 + PulseView/sigrok）只看高低电平（0/1），但自带协议解码器：抓一段波形直接解出 I2C 的地址/数据/ACK、SPI 的 MOSI 字节、UART 的字符、CAN 的帧 ID——比数示波器格子快一百倍。8 通道可以同时抓 I2C + 几个 GPIO 标记，分析"中断脚拉低后多久 I2C 去读"这种时序关联。

8.9.4 选型口诀：什么时候用哪个

  • 怀疑信号质量（幅值、纹波、边沿、毛刺、振铃）→ 示波器；
  • 怀疑协议内容（发的字节对不对、时序先后、多路关联）→ 逻辑分析仪；
  • 供电/通断 → 万用表，永远第一个拿。

【记忆口诀】"万用表查电，示波器看质，逻辑分析仪读协议。"

8.10 性能与系统观察

8.10.1 常用命令

top                    # 实时进程CPU/内存占用，按1展开每个核
htop                   # top的加强版：彩色、树状、鼠标操作（需安装）
ps aux | grep robotd   # 快照式看进程状态
free -h                # 内存：total/used/available（看available别看free）
vmstat 1               # 每秒一行：r(运行队列)/si,so(交换)/us,sy,id(CPU分布)
  • top 里 CPU %us（用户态）高 = 你的程序算得狠；%sy（内核态）高 = 系统调用/驱动太频繁；%wa（IO 等待）高 = 卡在存储。
  • vmstat 的 si/so 非零 = 在换页，内存不够了。

8.10.2 /proc 文件系统

Linux 把内核状态暴露成伪文件，cat 就能读，程序里 fopen 读也一样——这就是自己做监控的原理：

cat /proc/cpuinfo        # CPU信息
cat /proc/meminfo        # 内存详情（MemTotal/MemAvailable）
cat /proc/stat           # 第一行cpu：user nice system idle iowait... 各项累计jiffies
cat /proc/self/statm     # 本进程内存：size resident...(页数)
cat /proc/loadavg        # 1/5/15分钟负载
cat /proc/net/dev        # 各网卡收发字节数

CPU 占用率怎么算：/proc/stat 的 cpu 行是开机累计的各状态时间，间隔 dt 采两次，(busy2-busy1)/(total2-total1) 就是这段时间的 CPU 百分比——没有"瞬时 CPU 占用"这种文件，全是差分算出来的。

作者 robotd 的 monitor 线程正是这个思路：周期 fopen("/proc/stat") 解析 cpu 行做差分算 cpu_percent，fopen("/proc/self/statm") 读 resident 乘页大小得 RSS，连同 CAN 速率、MQTT 重连数一起写进 perf_log 表、导出到 /dev/shm/robotd_hmi.json 给 HMI 显示。"用 /proc 手写监控线程" 面试讲出来，证明你理解 top 背后的原理而不是只会敲命令。

8.10.3 进阶三件一句话

  • strace：跟踪进程的系统调用（strace -p <pid>），程序卡死时看它在哪个 syscall 里出不来（read 等数据？futex 等锁？）。
  • ltrace：跟踪动态库函数调用，看程序调了什么库函数，用得少。
  • perf：Linux 性能分析利器，perf top 看热点函数、perf record/report 采样找 CPU 花在哪，优化性能前先 perf 定位，别瞎猜。

【记忆口诀】"top 看进程，free 看内存，vmstat 看趋势，/proc 自己读，卡住 strace，热点 perf。"

8.11 面试高频问答

Q1：SQLite 攒批写为什么快那么多？
A：瓶颈在提交时的 fsync。逐条 INSERT 每条都是独立事务、每条一次刷盘（毫秒级）；32 条放一个事务只刷一次盘，吞吐提升一两个数量级。配套 200ms 超时兜底，掉电最多丢 200ms。我项目里就是 32 条/200ms 攒批 + BEGIN IMMEDIATE 单事务落盘。

Q2：WAL 是什么？为什么嵌入式爱用？
A：Write-Ahead Logging 预写日志：写先追加进 -wal 文件，读走主库旧快照，读写不互斥，并发性能好；崩溃恢复也简单。配 synchronous=NORMAL 只在 checkpoint 同步，掉电不损库最多丢最后一笔，是嵌入式写多读少场景的经典折中。再加 busy_timeout=2000 消化多线程写竞争。

Q3：V4L2 采集流程说一下？
A：open → QUERYCAP 查能力 → S_FMT 设分辨率像素格式（读回核对）→ REQBUFS+QUERYBUF+mmap 申请映射 4 个内核缓冲 → 全部 QBUF 入队 + STREAMON → poll 等帧 + DQBUF 取帧、处理完 QBUF 归还循环 → STREAMOFF 收尾。本质是内核缓冲队列的生产者消费者模型。

Q4：mmap 为什么比 read 快？
A：read 要把数据从内核缓冲拷贝一次到用户态，且每次 read 是一次系统调用；mmap 直接把内核缓冲映射进进程地址空间，应用访问的是同一块物理内存，零拷贝，也没有逐次系统调用开销。V4L2 的 MMAP 模式、framebuffer 画图都是这个收益。

Q5：没有 GPU/VPU 的单核 A7 怎么推视频流？
A：libjpeg-turbo 软编 MJPEG（SIMD 加速，每帧独立无依赖），HTTP multipart/x-mixed-replace 逐帧推送，浏览器 img 标签直接播。我项目 OV5640 UYVY 采集 → 定点 UYVY 转 RGB → quality 70 编码，640x480 实测 7-9fps，并用 VIDIOC_S_PARM 源头限到 15fps 给 DDR 留余量；要更高帧率只能降分辨率或上硬编。

Q6：LVGL 移植需要做什么？
A：三要素：显示驱动（flush 回调把 LVGL 画好的矩形 memcpy 到 framebuffer，结束调 flush_ready）、输入设备（触摸 FT5x06 走 evdev，注册 POINTER 类型 indev）、tick 心跳（周期 lv_tick_inc + 主循环 lv_timer_handler）。我项目 HMI 数据只读 /dev/shm 的 JSON，不参与控制闭环，触摸失效时每 8 秒自动轮播页面降级。

Q7：GDB 怎么找段错误？
A：-g 编译；能复现就 gdb 里 run，崩了 bt 看调用栈、frame 切帧、p 看指针（多半是空指针/野指针/越界）；不能复现就 ulimit -c unlimited 开 core dump，gdb ./程序 core 尸检；现场随机崩、怀疑踩内存就上 watch 监视变量或 ASan 重编。板上调不了就 gdbserver :2345 + 宿主机交叉 gdb target remote。

Q8：示波器和逻辑分析仪怎么选？
A：看信号质量（幅值、纹波、边沿快慢、毛刺、电源）用示波器；看协议内容（I2C/SPI/UART/CAN 发了什么字节、多路时序关联）用逻辑分析仪——它自带协议解码。供电通断问题永远先上万用表。

Q9：tcpdump 怎么抓 MQTT？
A：tcpdump -i any port 1883 -w mqtt.pcap（MQTT 默认 1883），板子上录 pcap 拷回 PC，Wireshark 打开直接按 mqtt 协议解码，CONNECT/PUBLISH 的 topic 和 payload 全能看到；连不上时先用 tcp.flags.syn == 1 看 TCP 三步握手卡在哪。

Q10：CAN 总线怎么排查"偶发丢帧"？
A：ip link set can0 up type can bitrate 500000 起接口，candump -l can0 长时间录制成 log，canplayer 按原时间戳回放复现，配合脚本分析帧间隔；cansniffer 按 ID 聚合高亮变化字节盯数据；cangen 发压力流量验证链路稳定性。我项目 STM32 心跳丢帧就是这套流程定位的。

Q11：STM32 烧不进去程序怎么排查？
A：先查 SWD 接线（SWDIO/SWCLK/GND，最好接 NRST）；st-info --probe 看能不能认出芯片——认不出是接线/供电/芯片被读保护；认出但烧失败试 st-flash erase 全片擦除或用 OpenOCD 连接后 halt 再烧；烧完串口看 [BOOT]/[INIT] 日志确认程序跑起来。被读保护（RDP）时先解除保护（会全片擦除）。

Q12：不用 top，怎么在自己程序里统计 CPU 占用？
A：读 /proc/stat 第一行 cpu 的 user/nice/system/idle 等累计 jiffies，间隔采样两次做差分，busy 增量除以 total 增量即 CPU 百分比；进程内存读 /proc/self/statm 的 resident 字段乘页大小。我 robotd 的 monitor 线程就是这么写的，结果进 perf_log 表并导出 JSON 给 HMI 显示。

第9篇 项目实战解析与综合面试问答

前 8 篇把嵌入式工程师的知识地图铺完了：C 语言、Linux 系统编程、移植与驱动、总线协议、STM32/FreeRTOS、存储显示与调试工具链。但面试现场真正拉开差距的，从来不是"背知识点"，而是讲项目——面试官会用 30 分钟顺着你的项目往深挖，挖到每一层设计决策背后的"为什么"。本篇就是这场演练的彩排：我们把两个真实项目拆开揉碎，一个偏"硬"（智能物流 AGV 嵌入式机器人控制平台），一个偏"软"（embedded-agent 嵌入式开发智能体），让你看到前 8 篇的每一个知识点是如何在真实工程里长出血肉的。

阅读方法建议：9.1 和 9.2 是"素材库"，重点学怎么把技术细节组织成面试语言；9.3 是 30 条高频问答，可以直接背要点；9.4 是复盘自查表，面试前一天晚上对着打勾。

9.1 项目一：面向智能物流 AGV 协同的嵌入式机器人控制平台

9.1.1 电梯陈述：怎么开口讲这个项目

面试里"介绍一下你的项目"是必考题。回答必须分两个版本：30 秒版用来破冰，3 分钟版用来在对方示意"展开讲讲"之后接棒。两个版本都要先说价值，再说架构，最后说亮点，千万别一开口就背技术名词。

30 秒版（照这个结构练）：

"我做的是一个面向智能物流 AGV 场景的嵌入式机器人控制平台，采用的是典型的'云-边-端'三级架构：云端通过 MQTT 下发运动指令，边缘侧是一块 i.MX6ULL 的 Linux 板做车载主控和网关，底层是 STM32F407 跑 FreeRTOS 做 10ms 周期的四轮 PID 实时控制，中间用 500kbps 的 CAN 总线连接。整个系统我重点解决了三件事：一是 Linux 主控内部 7 线程的消息通信与有序退出，二是从 MQTT 断链到 MCU 看门狗的五层安全停车机制，三是把实车运行的'状态-动作'数据落盘成强化学习数据集。全链路有宿主机 vcan 端到端测试和 2 小时故障注入长稳测试背书。"

这段话说完大约 30 秒，信息量刚好：场景（物流 AGV）、架构（云-边-端）、你干的事（三条主线）、质量证据（测试体系）。注意没有说"我用了 paho-mqtt、SocketCAN、SQLite"这种细节——那是等对方追问时递的牌。

3 分钟版（在 30 秒版基础上按四段展开）：

  1. 背景与目标（20 秒）：物流仓储场景里多台 AGV 需要统一调度，要求车载控制器既能接云端指令远程行驶，又要在任何一环失效时保证车辆安全停车，还要沉淀运行数据供后续的调度算法和模仿学习使用。
  2. 系统架构（60 秒）：画出那条链路——云端 Mosquitto Broker 经 MQTT（QoS1，robot/v1/car01/... 主题体系）到 i.MX6ULL；板上四个进程（robotd 主控 7 线程、wifid 配网、webd 视频与 Web 控制台、robotd_hmi 本地 LVGL 屏显）通过 /dev/shm 下的 JSON 文件协作；robotd 经 SocketCAN 与 STM32F407 通信，自定义 8 个 CAN ID 的应用层协议；STM32 上 FreeRTOS 四个任务，控制任务 10ms 周期跑差速解算和四轮独立 PID，经 TIM8 的 10kHz PWM 驱动四路 TB6612 电机。
  3. 我负责的核心工作与难点（70 秒）：这里挑三样东西讲——①自研线程邮箱（环形队列+mutex+双条件变量），按消息重要性分级（命令不可丢、周期状态丢旧保新），并用 shutdown 广播实现 7 线程优雅退出；②五层安全停车设计，做到"任何一环失效都导向停车"的 fail-safe；③通信可靠性四件套：MQTT 侧 QoS1+seq 去重+TTL+robot_id 校验+LWT，CAN 侧 seq 双端去重+命令看门狗。如果对方是算法背景，补一句 rl_transition_raw 数据集（状态-动作-下一状态，供 Behavior Cloning/Offline RL）。
  4. 验证与结果（30 秒）：宿主机 vcan + STM32 模拟器做了 20 项断言的端到端测试；2 小时长稳注入 11 次 Broker 重启，全部自动重连、每次断链都正确停刷速度指令、内存 RSS 6.8MB 趋稳无泄漏；最终实车台架全链路回归通过——远程 0.15m/s 前进、原地转向、障碍自动 SAFE_STOP、急停/解除都实测达标。

讲的时候手里最好有张架构图（哪怕是白板手绘），语速放慢，每段之间停顿给对方插问的机会。面试官打断你是好事，说明他在跟着你的思路走。

9.1.2 架构总览：一张图记住整个系统

云服务器 (Mosquitto Broker, tcp://47.109.91.11:1883, 用户名密码认证)
        │  MQTT over TCP   topic: robot/v1/{robot_id}/...
        ▼
i.MX6ULL Linux 板（单核 Cortex-A7）
  ┌──────────── robotd（7 线程主控守护进程）────────────┐
  │ mqtt_thread → 邮箱 → command_thread → 邮箱 → can_tx  │
  │ can_rx_thread → 邮箱 → state_thread → MQTT 上报      │
  │ storage_thread(SQLite 唯一写者) + monitor_thread(看门)│
  └──────────────────────────────────────────────────────┘
  wifid(配网)  webd(视频/Web控制台)  robotd_hmi(LVGL屏显)
        │  进程间靠 /dev/shm 下 JSON 文件原子写协作
        │  SocketCAN 500kbps，8 个应用层 CAN ID
        ▼
STM32F407（FreeRTOS 实时控制）
  ctrl 任务 10ms：编码器 M 法测速 → 安全门控 → 四轮 PID → TIM8 PWM
  can 任务 10ms：CAN 收发分发；svc 任务 50ms：电池/超声/遥测；dbg 任务
        │  PWM/GPIO
        ▼
四路 TB6612 → 四个直流电机（带 107 脉冲/圈单通道编码器）

几个要在脑子里焊死的数字：MQTT 命令刷新周期 100ms、CAN 波特率 500kbps、STM32 命令看门狗 500ms、Linux 心跳周期 500ms / STM32 心跳超时判定 1500ms、PID 周期 10ms、PWM 频率 10kHz、测速窗口 100ms。这组数字本身就是面试的"质感来源"——能脱口而出，说明你真做过。

9.1.3 核心设计决策逐条剖析（问题 → 方案 → 权衡）

a) 为什么 Linux + MCU 分层，而不是单 Linux 或单 MCU

  • 问题：运动控制要 10ms 级硬实时，云端接入要 TCP/IP 协议栈、MQTT 客户端、数据库、视频编码，一块芯片能不能全包？
  • 方案：分层。i.MX6ULL（Linux）做"边缘网关+主控"：MQTT 收发、命令校验、状态聚合、SQLite 落盘、视频、Web、配网；STM32F407（FreeRTOS）做"实时运动控制"：编码器采样、PID、PWM、安全看门狗、超声避障。中间 CAN 总线解耦。
  • 权衡：单 Linux 方案的致命伤是 PREEMPT_RT 补丁也保证不了的确定性——PID 周期抖动、进程被杀控制即停摆；单 MCU 方案跑不动 MJPEG 视频、SQLite、完整 MQTT 生态，云端接入和后续 RL 数据管线无从谈起。分层的代价是多了一条 CAN 链路要设计协议、多了双端心跳要维护，但换来的是实时性归 MCU、生态归 Linux、故障域天然隔离——Linux 宕机，STM32 看门狗 500ms 内停车，这本身就是安全设计的一部分。

b) 7 线程职责划分与自研"环形队列+mutex+cond"邮箱

  • 问题：MQTT 回调线程、CAN 收发、命令校验、状态聚合、存储、监控，这些职责揉在一个线程里会互相阻塞（SQLite 写慢了就拖死控制链），开多线程又怎么安全通信、怎么有序退出？
  • 方案：robotd 拆 7 个线程——mqtt_thread（连接/订阅/发布/重连）、can_rx_thread（poll 收帧解码）、can_tx_thread（急停优先发送+Linux 心跳）、command_thread（校验与 100ms CMD_VEL 刷新）、state_thread（聚合上报）、storage_thread（SQLite 攒批写）、monitor_thread（1s 节拍看门）。线程间唯一通信原语是自研邮箱：固定容量环形队列 + 一个 mutex + 双条件变量（not_empty/not_full），消息是结构化 robot_msg_t（type 枚举 + union 载荷）。
  • 关键设计点（每一点都是面试加分项）：
    • 条件变量绑 CLOCK_MONOTONIC（pthread_condattr_setclock），系统校时不会扰乱超时判断；
    • 超时阻塞当节拍器用：各线程 mailbox_recv_timeout(50~200ms)，"有消息立刻处理、没消息按节拍醒"，一条 API 同时解决事件驱动和周期任务；
    • 消息分级：命令/故障事件用限时阻塞投递不可丢（mb_command=32、mb_mqtt_event=16），周期状态/速度/发布用 mailbox_send_overwrite() 丢旧保新（mb_velocity=4、mb_state=8、mb_mqtt_pub=32）——队列满时覆盖最旧消息并累计 dropped 计数，永不阻塞；
    • 存储不反压控制链：mb_storage=64，投递失败只打日志，SQLite 卡顿永远拖不跨控制线程；
    • shutdown 广播：退出时置标志 + pthread_cond_broadcast 双条件变量，唤醒全部阻塞收发，之后所有操作立即返回 MAILBOX_SHUTDOWN——这是 7 线程能被 pthread_join 有序回收的关键，SIGTERM 优雅退出还是 e2e 测试的第 19 项断言。
  • 权衡：为什么不用 POSIX 消息队列或管道？mq 在内核里排队、优先级机制用不上、跨平台差；pipe 只有字节流没有消息边界。自研 204 行换来：消息边界清晰、丢旧保新语义内建、shutdown 语义内建、可被单元测试完整覆盖（FIFO/阻塞/超时/覆盖/广播/SPSC 2 万条/4P3C 2 万条总量守恒）。全局健康状态用 C11 原子量（health_t），跨线程只读共享不加锁，避免了锁层级问题。

c) MQTT 可靠性四件套（外加 LWT 和 3s 重连）

  • 问题：QoS1 保证"至少一次"到达，意味着必然有重复；网络抖一下命令晚到 10 秒，车还该不该执行？Broker 重启后车连回来，会不会把重连前的旧命令再跑一遍？
  • 方案（每条对应一个真实代码机制）：
    1. QoS 分级：命令类（cmd/velocity、cmd/control、config/set）QoS1 不丢；周期状态（state/motion 200ms、state/sensor 500ms、state/system 2s）QoS0，丢了下一秒还有——省带宽；
    2. seq 去重：每条命令带单调递增 seq，command_thread 校验 seq > last_mqtt_seq，重复即 reject_dup_seq——QoS1 重发的 seq 相同，天然被去重；
    3. timestamp + TTL：命令带 timestamp_ms 和 ttl_ms=500，age 超 TTL 即 reject_expired；墙上时钟未校时（< 2020-01-01）跳过 TTL 检查，防止 RTC 没电的板子把自己锁死；
    4. robot_id 校验：统一前缀 robot/v1/{robot_id}/，payload 里 robot_id 必须匹配本车 car01，否则丢弃计数——为多车队列预留，防串车；
    5. LWT + retained status：连接时设 will（status=offline, QoS1, retained），正常退出也先发 retained offline——kill -9 之后 Broker 按 keepalive 10s 的约 1.5 倍时间代为发布离线，上位机永远知道车的真实在线状态；
    6. 3s 周期重连：断链后 3s 重连、重发订阅、重发 retained online，重连后不自动恢复旧速度——必须等新命令，这是安全语义不是缺陷。
  • 权衡：TTL 依赖校时是个坑（用单调钟规避了内部计时，但跨设备 TTL 只能用墙上钟），所以加了"未校时跳过"的逃生门；QoS1 的去重成本是每个连接周期记住一个 last_seq，换来的是幂等语义——分布式系统里"恰好一次"不存在，能做的只有"至少一次+幂等"。

d) CAN 帧设计：8 个 ID 与仲裁优先级的活用

  • 问题：总线上要跑命令、遥测、心跳、参数、急停，怎么分配 ID？急停帧被普通流量堵住怎么办？
  • 方案：500kbps 标准帧，全部多字节标量显式小端编解码，8 个 ID 按"越紧急 ID 越小"分配：
    • 0x060 EMERGENCY_CMD（急停/解除，事件帧）
    • 0x080 FAULT_EVENT（故障上报，fault 位上升沿才发，code 1~7）
    • 0x100 CMD_VEL（线速度 i16 mm/s + 角速度 i16 mrad/s + seq + flags，100ms 刷新）
    • 0x180 WHEEL_SPEED（四轮速，20ms）
    • 0x200 SENSOR_STATE（超声/舵机角/电池/标志位，50ms）
    • 0x300 PARAM_SET（kp/ki/kd/max_speed，定点 ×1000，事件帧）
    • 0x700 LINUX_HEARTBEAT（500ms）/ 0x701 MCU_HEARTBEAT（500ms）
  • 两道保险保急停：①0x060 是总线上最小 ID，CAN 非破坏性仲裁物理上就是最高优先级——这在第 5 篇讲过，这里是活学活用；②软件上急停帧走独立高优先级邮箱 mb_can_tx_hi，can_tx_thread 每 20ms 节拍先清空 hi 队列再发普通帧，且普通队列每节拍最多发 8 帧防突发挤占。
  • seq 双端规则：Linux 侧所有下行帧共用一个递增计数器；STM32 侧新 seq 接受并刷新看门狗、重复 seq 不重复执行、明显旧 seq 丢弃统计。QoS1 的去重在 Linux 侧按 MQTT seq 完成，CAN 侧 seq 是第二层——每一层有自己的幂等机制，互不依赖。
  • 权衡：周期帧用 i16 mm/s / mrad/s 定点而不用 float，省字节、消歧义、两端无浮点格式差异；参数用定点 ×1000 兼顾精度。代价是编解码代码两端各写一份——用 test_can_proto 逐位核对 9 种帧布局来兜底。

e) 5 层安全停车：fail-safe 的教科书式落地

  • 问题：这是一台会动的机器。任何一环（网络、进程、总线、MCU）失效，车的默认行为必须是"停下来"，而不是"保持最后指令继续跑"。
  • 方案（背下来，面试必考）：
    1. MQTT 断链 → command_thread 的安全门控立刻 clear_target() 停刷 CMD_VEL → STM32 侧 500ms 命令看门狗超时 → 进 SAFE_STOP 并报 fault code=1；
    2. STM32 心跳超时（1.5s） → monitor_thread 标记离线 → 新速度命令拒绝下发（reject_mcu_offline）并 MQTT 上报故障；
    3. 急停 → 0x060 走最小 ID + 高优先级邮箱直发，恢复前除 clear_emergency 外一切命令拒绝（reject_emergency）；
    4. robotd 进程崩溃 → 没人刷 CMD_VEL → 还是落到 STM32 500ms 看门狗兜底——进程级故障由硬件侧机制兜底，这是分层架构的红利；
    5. 运动控制 Topic 禁止 retain → 车重连 Broker 后绝不会执行历史运动命令。
  • STM32 侧的安全仲裁：Safety_Tick() 综合 cmdAge>500ms、hbAge>1500ms、障碍（连续 3 次去抖）、极低电、bus-off 任一触发即 Mode_Request(MODE_SAFE_STOP)；CtrlTask 中 Safety_IsSafeToRun() 为假时不调用 Motion_Tick10ms——不闭环输出、避免对抗刹车，PID 保持清零。故障位跟随实时状态可恢复（不锁存），防止 boot 时 ADC 未稳的低电误报把车永久锁死。
  • 权衡：500ms/1500ms 这组超时是"灵敏度 vs 误触发"的折中——看门狗太短，网络抖动就急停；太长，失控距离变长。1500ms = 3 倍心跳周期，给足丢帧余量。这套设计的哲学一句话：每一层都假设上游会死，死了就往安全态倒（fail-safe，不是 fail-operational）。

f) SQLite 五表与 rl_transition_raw 强化学习数据集

  • 问题：控制链路要留痕（出了事故能复盘）、系统要可观测（性能趋势）、还要为"智能物流"的"智能"二字沉淀数据资产——嵌入式数据库怎么设计？
  • 方案：五张表各司其职——cmd_log（每条命令的进出与结果）、state_log（500ms 轮速/超声/电池全量状态）、event_log（分级事件）、perf_log（每 5s 落盘 CPU/RSS/CAN 速率/邮箱深度）、rl_transition_raw（状态-动作-下一状态转移记录）。工程化手段：WAL + synchronous=NORMAL + busy_timeout=2000 的嵌入式折中；storage_thread 是全库唯一写者；攒批 32 条/200ms 单事务提交；五条 INSERT 全部预编译复用；双时间戳（monotonic_ts 排序可靠 + wall_ts 人类可读）。
  • rl_transition_raw 的巧思：每条被接受的速度命令开启一条转移——动作前取状态快照（紧凑 JSON：四轮速/超声/电池/模式），记录 action_v/action_w/action_mode/action_ts，200ms 后（或下条命令到来时）补 next_state 快照落盘；episode_id 每次 start 自增，event_flags 是该转移期间故障位图，task_id 来自 MQTT 消息供标注。这正好就是 Behavior Cloning / Offline RL 需要的 (s, a, s') 三元组——机器人控制项目的日志设计天然可以产出学习数据，关键是你建表时有没有这个意识。2 小时长稳实测该表 3210 行，数据管线是真实跑通的。
  • 权衡：SQLite 单写者意味着吞吐上限，攒批事务用 200ms 延迟换 I/O 次数；存储投递失败不反压——数据可以丢，控制不能堵，分级思想一以贯之。

g) WiFi 配网状态机与 webd 视频管线、LVGL HMI

  • wifid：单文件纯 libc 守护（1128 行，不链接第三方库），2s 一个 tick 跑三态状态机：STA_CONNECTING（拉起 wpa_supplicant+udhcpc，轮询 wpa_cli status，60s 连不上转 AP）→ STA_OK（断开靠 supplicant 自动重连，连续 120s 未恢复转 AP）→ AP_MODE（停 STA 组件、起 hostapd+udhcpd、配 192.168.4.1/24、开 captive portal 风格配网页，有配置时每 300s 回 STA 重试）。外部组件全走 popen/system 编排，杀进程扫 /proc 的 comm 匹配而不用 killall 防误杀，conf 文件先写 .tmp 再 rename 原子替换。
  • 80 端口错峰：wifid 只在 AP 模式监听 80；webd 每 2 秒读 /dev/shm/wifi_status.json，仅当 connected 才 bind 80，模式变化时主动 shutdown 所有视频流客户端还端口——两个进程共享一个端口而不冲突，靠的是文件做信号量的朴素 IPC。
  • webd 视频管线：V4L2 MMAP 四缓冲（固定 640x480 UYVY）→ select 等帧 → DQBUF → 残帧校验（ERROR 标志或 bytesused < 宽×高×2 直接 QBUF 丢回，这是修花屏的关键：CSI 带宽竞争丢帧尾，残留数据解码就是绿屏/花屏）→ 可选软件旋转 180°（UYVY 宏像素逆序+对内 Y 交换）→ 可选 2x2 盒式降采样到 320x240（驱动不支持运行时切传感器模式，S_FMT 成功但 STREAMON 报 EPIPE，改软件缩放）→ UYVY 转 RGB（BT.601 整数运算）→ libjpeg 内存编码 → 全局帧缓冲（mutex+cond+帧序号）→ MJPEG over HTTP（multipart/x-mixed-replace，最多 4 路，所有客户端共享同一份最新帧，编码只做一次）。录像更是硬核：不依赖 ffmpeg，纯手写 RIFF MJPEG-AVI——hdrl/movi/每帧一个 00dc chunk/idx1 索引/结束后回填头部各长度字段，单文件 5 分钟或 100MB 安全阀。i.MX6ULL 无 VPU 全软件编码，640x480 q70 实测约 7.5fps。
  • LVGL HMI：1024×600 /dev/fb0，六页触摸切换（总览/CAN/MQTT/线程/系统/WiFi），数据源只读 /dev/shm JSON，不参与控制闭环；FT5x06 evdev 触摸，失效时每 8s 自动轮播；线程页把 stall_mask 位图渲染成 7 线程红黄绿。踩过的坑：预编译 liblvgl 的 lv_snprintf 没开浮点（%f 打不出，改 libc snprintf 预格式化）；Makefile 无头文件依赖导致 health_t 结构错位（增量编译混入旧布局 .o，全部加 -MMD -MP）。
  • 权衡：这一组设计的共同主题是**"资源受限下的实用主义"**——能用文件协作就不上 D-Bus，能软件缩放就不折腾传感器驱动，能手写 AVI 就不拖 ffmpeg 上板。面试时可以主动讲这种取舍意识。

h) 测试体系：vcan 宿主机 e2e 20 项断言 + 2h 故障注入长稳

  • 问题：没有车的日子里怎么开发？上了车怎么证明系统可靠？"我测过了"三个字在面试里一文不值，可重复的测试设施才是工程能力的证据。
  • 方案（三层）：
    1. 宿主机单元测试：test_mailbox（FIFO/阻塞/超时/丢旧保新/shutdown/2 万条并发守恒）、test_can_proto（9 种帧字节布局逐位核对含负值小端）、test_jsonmini（畸形输入安全）；
    2. 宿主机 e2e：modprobe vcan 起虚拟 CAN，本机 mosquitto + 自研 stm32_sim 模拟器，robotd 真身跑全链路，20 项断言覆盖——retained online 上线、CMD_VEL 100ms 周期在 candump 里可见、QoS1 重复 seq 被拒、10s 前时间戳被 TTL 拒、robot_id=car99 被丢、急停帧 0x060 到达模拟器、急停中速度命令被拒、参数定点 ×1000 下发正确、五表落盘有数据、SIGTERM 优雅退出、kill -9 后 LWT 在约 15s 内发布 offline；
    3. 2h 长稳+故障注入：每 2s 一条正弦速度命令、每 30s 一次参数下发、每 10 分钟重启一次 mosquitto。实测：11 次断链全部自动重连、每次断链均停刷 CMD_VEL 且重连后不恢复旧速度、心跳停滞告警 0、CAN 发送失败 0、RSS 6.8MB 趋稳（无泄漏）、rl_transition_raw 3210 行。
  • 面试话术：这套体系的价值不在"通过了"，而在每一层都能独立跑——面试官随时可以在自己电脑上复现 vcan e2e，这比任何 PPT 都有说服力。故障注入（主动杀 Broker）体现的是混沌工程的朴素版：与其等线上断网，不如每 10 分钟亲手掐一次。

【记忆口诀】五层安全网，层层有兜底；命令不丢、状态丢旧；急停最小 ID 双保险；存储落盘不压控制链；断电断网断进程，车都只会停。

9.1.4 8 个典型 bug 案例复盘（面试"你踩过什么坑"的素材库）

面试官问"项目中遇到过什么困难/印象最深的 bug"，考察的不是你多倒霉，而是你的定位方法论：能不能讲清"现象→怎么查→根因→怎么修→沉淀了什么经验"。下面 8 个案例全部来自真实调试记录，每个都按这个五段式组织，挑 3~4 个练熟即可覆盖绝大多数追问。

案例 1：心跳无符号时间戳下溢，误判 STM32 离线

  • 现象：robotd 偶发拒绝速度指令（reject_mcu_offline），日志里心跳年龄是 18446744073709551614ms（=2^64-2）。
  • 定位：这个年龄值大得离谱，一眼就是无符号减法下溢——2^64 减 2 是签名特征。
  • 根因：monitor 线程先采样 now，CAN RX 线程后写入 last，两个 64 位时间戳跨线程无同步，竞争窗口下 now < last，now - last 在无符号域回绕成巨值。
  • 修复：3 处统一钳位 age = (now >= last) ? now - last : 0。
  • 经验：无符号时间戳相减必须考虑竞争与回绕；跨线程共享的时间戳要么原子读，要么做防御性钳位。

案例 2：单通道编码器不能判向，反转时 PID 正反馈跑飞

  • 现象：下发反转指令后，轮子越转越快停不下来。
  • 定位：正转一切正常、反转跑飞——问题必然在反馈符号上。
  • 根因：单通道编码器只有脉冲计数没有方向信息，反转时反馈仍读出正速度；目标为负、反馈为正，误差同号叠加，PID 变正反馈。
  • 修复：Motion_Tick10ms 里按驱动方向赋予反馈符号（Motor_GetDir()==BACKWARD 时取负）。
  • 经验：传感器的能力边界决定控制律设计——选型时省下来的正交编码器成本，会以软件复杂度的形式还回来。这是"硬件约束传导到软件"的经典案例，面试非常好讲。

案例 3：编码器系数占位值错 9 倍，闭环 act 恒 0、PWM 顶满

  • 现象：轮速闭环反馈恒为 0，PWM 输出顶满 100%。
  • 定位：反馈恒 0 而电机明明在转，先查测速链路，再查换算系数。
  • 根因：board_config.h 里码盘常数是占位值 960 脉冲/圈（按"20 线×48 减速比"拍脑袋填的），实物电机根本不是这个规格，换算出来反馈≈0；目标远大于反馈，积分饱和把输出顶满。
  • 修复：台架肉眼数圈标定（右后轮 2.67 圈=285 脉冲）得真实值 107 脉冲/圈；顺手把测速窗口从 10ms 拉到 100ms，量化误差从 197mm/s 降到 19.7mm/s。
  • 经验：占位常量必须显式标注、集中管理、尽早实测标定；M 法测速的窗口长度是分辨率与延迟的权衡，低线数编码器尤其敏感。

案例 4：停车后电机哼鸣，残余 20% 占空比

  • 现象：stop 指令后车停了，但电机持续哼鸣，示波器看占空比残余约 20%。
  • 定位：tgt=0 且 act=0，比例微分项都是 0，输出却非 0——只剩积分项有嫌疑。
  • 根因：停车后残余积分不清零，ki×integral 持续顶出一个空耗占空比。
  • 修复：Motion_Tick10ms 增加"停车保持"分支：tgt=0 且 act=0 时清积分、清 prev_err、彻底关输出。
  • 经验：位置式 PID 的工程细节全在边界条件——积分限幅、抗饱和、停车清零，教科书公式之外的三件套缺一不可。

案例 5：电池采样大负载干扰 + 停机瞬间误触发低电保护（两连修）

  • 现象：电机一加载就 SAFE_STOP，电池读数 3.4~5.5V（静置 8.05V 完全正常）；第一版修完后，又在停车瞬间误触发低电/极低电（code=3/4）。
  • 定位：对比"静置正常、加载异常"锁定干扰源在电机电流；第二次故障固定在停车瞬间，顺着去抖计数器的时序查。
  • 根因：大电流下分压采样点受干扰读数偏低；第一版只在 safety_manager 的判定环节加了负载门控，但 battery_monitor 的去抖计数在高负载期间照样累积——停车瞬间 PWM 回落、门控放开，计数恰好攒满立即误判。
  • 修复：判定与去抖计数双重门控——全部电机 |pwm|≤2000 时才判定/计数，高负载期间计数清零（跨两个模块的协调修复）。
  • 经验：门控要覆盖整条判定链（采样→滤波→去抖→判定→动作），只罩最后一环等于没罩；硬件侧的根治建议是开尔文接法采样、电池与电机不共地线回路。这个案例讲"跨模块 bug"和"修复引入次生 bug"都好用。

案例 6：障碍期间 SAFE_STOP/REMOTE 模式 10Hz 高频抖动

  • 现象：超声检测到障碍期间，模式在 SAFE_STOP 与 REMOTE 之间以 10Hz 频率来回跳。
  • 定位：抖动频率恰等于 CMD_VEL 的到达频率（100ms 周期）——两个控制源在每帧节拍上互拉。
  • 根因：CMD_VEL flags 里的模式位强制 Mode_Request(REMOTE)，而 safety_manager 因障碍要求 SAFE_STOP，两个决策源没有仲裁。
  • 修复：模式切换统一收归 safety_manager 门控，CMD_VEL flags 只保留急停位。
  • 经验：单控制源原则——同一个状态机只能有一个写入者，多源写入必然要仲裁层，否则就是抖动之源。

案例 7：CAN 硬件 IDLIST 过滤器上电周期不一致，回退全收+软件过滤

  • 现象：STM32 某些上电周期收不到 0x100/0x300 命令帧但收得到 0x700 心跳，寄存器配置读回完全正确。
  • 定位：按 ID 分组的"选择性失明"指向过滤器；复位若干次统计成功率，确认与上电周期相关。
  • 根因：疑似硬件 IDLIST 过滤器初始化时序竞争（未实锤），调试中还发现调试器读过期符号地址的干扰。
  • 修复：过滤器回退为 32-bit MASK 全 0 全收 + 软件分发过滤，复位稳定性 6/6 通过；实车如需白名单再专项排查。
  • 经验：可靠性优先于"教科书正确"——软件过滤是合法降级，CPU 多花几微秒分发，换来的是每次复位行为一致。做不出可复现的硬件 bug，先绕开再追查，别让用户陪你赌概率。

案例 8：AP 配网网段与 eth0 冲突，配网页永远打不开

  • 现象：手机连上设备热点后，浏览器访问配网页 TCP 握手永远失败。
  • 定位：tcpdump 在 wlan0 抓到 SYN、看不到回包，顺着路由表查发现回包错走 eth0。
  • 根因：AP 网段配成 192.168.1.0/24，与 eth0 有线网段相同——双接口同网段，内核路由把回包扔去了错误的接口。
  • 修复：AP 网段改 192.168.4.0/24 刻意避开，文档注明"实测踩过"；同批还修了 conf_has_network() 误匹配注释里 # network={ 示例导致 AP 每 5 分钟被 STA 重试打断的问题（改跳过注释行）。
  • 经验：网络问题先抓包再猜；嵌入式设备多网卡同网段是经典网工坑，产品定义阶段就要把各接口网段规划开。

（候补素材库：Web 遥控台 seq 从 1 开始小于 robotd 历史值被全量拒——改 Date.now() 做基数；MQTT 同 clientID 互踢——板端与宿主机同用 car01 被 Broker 反复踢线 768 次；bxCAN 未开 AutoWakeUp 外设进睡眠发送全停；多任务并发 HAL_UART_Transmit 卡死 BUSY_TX——加互斥锁。这些一句话版可以在追问时抛出。）

【记忆口诀】下溢看 2 的幂，跑飞查反馈符号，顶满找占位常量，哼鸣清残余积分，门控罩全链，模式单写源，过滤可回退，网段别撞车。

9.2 项目二：embedded-agent 嵌入式开发智能体

9.2.1 电梯陈述

30 秒版：

"这是一个本地运行的嵌入式开发智能体：用户上传原理图 PDF 和 CubeMX 工程，用自然语言描述需求，系统自动完成'资料解析 → 需求澄清 → 代码生成 → 编译 → 烧录 → 串口验证'的完整闭环。技术上它不是一个单体大模型，而是一条多模型流水线：Kimi 做原理图视觉解析，DeepSeek 做需求对话和结构化摘要，OpenCode 作为代码 agent 在真实工程目录里写代码，所有编译、静态检查、烧录、串口判定都由本地脚本做硬门禁。最大的特色是把'硬件在环验证'作为验收终点——AI 生成的固件必须真烧到板子上、串口真的打印出 [BOOT]/[INIT]/[STATE] 日志才算过。"

3 分钟版（四段式）：

  1. 背景（25 秒）：嵌入式开发有大量重复劳动——读原理图确认引脚、查手册、搭 CubeMX 工程、写 BSP。通用代码 AI 生成的 STM32 代码常见三类病：引脚靠猜（幻觉）、能编译但跑不起来（缺硬件验证）、需求聊着聊着就飘（长对话漂移）。这个项目就是针对这三类病开药。
  2. 架构（60 秒）：两条入口同一套阶段——CLI 五阶段流水线和 Web 九步引导式状态机。模型分工：Kimi K2.6 视觉模型逐页解析原理图输出严格 JSON schema 的引脚事实；DeepSeek V4 Pro 做需求多轮对话并维护结构化摘要；OpenCode 开源代码 agent 在真实工程目录里读写代码、跑构建；本地 Makefile/脚本做零警告编译门、静态质量门、OpenOCD/st-flash 烧录、串口采集与运行时日志门——凡是要确定性的事都不交给模型。
  3. 关键设计（70 秒）：挑四个讲——①权威硬件事实链：pin_map.json 标注 authoritative:true，模型先验必须让位，unknown 禁止当默认值用，引脚硬冲突直接 fail 流水线；②requirements.md 四分法（已确认需求/硬件事实约束/接口协议参数/验收标准）治理长对话漂移，确认绑定内容 sha256 digest，内容变了确认自动失效；③CubeMX 基座 + overlay 三层架构：AI 代码隔离在 ea_bsp/ea_modules/embedded_agent.mk，CubeMX 重新生成时快照回贴，AI 代码永不丢失；④验收现实主义：编译零警告才算过（returncode=0 但有 1 个 warning 就判 failed 的真实案例）、串口 no_data 绝不算过、必需日志 [BOOT]/[INIT]/[STATE] 与禁止日志 [ERROR]/[FAIL]/[TIMEOUT] 双清单。
  4. 价值与边界（25 秒）：已有 4 个真实项目工作区入库展示完整产物（含真实串口验证日志：AT 指令进透传、周期 [STATE] 上报）。定位是"嵌入式工程师的副驾驶"而不是替代者——板卡预检、人工核查关卡、硬件在环的最终判断都把人留在回路里。

9.2.2 流水线九阶段与多模型分工

Web 引导式工作流九步状态机（每步产物落 manifest.json + snapshot.json，可逐级回退）：

NO_PROJECT → BASE_REQUIRED(CubeMX 基座) → MATERIALS_REQUIRED(上传资料)
→ PARSE_REQUIRED(解析) → HARDWARE_REVIEW_REQUIRED(人工核查, 必须输 yes)
→ REQUIREMENTS_REQUIRED(需求对话, 摘要+digest 双确认)
→ CODE_AGENT_READY(打开代码智能体) → VALIDATION_REQUIRED(编译/烧录/串口) → DONE

CLI 五阶段对应压缩版：原理图分析（Kimi）→ SDK 索引（本地）→ 输入验证（validator 引脚硬冲突即失败）→ 生成+编译修复循环（OpenCode/DeepSeek + 本地 make，每轮过零警告门和静态门，失败则构造 repair_context 进下一轮，git 切 repair/round-N 分支）→ 烧录+串口采集+运行时日志门+verify。

多模型分工的"为什么"（面试必答）：

角色 干什么 为什么是它
Kimi K2.6（视觉） 原理图/扫描页/图表页逐页解析，输出严格 JSON（chip/pins/peripherals/led_circuits/confidence/open_questions） 视觉任务是专门能力，且成本可控（每文档视觉页上限 4 页）
DeepSeek V4 Pro 需求多轮对话、结构化摘要、修复轮最小 diff 长上下文+工具调用+context cache（稳定前缀命中缓存，日志里可见 prompt_cache_hit_tokens）
OpenCode（代码 agent） 在真实工程目录读改代码、跑构建、看串口 不重复造轮子——embedded-agent 只做上下文与工具层，生成交给成熟的 agent，用权限配置（禁改 ThirdParty、禁 rm -rf）+AGENTS.md+contracts+codegen_skills 四层约束箍在嵌入式安全边界内
本地脚本/Makefile 编译门禁、静态检查、烧录、串口判定 确定性任务不给模型：编译过没过、串口有没有 [BOOT]，是 0 和 1 的问题，必须可复现、可审计

一句话总结分工哲学：模型负责"理解"和"生成"，脚本负责"判断"；理解可以模糊，判断必须确定。

9.2.3 关键设计逐条讲

① 资料路由：视觉 vs 文本。 document_router.py 对每个上传文件定路由：纯文本/有文本层 PDF 本地 pdftotext 切块索引（1800 字符、overlap 180、≤80 块）；图片和原理图渲染 PNG 交 Kimi 视觉；视觉页判据包括文件名关键词、页面含"时序图/引脚图/框图"词、文本层字符数 <120 等；长扫描 PDF 无文本层直接跳过不硬调 Kimi（成本控制）；Excel 协议表有专门解析器（sheet/颜色图例/协议亮点转 Markdown）。原则：原理图给眼睛看，手册给检索用，纯文本项目不强行调视觉模型。

② requirements.md 四分法治长对话漂移。 这是整个项目最有方法论味道的设计：多轮对话中 DeepSeek 每轮回复末尾维护结构化摘要块；最终产出 requirements.md 固定四节——已确认功能需求（编号锁定到具体引脚参数）、硬件事实约束（含冲突纠正记录，如"PC13=WiFi EN 不可作普通 GPIO"）、接口/协议/参数（CAN 帧布局+样例字节流+超时参数+占位常量集中 board_config.h 的声明）、验收标准（可逐条验证的行为语句）。文件头声明"摘要为主输入，原始对话只作追溯来源，不反向覆盖"；确认机制绑定内容 sha256 digest——内容一改确认自动失效。**聊天记录是会漂移的，只有落盘并确认的文档是需求。**生成阶段默认不读 chat_history.jsonl。

③ 权威硬件事实链。 Kimi 逐页 JSON → 聚合去重成 pin_map.json（标 authoritative:true，规则写明"必须优先使用这些事实而非历史 assistant 猜测或常见开发板默认值；没有记录的角色回答未知，不要编造"）→ 拓扑规则引擎修正保守输出（如"GPIO→电阻→LED→GND 则 active_high"，保留 previous/reason 审计痕迹）→ board_profile.json 的 unknown 禁止当默认值、必须转 open_questions 人工确认 → HARDWARE_REVIEW 关卡人工输 yes（digest 绑定）→ validator 对硬角色冲突（同一引脚既是 LED 又是 RESET/BOOT/OSC）直接 fail 流水线。"AI 幻觉引脚"被六道关卡层层拦截——这就是回答"你怎么保证 AI 生成的代码不烧板子"的标准答案。

④ CubeMX 基座 + overlay 三层。 嵌入式工程师的真实工作流以 CubeMX 为中心，所以系统选择共生而非对抗：第一层 CubeMX 基座（.ioc/MX_*_Init/Drivers/Makefile，只保留不重写）；第二层 overlay（AI 生成物固定在 ea_bsp/、ea_modules/、driver_api、debug_log、board_config.h、embedded_agent.mk）；第三层实际工程 = 基座 + overlay + 最小 USER CODE 接入（main.c 只动 USER CODE 区）。embedded_agent.mk 用 wildcard 并入源文件，托管命令块（make all/size/flash/reset/monitor/serial/verify/doctor）由系统维护、AI 不得删除只维护源文件清单；重新上传 CubeMX 工程时先快照 overlay 再重建、然后覆盖回——CubeMX 重新生成永远冲不掉 AI 代码。

⑤ 零警告编译门 + 静态质量门。 编译门：passed ⟺ returncode==0 且 warnings==0 且 errors==0——仓库里就躺着一份 returncode=0 但 1 个 -Wunused-variable 被判 failed 的真实报告。静态门：禁 TODO/FIXME/占位字样；空函数和仅 (void)param; 的伪实现；针对 ESP8266 场景的 UART/AT 协议五类反模式专项检测（不完整帧就 pop 环形缓冲、长度前缀 payload 用 strlen、> 提示符按行解析、异步发送存外部 payload 悬垂指针、声明长度与字面量不符）——每条带中文说明和修改建议，本质是把调试经验固化成静态规则。

⑥ 板卡预检读 DBGMCU_IDCODE。 生成前先预检：芯片必须是芯片目录里的具体订货号（手输模糊型号给候选清单并 blocker）；检测 STM32_Programmer_CLI/openocd/st-info/pyocd/JLink 工具链；lsusb 识别 ST-Link（0483:374x）与 DFU Bootloader（0483:df11）；用三种工具实测读 0xE0042000（DBGMCU_IDCODE）与 23 个 Device ID 表比对家族，实测家族与目标不符直接 blocker；串口实际 open 测可用性；烧录方式推断分级。定位说得很诚实："不是完整硬件验证，只是减少开始生成后才发现工具链/串口/烧录命令没配置。"

⑦ [BOOT]/[INIT]/[STATE] 运行时日志门。 烧录后先开串口再复位（捕捉 BOOT 日志），必需事件默认 [BOOT]/[INIT]/[STATE] 外加从需求文档扫描出的显式标记（如 [ESP8266]/[MOTOR]，最多 20 个），禁止事件 [ERROR]/[FAIL]/[TIMEOUT]；串口 no_data 绝不算通过；配套生成约束要求固件主循环早期周期重复输出运行摘要（因为串口可能复位后才打开）。stm32_imu 示例里躺着真实日志：[BOOT]→[INIT]×7→[ESP8266] AT+CWMODE/CWJAP/CIPSTART/CIPMODE/CIPSEND→透传→[STATE] 周期上报 Rx/Valid/Err 计数——拿这个讲"验收"比任何抽象描述都硬。

⑧ git 里程碑可回退。 工程目录内建 git：bootstrap 分支→"构建通过"提交→feature/flash-verify→feature/runtime-verify，修复轮切 repair/round-N 分支；guided workflow 按步回退逐级清理下游产物，回退需求层时保留原理图解析成果；旧一轮归档到 iterations/<时间戳> 后可推翻重来。AI 生成物必须像人写的代码一样可审计、可 diff、可回滚。

⑨ experience.jsonl 经验库。 每个失败/通过节点自动记录 source/stage/outcome/chip/problem/root_cause_hint/resolution_hint/tags 到 JSONL。最值得讲的是一个诚实的设计注释：当前"故意被动"（deliberately passive）——只持久化供后续检索，生成提示词还不读它。定位是失败模式数据库，为未来"相似问题快速提示/自动修复策略"攒数据资产。

9.2.4 面试可讲的两个工程思想

为什么"硬件在环验证"比代码评审更可靠？ 对 AI 生成的嵌入式代码，评审能抓住风格问题，但抓不住三类致命伤：引脚配错（烧上板才知道）、时钟树算错（跑了才知道）、外设时序不对（联调才知道）。代码评审是人对文本的判断，硬件在环是物理世界对代码的投票——DBGMCU_IDCODE 读出来对不对、串口 [BOOT] 打没打出来、LED 亮不亮，这些事实不接受辩解。所以流水线把验收终点放在"烧录+串口日志门"而不是"模型自查通过"，并且 OpenCode 默认流程运行验收只做一次就展示报告——把最终判断留给人，而不是让模型自圆其说。

为什么经验库"故意被动"？ 直觉上经验库应该立刻回喂生成（RAG），但这个系统选择先只记不读，原因是：未经验证的经验回喂会污染生成——一条错误的 resolution hint 被模型当成权威引用，比没有经验库更糟糕。先把 schema 设计好（problem/root_cause_hint/resolution_hint/tags）、把数据攒起来，等样本量和质量足够、检索策略验证过之后，再考虑回喂。这体现的是数据资产的迭代节奏意识：先建管道，再开阀门。面试里讲这个，传递的是"我知道 AI 系统什么时候该克制"。

【记忆口诀】眼睛归 Kimi、对话归 DeepSeek、写码归 OpenCode、裁判归脚本；引脚六关拦幻觉，摘要四分治漂移；基座 overlay 三层皮，零警告才算过编译；BOOT INIT STATE 不见不算完，经验库先攒后用不着急。

9.3 综合面试问答（30 条）

每条给"参考答案要点"，面试时用要点组织口语回答，别背稿子。标记 ★ 的为超高频题。

项目讲述类

  1. ★自我介绍时项目怎么讲？ 30 秒版破冰：场景一句话（物流 AGV 车载控制平台）→ 架构一句话（云 MQTT → Linux 主控 → CAN → STM32 实时控制）→ 你干的三件事（7 线程邮箱/五层安全/RL 数据集）→ 质量证据（20 项 e2e 断言 + 2h 故障注入）。对方示意展开再接 3 分钟版（背景→架构→难点→验证）。全程"价值先行，细节殿后"，手里备一张架构图。

  2. ★你项目最大的难点是什么？ 推荐答"五层安全停车"：难点不在任何单点技术，而在让分布式系统里每一环失效时默认行为都是停车——MQTT 断链靠停刷命令+MCU 500ms 看门狗、进程崩溃天然落进同一张网、STM32 离线靠 1.5s 心跳双向判定、急停靠 CAN 最小 ID 仲裁+独立高优先级队列、重连防历史命令靠禁 retain。追问时补案例 5（电池干扰两连修）展示跨模块调试能力。

  3. 这个项目如果让你重做，哪里会改进？ 诚实的点：①CAN 过滤器回退成全收+软件过滤是降级不是终结，实车要排查 IDLIST 时序问题恢复硬件白名单；②单通道编码器应升级正交编码器，从硬件上消灭反馈符号补偿逻辑；③TTL 校验依赖校时，可加 RTC 电池或 NTP 强校时流程；④多车调度目前只预留了 robot_id 命名空间，真正多车要加 Broker ACL 和任务仲裁。

  4. 项目里你最有成就感的部分？ 自选，但建议选"有数字的"：2h 长稳 11 次 Broker 重启全恢复、RSS 6.8MB 无泄漏；或 vcan 宿主机把整条车端链路搬进 CI 式测试，20 项断言全自动。成就感 = 可量化的结果。

多线程与并发类

  1. ★为什么用多线程不用多进程？ robotd 内部七个子任务共享大量状态（health_t 健康位图、邮箱、配置），线程间共享地址空间通信成本最低，C11 原子量就能承载只读共享；进程隔离的代价（IPC 序列化、共享内存+信号量的复杂度）对这种紧耦合协作不划算。反过来说，跨职责边界的地方恰恰用了进程——robotd/wifid/webd/hmi 四进程各自独立部署、崩溃互不影响、靠 /dev/shm JSON 文件协作。所以答案是"紧耦合一进程多线程，松耦合分进程"，两层都用上了。

  2. ★为什么自己写邮箱，不用 POSIX 消息队列/管道？ mq 在内核排队、消息优先级机制本项目用不上、丢旧保新语义要自己包一层、shutdown 广播语义不支持；管道只有字节流没有消息边界。自研 204 行环形队列+mutex+双 cond，换来四个内建语义：消息边界、丢旧保新（覆盖最旧+丢帧计数）、超时阻塞当节拍器、shutdown 广播唤醒全部线程有序退出。而且可被单元测试完整覆盖。

  3. 条件变量为什么用 CLOCK_MONOTONIC？ pthread_cond_timedwait 默认用 CLOCK_REALTIME，系统校时（NTP 跳变、RTC 校正）会让超时瞬间过期或永不触发——车载设备校时场景很常见。pthread_condattr_setclock 绑单调钟后，deadline 只随真实流逝时间推进，语义稳定。

  4. ★丢旧保新会不会丢关键数据？ 不会，因为消息是按语义分级的：周期状态（速度/轮速/发布）天生可丢——下一帧 20ms/200ms 后就来，旧值没有保留价值，丢了反而避免消费过期指令；命令和故障事件走另一条路（限时阻塞投递+大容量队列），不可丢。分级的判断标准是"这条消息的价值随时间衰减吗"：衰减→丢旧保新，不衰减→保证送达。存储投递失败不反压控制链，也是同一哲学的延伸：新鲜度优先于完整性的是状态，完整性优先的是事件。

  5. 7 个线程怎么保证有序退出？ SIGINT/SIGTERM 处理器只置原子 shutdown 标志（信号安全），主循环调 mailboxes_shutdown() 对所有邮箱置标志并 broadcast 双条件变量，唤醒全部阻塞收发；各线程每圈检查标志自然退出（command_thread 退出前尽力发一帧零速）；pthread_join 有序回收后再销毁邮箱。e2e 测试第 19 项断言就是 SIGTERM 优雅退出 + retained offline 发布。

  6. monitor 怎么发现线程假死？ 每个线程每圈调 thread_beat() 上报原子心跳，monitor 1s 节拍检查，10s 无心跳置 stall_mask 位图（10s 的阈值特意覆盖 MQTT 重连阻塞的正常时长），HMI 线程页渲染红黄绿。2h 长稳实测停滞告警 0 次。

通信协议类

  1. ★MQTT 和 HTTP 怎么选？ 车载遥测/控制选 MQTT：发布订阅解耦（多车上报、多端订阅天然匹配）、长连接低开销（HTTP 每请求三次握手+头部开销）、QoS 分级、LWT 遗嘱（进程暴毙 Broker 代发 offline）、Broker 可做边缘缓冲。HTTP 适合：请求响应语义的配置下发、文件传输、webd 的状态页/视频流（MJPEG 本来就是 HTTP multipart）。本项目两者都用：控制遥测走 MQTT，板端 Web 控制台走 HTTP——按交互模式选协议，不按信仰选。

  2. ★CAN 和 RS485 怎么选？ CAN 赢在：多主无损仲裁（ID 越小优先级越高，急停帧 0x060 物理层就插队）、硬件错误处理（CRC/ACK/错误帧/bus-off 自动隔离）、消息寻址（ID 过滤）、差分抗干扰+故障界定。RS485 只是电气层标准，多主仲裁、错误恢复全要应用层自己写。车规场景 CAN 是事实标准，收发器（TJA1042）和 MCU 外设（bxCAN）生态成熟。485 适合：超长距离（1200m vs CAN 40m@1Mbps）、低成本楼宇/传感器网络、纯主从轮询。本项目 Linux↔STM32 短距离实时控制，CAN 无可争议。

  3. CAN 帧为什么用小端、为什么用定点不用 float？ 两端架构不同（ARM Linux 与 Cortex-M4 虽都是小端，但协议明确写死字节序是防御可移植性）；定点 i16 mm/s / mrad/s 和参数 ×1000：省字节、消除浮点格式/精度歧义、MCU 端无需浮点转换开销、协议文档里每个字节的含义可以逐位核对（test_can_proto 就是这么测的）。

  4. QoS1 会重复，你怎么处理？ "恰好一次"在分布式系统里不存在，工程上只有"至少一次+幂等"。命令带单调 seq，接收端记 last_seq，重复即拒（reject_dup_seq）；CAN 侧还有第二层 seq 去重。此外 TTL 处理"迟到"（age>ttl 拒收）、robot_id 处理"串台"、禁 retain 处理"复活"（重连后不执行历史命令）。

  5. 心跳周期和超时怎么定？ 经验法则：超时 = 3 倍周期起步。Linux 心跳 500ms、STM32 判离线 1500ms；CMD_VEL 刷新 100ms、看门狗 500ms（容忍丢 4 帧）。太短误触发（网络抖动就急停），太长失控距离变大——按场景的"最坏失控时间"反推。

控制与实时类

  1. ★PID 怎么调？ 本项目是位置式 PID，周期 10ms，整定值 Kp=30 Ki=40 Kd=0（输出量纲=CCR 占空比，err 1mm/s→30 CCR）。方法：先 P 到响应不迟滞、再加 I 消静差（积分限幅 ±ARR/2+抗积分饱和+停车清零三件套必须先在位，否则积分饱和顶满就是案例 3/4 的样子）、D 在速度环噪声大时保持 0。参数在线整定链路：MQTT config/set → CAN 0x300 定点 ×1000 → STM32 内存生效，复位回默认值——台架整定不用重烧固件。

  2. ★实时性怎么保证？ 分层保证：硬实时（10ms PID、编码器采样）在 STM32 侧，FreeRTOS 的 vTaskDelayUntil 给绝对节拍（消除累积漂移）、ctrl 任务 High 优先级、CAN RX 中断只入队（xQueueSendFromISR，32 深）业务在任务里消费——ISR 极简原则；软实时在 Linux 侧：命令刷新 100ms 节拍用邮箱超时实现，状态链路全程非阻塞+丢旧保新防止积压传导。实时性的最后一道防线不是调度器，是STM32 的 500ms 命令看门狗——Linux 侧再慢，车也只会安全停下。

  3. 编码器测速为什么用 M 法、窗口为什么 100ms？ M 法（固定窗口数脉冲）实现最简单，适合中高速；T 法（测脉冲周期）低速精度高但实现复杂。107 脉冲/圈的低线数编码器，10ms 窗口 1 个脉冲对应 197mm/s 量化误差太粗，攒到 100ms 窗口降到 19.7mm/s；代价是速度反馈延迟增加，与 10ms PID 周期的关系是"每 10 个控制周期才更新一次反馈"——可接受，因为车体惯性本身就是低通的。这就是传感器分辨率、控制带宽、量化噪声的三角权衡。

  4. 超声避障怎么去抖？ 连续 3 次读数低于 250mm 才判定障碍（读数周期 50ms，约 150ms 确认延迟），正常/超时读数立即清零计数。修过单次 195mm 误读误触急停。测距本身用五态非阻塞状态机（IDLE→SERVO_MOVE→SETTLE 300ms→TRIG→WAIT，35ms 无回波判无效），TIM5 1MHz 自由运行+双边沿 EXTI 测回波脉宽——全程无 HAL_Delay 阻塞。

系统与排查类

  1. ★系统宕机/跑飞怎么排查？ 分域排查法：①先定边界——是 Linux 侧还是 STM32 侧？看 CAN 心跳双向是否活着（candump 抓 0x700/0x701）；②Linux 侧：HMI 线程页看 stall_mask 哪个线程停滞，perf_log 看 RSS/CPU 趋势（泄漏是单调爬升），event_log 按时间回放故障序列；③STM32 侧：dbg 任务 500ms 全量状态日志（mode/tgt/act/pwm/fault/cmdAge/hbAge），栈溢出 hook 会打印任务名（踩过 can/dbg 任务 256 字栈溢出改 512）；④总线侧：错误帧统计识别 bus-off（CAN_ERR_BUSOFF）。原则：先切分故障域，再在域内按数据流逆推。

  2. ★Linux 和 MCU 的分工边界怎么划？ 判据三条：①确定性要求——10ms 级周期任务、安全兜底（看门狗/急停执行）必须 MCU；②生态需求——TCP/IP、MQTT、数据库、视频编码、Web 必须 Linux；③故障域——希望"Linux 死了车也安全"，所以停车能力必须不依赖 Linux。边界上跑的是 CAN 应用层协议，协议即契约：ID 表、字节布局、seq 规则、超时参数，两端各写一份代码同测一份协议文档。

  3. 内存泄漏怎么查？ 嵌入式三板斧：①RSS 长时趋势（perf_log 每 5s 落盘，2h 长稳 6.8MB 趋稳就是无泄漏证据）；②valgrind 宿主机版（make HOST=1 就是为这类工具存在的）；③代码纪律：robotd 全程无 malloc 热路径，消息走固定容量邮箱，动态分配集中在启动期——最好的查泄漏方法是不给泄漏机会。

  4. 多核/多线程共享数据要注意什么？ 本项目实践：只读共享+低频写用 C11 原子量（health_t）；生产者-消费者走邮箱（mutex+cond 内部封装）；禁跨线程直接调非线程安全库（所有 paho 发布串行化在 mqtt_thread，SQLite 单写者）；时间戳跨线程比较要防竞争（案例 1 的下溢 bug）。再加一条教训：结构体改了头文件一定要全量重编——Makefile 加 -MMD -MP 自动生成头文件依赖，否则增量编译混入旧布局 .o 会出现"灵异"的结构错位。

扩展与架构演进类

  1. ★如果做多车协同，怎么扩展？ 现状已预留 robot_id 命名空间（robot/v1/{robot_id}/...）。要做的是：①Broker 侧 ACL——每车独立账号，只能发布自己的 state、订阅自己的 cmd；②调度层加一个车队管理服务：订阅所有车状态（通配 robot/v1/+/state/#）、按任务分配 goal，任务级 seq/任务 ID 已有（payload 里 task_id 就是为此准备的）；③车端不变——这就是发布订阅拓扑的好处，加车不改车；④数据集侧 rl_transition_raw 有 robot_id 字段，多车数据天然可分片汇总做集中训练；⑤安全侧每车独立的五层机制天然隔离，一车失控不影响他车。

  2. 为什么不直接上 ROS？ 车端资源（单核 A7+512MB）和确定性要求下，ROS 的 DDS/节点框架太重；团队需要的是"够用且完全可控"的最小栈——200 行邮箱比 roscpp 的回调链好查 bug。但架构思想是通的：topic 命名空间、发布订阅、消息分级，本质是把 ROS 的核心理念用 1% 的复杂度实现。如果未来上激光 SLAM/导航，可以在 Linux 侧加 ROS2 容器层，MQTT 网关层做协议桥——架构留了演进台阶，而不是一步到位上重框架。

  3. SQLite 会不会成为瓶颈？坏了怎么办？ 攒批 32 条/200ms 单事务，实测 2h 写 2 万+行无压力，远低于 WAL 模式上限；可靠性三件套：journal_mode=WAL（读写不互堵）、synchronous=NORMAL（性能与掉电安全折中）、busy_timeout=2000；单写者+邮箱解耦保证写入可背压丢弃不拖控制链。库文件损坏的兜底：数据价值是"复盘与训练"，丢了不致命；真要加固可加定期 VACUUM INTO 备份。

智能体项目类

  1. ★智能体项目的价值与局限是什么？ 价值：把嵌入式开发里最重复的四件事（读原理图确认引脚、查手册、搭工程骨架、写 BSP）自动化，并用"权威硬件事实链+静态门禁+硬件在环验证"三道闸控制 AI 幻觉风险；已有真实项目跑通到串口日志验证。局限（必须诚实讲）：①不能替代工程师的硬件判断——板卡预检、HARDWARE_REVIEW 人工关卡、运行验收只跑一次留给人，都是把人留在回路里的设计；②复杂业务逻辑（如本项目这种带安全语义的控制律）仍需人工主导需求；③经验库当前"故意被动"，离"相似问题自动修复"还有距离；④成本与速度——视觉解析和多轮生成的 token 开销决定了它适合"从 0 到 1"而非日常小改。

  2. 为什么不让一个大模型包打天下？ 四个理由：①能力专精——视觉解析和代码生成是不同能力分布，专门模型各干各的；②上下文长度——把原理图 PNG、手册全文、需求对话全塞一个窗口既不经济也漂移，拆分后每步只给该给的上下文（修复轮只给 ≤20 个 focus_files）；③确定性——编译过没过、串口有没有 [BOOT]，是 0/1 判断，本地脚本做才可信，模型只能做"理解"和"生成"不能做"裁判"；④可审计——多阶段流水线每步产物落盘（报告/manifest/digest），单模型黑盒无法回溯。

  3. ★你的技术栈哪里最强、哪里最弱？ 强（对照前 8 篇挑你有证据的）："我最强的是 Linux 用户态系统编程与通信协议这一层——项目里 SocketCAN、手写 rtnetlink 配波特率、MQTT 可靠性工程、自研线程邮箱都是亲手实现并有测试覆盖的；MCU 侧 FreeRTOS 任务设计、PID 工程化、CAN 应用层协议设计也有实车验证。"弱（要真实且给改进计划）："内核驱动开发是我的相对短板——项目里 CSI/V4L2 用的是现成驱动，我做到的是用户态 V4L2 管线和读懂内核日志（imx7-csi: skip frame），但还没独立写过字符设备驱动。目前在学习第 4 篇的驱动框架路线，计划把板子的按键/LED 用 platform driver 重写一遍练手。"弱点要选"相邻且正在补"的，别选岗位核心能力。

  4. 面试官追问一个你不会的细节怎么办？ 三步：①诚实划定边界——"这个点我没深入过，我熟悉的边界在 XX"；②给出相邻知识——"但相关问题我在 YY 里遇到过，我的理解是……"；③给出求解路径——"如果工作中遇到，我会先查 datasheet 的 ZZ 章节/用 WW 工具验证"。面试不是闭卷考试，展示边界感和方法论比硬编答案安全一百倍——案例 7 里"未实锤根因，先回退保底"本身就是工程师的成熟表态。

【记忆口诀】三十秒破冰三分钟展开，难点讲安全 bug 讲五段；线程进程看耦合，丢旧保新看衰减；MQTT 管动 HTTP 管看，CAN 仲裁 485 远；PID 三件套防饱和，实时兜底看门狗；多车加车不改车，弱点要选正在补。

9.3.1 邮箱九连问速答版（抢答节奏）

真实面试里邮箱是被连环追问的重灾区。下面九问各给 1-2 句"脱口而出"版，用于开场抢答；被继续深挖再展开，完整版见第 2 篇 2.6 节（2.6.5 逐问话术+追问预测）。

  1. 为什么用线程邮箱？ 解决 7 线程解耦——线程间唯一通信原语，生产者消费者互不见面，边界清晰、可单测、出问题只查队列两头。
  2. 怎么实现的？ 固定容量环形数组 + head/tail + 一把 mutex + 双条件变量（not_empty/not_full），消息 robot_msg_t 按值拷贝，200 行能白板默写。
  3. 并发互斥还有什么方式？ mutex/rwlock/spinlock 管互斥，条件变量/信号量管通知，C11 原子量管只读共享（health_t 就是）——但这些管"安全共享"，邮箱的思路是"干脆不共享"。
  4. 和消息队列的区别？ POSIX mq 在内核排队、能跨进程但两次拷贝、语义定死；自研邮箱纯用户态内存拷贝，丢旧保新、shutdown 广播按需定制——线程间用邮箱，进程间用 mq 或 /dev/shm。
  5. 比"全局变量+互斥锁"强在哪？ 自带消息边界、自带唤醒不空转、天然背压；锁粒度、通知机制、全员耦合这些全局变量的坑全绕开了，代价仅一次几十字节拷贝。
  6. 难点是什么？ 三个：cond_wait 必须 while 复查（虚假唤醒）；timedwait 用单调时钟算绝对时间（NTP 校时会坑 CLOCK_REALTIME）；shutdown 要置标志+broadcast 双 cond 优雅唤醒，不能用 pthread_cancel（可能杀在持锁态）。
  7. 丢过数据吗？ 按语义分级主动丢：周期状态（20ms 就来新帧）丢旧保新+丢帧计数；命令/事件走阻塞投递绝不丢。判据：价值随时间衰减就丢，不衰减就保。
  8. 只能存结构体吗？ 不是必须，但定长按值拷贝最省心：type 枚举+union 载荷，无堆分配无所有权问题；可变长大数据走 /dev/shm，邮箱只传句柄。
  9. 收发怎么实现的？ 三发（阻塞/限时/overwrite）两收（阻塞/超时），全在持锁+while 复查里完成；超时收发顺手当任务节拍器，storage 用它攒批 32 条/200ms 单事务落盘。

9.4 面试复盘清单（技术面自查表）

面试前对着这张表打勾。每一项都标注对应篇目，不熟就回炉。分为"必须能脱口而出"（A 级）和"被追问能接住"（B 级）。

9.4.1 C 语言与基础（第 1 篇）

  • [ ] A：指针与数组的区别、函数指针、回调机制（邮箱/paho 回调里都用了）
  • [ ] A：volatile/const/static/extern 的语义与使用场景（健康位图、ISR 共享变量）
  • [ ] A：结构体内存对齐、union 用法（robot_msg_t 消息载荷）
  • [ ] A：大小端判断与转换（CAN 协议显式小端编解码）
  • [ ] B：位操作三板斧（故障位图 event_flags=1u<<code、flags 位段）
  • [ ] B：C11 原子量与内存序（health_t 无锁共享）

9.4.2 Linux 系统编程（第 2 篇）

  • [ ] A：pthread 创建/回收、mutex 与条件变量配对、虚假唤醒为什么 while 判断
  • [ ] A：生产者-消费者模型的完整实现（能白板默写邮箱核心 30 行）
  • [ ] A：poll/select/epoll 的区别（can_rx 用 poll+非阻塞 drain）
  • [ ] A：信号处理的安全写法（SIGTERM 只置标志、忽略 SIGPIPE）
  • [ ] B：进程间通信全家桶对比（为什么项目选 /dev/shm JSON 文件协作）
  • [ ] B：CLOCK_MONOTONIC vs CLOCK_REALTIME（条件变量、TTL 校验两处实战）

9.4.3 移植与启动（第 3 篇）

  • [ ] A：交叉编译工具链的组成、sysroot 概念（arm-linux-gnueabihf）
  • [ ] B：U-Boot 启动流程、TFTP 优先+eMMC 回退的启动策略（项目实装）
  • [ ] B：设备树基本语法、节点与驱动匹配（板级适配时改过）

9.4.4 驱动与内核（第 4 篇）

  • [ ] A：字符设备驱动框架（file_operations、copy_to_user）——至少能讲流程
  • [ ] B：V4L2 采集流程（MMAP 四缓冲 DQBUF/QBUF，项目视频管线实战）
  • [ ] B：中断上下半部、为什么 ISR 要短（STM32 侧 CAN RX 中断只入队）
  • [ ] B：SocketCAN 的内核位置、PF_CAN/SOCK_RAW 编程流程

9.4.5 总线与协议（第 5 篇）

  • [ ] A：CAN 仲裁机制、ID 优先级、标准帧格式（急停 0x060 的活用案例）
  • [ ] A：CAN 错误处理：错误帧、bus-off 与恢复（项目 AutoBusOff+主动恢复）
  • [ ] A：UART/I2C/SPI 物理层差异与选型（传感器接口选型的谈资）
  • [ ] B：MQTT 报文结构、QoS 三级、LWT、retain 语义（四件套全部实战）
  • [ ] B：RS485 与 CAN 的对比（9.3 第 12 条）

9.4.6 RTOS 与 STM32（第 7 篇）

  • [ ] A：FreeRTOS 任务状态机、vTaskDelay vs vTaskDelayUntil（10ms 绝对节拍）
  • [ ] A：任务优先级怎么分（ctrl/can 同 High、svc Normal、dbg Low 的理由）
  • [ ] A：Queue 的 ISR 安全 API（xQueueSendFromISR，32 深队列实战）
  • [ ] A：栈溢出怎么防怎么查（hook 打印任务名、256→512 字的实战）
  • [ ] B：PWM/定时器配置计算（TIM8 168MHz→10kHz、TIM3 84MHz→50Hz 舵机）
  • [ ] B：ADC 采样滤波与门控（滑动滤波+负载屏蔽两连修案例）

9.4.7 存储、显示与工具链（第 8 篇）

  • [ ] A：SQLite WAL/synchronous/busy_timeout 的嵌入式折中、事务攒批
  • [ ] A：GDB 基本命令、core dump 分析流程
  • [ ] B：can-utils（candump/cansend）、tcpdump 抓包定位（网段冲突案例）
  • [ ] B：LVGL 显示框架、framebuffer、evdev 触摸（HMI 六页实战）
  • [ ] B：Git 工作流（智能体项目的里程碑分支模型也是谈资）

9.4.8 项目深挖预演（本篇）

  • [ ] A：30 秒/3 分钟电梯陈述各演练 3 遍，计时
  • [ ] A：能白板画出系统架构图（四进程+7 线程+CAN ID 表+STM32 四任务）
  • [ ] A：五层安全停车逐条讲清触发链路与超时数字（100/500/1500ms）
  • [ ] A：8 个 bug 案例至少 4 个能按五段式流畅讲出
  • [ ] A：邮箱为什么自研、丢旧保新的分级依据、shutdown 广播——三连问必答
  • [ ] B：智能体项目能讲清多模型分工的理由与"硬件在环"验收哲学
  • [ ] B：多车扩展、ROS 对比、SQLite 瓶颈——三个演进题有腹稿
  • [ ] B：准备好自己的"弱点+改进计划"答案（9.3 第 29 条模板）

【记忆口诀】A 级脱口出，B 级接得住；讲项目先价值后细节，被深挖给证据给数字；不会的画边界给路径，诚实永远是最稳的技术。

本篇小结：两个项目一硬一软，覆盖了嵌入式工程师面试的两大叙事方向——"我能把一台物理机器造得安全可靠"和"我能用现代工具链（含 AI）提升开发效率"。前 8 篇的知识点在这里全部落了地：C 的原子量与位操作在邮箱和故障位图里、Linux 的线程同步与 poll 在 robotd 里、CAN/UART/PWM 在 STM32 固件里、SQLite 与 V4L2 在数据与视频管线里。面试的本质是让面试官相信"这个人做的东西经得起追问"——本篇给你的，正是经得起追问的素材与讲法。

第10篇 手撕代码题库

本篇使用说明

面试中的"手撕代码"（现场写代码）与笔试刷题不同，评分通常看三点：

  1. 能写对：代码逻辑正确，核心路径、边界路径都能跑通。写完要自己"人肉编译"一遍，拿测试用例走一遍流程，而不是写完就交。
  2. 能讲清：面试官会指着某一行问"为什么这样写"。你要能解释每一行的目的、复杂度、以及为什么不用别的写法。
  3. 能主动处理边界：空指针、空数组、负数、溢出、内存重叠……主动提出并处理边界条件，是从"会写代码"到"像工程师"的分水岭。

本篇每道题按统一格式组织：面试原题 → 思路 → 可编译完整代码 → 逐行讲解 → 易错点与追问。建议学习顺序：先自己默写代码，再对照讲解，最后合上书把"追问"也答出来。所有代码均为标准 C，可直接用 gcc xxx.c && ./a.out 编译运行验证。

10.1 C 语言手撕

10.1.1 冒泡排序 + 统计二进制中 1 的个数

面试原题：手写冒泡排序，并讲清楚原理。附加题：判断一个整数的二进制表示中 1 的个数。

思路：冒泡排序：相邻两两比较，逆序就交换，每一轮把当前最大值"冒泡"到末尾；第 i 轮后末尾 i 个数已有序，故内层循环到 n-1-i 为止。统计 1 的个数：n & (n-1) 会把 n 最低位的 1 消掉，消几次就有几个 1，时间复杂度 O(1的个数)，优于逐位右移的 O(32)。

#include <stdio.h>

void bubble_sort(int a[], int n)
{
    for (int i = 0; i < n - 1; i++) {          /* 共 n-1 轮 */
        int swapped = 0;                        /* 提前退出优化 */
        for (int j = 0; j < n - 1 - i; j++) {   /* 末尾 i 个已有序 */
            if (a[j] > a[j + 1]) {
                int t = a[j]; a[j] = a[j + 1]; a[j + 1] = t;
                swapped = 1;
            }
        }
        if (!swapped) break;                    /* 一轮无交换，已有序 */
    }
}

int count_ones(unsigned int n)
{
    int cnt = 0;
    while (n) {
        n &= (n - 1);                           /* 消掉最低位的 1 */
        cnt++;
    }
    return cnt;
}

int main(void)
{
    int a[] = {5, 2, 9, 1, 7, 7, 3};
    int n = sizeof(a) / sizeof(a[0]);
    bubble_sort(a, n);
    for (int i = 0; i < n; i++) printf("%d ", a[i]);   /* 1 2 3 5 7 7 9 */
    printf("\n");
    printf("%d\n", count_ones(0xF0F0));                 /* 8 */
    return 0;
}

逐行讲解：

  • for (i = 0; i < n - 1; i++)：n 个数最多需要 n-1 轮；每轮确定一个最大值落位。
  • j < n - 1 - i：这是最易写错的地方。第 i 轮结束后数组末尾 i 个元素已经有序，无需再比，写成 n-1 不错但浪费；写成 n-i 会越界访问 a[j+1]。
  • swapped 标志：若一整轮没有发生交换，说明数组已有序，提前退出，最好情况 O(n)。
  • n &= (n - 1)：n-1 会把 n 最低位的 1 变成 0、其后的 0 全变 1，再与 n 相与，恰好消掉那一个 1。参数用 unsigned int 是为了对负数输入也按位处理（右移有符号数有符号位问题）。

易错点与追问：

  1. 追问：冒泡排序的复杂度与稳定性？ 时间平均/最坏 O(n²)，最好（加 swapped 优化）O(n)；空间 O(1)；只交换相邻逆序对，是稳定排序。
  2. 追问：统计 1 的个数还有哪些方法？ 方法一：循环 32 次 (n >> i) & 1；方法二：while(n){cnt += n&1; n>>=1;}（注意负数要转 unsigned）；方法三：n&(n-1) 最快，只循环"1 的个数"次。
  3. 易错：直接对有符号负数右移是算术右移，可能死循环（如 0x80000000 不断补 1），所以一律用 unsigned int 接收。

10.1.2 快速排序

面试原题：手写快速排序，讲讲分治思想和 partition 过程，最坏情况是什么？

思路：分治：选一个基准值 pivot，通过 partition 把数组分成"左边 ≤ pivot、右边 > pivot"两段，pivot 落在最终位置，再递归处理左右两段。平均 O(n log n)，最坏 O(n²)——当每次选的 pivot 都是最值（如已排序数组总取第一个元素）时退化。

#include <stdio.h>

static void swap(int *a, int *b) { int t = *a; *a = *b; *b = t; }

/* Lomuto 划分：以 a[high] 为基准，返回基准最终下标 */
int partition(int a[], int low, int high)
{
    int pivot = a[high];
    int i = low - 1;                     /* i 指向"小于等于区"的末尾 */
    for (int j = low; j < high; j++) {
        if (a[j] <= pivot) {
            i++;
            swap(&a[i], &a[j]);
        }
    }
    swap(&a[i + 1], &a[high]);           /* 基准归位 */
    return i + 1;
}

void quick_sort(int a[], int low, int high)
{
    if (low < high) {
        int p = partition(a, low, high);
        quick_sort(a, low, p - 1);
        quick_sort(a, p + 1, high);
    }
}

int main(void)
{
    int a[] = {9, 3, 7, 1, 8, 2, 5};
    quick_sort(a, 0, 6);
    for (int i = 0; i < 7; i++) printf("%d ", a[i]);  /* 1 2 3 5 7 8 9 */
    printf("\n");
    return 0;
}

逐行讲解：

  • i = low - 1：区间 [low, i] 维护"≤ pivot 的元素"，初始为空。扫描指针 j 遇到小元素就扩张该区间。
  • swap(&a[i+1], &a[high])：j 扫完后，i+1 位置就是 pivot 的最终位置。
  • if (low < high)：递归终止条件，区间只剩 0 或 1 个元素时返回。缺少它会无限递归直至栈溢出。

易错点与追问：

  1. 追问：如何避免最坏 O(n²)？ 随机选 pivot（随机化快排）或三数取中；这样期望复杂度稳定为 O(n log n)。
  2. 追问：快排稳定吗？空间复杂度？ 不稳定（partition 中远距离交换）；原地排序，但递归栈空间平均 O(log n)、最坏 O(n)。可用尾递归+循环处理较大分区把栈深度压到 O(log n)。
  3. 易错：递归边界写成 quick_sort(a, low, p) 会死循环/越界，pivot 已在正确位置，必须排除它。

10.1.3 插入排序

面试原题：手写插入排序。

思路：像打扑克理牌：把数组看成"已排序区 + 未排序区"，每次取未排序区第一个元素，在已排序区从后往前找位置插入，比它大的元素依次后移一位。稳定排序，平均 O(n²)，对基本有序的数组接近 O(n)，适合小规模或近似有序数据。

#include <stdio.h>

void insert_sort(int a[], int n)
{
    for (int i = 1; i < n; i++) {
        int key = a[i];                  /* 待插入的牌 */
        int j = i - 1;
        while (j >= 0 && a[j] > key) {   /* 比 key 大的后移 */
            a[j + 1] = a[j];
            j--;
        }
        a[j + 1] = key;                  /* 插入空出的位置 */
    }
}

int main(void)
{
    int a[] = {4, 2, 8, 1, 9, 3};
    insert_sort(a, 6);
    for (int i = 0; i < 6; i++) printf("%d ", a[i]);  /* 1 2 3 4 8 9 */
    printf("\n");
    return 0;
}

逐行讲解：

  • key = a[i]：必须先备份，因为后移操作会覆盖 a[i]。
  • while (j >= 0 && a[j] > key)：两个条件顺序不能反，先判断下标合法再访问数组；用 > 而不是 >= 保证稳定性（相等元素不交换）。
  • a[j+1] = key：循环退出时 j 停在最后一个小于等于 key 的位置（或 -1），空位是 j+1。

易错点与追问：

  1. 追问：为什么对近似有序数组快？ 内层 while 几乎不进，每个元素只比较一次，总比较次数 = n + 逆序对数，近似有序时逆序对少。
  2. 追问：和冒泡、选择的对比？ 三者都 O(n²)；插入与冒泡稳定、选择不稳定；插入移动次数少于冒泡（交换是 3 次赋值），实践中插入最快，是很多库排序在小分区的兜底算法（如 qsort、Timsort）。
  3. 易错：内层写成 for 并直接交换（变冒泡）不算错，但"边比较边后移"的写法才是插入排序的标准考法。

10.1.4 二分查找

面试原题：手写二分查找，注意边界条件：while(left <= right) 还是 <，mid 怎么写防溢出。

思路：前提：数组有序。维护闭区间 [left, right]，每次取中点比较，缩小一半范围。闭区间写法配 left <= right 和 right = mid - 1；若用左闭右开 [left, right)，则是 left < right 且 right = mid，两种写法不能混搭。mid = left + (right - left) / 2 防止 left + right 溢出。

#include <stdio.h>

int binary_search(const int a[], int n, int target)
{
    int left = 0, right = n - 1;          /* 闭区间 [left, right] */
    while (left <= right) {
        int mid = left + (right - left) / 2;  /* 防溢出 */
        if (a[mid] == target) return mid;
        else if (a[mid] < target) left = mid + 1;
        else right = mid - 1;
    }
    return -1;
}

int main(void)
{
    int a[] = {1, 3, 5, 7, 9, 11};
    printf("%d\n", binary_search(a, 6, 7));    /* 3 */
    printf("%d\n", binary_search(a, 6, 4));    /* -1 */
    return 0;
}

逐行讲解：

  • right = n - 1：闭区间，right 是合法下标，所以循环条件用 <=，更新用 mid - 1（mid 已检查过，排除）。
  • left + (right - left) / 2：数学上等于 (left+right)/2，但 left+right 在 int 接近 2³¹ 时相加会溢出，先减后加不会。
  • return -1：循环结束（left > right）说明查找区间为空，目标不存在。

易错点与追问：

  1. 追问：什么时候用 <？ 区间定义为左闭右开 [left, right) 时：right = n，循环 left < right，更新 right = mid（因为 mid 本身不在区间内）。口诀："区间开闭决定等号与 ±1"。
  2. 追问：找第一个 ≥ target 的元素（lower_bound）怎么改？ if (a[mid] >= target) right = mid; else left = mid + 1;，配合左闭右开区间，最终 left 即答案。
  3. 易错：left <= right 配 right = mid（不减 1）会在两元素时死循环，这是手写二分最常见 bug。

10.1.5 手写 strcmp / strlen / strcat / strcpy

面试原题：手写 strcmp、strlen、strcat、strcpy。面试官常追问返回值。

思路：四个都是面试"默写题"，考点一致：遍历到 '\0' 为止、dest 空间由调用者保证、返回值必须和标准库一致（strcpy/strcat 返回 dest 便于链式调用；strcmp 返回差值；strlen 返回长度，不含 '\0'）。防御性编程：先判空指针。

#include <stdio.h>
#include <assert.h>

size_t my_strlen(const char *s)
{
    assert(s != NULL);
    const char *p = s;
    while (*p) p++;
    return (size_t)(p - s);
}

int my_strcmp(const char *s1, const char *s2)
{
    assert(s1 && s2);
    while (*s1 && (*s1 == *s2)) { s1++; s2++; }
    return (unsigned char)*s1 - (unsigned char)*s2;   /* 与标准一致用无符号比较 */
}

char *my_strcpy(char *dest, const char *src)
{
    assert(dest && src);
    char *ret = dest;
    while ((*dest++ = *src++) != '\0')   /* 连 '\0' 一起拷贝 */
        ;
    return ret;
}

char *my_strcat(char *dest, const char *src)
{
    assert(dest && src);
    char *ret = dest;
    while (*dest) dest++;                /* 走到 dest 的 '\0' */
    while ((*dest++ = *src++) != '\0')
        ;
    return ret;
}

int main(void)
{
    char buf[64] = "hello";
    printf("%zu\n", my_strlen(buf));                    /* 5 */
    printf("%d\n", my_strcmp("abc", "abd") < 0);        /* 1 (true) */
    my_strcat(buf, " world");
    printf("%s\n", buf);                                /* hello world */
    char b2[64];
    printf("%s\n", my_strcpy(b2, "embed"));             /* embed */
    return 0;
}

逐行讲解：

  • assert(s != NULL)：标准库对空指针是未定义行为，手写版加断言体现防御意识，面试加分。
  • (*dest++ = *src++) != '\0'：赋值表达式的值就是被赋的值，这一行完成"拷贝字符 + 双指针前进 + 遇 '\0' 停止"三件事；'\0' 本身也被拷贝后才退出，所以目标串正确结尾。
  • return ret：dest 在循环中已走掉，必须提前保存原指针返回——这是最高频追问。
  • (unsigned char) 转换：strcmp 标准规定按无符号字符比较，避免高位字符（如 'é'）被解释成负数导致比较结果错误。

易错点与追问：

  1. 追问：strcpy 为什么返回 dest？ 支持链式调用，如 strcat(strcpy(d, s1), s2)。
  2. 追问：strcpy 有什么安全隐患？ 不检查 dest 容量，易缓冲区溢出；工程上用 strncpy/snprintf/strcpy_s，或先 strlen 检查。
  3. 追问：strcmp 返回 -1/0/1 吗？ 标准只保证 负/0/正，不要写 == -1 判断，应写 < 0。

10.1.6 手写 memcpy，考虑内存重叠（引出 memmove）

面试原题：实现 memcpy，必须考虑源和目标内存重叠的情况，并说说 memmove 的区别。

思路：标准 memcpy 不保证重叠时正确（行为未定义），但面试要求你"考虑重叠"，即写出 memmove 级别的实现：当 dest 落在 src 的上方重叠区时，若从前向后拷，前面的数据还没拷就被覆盖，所以必须从后向前拷；其余情况从前向后拷。按字节拷贝最通用（原样内存语义），可优化为按 word 拷贝但需注意对齐。

src: [ a b c d ]        dest = src+2，前向拷贝：先 dest[0]=a 覆盖 c，拷 c 时已是 a —— 错！
dest:     [ ? ? ? ? ]   后向拷贝：先拷 d、c，再 b、a —— 正确

#include <stdio.h>
#include <string.h>
#include <assert.h>

void *my_memcpy(void *dest, const void *src, size_t n)   /* 处理重叠版 = memmove */
{
    assert(dest && src);
    unsigned char *d = (unsigned char *)dest;
    const unsigned char *s = (const unsigned char *)src;
    if (d == s || n == 0) return dest;

    if (d > s && d < s + n) {          /* dest 在 src 上方重叠区：从后向前 */
        for (size_t i = n; i > 0; i--)
            d[i - 1] = s[i - 1];
    } else {                            /* 无重叠或 dest 在下方：从前向后 */
        for (size_t i = 0; i < n; i++)
            d[i] = s[i];
    }
    return dest;
}

int main(void)
{
    char buf[32] = "abcdefghij";
    my_memcpy(buf + 2, buf, 8);        /* 重叠拷贝 */
    printf("%s\n", buf);               /* ababcdefgh */
    char b2[32];
    my_memcpy(b2, buf, strlen(buf) + 1);
    printf("%s\n", b2);                /* ababcdefgh */
    return 0;
}

逐行讲解：

  • unsigned char *：memcpy 语义是"按字节搬运"，C 标准只允许用字符类型指针安全地逐字节访问任意对象。
  • if (d > s && d < s + n)：只有 dest 起始地址落在 [s, s+n) 内才会被前向拷贝污染；d < s 时前向拷贝天然安全。
  • return dest：与标准库一致，返回目标指针。
  • 循环里 i - 1：从最后一个字节 n-1 向前拷到 0，避免无符号 i 下溢。

易错点与追问：

  1. 追问：memcpy 和 memmove 的区别？ 功能相同，但 memcpy 要求区域不重叠（重叠是 UB），memmove 保证重叠时结果正确（如同先复制到临时区再拷回）。memmove 因多一次判断略慢。
  2. 追问：怎么优化速度？ 按机器字（4/8 字节）整块拷贝，头部尾部按字节处理对齐；glibc 还会用 SIMD（SSE/AVX）指令。
  3. 易错：直接用 int * 强转逐 int 拷贝，未对齐地址在某些嵌入式平台（如 ARM 老核、MIPS）会触发硬件异常——字节拷贝写法最稳。

10.1.7 函数指针 vs 指针函数

面试原题：函数指针和指针函数有什么区别？各写一个示例。

思路：名字反过来，本质完全不同。函数指针是一个"指针"，指向一个函数，可用于回调、查表、状态机；指针函数是一个"函数"，其返回值是指针。判读口诀：看标识符先和谁结合——int (*fp)(int) 中 *fp 先结合，fp 是指针；int *f(int) 中 f 先和 () 结合，f 是函数。

#include <stdio.h>

/* 1) 函数指针：指向函数的指针 */
int add(int a, int b) { return a + b; }
int sub(int a, int b) { return a - b; }

/* 2) 指针函数：返回指针的函数 */
int *find_max(int *arr, int n)          /* int * 开头的函数 = 指针函数 */
{
    int *m = arr;
    for (int i = 1; i < n; i++)
        if (arr[i] > *m) m = &arr[i];
    return m;                            /* 返回数组内部元素的地址，安全 */
}

int main(void)
{
    int (*op)(int, int) = add;           /* 声明并赋值函数指针 */
    printf("%d\n", op(3, 4));            /* 7，等价于 (*op)(3,4) */
    op = sub;
    printf("%d\n", op(3, 4));            /* -1 */

    int a[] = {1, 9, 3, 7};
    int *p = find_max(a, 4);             /* p 指向 9 */
    printf("%d\n", *p);
    return 0;
}

逐行讲解：

  • int (*op)(int, int)：括号不能省；int *op(int,int) 是"返回 int* 的函数"的声明，含义全变。
  • op = add：函数名在表达式中退化为指向函数的指针，&add 等价。
  • find_max 返回的是实参数组内部地址，调用方仍持有该数组，地址有效；绝不能返回局部变量的地址（栈帧销毁后悬垂）。

易错点与追问：

  1. 追问：函数指针的典型应用？ 回调（qsort 的比较函数、中断向量表、注册回调）、命令分发表、状态机、C 语言实现多态（结构体内嵌函数指针模拟虚表）。
  2. 追问：函数指针数组怎么写？ int (*ops[4])(int,int) = {add, sub, ...}; 配合枚举下标做查表替代 switch。
  3. 易错：指针函数返回局部数组 int a[10]; return a; 是经典错误，编译器会警告，运行行为未定义。

10.1.8 指针常量 vs 常量指针

面试原题：const int *p 和 int * const p 有什么区别？口述判断口诀。

思路：口诀："const 修饰谁，谁就不可变；从右往左读"。const int *p（= int const *p）：const 修饰 *p，指向的内容不可通过 p 修改，但 p 可以指向别处——常量指针（指向常量的指针）。int * const p：const 修饰 p，指针本身不可改向，但内容可改——指针常量。const int * const p：两个都不能改。

#include <stdio.h>

int main(void)
{
    int a = 10, b = 20;

    const int *p1 = &a;   /* 常量指针：内容只读 */
    /* *p1 = 100;        编译错误！*/
    p1 = &b;               /* OK：指针可变 */
    printf("%d\n", *p1);   /* 20 */

    int * const p2 = &a;  /* 指针常量：指向固定 */
    *p2 = 100;             /* OK：内容可改 */
    /* p2 = &b;           编译错误！*/
    printf("%d\n", a);     /* 100 */

    const int * const p3 = &a;  /* 双重只读：嵌入式只读句柄常见 */
    printf("%d\n", *p3);
    return 0;
}

逐行讲解：

  • const int *p1：从右读，"p1 是指针，指向 const int"，即指向的内容被承诺只读；注意只是"通过 p1 不能改"，a 本身不是常量，直接改 a 合法。
  • int * const p2：const 紧邻 p2，p2 是常量，定义时必须初始化。
  • 三者混用常见于函数参数：void f(const char *s) 承诺不改字符串内容，是良好 API 设计。

易错点与追问：

  1. 追问：const 在嵌入式中的实际意义？ const 全局数据会被链接器放进 .rodata（Flash），省 RAM；const volatile uint32_t *reg 是"只读寄存器"的标准写法（如状态寄存器）。
  2. 追问：char * const p 和字符串字面量？ char *s = "abc"; s[0]='x' 是 UB（字面量在只读段）；应写 const char *s。
  3. 易错：以为 const int *p 让目标变量变常量——错，它只限制这条访问路径。

10.1.9 数组指针 vs 指针数组

面试原题：数组指针与指针数组的区别，各写示例；用 int (*p)[5] 访问二维数组元素。

思路：数组指针 int (*p)[5]：一个指针，指向"含 5 个 int 的数组"，步长为 5 个 int，常用于遍历二维数组的行。指针数组 int *p[5]：一个数组，5 个元素都是 int*，常用于字符串表、命令表。口诀还是看结合优先级：[] 优先级高于 *，没括号时是数组，有括号时 *p 先结合是指针。

#include <stdio.h>

int main(void)
{
    /* 1) 数组指针：指向一整行 */
    int m[3][5] = {{1,2,3,4,5},{6,7,8,9,10},{11,12,13,14,15}};
    int (*p)[5] = m;                 /* p 指向 m 的第 0 行 */
    printf("%d\n", (*p)[2]);         /* 3：第0行第2列 */
    p++;                             /* 步进一整行(20字节) */
    printf("%d\n", (*p)[3]);         /* 9 */
    printf("%d\n", *(*(m + 2) + 4)); /* 15：m[i][j] 的指针展开式 */

    /* 2) 指针数组：数组里装指针 */
    const char *week[3] = {"Mon", "Tue", "Wed"};
    for (int i = 0; i < 3; i++)
        printf("%s ", week[i]);
    printf("\n");
    return 0;
}

逐行讲解：

  • int (*p)[5] = m;：m 退化为"指向 int[5] 的指针"，类型正好匹配；p++ 前进 5*sizeof(int) 字节，即一整行。
  • (*p)[2]：括号不能少，*(p[2]) 完全是另一回事。
  • *(*(m+2)+4)：m+2 是第 2 行的指针，*(m+2) 退化为该行首元素指针，+4 到第 4 列，再解引用得 15——a[i][j] == *(*(a+i)+j) 是必背等价式。
  • const char *week[3]：每个元素指向一个字符串字面量，sizeof(week) = 3×指针大小。

易错点与追问：

  1. 追问：int *p[5] 和 int (*p)[5] 的 sizeof？ 前者是数组，5×8=40 字节（64 位）；后者是指针，8 字节。
  2. 追问：二维数组作函数参数怎么写？ void f(int a[][5], int rows) 或 void f(int (*a)[5], int rows)，列数必须给，行数可省——因为编译器需要列数计算步长。
  3. 易错：把二维数组名赋给 int **——不行，int[3][5] 退化后是 int(*)[5]，不是二级指针。

10.1.10 数组中第 k 大的元素

面试原题：给定长度 n 的数组，找出第 k 大的元素。

思路：方法一（排序法）：排序后取下标 n-k，O(n log n)，面试保底答案。方法二（快排 partition 思想，quickselect）：partition 后基准落在下标 p，若 p == n-k 即答案；p 偏大则递归左半，否则递归右半。平均 O(n)，最坏 O(n²)（随机选 pivot 可避免）。

#include <stdio.h>

static void swap(int *a, int *b) { int t = *a; *a = *b; *b = t; }

static int partition(int a[], int lo, int hi)
{
    int pivot = a[hi], i = lo - 1;
    for (int j = lo; j < hi; j++)
        if (a[j] <= pivot) swap(&a[++i], &a[j]);
    swap(&a[i + 1], &a[hi]);
    return i + 1;
}

/* 第 k 大 = 升序意义下下标 n-k */
int find_kth_largest(int a[], int n, int k)
{
    int lo = 0, hi = n - 1, target = n - k;
    while (lo <= hi) {
        int p = partition(a, lo, hi);
        if (p == target) return a[p];
        else if (p > target) hi = p - 1;
        else lo = p + 1;
    }
    return -1;  /* k 非法 */
}

int main(void)
{
    int a[] = {3, 2, 1, 5, 6, 4};
    printf("%d\n", find_kth_largest(a, 6, 2));   /* 5 */
    int b[] = {7, 7, 7};
    printf("%d\n", find_kth_largest(b, 3, 1));   /* 7 */
    return 0;
}

逐行讲解：

  • target = n - k：把"第 k 大"翻译成升序下标，是解题关键一步；k 从 1 开始计数。
  • 循环版 quickselect：每次 partition 后只保留一半区间，平均总代价 n + n/2 + n/4 + … ≈ 2n，即 O(n)。
  • if (k < 1 || k > n) 这类合法性检查面试时应主动说明（此处简化，main 中保证合法）。

易错点与追问：

  1. 追问：为什么平均 O(n)？ 每层 partition 是线性的，但只进一半，等比数列求和收敛到 O(n)；与快排 O(n log n) 的区别在于不处理另一侧。
  2. 追问：还有其他方法吗？ 维护大小为 k 的小顶堆，O(n log k)，适合数据流/超大数组；或计数排序思想（值域小时 O(n)）。
  3. 易错：把"第 k 大"当下标 k；有重复元素时确认题目是否按去重排名——本实现按"排序后位置"理解，{7,7,7} 第 1 大是 7。

10.1.11 宏定义计算数组长度

面试原题：写一个宏计算数组元素个数，并说明为什么不能传指针。

思路：sizeof(a) 对真数组返回整个数组字节数，sizeof(a[0]) 是单个元素字节数，相除得元素个数。但数组作为函数参数时退化为指针，sizeof(指针) = 8（64 位），结果错误。所以该宏只能用于同一作用域内可见定义的数组。

#include <stdio.h>

#define ARRAY_LEN(a) (sizeof(a) / sizeof(a[0]))

void demo(int arr[])            /* 形参实为 int *arr */
{
    printf("in func: %zu\n", sizeof(arr));   /* 8，不是数组总大小！*/
}

int main(void)
{
    int a[10];
    double b[] = {1.1, 2.2, 3.3};
    printf("%zu\n", ARRAY_LEN(a));   /* 10 */
    printf("%zu\n", ARRAY_LEN(b));   /* 3 */
    demo(a);
    return 0;
}

逐行讲解：

  • sizeof(a)：编译期运算，不产生运行时代码；a 是完整数组类型 int[10]，故为 40。
  • 除法结果是 size_t，打印用 %zu。
  • demo 中 sizeof(arr)=8：形参 int arr[] 被编译器调整为 int *arr，这就是"数组退化为指针"的现场演示。

易错点与追问：

  1. 追问：如何让宏在传指针时报错而不是算出错误值？ Linux 内核的 ARRAY_SIZE 用编译期类型检查（GCC __builtin_types_compatible_p）让指针输入直接编译失败；C11 也可结合 _Static_assert。
  2. 追问：函数内想知道数组长度怎么办？ 约定额外传长度参数（void f(int *a, size_t n)），或哨兵值（如 '\0' 结尾），这是 C 的惯例。
  3. 易错：对 malloc 返回的指针用该宏——得到的是 sizeof(指针)/sizeof(int)，完全错误；动态数组必须自己记录容量。

10.1.12 计算 2 的 1024 次方（大数运算）

面试原题：计算并打印 2 的 1024 次方。

思路：2^1024 有 309 位十进制数字，远超任何内置类型（uint64_t 仅约 19 位）。用数组模拟十进制大数：每个元素存一位（低位在前便于进位），做 1024 次"乘 2"：逐位乘 2 加进位，≥10 则进位。最后倒序输出。

#include <stdio.h>

int main(void)
{
    int d[400] = {0};    /* d[i] 存第 i 位（个位在 d[0]），309 位足够 */
    d[0] = 1;            /* 2^0 = 1 */
    int len = 1;         /* 当前有效位数 */

    for (int i = 0; i < 1024; i++) {     /* 乘 1024 次 2 */
        int carry = 0;
        for (int j = 0; j < len; j++) {
            int v = d[j] * 2 + carry;
            d[j] = v % 10;
            carry = v / 10;
        }
        if (carry) d[len++] = carry;     /* 最高位进位，位数 +1 */
    }

    printf("digits = %d\n", len);        /* 309 */
    for (int j = len - 1; j >= 0; j--)   /* 高位在后，倒序打印 */
        putchar('0' + d[j]);
    putchar('\n');
    return 0;
}

逐行讲解：

  • d[0]=1：大数初值为 1，低位在前是惯例——进位往数组尾部传播，天然符合下标递增方向。
  • v = d[j]*2 + carry：每位新值 = 原位×2 + 低位进位；%10 留本位、/10 出进位。
  • if (carry) d[len++] = carry：×2 最多进 1，一次判断即可；若是一般乘法要用 while 处理多位进位。
  • 倒序输出：数组低位在前、书写高位在前。

易错点与追问：

  1. 追问：复杂度与优化？ O(1024 × 位数)。优化：每个数组元素存 4 位或 9 位（"压位"），乘 2 次数不变但每位循环缩短约一个数量级。
  2. 追问：2^1024 有更快的数学方法吗？ 本题本质是"大数左移 1024 位"，也可按二进制存储再转十进制；但面试要的就是大数乘法模板。
  3. 易错：进位只处理一层或忘记位数增长；打印顺序写反（输出数字完全颠倒）。

10.1.13 打印 100 以内 2 和 3 的公倍数，且个位十位都不含 6

面试原题：打印 100 以内（含）既是 2 的倍数又是 3 的倍数，且个位、十位数字都不是 6 的数。

思路：2 和 3 的公倍数 = 6 的倍数，直接以 6 为步长枚举，避免取模。再拆出十位 (x/10)%10 与个位 x%10 检查是否含 6。

#include <stdio.h>

int main(void)
{
    for (int x = 6; x <= 100; x += 6) {
        int ones = x % 10;
        int tens = (x / 10) % 10;
        if (ones == 6 || tens == 6) continue;   /* 6,36,60,66,96 被排除 */
        printf("%d ", x);                        /* 12 18 24 30 42 48 54 72 78 84 90 */
    }
    printf("\n");
    return 0;
}

逐行讲解：

  • x += 6：公倍数步进枚举，比 if (x%2==0 && x%3==0) 更高效也更显数学理解（lcm(2,3)=6）。
  • (x/10)%10：取任意位的通用写法——除以 10^k 再对 10 取模，100 的十位是 0，不含 6，通过。
  • continue：命中排除条件直接跳过，保持主逻辑扁平。

易错点与追问：

  1. 追问：要求"各位数字都不含 6"怎么扩展？ 写个循环版 has_digit(x, 6)：while(x){ if(x%10==6) return 1; x/=10; }。
  2. 追问：范围改为 n 呢？ 把 100 换成参数；若 n 很大且要计数而非打印，可用容斥：总数 n/6 − 含 6 的个数。
  3. 易错：忘记"100 以内"是否包含 100 要和面试官确认；0 是公倍数但通常从 6 开始，确认起点。

10.1.14 去掉字符串前导和尾随的 0 与空格

面试原题：字符串处理："00 10020 0" → "1002"，即去掉前导和尾随的 '0' 与空格。

思路：双指针：left 从左跳过所有 '0' 和 ' '，right 从右跳过；[left, right] 即有效段。再把该段原样搬回字符串开头（或原地移位）并补 '\0'。注意全部是无效字符时的空串边界。

#include <stdio.h>
#include <string.h>

void trim_zero_space(char *s)
{
    if (!s) return;
    int left = 0, right = (int)strlen(s) - 1;
    while (left <= right && (s[left] == '0' || s[left] == ' ')) left++;
    while (right >= left && (s[right] == '0' || s[right] == ' ')) right--;
    int len = right - left + 1;              /* 可能为 0（全是无效字符） */
    memmove(s, s + left, (size_t)len);       /* 段内重叠，用 memmove */
    s[len] = '\0';
}

int main(void)
{
    char a[] = "00 10020 0";
    trim_zero_space(a);
    printf("[%s]\n", a);      /* [1002]：中间的 0 和空格保留吗？不——见下方说明 */
    char b[] = "000";
    trim_zero_space(b);
    printf("[%s]\n", b);      /* [] */
    return 0;
}

逐行讲解：

  • 两个 while 分别从两端收缩，注意条件 left <= right / right >= left 防止全串都是无效字符时越界。
  • memmove：源区间在目标区间上方且重叠，按 10.1.6 的结论必须用 memmove 而非 memcpy。
  • 对 "00 10020 0"：前导去掉 "00 "，尾随去掉 " 0"，结果 "10020 0"……注意！题目示例答案是 "1002"，说明中间的尾随部分也要按右端继续收：right 指针已把结尾 "0 0" 全部跳过，最终 left=2（'1'），right 停在 '2'（原串下标 6），结果为 "1002"。本代码正确输出 1002。

易错点与追问：

  1. 追问：为什么不能只 trim 一次？ 右端是 "0" 和空格交替出现（"…20 0"），所以右指针必须在两者间交替跳过，本实现的循环天然处理。
  2. 追问：只读字符串（const char）怎么办？* 不能原地改，返回指向新分配的副本或返回 (start,len) 区间，让调用者处理所有权。
  3. 易错：结果为空串时 right-left+1=0，仍能正确写 s[0]='\0'——但前提是收缩循环的边界条件写对，否则 right 变 -1 后访问 s[-1]。

10.1.15 求三个数的最小公倍数

面试原题：求三个数的最小公倍数（考虑输入为 0、输入超过 65535 的情况）。

思路：gcd 用辗转相除：gcd(a,b) = gcd(b, a%b) 直到 b 为 0。lcm(a,b) = a/gcd(a,b)*b（先除后乘防溢出）。三个数：lcm(lcm(a,b), c)。边界：任一为 0 时 lcm 定义为 0；输入可能超 65535（16 位），乘积更大，用 unsigned long long。

#include <stdio.h>

typedef unsigned long long ull;

ull gcd(ull a, ull b)
{
    while (b) { ull t = a % b; a = b; b = t; }
    return a;
}

ull lcm2(ull a, ull b)
{
    if (a == 0 || b == 0) return 0;      /* 与 0 的公倍数约定为 0 */
    return a / gcd(a, b) * b;            /* 先除后乘，防中间溢出 */
}

ull lcm3(ull a, ull b, ull c)
{
    return lcm2(lcm2(a, b), c);
}

int main(void)
{
    printf("%llu\n", lcm3(4, 6, 8));         /* 24 */
    printf("%llu\n", lcm3(0, 5, 7));         /* 0 */
    printf("%llu\n", lcm3(70000, 65536, 3)); /* 860160000，70000×65536 中间量已超 32 位 */
    return 0;
}

逐行讲解：

  • while (b) { t = a%b; a=b; b=t; }：辗转相除的迭代版，比递归版省栈，嵌入式场合更稳。
  • a / gcd(a,b) * b：若写成 a*b/gcd，a*b 可能先溢出——即使最终结果能放下，中间量也不行，这是本题的核心考点。
  • ull：输入超 65535 意味着 16 位 int 不够，乘积可能超 32 位，unsigned long long（≥64 位）是安全选择；无符号还避免了负数取模的语义坑。

易错点与追问：

  1. 追问：gcd 为什么收敛？ 每步余数严格小于除数，非负整数序列严格递减，必在有限步到 0；时间 O(log min(a,b))。
  2. 追问：负数输入怎么处理？ 先取绝对值（gcd/lcm 对符号不敏感），这也是把参数定为 unsigned 的理由——把非法输入挡在类型层。
  3. 易错：lcm(a,0) 若不做特判会得到 0（数学上可接受），但 gcd(0,0) 无定义，要说明约定；返回值若可能超 64 位需换大数方案（见 10.1.12）。

10.1.16 字符串中第一个只出现一次的字母

面试原题：找出字符串中第一个只出现一次的字母。

思路：两遍扫描 + 计数数组：第一遍用 cnt[26]（或 256 覆盖全 ASCII）统计每个字母出现次数；第二遍按原顺序扫描，第一个计数为 1 的字符即答案。O(n) 时间、O(1) 额外空间（字符集大小固定）。

#include <stdio.h>
#include <ctype.h>

char first_unique(const char *s)
{
    int cnt[26] = {0};
    for (const char *p = s; *p; p++)
        if (isalpha((unsigned char)*p))
            cnt[tolower((unsigned char)*p) - 'a']++;
    for (const char *p = s; *p; p++)
        if (isalpha((unsigned char)*p) &&
            cnt[tolower((unsigned char)*p) - 'a'] == 1)
            return *p;
    return '\0';    /* 不存在 */
}

int main(void)
{
    printf("%c\n", first_unique("aabbcddce"));   /* 'e' */
    printf("%c\n", first_unique("leetcode"));    /* 'l' */
    printf("%d\n", first_unique("aabb") == 0);   /* 1：不存在返回 '\0' */
    return 0;
}

逐行讲解：

  • cnt[26]：字母表大小是常数，所以空间仍是 O(1)——这是面试官爱听的回答。
  • 两遍扫描的顺序性：第二遍必须按原串顺序，才能保证"第一个"。
  • tolower：视题目要求决定大小写是否合并，面试时主动说明假设；isalpha 的参数要转 unsigned char 避免负值 UB。

易错点与追问：

  1. 追问：字符串很长且字母集大（Unicode）怎么办？ 计数数组换哈希表；或存 (count, first_index) 对，最后取 count==1 中 index 最小者，仍 O(n)。
  2. 追问：能一遍扫描吗？ 可以：用哈希计数 + 队列维护候选，队首重复就弹出，均摊 O(n) 一遍完成（适合流式数据）。
  3. 易错：只统计字母却按下标 *p-'a' 直接索引其他字符导致越界；先 isalpha 过滤。

10.1.17 宏定义两数最大值与三数最大值（括号陷阱与副作用）

面试原题：用宏定义返回两个参数中较大者，再嵌套求三个数的最大值。讲宏的括号陷阱和副作用。

思路：MAX(a,b) 用三目运算符实现，每个参数和整体都加括号：((a) > (b) ? (a) : (b))。三数最大值嵌套 MAX(a, MAX(b,c))。两大坑：① 参数/整体不加括号时，传入表达式会因优先级被错误展开；② 参数带副作用（如 i++）会被求值两次。

#include <stdio.h>

#define MAX(a, b)       ((a) > (b) ? (a) : (b))
#define MAX3(a, b, c)   (MAX((a), MAX((b), (c))))

/* 反面教材：#define BAD_MAX(a,b) a > b ? a : b
   BAD_MAX(1+2, 2) 展开为 1+2 > 2 ? 1+2 : 2，这步碰巧对；
   但 BAD_MAX(x, y) + 1 展开为 x > y ? x : y + 1，整体优先级出错！*/

int main(void)
{
    printf("%d\n", MAX(3, 5));            /* 5 */
    printf("%d\n", MAX(1 + 2, 2 * 3));    /* 6：参数是表达式，括号救命 */
    printf("%d\n", MAX3(7, 2, 9));        /* 9 */
    printf("%d\n", 10 + MAX(1, 2));       /* 12：整体括号保证优先级 */

    int i = 5;
    int m = MAX(i++, 3);   /* 展开为 ((i++) > (3) ? (i++) : (3))，i++ 执行两次！*/
    printf("m=%d i=%d\n", m, i);          /* m=6 i=7：经典副作用坑 */
    return 0;
}

逐行讲解：

  • 参数括号 (a)：若 a 是 x+y，不括号则 x+y > b ? x+y : b 中外层还好，但 a*b 形式传入时 a*b > c 没问题而 a > b ? a : b 与加减混合时会错；整体括号防止 10 + MAX(...) 被解析成三目的一部分。
  • MAX3 嵌套：宏展开是纯文本替换，MAX(a, MAX(b,c)) 展开后参数 b/c 各被求值两次、a 一次——逻辑上对纯值正确。
  • MAX(i++, 3)：展开后 i++ 出现两次且都执行，i 从 5 变 7，结果 m=6 而非直觉的 5——宏不知道"副作用"。

易错点与追问：

  1. 追问：如何避免副作用问题？ 用内联函数 static inline int max(int a,int b){ return a>b?a:b; }：参数只求值一次、有类型检查、可调试；C23 或 GNU C 可用 __typeof__ 语句表达式宏（({...})）实现只求值一次的 safe max（Linux 内核 min/max 即如此）。
  2. 追问：宏相比函数的优势？ 无调用开销、类型泛化（int/double/指针都能比）。代价：无类型检查、多次求值、代码膨胀、难调试。
  3. 易错：#define MAX(a,b) ((a)>(b)?(a):(b)) 后加分号、或写成 if 语句宏却不用 do{...}while(0) 包裹，都是常考点。

10.1.18 求字符串长度，求 10 次（while/for 与 volatile 考点）

面试原题：对一个字符串求 10 次长度。（考察循环熟练度 + 编译器优化与 volatile）

思路：表面送分题，考点在第二层：如果对同一字符串循环求 10 次长度且结果未使用，编译器可能把 9 次调用优化掉（甚至全部）；若想测真实执行时间或防止优化，要用 volatile 接收结果。这正是嵌入式里"延时循环被优化掉"的同款坑。

#include <stdio.h>
#include <string.h>

int main(void)
{
    const char *s = "embedded interview";
    size_t total = 0;

    /* 写法1：for */
    for (int i = 0; i < 10; i++)
        total += strlen(s);

    /* 写法2：while */
    int i = 0;
    while (i < 10) { total += strlen(s); i++; }

    /* 写法3：手写 strlen + volatile 防优化 */
    volatile size_t sink = 0;      /* volatile：每次循环都必须真做 */
    for (int k = 0; k < 10; k++) {
        const char *p = s;
        while (*p) p++;
        sink += (size_t)(p - s);
    }

    printf("total=%zu sink=%zu\n", total, (size_t)sink);  /* 360 180：total 累加了 for+while 共 20 次 */
    return 0;
}

逐行讲解：

  • for/while 两种循环结构都要能随手写——这就是"求 10 次"的字面考点。
  • volatile size_t sink：告诉编译器该变量"可能被外部因素改变"，禁止把对它的读写优化掉；否则 sink += ... 循环在 -O2 下可能整段消失或折叠成一次乘法。
  • 手写 while(*p) p++ 版 strlen：体现不依赖库函数的能力。

易错点与追问：

  1. 追问：volatile 的三个典型场景？ ① 硬件寄存器（MMIO）；② 中断服务程序与主循环共享的变量；③ 多线程共享标志（但 volatile 不保证原子性/内存序，不能替代锁或 atomic）。
  2. 追问：编译器为什么敢优化掉？ C 标准按"as-if"原则：可观察行为（volatile 访问、I/O）不变即可任意变换；普通局部变量的死代码可整体删除。
  3. 易错：以为 volatile 能用于多线程同步——它只防编译器优化，不防 CPU 乱序和缓存一致性问题。

10.1.19 输出整数的二进制表示（处理负数）

面试原题：输入一个整数，逐位打印其二进制表示，负数也要处理。

思路：对有符号数，直接打印其补码位模式即可（这也是机器里真实存储的形式）：从最高位（第 31 位）到最低位，逐位 (n >> i) & 1。为避免算术右移的符号位干扰，把值先转到 unsigned（按标准，转 unsigned 保留位模式）。负数不打印 '-'，而是展示 32 位补码——要主动和面试官说明这一选择。

#include <stdio.h>
#include <stdint.h>

void print_binary(int32_t n)
{
    uint32_t u = (uint32_t)n;          /* 保留位模式，规避算术右移 */
    for (int i = 31; i >= 0; i--) {
        putchar((u & (1u << i)) ? '1' : '0');
        if (i % 8 == 0 && i) putchar(' ');   /* 每 8 位分组，易读 */
    }
    putchar('\n');
}

int main(void)
{
    print_binary(5);    /* 00000000 00000000 00000000 00000101 */
    print_binary(-1);   /* 11111111 11111111 11111111 11111111 */
    print_binary(-5);   /* 11111111 11111111 11111111 11111011 */
    return 0;
}

逐行讲解：

  • (uint32_t)n：C 标准规定有符号转无符号是模 2^32 加，位模式即补码，安全可移植。
  • 1u << i：用无符号 1 移位，避免 1 << 31 触发有符号溢出 UB。
  • 测试用例 -5：原码 5 取反加 1 = ...11111011，验证补码理解。

易错点与追问：

  1. 追问：负数在计算机里怎么表示？ 补码：-x = ~x + 1；好处是加减统一、只有一个 0。
  2. 追问：想打印"人类友好"的 -101 形式怎么办？ 判负先打 '-' 再对绝对值（注意 INT_MIN 取绝对值溢出，需用 unsigned 技巧）逐位打印，并去掉前导 0。
  3. 易错：用 n & (1<<31) 对有符号 int——1<<31 是 UB；还有 n >>= 1 循环法对负数算术右移永不归零，死循环。

10.1.20 字符串字母提取并排序

面试原题：给定字符串，提取其中所有字母，按字母序排序后输出。

思路：两步：① 遍历，用 isalpha 过滤出字母存入缓冲区；② 对缓冲区排序——字母只有 26 种，用计数排序 O(n) 最优雅，也可用插入/冒泡等通用排序。

#include <stdio.h>
#include <ctype.h>
#include <string.h>

void extract_sort(const char *s, char *out)
{
    int cnt[256] = {0};                 /* 计数排序桶：全 ASCII */
    for (const char *p = s; *p; p++)
        if (isalpha((unsigned char)*p))
            cnt[(unsigned char)*p]++;
    int k = 0;
    for (int c = 0; c < 256; c++)       /* 按 ASCII 序回填 */
        while (cnt[c]--) out[k++] = (char)c;
    out[k] = '\0';
}

int main(void)
{
    char out[128];
    extract_sort("He11o, World! 2024", out);
    printf("%s\n", out);                /* HWdeloor：大写 ASCII 在前 */
    return 0;
}

逐行讲解：

  • cnt[256]：大小写不合并，按 ASCII 排序则大写字母（65–90）自然排在小写（97–122）前；若题目要求忽略大小写，先 tolower。
  • isalpha((unsigned char)*p)：char 可能为负，强转 unsigned char 是 ctype 函数的正确用法。
  • 计数排序天然稳定且 O(n + 字符集)，对"已知值域很小"的场景优于比较排序。

易错点与追问：

  1. 追问：为什么不用快排？ 可以，O(n log n) 也对；但值域只有 26/256 时计数排序 O(n)，答出这个差异体现复杂度意识。
  2. 追问：输出缓冲区多大？ 最坏等于原串长度，面试时主动确认 out 的容量契约（本例约定调用者保证足够）。
  3. 易错：'Z' < 'a'，若期望 aAbB 交错序需自定义比较；别忘结尾 '\0'。

10.1.21 字符串压缩 + XOR 异或加密解密

面试原题：把 "aaabbbcccdddffffee" 压缩为 "a3b3c3d3f4e2"；若压缩后不比原串短则返回原串；再对压缩结果用密钥 "secret key 123" 循环做 XOR 加密，并写解密函数验证。

思路：① 游程编码：扫描统计连续相同字符个数，输出 字符+计数。② 比较长度决定返回谁。③ XOR 加密：cipher[i] = plain[i] ^ key[i % keylen]；XOR 自反（a^b^b = a），同一函数即解密。注意密文可能含不可打印字节，按长度处理而非按字符串。

#include <stdio.h>
#include <string.h>

/* 游程压缩，写入 out（容量 >= 2*n+1），返回压缩串或原串 */
const char *compress(const char *s, char *out)
{
    int k = 0, n = (int)strlen(s);
    for (int i = 0; i < n; ) {
        char c = s[i];
        int cnt = 0;
        while (i < n && s[i] == c) { i++; cnt++; }
        k += sprintf(out + k, "%c%d", c, cnt);
    }
    return (k < n) ? out : s;      /* 没变短则返回原串 */
}

/* XOR 加解密一体：key 循环使用 */
void xor_crypt(const unsigned char *in, unsigned char *out, int len,
               const char *key)
{
    int klen = (int)strlen(key);
    for (int i = 0; i < len; i++)
        out[i] = in[i] ^ (unsigned char)key[i % klen];
}

int main(void)
{
    char comp[64];
    const char *r = compress("aaabbbcccdddffffee", comp);
    printf("%s\n", r);                        /* a3b3c3d3f4e2 */

    const char *key = "secret key 123";
    int len = (int)strlen(r);
    unsigned char enc[64], dec[64];
    xor_crypt((const unsigned char *)r, enc, len, key);   /* 加密 */
    xor_crypt(enc, dec, len, key);                        /* 解密（同一函数） */
    dec[len] = '\0';
    printf("decrypt ok: %d -> %s\n", strcmp((char *)dec, r) == 0, dec);
    return 0;
}

逐行讲解：

  • 内层 while (s[i]==c) 完成游程计数，i 直接跳到下一段，O(n) 一遍。
  • sprintf(out+k, "%c%d", c, cnt)：计数可能是多位数（如 a12），sprintf 自动处理；返回写入字符数用于推进 k。
  • out[i] = in[i] ^ key[i % klen]：i % klen 实现密钥循环；加解密同函数靠 XOR 自反性。
  • 密文用 unsigned char + 显式长度：XOR 结果可能是 '\0' 或不可打印字节，不能用 strlen/strcpy 处理密文。

易错点与追问：

  1. 追问：XOR 加密安全性如何？ 密钥循环使用的多表异或极易被频率分析和已知明文攻击破解，仅作教学；工程用 AES/ChaCha20。
  2. 追问：压缩率与适用场景？ 对长重复段有效（如二值图像 RLE），对随机数据反而膨胀——所以题目要求"不短则返回原串"。
  3. 易错：密文按字符串打印/拷贝——含 0 字节会被截断；压缩计数超过 9 时忘记多位数处理。

10.1.22 字符串逆序并去除异常字符

面试原题：将字符串逆序，并去除异常字符（只保留字母、数字、空格）。

思路：先过滤后逆序（或边过滤边收集，最后双指针原地翻转）。过滤用 isalnum + 空格判断；逆序用首尾双指针交换。O(n)，原地完成。

#include <stdio.h>
#include <ctype.h>
#include <string.h>

void reverse_clean(char *s)
{
    /* 1) 原地过滤：读指针 r，写指针 w */
    int w = 0;
    for (int r = 0; s[r]; r++)
        if (isalnum((unsigned char)s[r]) || s[r] == ' ')
            s[w++] = s[r];
    s[w] = '\0';

    /* 2) 双指针逆序 */
    for (int l = 0, h = w - 1; l < h; l++, h--) {
        char t = s[l]; s[l] = s[h]; s[h] = t;
    }
}

int main(void)
{
    char a[] = "he@ll#o w0r!ld";
    reverse_clean(a);
    printf("[%s]\n", a);   /* [dlr0w olleh] */
    return 0;
}

逐行讲解：

  • 读写双指针过滤：w <= r 恒成立，原地覆盖安全；最后补 '\0'。
  • 逆序循环条件 l < h：奇数长度时中点无需动，偶数时交错即停；写成 l <= h 无错但多一次自交换。
  • 先过滤再逆序：若先逆序再过滤，结果相同，但"过滤"在前更易想清楚下标。

易错点与追问：

  1. 追问：如何不修改原串？ 从尾部向前扫描原串，把合法字符依次写入新缓冲区，天然得到"过滤+逆序"一步完成的结果。
  2. 追问：isalnum 受 locale 影响吗？ 受；嵌入式默认 C locale 下即 ASCII 字母数字。要严格 ASCII 可手写 (c>='a'&&c<='z')||...。
  3. 易错：过滤后忘记重新设置 '\0'，旧尾部残留会被打印出来。

10.1.23 字符串相加（大数加法）

面试原题："123" + "321" = "444"，字符串形式的大数加法。

思路：从两个字符串末尾（个位）对齐，逐位相加加进位，结果逆序写入或先反存再翻转。每一位：'字符' - '0' 得数值，结果 %10 留位、/10 进位。注意最后可能多出一位进位。

#include <stdio.h>
#include <string.h>

/* out 容量至少 max(len1,len2)+2 */
void add_strings(const char *a, const char *b, char *out)
{
    int i = (int)strlen(a) - 1, j = (int)strlen(b) - 1, k = 0, carry = 0;
    while (i >= 0 || j >= 0 || carry) {
        int sum = carry;
        if (i >= 0) sum += a[i--] - '0';
        if (j >= 0) sum += b[j--] - '0';
        out[k++] = (char)('0' + sum % 10);
        carry = sum / 10;
    }
    out[k] = '\0';
    for (int l = 0, h = k - 1; l < h; l++, h--) {   /* 结果是逆序的，翻转 */
        char t = out[l]; out[l] = out[h]; out[h] = t;
    }
}

int main(void)
{
    char out[64];
    add_strings("123", "321", out);  printf("%s\n", out);  /* 444 */
    add_strings("999", "1", out);    printf("%s\n", out);  /* 1000 */
    add_strings("0", "0", out);      printf("%s\n", out);  /* 0 */
    return 0;
}

逐行讲解：

  • 循环条件 i >= 0 || j >= 0 || carry：三者任一存在就继续——"999"+"1" 的最后一位纯靠 carry 产生。
  • 结果低位在前生成，末尾统一翻转一次；也可以先算总长再正序填，省一次翻转。
  • '0' + sum % 10：数值转回字符。

易错点与追问：

  1. 追问：如何验证结果正确？ 边界用例：全 9 + 1（进位传播到底）、含前导 0、一长一短、双 0。
  2. 追问：能扩展成大数乘法吗？ 竖式乘法：res[i+j] += a[i]*b[j] 再统一进位，O(n·m)。
  3. 易错：循环条件漏掉 || carry 导致最高位进位丢失（999+1=000）；输入含非数字字符时应先校验。

10.1.24 数组中唯一只出现一次的元素（其余出现三次）

面试原题：整数数组中，除一个元素只出现一次外，其余每个都恰好出现三次，找出它。

思路：位计数法：对 32 个位分别统计所有数在该位上 1 的个数，出现三次的数贡献的 1 必为 3 的倍数，count % 3 剩下的就是那个唯一元素的位。O(32n) = O(n)，O(1) 空间。对比经典题"其余出现两次"：直接全员异或即可，因为 a^a=0；三次则异或失效，必须按位计数。

#include <stdio.h>
#include <stdint.h>

int single_number(const int *a, int n)
{
    int result = 0;
    for (int b = 0; b < 32; b++) {
        int cnt = 0;
        for (int i = 0; i < n; i++)
            cnt += ((uint32_t)a[i] >> b) & 1u;   /* 统计第 b 位 */
        if (cnt % 3)                              /* 余 1：答案在该位是 1 */
            result |= (1 << b);
    }
    return result;
}

int main(void)
{
    int a[] = {2, 2, 3, 2};
    printf("%d\n", single_number(a, 4));          /* 3 */
    int b[] = {0, 1, 0, 1, 0, 1, 99};
    printf("%d\n", single_number(b, 7));          /* 99 */
    int c[] = {-2, -2, -2, 7};
    printf("%d\n", single_number(c, 4));          /* 7，负数按补码位参与同样正确 */
    return 0;
}

逐行讲解：

  • 外层 32 位循环：对 int 每一位独立统计，位与位之间互不干扰。
  • cnt % 3：某位的总 1 数 = 3×(三次数贡献) + 答案位，模 3 滤掉前者。
  • 负数也正确：补码位模式参与计数，模 3 逻辑对每个位独立成立。

易错点与追问：

  1. 追问："其余出现两次"的经典版怎么写？ int x=0; for(...) x^=a[i];——异或满足交换律、自反律，成对抵消，O(n)/O(1)。
  2. 追问："出现 k 次找一次"的通式？ 位计数 % k；k=2 时退化为异或。
  3. 易错：(1 << 31) 有符号溢出 UB——严格写法 1u << b 再转；a[i] >> b 对有符号负数是算术右移，故先转 uint32_t。

10.1.25 数组中找最大值和次大值（一遍遍历）

面试原题：找数组的最大值和次大值，只能遍历一遍。

思路：维护两个变量 max1、max2：新元素 > max1 时，max1 降级为 max2、新元素上位；否则若 > max2 则只更新 max2。注意初始值与重复最大值（如 {5,5}）的处理约定。

#include <stdio.h>
#include <limits.h>

void find_top2(const int *a, int n, int *max1, int *max2)
{
    *max1 = *max2 = INT_MIN;
    for (int i = 0; i < n; i++) {
        if (a[i] > *max1) {
            *max2 = *max1;          /* 旧冠军退居第二 */
            *max1 = a[i];
        } else if (a[i] > *max2 && a[i] < *max1) {
            *max2 = a[i];           /* 严格小于 max1：次大按“不同值”计 */
        }
    }
}

int main(void)
{
    int a[] = {3, 9, 1, 9, 5};
    int m1, m2;
    find_top2(a, 5, &m1, &m2);
    printf("%d %d\n", m1, m2);     /* 9 5 */
    int b[] = {2, 2};
    find_top2(b, 2, &m1, &m2);
    printf("%d %d\n", m1, m2);     /* 2 INT_MIN：无“不同值”的次大 */
    return 0;
}

逐行讲解：

  • INT_MIN 初始化：避免用 a[0] 初始化时漏处理"只有一个元素"或全相同的情况；但要检查 n≥1。
  • a[i] > *max2 && a[i] < *max1：加上 < max1 条件表示"次大值必须不同于最大值"；若题目允许重复（{9,9} 次大是 9），去掉该条件即可——面试时主动确认语义。
  • 每元素最多两次比较，O(n) 一遍，优于排序法 O(n log n)。

易错点与追问：

  1. 追问：次大值是否允许等于最大值？ 两种语义都行，关键是面试时问清楚并说明自己实现的约定。
  2. 追问：扩展到第 k 大？ 维护大小 k 的最小堆，或 quickselect（见 10.1.10）。
  3. 易错：max2 = max1; max1 = a[i]; 顺序写反；n<2 时没有次大值，要返回约定标志（本实现以 INT_MIN 表示不存在）。

10.1.26 超长数字字符串相加并返回字符串（大数加法完整版）

面试原题：两个仅含数字的超长字符串（比如几百位），转成数字相加再以字符串返回，不能用 atoi/strtol。

思路：这是 10.1.23 的完整版，强化三点：① 输入"仅含数字"但仍建议校验（防御性）；② 超长意味着任何内置整数类型都放不下，必须纯字符串运算；③ 规范工程写法：结果长度 max+1，从高位侧直接正序填充，避免翻转。也可用压位（每 4 位一段）提速，但面试写逐位版即可。

#include <stdio.h>
#include <string.h>
#include <stdbool.h>

static bool is_digits(const char *s)
{
    if (!*s) return false;
    for (; *s; s++) if (*s < '0' || *s > '9') return false;
    return true;
}

/* 返回 0 成功；out 容量 >= max(la,lb)+2 */
int big_add(const char *a, const char *b, char *out)
{
    if (!is_digits(a) || !is_digits(b)) return -1;
    int la = (int)strlen(a), lb = (int)strlen(b);
    int lmax = la > lb ? la : lb;
    out[lmax + 1] = '\0';               /* 先定终点 */
    int carry = 0, k = lmax;            /* k 从右往左填 */
    int i = la - 1, j = lb - 1;
    while (k > 0) {
        int sum = carry;
        if (i >= 0) sum += a[i--] - '0';
        if (j >= 0) sum += b[j--] - '0';
        out[k--] = (char)('0' + sum % 10);
        carry = sum / 10;
    }
    out[0] = (char)('0' + carry);       /* 最高位（可能是 0） */
    if (out[0] == '0' && out[1])        /* 无进位则整体左移一位去掉前导 0 */
        memmove(out, out + 1, (size_t)lmax + 1);
    return 0;
}

int main(void)
{
    char out[600];
    big_add("123456789012345678901234567890",
            "987654321098765432109876543210", out);
    printf("%s\n", out);   /* 1111111110111111111011111111100 */
    big_add("999", "1", out);
    printf("%s\n", out);   /* 1000 */
    return 0;
}

逐行讲解：

  • out 预分配 max+2：最长结果是 max+1 位加 '\0'。
  • 从 k = lmax 向左填充：天然正序，省掉 10.1.23 的翻转步骤。
  • out[0] = '0' + carry：最高位要么是进位 1 要么是占位 0；为 0 时 memmove 左移去掉（注意连同 '\0' 一起移动，所以长度 +1）。
  • is_digits 校验：题目保证仅数字，但工程函数不轻信输入，返回 -1 表示错误。

易错点与追问：

  1. 追问：为什么不能用 atoi？ atoi 返回 int（通常 32 位），几百位的数必然溢出；且 atoi 溢出行为未定义、无错误报告。strtoull 也只能到 64 位。
  2. 追问：性能优化方向？ 压位存储（每个 int 存 9 位十进制），加法按段进行，吞吐约 9 倍；或转二进制大数用 GMP 类库。
  3. 易错：前导 0 处理（"007"+"3"="10"）；空串校验；memmove 忘带 '\0'。

10.1.27 句子单词逆序："how are58 _ _you" → "you are how"

面试原题：将 "how are58 _ _you" 变为 "you are how"：只保留空格和字母、连续空格压缩为一个、单词顺序颠倒。

思路：三步走：① 过滤：只留字母和空格（58 _ 被去掉），同时把连续空格压缩为一个；② 整体逆序字符串；③ 逐个单词再逆序回来。这就是"单词逆序"经典三步法，O(n) 原地完成。

#include <stdio.h>
#include <ctype.h>
#include <string.h>

static void reverse(char *s, int l, int r)
{
    for (; l < r; l++, r--) { char t = s[l]; s[l] = s[r]; s[r] = t; }
}

void word_reverse(char *s)
{
    /* 1) 过滤 + 压缩空格：读 r 写 w */
    int w = 0, n = (int)strlen(s);
    for (int r = 0; r < n; r++) {
        if (isalpha((unsigned char)s[r])) {
            s[w++] = s[r];
        } else if (s[r] == ' ' && w > 0 && s[w-1] != ' ') {
            s[w++] = ' ';               /* 只保留一个，且不在开头 */
        }
    }
    if (w > 0 && s[w-1] == ' ') w--;    /* 去掉尾部空格 */
    s[w] = '\0';

    /* 2) 整体逆序 */
    reverse(s, 0, w - 1);

    /* 3) 逐词逆序 */
    for (int i = 0; i < w; ) {
        int j = i;
        while (j < w && s[j] != ' ') j++;
        reverse(s, i, j - 1);
        i = j + 1;
    }
}

int main(void)
{
    char a[] = "how are58 _ _you";
    word_reverse(a);
    printf("[%s]\n", a);                /* [you are how] */
    return 0;
}

逐行讲解：

  • 过滤阶段的 w > 0 && s[w-1] != ' '：同时解决"连续空格"（_ _ 之间的多个）与"前导空格"两类问题。
  • 整体逆序 "woh era uoy"，再逐词逆序得到 "you are how"——三步法每步都是简单线性操作。
  • i = j + 1：跳过词后空格进入下一词；单词界定完全靠空格，因数字符号已在第 1 步清除。

易错点与追问：

  1. 追问：为什么用"整体逆序+逐词逆序"而不是栈？ 栈法 O(n) 空间且要处理拷贝；三步法原地 O(1) 额外空间，是面试官期待的最优解。
  2. 追问：步骤 2、3 能交换吗？ 不能。先逐词逆序再整体逆序结果等价吗？实际上"先逐词逆序再整体逆序"结果相同（两次逆序可交换），可以拿这个展示理解，但三步法标准表述更稳。
  3. 易错：过滤后尾部残留空格导致第 2 步把空格转到最前；忘记原地算法要求可写缓冲区，不能传字符串字面量。

10.1.28 设备版本号比较（日期编码、二进制位域拆解）

面试原题：旧设备版本号以二进制形式编码日期（如 2025年9月25日），新设备号小于旧设备号则需要更新。写判断函数：需要更新返回 true，否则 false。

思路：典型方案：把年月日打包进一个 32 位整数的位域：ver = (year << 9) | (month << 5) | day（年 23 位、月 4 位、日 5 位，月≤12 需 4 位、日≤31 需 5 位）。因为高位是年、次高位是月、低位是日，整数比较即字典序日期比较——新号 < 旧号就要更新。拆解用移位和掩码。嵌入式固件版本号、协议字段常用这种打包。

 bit:  31........9 | 8....5 | 4...0
       year        | month  | day
 2025-09-25 → (2025<<9)|(9<<5)|25 = 0x000FA129

#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>

static uint32_t encode_date(int year, int month, int day)
{
    return ((uint32_t)year << 9) | ((uint32_t)month << 5) | (uint32_t)day;
}

static void decode_date(uint32_t v, int *y, int *m, int *d)
{
    *y = (int)(v >> 9);            /* 高位直接右移 */
    *m = (int)((v >> 5) & 0xF);    /* 4 位掩码 0b1111 */
    *d = (int)(v & 0x1F);          /* 5 位掩码 0b11111 */
}

/* 新设备号 < 旧设备号 → 需要更新，返回 true */
bool need_update(uint32_t new_ver, uint32_t old_ver)
{
    return new_ver < old_ver;
}

int main(void)
{
    uint32_t old_ver = encode_date(2025, 9, 25);
    uint32_t new_ver = encode_date(2025, 9, 20);
    int y, m, d;
    decode_date(old_ver, &y, &m, &d);
    printf("old = %04d-%02d-%02d\n", y, m, d);   /* 2025-09-25 */
    printf("update? %d\n", need_update(new_ver, old_ver));  /* 1：更旧要更新 */
    printf("update? %d\n", need_update(encode_date(2025, 10, 1), old_ver)); /* 0 */
    return 0;
}

逐行讲解：

  • (year << 9) | (month << 5) | day：位域拼接；位宽分配由取值范围决定（月 1–12 → 4 位；日 1–31 → 5 位）。
  • 解码掩码 0xF、0x1F：x & 0x1F 取低 5 位；先右移再掩码取中间字段。
  • 比较直接 <：打包顺序 = 比较优先级（年>月>日），这是编码设计的关键；若顺序错了，整数比较就不等于日期比较。

易错点与追问：

  1. 追问：为什么要自己打包而不用结构体存三个字段？ 协议/存储要求定长紧凑；位域结构体 struct {unsigned y:23, m:4, d:5;} 也可，但位域的内存布局是实现定义的，跨平台/跨编译器传输必须手动移位打包。
  2. 追问：年份能表示到多大？ 23 位 → 0~8,388,607 年，足够；若要省位可存 year-2000 偏移。
  3. 易错：移位前不转 uint32_t（int 移位符号扩展）；位宽算错（12 需 4 位不是 3 位，2³=8 < 12）；比较方向搞反（题意：新号小 = 落后 = 需要更新）。

10.1.29 四则运算表达式求值（处理空格与负数）

面试原题：实现计算器：计算含 + - * /、空格和负数的表达式，如 " -3 + 4 * 2 "。

思路：无括号表达式用一个数栈 + 延迟计算最简洁：扫描时维护当前数字 num 和上一个运算符 op；遇到新运算符（或结尾）时，按 op 处理 num——+/- 把 ±num 压栈，*// 弹出栈顶与 num 算完再压回。最后栈内求和。乘除因此天然优先于加减。负数处理：把开头的 - 当作一元负号，即"上一个运算符初始为 '+'、num 初值 0"时允许 - 直接修饰数字。更通用的做法（支持括号）是数栈+符号栈的双栈法或递归下降。

#include <stdio.h>
#include <ctype.h>

int calculate(const char *s)
{
    int stack[256], top = 0;
    long num = 0;
    char op = '+';                    /* 前一个运算符：首数视为 +num，自然支持 -3 */
    for (int i = 0; ; i++) {
        char c = s[i];
        if (isdigit((unsigned char)c)) {
            num = num * 10 + (c - '0');
        }
        if ((!isdigit((unsigned char)c) && c != ' ') || c == '\0') {
            if (op == '+') stack[top++] = (int)num;
            else if (op == '-') stack[top++] = (int)-num;
            else if (op == '*') stack[top-1] *= (int)num;
            else if (op == '/') stack[top-1] /= (int)num;
            op = c;
            num = 0;
            if (c == '\0') break;
        }
    }
    int sum = 0;
    for (int i = 0; i < top; i++) sum += stack[i];
    return sum;
}

int main(void)
{
    printf("%d\n", calculate(" -3 + 4 * 2 "));   /* 5 */
    printf("%d\n", calculate("3+22*2"));         /* 47 */
    printf("%d\n", calculate(" 14/ 3 "));        /* 4：整数除法 */
    return 0;
}

逐行讲解：

  • op 初值 '+'：首数字先以 "+num" 入栈，所以 "-3..." 的一元负号无需特判——扫描到 - 时 num=0，压入 +0，op 变 -，接着数字 3 以 -3 入栈。
  • 触发计算的时机是"遇到下一个运算符或串尾"，此时结算上一个 op 与 num——延迟一拍是本算法的精髓。
  • *、/ 直接改栈顶：保证乘除先于最后的加法求和，等价于运算符优先级。
  • 空格被两个 if 都跳过（第一个 if 不满足、第二个 if 的条件排除空格）。

易错点与追问：

  1. 追问：带括号怎么办？ 方案 A：双栈法——数栈与符号栈，符号栈按优先级决定是否先算，遇 ( 压栈、遇 ) 弹到匹配；方案 B：递归下降——expr := term {(+|-) term}，term := factor {(*|/) factor}，factor := num | '(' expr ')'，文法天然表达优先级，一元负号在 factor 层处理。
  2. 追问：除零和溢出？ 工程代码要检查除数为 0 并报错；中间值用 long 缓解溢出，或说明输入范围假设。
  3. 易错：遇到运算符立刻用"当前"运算符结算（应先结算上一个）；结尾忘记结算最后一个数（本实现靠 c=='\0' 触发）；字符串含空格时把它当运算符边界处理错误。

（10.1 C 语言手撕到此结束；10.2 数据结构与 10.3 综合题及篇末问答见下半部分。）

10.2 数据结构手撕

10.2.1 两个链表查重：找相交节点

面试原题：给你两个单链表的头指针，判断两个链表是否相交，如果相交，返回第一个公共节点。要求 O(n) 时间、O(1) 空间。

思路

关键观察：两个单链表一旦相交，从交点开始往后的所有节点必然完全重合（因为每个节点只有一个 next）。所以：

  1. 先分别遍历两个链表，求出长度 lenA、lenB。
  2. 长的链表先走 |lenA - lenB| 步，让两个指针"走齐"到距离尾部同样远的位置。
  3. 然后两个指针同步前进，第一个相等的节点就是交点；走到尾都NULL则不相交。

画图理解（Y 形结构）：

headA: a1 -> a2 -> c1 -> c2 -> c3 -> NULL
headB:      b1 -> b2 -> b3 ↗
lenA=5, lenB=6，B 先走 1 步到 b2，然后同步走，相遇于 c1。

#include <stdio.h>
#include <stdlib.h>

typedef struct Node {
    int data;
    struct Node *next;
} Node;

static Node *new_node(int data)
{
    Node *n = (Node *)malloc(sizeof(Node));
    n->data = data;
    n->next = NULL;
    return n;
}

static int list_len(Node *head)
{
    int len = 0;
    while (head) { len++; head = head->next; }
    return len;
}

/* 返回第一个公共节点，不相交返回 NULL */
Node *find_intersect(Node *headA, Node *headB)
{
    int lenA = list_len(headA);
    int lenB = list_len(headB);
    Node *pa = headA, *pb = headB;
    int diff;

    /* 长的先走 |lenA - lenB| 步 */
    if (lenA > lenB) {
        diff = lenA - lenB;
        while (diff--) pa = pa->next;
    } else {
        diff = lenB - lenA;
        while (diff--) pb = pb->next;
    }

    /* 同步前进找公共节点 */
    while (pa && pb) {
        if (pa == pb)      /* 比较指针，不是比较值！ */
            return pa;
        pa = pa->next;
        pb = pb->next;
    }
    return NULL;
}

int main(void)
{
    /* 公共部分 c1->c2->c3 */
    Node *c1 = new_node(7), *c2 = new_node(8), *c3 = new_node(9);
    c1->next = c2; c2->next = c3;

    Node *headA = new_node(1); headA->next = new_node(2);
    headA->next->next = c1;

    Node *headB = new_node(3); headB->next = new_node(4);
    headB->next->next = new_node(5);
    headB->next->next->next = c1;

    Node *x = find_intersect(headA, headB);
    if (x) printf("intersect at %d\n", x->data);  /* 输出 7 */
    else   printf("no intersect\n");

    Node *p1 = new_node(1), *p2 = new_node(2);
    printf("disjoint: %s\n", find_intersect(p1, p2) ? "yes" : "no");
    return 0;
}

逐行讲解

  • if (pa == pb) return pa;：必须比较指针地址而不是 data 值。两个不相交的链表完全可以有相同值的节点，比值会误判。这是本题最大的坑。
  • 求长度时不带头结点（若带头结点需统一减去，否则无所谓，因为两边处理方式一致）。
  • 时间 O(lenA+lenB)，空间 O(1)。

易错点与追问

  • 易错：比较 pa->data == pb->data 导致值相同但不相交的链表误判。
  • 追问1：如果链表可能有环怎么办？答：先各自判断是否有环（快慢指针）。一个有环一个无环必不相交；都无环按上面做；都有环则比较入环节点是否相同，相同则按入环前的长度差对齐；不同则从一个入环节点绕环一圈看能否遇到另一个入环节点。
  • 追问2：能不能用哈希表？可以，遍历 A 把节点地址存入哈希表，再遍历 B 查找，但空间 O(n)，不满足 O(1) 空间要求。

10.2.2 二叉树：结构体、前序遍历（递归+非递归）、求深度

面试原题：定义二叉树节点结构体，写前序遍历（先递归，再要求不用递归），再写一个求树深度的函数。

思路

  • 前序遍历顺序：根 → 左子树 → 右子树。
  • 递归版三行核心代码。
  • 非递归版用显式栈：根入栈；循环：弹栈顶并访问，先压右孩子再压左孩子（栈是后进先出，想先处理左就要后压左）。
  • 深度：max(左深度, 右深度) + 1，空树为 0。
#include <stdio.h>
#include <stdlib.h>

typedef struct TreeNode {
    int data;
    struct TreeNode *left;
    struct TreeNode *right;
} TreeNode;

static TreeNode *new_tnode(int data)
{
    TreeNode *n = (TreeNode *)malloc(sizeof(TreeNode));
    n->data = data;
    n->left = n->right = NULL;
    return n;
}

/* 1) 前序遍历：递归版 */
void preorder_rec(TreeNode *root)
{
    if (!root) return;
    printf("%d ", root->data);
    preorder_rec(root->left);
    preorder_rec(root->right);
}

/* 2) 前序遍历：非递归（显式栈） */
void preorder_iter(TreeNode *root)
{
    TreeNode *stack[128];
    int top = -1;
    if (!root) return;
    stack[++top] = root;                /* 根入栈 */
    while (top >= 0) {
        TreeNode *cur = stack[top--];   /* 弹出并访问 */
        printf("%d ", cur->data);
        if (cur->right) stack[++top] = cur->right;  /* 先压右 */
        if (cur->left)  stack[++top] = cur->left;   /* 后压左 */
    }
}

/* 3) 求深度：递归 */
int tree_depth(TreeNode *root)
{
    int ld, rd;
    if (!root) return 0;
    ld = tree_depth(root->left);
    rd = tree_depth(root->right);
    return (ld > rd ? ld : rd) + 1;
}

int main(void)
{
    /*       1
     *      / \
     *     2   3
     *    / \
     *   4   5       */
    TreeNode *root = new_tnode(1);
    root->left = new_tnode(2);
    root->right = new_tnode(3);
    root->left->left = new_tnode(4);
    root->left->right = new_tnode(5);

    preorder_rec(root);  printf("\n");   /* 1 2 4 5 3 */
    preorder_iter(root); printf("\n");   /* 1 2 4 5 3 */
    printf("depth = %d\n", tree_depth(root));  /* 3 */
    return 0;
}

逐行讲解

  • if (cur->right) stack[++top] = cur->right; 在 left 之前：栈 LIFO，右先压、左后压，弹栈时左先出来，符合"先左后右"的前序要求。写反了就是"根右左"。
  • tree_depth 用三目 (ld > rd ? ld : rd) + 1，空节点返回 0，叶子返回 1。

易错点与追问

  • 易错：非递归版压栈顺序写反；忘记判空导致访问 NULL。
  • 追问1：中序非递归怎么写？答：指针沿左链一路压栈到底，弹出访问，然后转向右孩子，重复。
  • 追问2：层序遍历？用队列（BFS），数组模拟环形队列即可。
  • 追问3：为什么嵌入式场景慎用递归？答：栈空间有限（线程栈可能只有几 KB），深树会栈溢出；且不利于形式化验证（MISRA-C 规则 17.2 禁止递归）。
  • 追问4：树深度最坏情况递归多少层？答：n 层（退化成链表时），这也是嵌入式要改非递归的原因。

10.2.3 单链表反转（迭代 + 递归）

面试原题：反转一个单链表。先写迭代，再要求"不用循环，递归写"。

思路

迭代法（三指针）：prev、cur、next 三个指针。每步：next = cur->next 保存后继；cur->next = prev 断链反向；prev = cur、cur = next 整体前移。

指针变化图（反转 1→2→3，初始 prev=NULL, cur=1）：

初始:  NULL    1 -> 2 -> 3 -> NULL
       prev    cur
第1步: NULL <- 1     2 -> 3
              prev   cur
第2步: NULL <- 1 <-  2     3
                     prev  cur
第3步: NULL <- 1 <-  2 <-  3    NULL
                          prev cur
结束：prev 即新头

递归法：先递归反转 head->next 之后的部分，拿到新头；然后 head->next->next = head（让后继指回自己），head->next = NULL（防环）。

#include <stdio.h>
#include <stdlib.h>

typedef struct Node {
    int data;
    struct Node *next;
} Node;

static Node *new_node(int data)
{
    Node *n = (Node *)malloc(sizeof(Node));
    n->data = data; n->next = NULL;
    return n;
}

/* 迭代法：三指针 */
Node *reverse_iter(Node *head)
{
    Node *prev = NULL, *cur = head, *next;
    while (cur) {
        next = cur->next;   /* 1. 保存后继 */
        cur->next = prev;   /* 2. 反向 */
        prev = cur;         /* 3. prev 前移 */
        cur = next;         /* 4. cur 前移 */
    }
    return prev;            /* 原尾即新头 */
}

/* 递归法 */
Node *reverse_rec(Node *head)
{
    Node *new_head;
    if (!head || !head->next)
        return head;                    /* 空表或单节点：直接返回 */
    new_head = reverse_rec(head->next); /* 反转后半段，new_head 是全局新头 */
    head->next->next = head;            /* 后继节点指回当前节点 */
    head->next = NULL;                  /* 当前节点变尾，断原链 */
    return new_head;
}

static void print_list(Node *head)
{
    while (head) { printf("%d ", head->data); head = head->next; }
    printf("\n");
}

int main(void)
{
    Node *h = new_node(1);
    h->next = new_node(2);
    h->next->next = new_node(3);
    h->next->next->next = new_node(4);

    print_list(h);                 /* 1 2 3 4 */
    h = reverse_iter(h);
    print_list(h);                 /* 4 3 2 1 */
    h = reverse_rec(h);
    print_list(h);                 /* 1 2 3 4 */
    printf("empty: %p\n", (void *)reverse_iter(NULL));  /* (nil) */
    return 0;
}

逐行讲解

  • 迭代法四步顺序不能乱：必须先 next = cur->next 保存后继，否则反向后就找不到后面的节点了。
  • return prev：循环结束时 cur 已是 NULL，prev 停在原尾节点，即新头。误写 return cur 返回 NULL 是经典错误。
  • 递归法中 head->next->next = head：递归返回时 head->next 仍指向原后继（它已是反转后子链表的尾），让它指回 head 完成局部反转。

易错点与追问

  • 易错：迭代忘保存 next 丢链；递归忘写 head->next = NULL 形成环。
  • 追问1：递归的空间复杂度？O(n)（调用栈），嵌入式场景应选迭代 O(1)。
  • 追问2：只反转链表中第 m 到第 n 个节点怎么做？（LeetCode 92，答：定位 m 前驱，对区间内用头插法反转，再拼接。）
  • 追问3：带头结点的链表反转有什么差别？答：从 head->next 开始反转，最后 head->next = new_first 即可，更简单。

10.2.4 链表重排：L0→Ln→L1→Ln-1 交叉重排

面试原题：链表 1→2→3→4→5→6→7→8→9，重排成 1→9→2→8→3→7→4→6→5。要求直接操纵节点，不允许改节点里的值。

思路（三板斧）

这就是经典的"重排链表"（LeetCode 143）：

  1. 找中点：快慢指针，slow 走一步 fast 走两步，fast 到尾时 slow 在中点。
  2. 反转后半段：用上一题的三指针迭代反转。
  3. 交替合并：两个头指针 p1（前半）、p2（反转后的后半），轮流摘节点接到结果上。

以 1→2→3→4→5→6→7→8→9 为例：中点后前半 1→2→3→4→5，后半反转得 9→8→7→6，交替合并：1→9→2→8→3→7→4→6→5，正好是题目要求。

#include <stdio.h>
#include <stdlib.h>

typedef struct Node {
    int data;
    struct Node *next;
} Node;

static Node *new_node(int data)
{
    Node *n = (Node *)malloc(sizeof(Node));
    n->data = data; n->next = NULL;
    return n;
}

static Node *reverse(Node *head)   /* 复用 10.2.3 的迭代反转 */
{
    Node *prev = NULL, *cur = head, *next;
    while (cur) {
        next = cur->next;
        cur->next = prev;
        prev = cur;
        cur = next;
    }
    return prev;
}

/* 原地重排：L0->L1->...->Ln 变为 L0->Ln->L1->Ln-1->... */
void reorder_list(Node *head)
{
    Node *slow, *fast, *second, *p1, *p2, *t1, *t2;
    if (!head || !head->next) return;

    /* 1. 快慢指针找中点：slow 停在前半段末尾 */
    slow = head;
    fast = head;
    while (fast->next && fast->next->next) {
        slow = slow->next;
        fast = fast->next->next;
    }

    /* 2. 断开并反转后半段 */
    second = reverse(slow->next);
    slow->next = NULL;

    /* 3. 交替合并 */
    p1 = head;
    p2 = second;
    while (p2) {
        t1 = p1->next;      /* 保存两个后继 */
        t2 = p2->next;
        p1->next = p2;      /* p2 插到 p1 后面 */
        p2->next = t1;
        p1 = t1;
        p2 = t2;
    }
}

int main(void)
{
    Node *h = new_node(1), *tail = h;
    int i;
    for (i = 2; i <= 9; i++) {
        tail->next = new_node(i);
        tail = tail->next;
    }

    reorder_list(h);
    while (h) { printf("%d ", h->data); h = h->next; }
    printf("\n");   /* 1 9 2 8 3 7 4 6 5 */
    return 0;
}

逐行讲解

  • 找中点循环条件 while (fast->next && fast->next->next)：这样 slow 停在"前半段的最后一个节点"。9 个节点时 slow 停在 5，后半段从 6 开始，反转后为 9→8→7→6。若写成 while (fast && fast->next)，slow 会多走一步，断链位置错。
  • slow->next = NULL 断链不可少：否则交替合并时前半段还连着旧的后半段，会死循环或结果错乱。
  • 合并时先保存 t1/t2 再改指针，理由同反转——任何"断链前先保存"的原则。

易错点与追问

  • 易错：中点循环条件写错导致偶数/奇数长度时断点偏一格；忘记断链。
  • 追问1：为什么"不允许改值"？因为交换值只适用于值可比较/可交换的场景，面试官要看的是指针操作能力；真实节点里可能有不透明数据（大结构体、函数指针），改值代价高甚至不可能。
  • 追问2：时间/空间复杂度？O(n) 时间，O(1) 空间（三趟线性遍历）。

10.2.5 现场纸笔题：链表增删 + 前序遍历 + "数组指针怎么访问数组元素"

面试原题（真实记录）：纸上写①创建单链表并插入节点、②删除指定值的节点、③二叉树前序遍历。写完面试官追问："数组指针怎么访问数组元素？"

思路与代码

#include <stdio.h>
#include <stdlib.h>

typedef struct Node {
    int data;
    struct Node *next;
} Node;

/* ① 创建：尾插法，返回头指针 */
Node *list_create(const int *arr, int n)
{
    Node *head = NULL, *tail = NULL;
    int i;
    for (i = 0; i < n; i++) {
        Node *n_ = (Node *)malloc(sizeof(Node));
        n_->data = arr[i];
        n_->next = NULL;
        if (!head) head = tail = n_;
        else { tail->next = n_; tail = n_; }
    }
    return head;
}

/* ② 删除第一个值为 key 的节点，返回新头（可能删的就是头） */
Node *list_delete(Node *head, int key)
{
    Node *cur = head, *prev = NULL;
    while (cur) {
        if (cur->data == key) {
            if (prev) prev->next = cur->next;  /* 中间/尾节点 */
            else      head = cur->next;        /* 删头节点 */
            free(cur);
            return head;
        }
        prev = cur;
        cur = cur->next;
    }
    return head;   /* 没找到 */
}

/* ③ 前序遍历（结构体定义见 10.2.2，此处略，直接复用） */

int main(void)
{
    int a[] = {1, 2, 3, 4};
    Node *h = list_create(a, 4);
    h = list_delete(h, 1);        /* 删头 */
    h = list_delete(h, 3);        /* 删中间 */
    while (h) { printf("%d ", h->data); h = h->next; }  /* 2 4 */
    printf("\n");
    return 0;
}

追问：数组指针怎么访问数组元素？

要把"数组指针（指向整个数组的指针）"和"指针数组"分清楚：

int arr[5] = {10, 20, 30, 40, 50};
int (*p)[5] = &arr;          /* 数组指针：指向 int[5] 整体的指针 */

/* 访问方式（四种等价）：*/
(*p)[2];        /* 30：先解引用得到数组，再取下标 */
p[0][2];        /* 30：p[0] 等价于 *p，即整个数组 */
*(*p + 2);      /* 30：*p 退化为首元素指针，+2 再解引用 */
*(&arr[0] + 2); /* 30：等价写法 */

/* 对比易混概念：*/
int *q[5];      /* 指针数组：数组里存 5 个 int*，不是数组指针！*/
int *r = arr;   /* 普通指针：指向首元素，r[2]、*(r+2) 也可访问 */

要点：int (*p)[5] 与 int *p[5] 的区别靠优先级——[] 优先级高于 *，加括号让 p 先与 * 结合才是指针。sizeof(p) 是指针大小（8/4 字节），sizeof(*p) 是整个数组大小（20 字节）。函数参数里写 int a[5] 会退化为 int *a，但 int (*a)[5] 不退化。

易错点与追问

  • 删除节点忘了"删头"的特例；删完忘 free 造成泄漏（面试官常盯着看有没有 free）。
  • 追问：纸笔写代码怎么自检？口头跑一遍边界：空表、删头、删尾、找不到。

10.2.6 1K 数据的哈希表：除留余数 + 链地址法

面试原题：有 1K（约 1000）个整数数据要存储，要求快速查找，用哈希表实现，写出插入、查找、删除的完整代码。

思路

  • 容量选择：装填因子 α = n / m，链地址法建议 α ≤ 1。1K 数据取 m = 1009（略大于 1000 的素数）。取素数是为了让 key % m 分布更均匀——若 m 与 key 的分布有公因子（如 m 是偶数、key 多为偶数），会大量冲突。
  • 哈希函数：除留余数法 h(key) = key % m（负数先取绝对值/转无符号）。
  • 冲突解决：链地址法（开链）——每个桶挂一条单链表，冲突节点头插进桶链。
#include <stdio.h>
#include <stdlib.h>

#define HASH_M 1009        /* 素数，略大于数据规模 1K */

typedef struct HNode {
    int key;
    struct HNode *next;
} HNode;

static HNode *table[HASH_M];   /* 桶数组，全局默认清零 */

static int hash_func(int key)
{
    unsigned int k = (unsigned int)key;  /* 处理负数 key */
    return (int)(k % HASH_M);
}

/* 插入：成功返回 0；已存在返回 1（按需选择覆盖或拒绝） */
int hash_insert(int key)
{
    int idx = hash_func(key);
    HNode *p = table[idx];
    while (p) {
        if (p->key == key) return 1;     /* 重复 key，不插 */
        p = p->next;
    }
    p = (HNode *)malloc(sizeof(HNode));
    if (!p) return -1;
    p->key = key;
    p->next = table[idx];                /* 头插 */
    table[idx] = p;
    return 0;
}

/* 查找：找到返回 1 且 *out 取值（此处 value 即 key 本身），否则 0 */
int hash_find(int key)
{
    int idx = hash_func(key);
    HNode *p = table[idx];
    while (p) {
        if (p->key == key) return 1;
        p = p->next;
    }
    return 0;
}

/* 删除：找到并删除返回 0，不存在返回 -1 */
int hash_delete(int key)
{
    int idx = hash_func(key);
    HNode *p = table[idx], *prev = NULL;
    while (p) {
        if (p->key == key) {
            if (prev) prev->next = p->next;
            else      table[idx] = p->next;
            free(p);
            return 0;
        }
        prev = p;
        p = p->next;
    }
    return -1;
}

int main(void)
{
    int i;
    for (i = 0; i < 1000; i++)
        hash_insert(i * 3 - 500);        /* 插入 1K 个数据（含负数） */

    printf("find 1000: %d\n", hash_find(1000));     /* 1 */
    printf("find -500: %d\n", hash_find(-500));     /* 1 */
    printf("find 99999: %d\n", hash_find(99999));   /* 0 */

    hash_delete(1000);
    printf("after del, find 1000: %d\n", hash_find(1000)); /* 0 */
    return 0;
}

逐行讲解

  • #define HASH_M 1009：1009 是大于 1000 的最小素数。除留余数法的口诀："m 取不大于表长的最大素数"。
  • (unsigned int)key：C 里负数取模结果依实现可能为负，转无符号避免数组下标为负的 UB。
  • 删除时要带 prev 指针做单链表删除，和 10.2.5 的删节点是同一套动作。

易错点与追问

  • 易错：负数 key 直接 % 导致负下标；删除忘 free。
  • 追问1：平均查找长度？链地址法成功查找约 1 + α/2，α=1 时约 1.5 次，接近 O(1)。
  • 追问2：除了链地址法还有什么冲突解决法？开放定址法（线性探测、二次探测、双重哈希）。开放定址删除麻烦（要打删除标记，否则探测链断裂），所以工程上链表场景多用链地址。
  • 追问3：嵌入式无 malloc 怎么做？答：静态数组池 + 空闲链表，或桶内用固定数组+开放定址，查表容量上界已知时很常见。
  • 追问4：如果 key 是字符串怎么办？答：用 BKDR/ELF 等字符串哈希把字符串映射成整数再取模。

10.2.7 无序链表按"奇升偶降"规则重排

面试原题：无序单链表 9→5→7→8→4→6→1→2→3，要求重排为 1→3→5→7→9→8→6→4→2（奇数升序排前面，偶数降序接后面）。直接操纵节点，不允许改值。

思路

三步：

  1. 拆分：遍历原链表，把奇数节点和偶数节点分别尾插进两条新链表（保持相对顺序，O(1) 摘接）。
  2. 排序：奇数链表升序排，偶数链表降序排。节点不允许改值，用"指针版插入排序"或"先反转再统一排序"。简便做法：两个链表都用交换指针的插入排序（摘节点插入到已排序区）。
  3. 拼接：奇链尾接偶链头。

更省事的等价做法：奇偶拆开后，先把偶数链表反转（降序变升序），然后两条链表统一按升序插入排序即可。下面给"拆 + 插入排序（可指定升降） + 拼接"的完整实现。

#include <stdio.h>
#include <stdlib.h>

typedef struct Node {
    int data;
    struct Node *next;
} Node;

static Node *new_node(int data)
{
    Node *n = (Node *)malloc(sizeof(Node));
    n->data = data; n->next = NULL;
    return n;
}

/* 指针版插入排序：ascend=1 升序，0 降序；不交换节点值，只改链接 */
static Node *insert_sort(Node *head, int ascend)
{
    Node dummy;
    Node *cur, *next, *p;
    dummy.next = NULL;                 /* 已排序区（带头结点） */
    cur = head;
    while (cur) {
        next = cur->next;              /* 保存后继 */
        p = &dummy;
        /* 在已排序区找插入位置：比较的是值，但改的是指针 */
        while (p->next &&
               (ascend ? (p->next->data < cur->data)
                       : (p->next->data > cur->data)))
            p = p->next;
        cur->next = p->next;           /* 摘下来插进去 */
        p->next = cur;
        cur = next;
    }
    return dummy.next;
}

/* 奇数升序 + 偶数降序 重排 */
Node *odd_even_reorder(Node *head)
{
    Node *oddH = NULL, *oddT = NULL;   /* 奇数链 头/尾 */
    Node *eveH = NULL, *eveT = NULL;   /* 偶数链 头/尾 */
    Node *cur = head, *next;

    /* 1. 拆分：尾插保持原相对顺序 */
    while (cur) {
        next = cur->next;
        cur->next = NULL;              /* 摘下当前节点 */
        if (cur->data % 2) {           /* 奇数（负数取模也适用） */
            if (oddT) oddT->next = cur; else oddH = cur;
            oddT = cur;
        } else {
            if (eveT) eveT->next = cur; else eveH = cur;
            eveT = cur;
        }
        cur = next;
    }

    /* 2. 排序：奇升、偶降 */
    oddH = insert_sort(oddH, 1);
    eveH = insert_sort(eveH, 0);

    /* 3. 拼接：奇链尾接偶链头 */
    if (!oddH) return eveH;
    oddT = oddH;
    while (oddT->next) oddT = oddT->next;
    oddT->next = eveH;
    return oddH;
}

int main(void)
{
    int a[] = {9, 5, 7, 8, 4, 6, 1, 2, 3};
    Node *h = NULL, *t = NULL;
    int i;
    for (i = 0; i < 9; i++) {          /* 建表 */
        Node *n = new_node(a[i]);
        if (t) t->next = n; else h = n;
        t = n;
    }

    h = odd_even_reorder(h);
    while (h) { printf("%d ", h->data); h = h->next; }
    printf("\n");   /* 1 3 5 7 9 8 6 4 2 */
    return 0;
}

逐行讲解

  • 拆分循环里 cur->next = NULL 是先"摘下"节点再挂到对应链尾，保证每条新链尾部干净。
  • insert_sort 用 dummy 头结点避免处理"插入到最前面"的特例，是链表排序的标准技巧。
  • 排序时比较的是 data（值只读不写），交换的是节点链接，满足"不改值"的要求。

易错点与追问

  • 易错：拆分后忘把新链尾部 next 置 NULL（残留旧链接会形成环，排序死循环）。
  • 追问1：为什么不允许改值？同 10.2.4：考查指针操纵能力；真实场景节点数据可能很大/不可交换。
  • 追问2：能用数组中转吗？可以（把指针存进数组排序再重链），但要 O(n) 空间，面试官一般希望 O(1) 额外空间。
  • 追问3：复杂度？拆分 O(n)，插入排序最坏 O(n²)；若允许用归并排序可到 O(n log n)（链表归并排序也是高频题，可顺带提一句加分）。

10.2.8 不改变链表结构反向打印

面试原题：单链表只能从头遍历，要求不改变链表结构（不允许反转链表）反向打印各节点的值。

思路

反向输出的本质是"先进后出"，两条路：

  1. 递归栈：递归到底再打印——函数调用栈就是天然的后进先出。
  2. 显式栈：遍历一遍把节点指针压栈，再依次弹栈打印。

为什么"反转再打印"常常不被接受：题目明确"不改变结构"；真实场景链表可能被其他模块/中断并发引用，反转会破坏其他持有者看到的状态；有些链表是 const 的或存在 Flash 里根本不可写。即使"反转→打印→再反转回来"两步走，时间翻倍且中途被中断就留下了不一致状态，面试官会追问这一点。

#include <stdio.h>
#include <stdlib.h>

typedef struct Node {
    int data;
    struct Node *next;
} Node;

/* 法一：递归（调用栈当栈用） */
void print_reverse_rec(Node *head)
{
    if (!head) return;
    print_reverse_rec(head->next);   /* 先递归到尾 */
    printf("%d ", head->data);       /* 回溯时打印 */
}

/* 法二：显式栈（嵌入式更安全，栈深可控） */
void print_reverse_stack(Node *head)
{
    Node *stack[128];                /* 容量上限已知时用定长数组 */
    int top = 0;
    while (head) {
        stack[top++] = head;
        head = head->next;
    }
    while (top > 0)
        printf("%d ", stack[--top]->data);
}

int main(void)
{
    Node a = {1, NULL}, b = {2, NULL}, c = {3, NULL}, d = {4, NULL};
    a.next = &b; b.next = &c; c.next = &d;   /* 1->2->3->4 */

    print_reverse_rec(&a);    printf("\n");  /* 4 3 2 1 */
    print_reverse_stack(&a);  printf("\n");  /* 4 3 2 1 */

    /* 验证结构未被修改 */
    printf("head still %d, next %d\n", a.data, a.next->data); /* 1 2 */
    return 0;
}

逐行讲解

  • 递归版打印语句放在递归调用之后：先压栈到底，回溯时才打印，所以尾部先输出。若打印放前面就变成正序了。
  • 显式栈版用定长数组是嵌入式常见写法（栈深可静态评估、无堆分配）；节点数超上限时需加溢出判断或改用动态栈。

易错点与追问

  • 追问1：两种方法复杂度？时间都是 O(n)，空间都是 O(n)（一个隐式调用栈、一个显式数组）。
  • 追问2：递归版在嵌入式有什么风险？n 大时调用栈溢出；MISRA-C 禁递归。显式栈容量静态可知，更安全。
  • 追问3：如果面试官允许"先反转打印再反转回来"，可以吗？答：技术上可以且空间 O(1)，但打印期间链表处于反转态，多线程/中断环境下有可见的不一致窗口，需评估；题目说"不改变结构"时稳妥做法是栈法。

10.3 并发与外设手撕

10.3.1 双线程交叉打印 12ab34cd…

面试原题：写两个线程，线程 A 打印数字 1-9，线程 B 打印字母 a-z，要求交叉输出 12ab34cd56ef78gh9ijklmnopqrstuvwxyz（数字两个一组、字母两个一组交替）。

思路

核心问题：两个线程的 printf 如果不加同步，执行顺序完全由调度器决定，输出必然乱序（比如 a 还没打印，数字 3 就抢跑了）。裸 printf 乱序的原因：①线程切换时机不可控；②printf 本身有内部缓冲区锁，但那只保证"单次调用不撕裂"，不保证"两个线程的调用次序"。所以必须用互斥锁 + 共享的 turn 变量 + 条件变量严格规定交替次序：

  • turn == 0 轮到数字线程，turn == 1 轮到字母线程。
  • 每个线程循环：加锁 → while (turn != mine) 在条件变量上等待 → 打印自己那组 → 切换 turn → broadcast 唤醒对方 → 解锁。

用 while 而不是 if 检查条件：防止虚假唤醒（spurious wakeup）和广播后条件又被别的线程改掉的竞态——这是 pthread 条件变量的铁律。

#include <stdio.h>
#include <pthread.h>

static pthread_mutex_t mtx  = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t  cond = PTHREAD_COND_INITIALIZER;
static int turn = 0;          /* 0=数字线程，1=字母线程 */
static int num_done = 0;      /* 数字线程是否已结束（数字只有9个，先跑完） */

static void *print_num(void *arg)
{
    int i;
    (void)arg;
    for (i = 1; i <= 9; i += 2) {           /* 1..9 每次两个 */
        pthread_mutex_lock(&mtx);
        while (turn != 0)                   /* 没轮到我：等待 */
            pthread_cond_wait(&cond, &mtx);
        printf("%d", i);
        if (i + 1 <= 9) printf("%d", i + 1);  /* 9 单独成组，防止越界 */
        turn = 1;                           /* 移交给字母线程 */
        pthread_cond_broadcast(&cond);
        pthread_mutex_unlock(&mtx);
    }
    pthread_mutex_lock(&mtx);               /* 告诉对方：我结束了，别再等我 */
    num_done = 1;
    pthread_cond_broadcast(&cond);
    pthread_mutex_unlock(&mtx);
    return NULL;
}

static void *print_alpha(void *arg)
{
    int i;
    (void)arg;
    for (i = 0; i < 26; i += 2) {           /* a..z 每次两个 */
        pthread_mutex_lock(&mtx);
        while (turn != 1 && !num_done)      /* 数字线程结束后直接放行 */
            pthread_cond_wait(&cond, &mtx);
        printf("%c%c", 'a' + i, 'a' + i + 1);
        turn = 0;
        pthread_cond_broadcast(&cond);
        pthread_mutex_unlock(&mtx);
    }
    return NULL;
}

int main(void)
{
    pthread_t t1, t2;
    pthread_create(&t1, NULL, print_num, NULL);
    pthread_create(&t2, NULL, print_alpha, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    printf("\n");   /* 12ab34cd56ef78gh9ijklmnopqrstuvwxyz */
    return 0;
}
/* 编译：gcc -o print_alt print_alt.c -lpthread */

逐行讲解

  • pthread_cond_wait(&cond, &mtx)：原子地"解锁 + 睡眠"，被唤醒返回前重新拿到锁。这就是为什么条件变量必须搭配互斥锁。
  • while (turn != 1)：字母线程被 broadcast 唤醒但 turn 已不是自己的（比如数字线程又先抢到锁）时，继续等，防止错序。
  • 打印和改 turn 都在临界区内完成，保证"打印完才放行对方"。
  • 末尾 pthread_join 不可少，否则主线程退出直接杀掉子线程。

易错点与追问

  • 易错：用 if 代替 while；忘 broadcast/signal；临界区外打印。
  • 追问1：裸 printf 为什么会乱序？答：线程调度不可控 + printf 只保证单次调用原子，不保证调用间的顺序；即使有终端行缓冲也不能作为同步手段。
  • 追问2：只用互斥锁不用条件变量行不行？可以（抢到锁发现不轮到自己就解锁重试），但那是忙等，CPU 空转；条件变量是"睡眠等待"，不占 CPU。
  • 追问3：能用一个信号量实现吗？可以，两个二值信号量 sem_num(初始1)/sem_alpha(初始0) 互相 post/wait，等价且更简洁。
  • 追问4：数字只有 9 个而字母 26 个，数字线程先退出会不会死锁？会！ 这是本题隐藏陷阱：数字线程退出后没人再把 turn 置回 1，字母线程将永久阻塞。所以代码里加了 num_done 标志——数字线程退出前广播该标志，字母线程的等待条件是 turn != 1 && !num_done，之后无需再等直接打印剩余字母。面试时主动指出并处理这一点很加分。

10.3.2 手撕线程邮箱（mailbox）接口与使用

面试原题：设计一个线程间"邮箱"：写出 init / send / recv / destroy 的接口头文件，并写出两个线程通过邮箱完成收发的代码，能编译即可。

思路

邮箱 = 环形队列 + 互斥锁 + 两个条件变量（not_full / not_empty），这是生产者-消费者的标准封装。工程上还要考虑两点：

  • 超时：recv 支持超时等待（pthread_cond_timedwait），避免线程永久阻塞，方便退出和看门狗。
  • shutdown 唤醒：销毁/关闭邮箱时把等待中的线程全部唤醒并返回错误码，否则等待线程会永远睡死（野指针等待已销毁的 cond 是灾难）。这也是真实项目（如 robotd）里容易踩的坑。

头文件 mailbox.h：

#ifndef MAILBOX_H
#define MAILBOX_H

#include <stdint.h>
#include <pthread.h>

#define MB_OK       0
#define MB_ERR     -1
#define MB_TIMEOUT -2
#define MB_CLOSED  -3

#define MB_CAP 16            /* 邮箱容量（消息条数） */

typedef struct {
    void   *buf[MB_CAP];     /* 环形队列：存消息指针 */
    int     head;            /* 取消息位置 */
    int     tail;            /* 放消息位置 */
    int     count;           /* 当前消息数 */
    int     shutdown;        /* 关闭标志：唤醒所有等待者 */
    pthread_mutex_t mtx;
    pthread_cond_t  not_full;   /* 有空位（生产者等） */
    pthread_cond_t  not_empty;  /* 有消息（消费者等） */
} mailbox_t;

int  mb_init(mailbox_t *mb);
/* 阻塞发送；邮箱满则等待；被 shutdown 返回 MB_CLOSED */
int  mb_send(mailbox_t *mb, void *msg);
/* 接收；timeout_ms < 0 表示永久阻塞；超时返回 MB_TIMEOUT */
int  mb_recv(mailbox_t *mb, void **msg, int timeout_ms);
/* 唤醒所有阻塞线程并销毁；此后 send/recv 返回 MB_CLOSED */
void mb_destroy(mailbox_t *mb);

#endif /* MAILBOX_H */

实现 mailbox.c：

#include "mailbox.h"
#include <time.h>
#include <errno.h>

int mb_init(mailbox_t *mb)
{
    mb->head = mb->tail = mb->count = 0;
    mb->shutdown = 0;
    pthread_mutex_init(&mb->mtx, NULL);
    pthread_cond_init(&mb->not_full, NULL);
    pthread_cond_init(&mb->not_empty, NULL);
    return MB_OK;
}

int mb_send(mailbox_t *mb, void *msg)
{
    pthread_mutex_lock(&mb->mtx);
    while (mb->count == MB_CAP && !mb->shutdown)
        pthread_cond_wait(&mb->not_full, &mb->mtx);
    if (mb->shutdown) { pthread_mutex_unlock(&mb->mtx); return MB_CLOSED; }

    mb->buf[mb->tail] = msg;
    mb->tail = (mb->tail + 1) % MB_CAP;   /* 环形回绕 */
    mb->count++;
    pthread_cond_signal(&mb->not_empty);  /* 唤醒一个消费者 */
    pthread_mutex_unlock(&mb->mtx);
    return MB_OK;
}

int mb_recv(mailbox_t *mb, void **msg, int timeout_ms)
{
    int rc = MB_OK;
    pthread_mutex_lock(&mb->mtx);

    if (timeout_ms < 0) {                          /* 永久阻塞 */
        while (mb->count == 0 && !mb->shutdown)
            pthread_cond_wait(&mb->not_empty, &mb->mtx);
    } else {                                       /* 超时等待 */
        struct timespec ts;
        clock_gettime(CLOCK_REALTIME, &ts);
        ts.tv_sec  += timeout_ms / 1000;
        ts.tv_nsec += (timeout_ms % 1000) * 1000000L;
        if (ts.tv_nsec >= 1000000000L) { ts.tv_sec++; ts.tv_nsec -= 1000000000L; }
        while (mb->count == 0 && !mb->shutdown) {
            int r = pthread_cond_timedwait(&mb->not_empty, &mb->mtx, &ts);
            if (r == ETIMEDOUT) {
                pthread_mutex_unlock(&mb->mtx);
                return MB_TIMEOUT;
            }
        }
    }

    if (mb->count == 0 && mb->shutdown) {          /* 被关闭且已空 */
        pthread_mutex_unlock(&mb->mtx);
        return MB_CLOSED;
    }
    *msg = mb->buf[mb->head];
    mb->head = (mb->head + 1) % MB_CAP;
    mb->count--;
    pthread_cond_signal(&mb->not_full);            /* 唤醒一个生产者 */
    pthread_mutex_unlock(&mb->mtx);
    return rc;
}

void mb_destroy(mailbox_t *mb)
{
    pthread_mutex_lock(&mb->mtx);
    mb->shutdown = 1;
    pthread_cond_broadcast(&mb->not_full);    /* 必须唤醒所有等待者 */
    pthread_cond_broadcast(&mb->not_empty);
    pthread_mutex_unlock(&mb->mtx);
    /* 实际项目里应等所有使用者退出后再 destroy 锁，此处简化 */
    pthread_mutex_destroy(&mb->mtx);
    pthread_cond_destroy(&mb->not_full);
    pthread_cond_destroy(&mb->not_empty);
}

上层两个线程的使用 main.c：

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include "mailbox.h"

static mailbox_t mb;

typedef struct { int seq; char text[32]; } msg_t;

static void *sender(void *arg)
{
    int i;
    (void)arg;
    for (i = 0; i < 5; i++) {
        static msg_t m;                    /* 简化：复用静态消息 */
        m.seq = i;
        snprintf(m.text, sizeof(m.text), "hello %d", i);
        if (mb_send(&mb, &m) != MB_OK) break;
        usleep(100 * 1000);
    }
    mb_send(&mb, NULL);                    /* NULL 消息 = 结束信号 */
    return NULL;
}

static void *receiver(void *arg)
{
    void *p;
    (void)arg;
    for (;;) {
        int rc = mb_recv(&mb, &p, 2000);   /* 2 秒超时 */
        if (rc == MB_TIMEOUT) { printf("recv timeout\n"); continue; }
        if (rc == MB_CLOSED)  break;
        if (!p) { printf("got end\n"); break; }
        printf("recv seq=%d text=%s\n", ((msg_t *)p)->seq, ((msg_t *)p)->text);
    }
    return NULL;
}

int main(void)
{
    pthread_t t1, t2;
    mb_init(&mb);
    pthread_create(&t1, NULL, sender, NULL);
    pthread_create(&t2, NULL, receiver, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    mb_destroy(&mb);
    return 0;
}
/* 编译：gcc -o mb_demo main.c mailbox.c -lpthread */

逐行讲解

  • 环形队列三要素 head/tail/count：取模回绕；count 判满判空，避免 head==tail 歧义（不牺牲一格的方案）。
  • while (mb->count == 0 ...)：同上一题，防虚假唤醒。
  • send 和 recv 里 signal 的是对方的条件变量：放入消息后等"非空"的人才有意义被唤醒。
  • destroy 里先置 shutdown 再 broadcast 两个条件变量：让所有阻塞在 send/recv 的线程醒来检查标志并返回 MB_CLOSED，这是"安全退出"的关键——很多面试者漏掉，导致程序退出时挂死。

易错点与追问

  • 易错：只 signal 不 broadcast 导致 shutdown 时只唤醒一个、其余永久阻塞；超时时间 timespec 的 nsec 溢出没进位。
  • 追问1：为什么传消息指针而不是拷贝消息体？零拷贝、效率高、消息大小可变；代价是生命周期由调用者管理（可用内存池解决）。
  • 追问2：mailbox 和消息队列（POSIX mq）/管道区别？mailbox 是进程内线程间、无内核拷贝；mq/pipe 可跨进程但有系统调用开销。
  • 追问3：MCU 上无 pthread 怎么办？用 RTOS 的 queue（FreeRTOS xQueue）就是同一模型：环形缓冲 + 任务阻塞链表，原理完全对应。

10.3.3 UART 帧协议解析：状态机逐字节解析

面试原题：串口收到一帧数据，格式为：帧头 0xAA 0x55（2 字节）+ 长度 LEN（1 字节，数据字节数）+ 数据（LEN 字节）+ 校验和 SUM（1 字节，从 LEN 到数据末尾逐字节累加取低 8 位）。写一个解析器，逐字节喂入。

思路

串口数据是字节流，一次中断/DMA 可能来半个帧、也可能来两个半帧，所以解析器必须是可重入的状态机：每收到一个字节调一次 uart_parse_feed(byte)，状态机自己记住进度，凑齐一帧且校验通过就回调。状态划分：

IDLE ──0xAA──> HEAD1 ──0x55──> LEN ──> DATA(收LEN个) ──> SUM ──校验──> 输出帧
  │非0xAA回IDLE  │非0x55回IDLE（若又是0xAA留在HEAD1）  │校验失败回IDLE

#include <stdio.h>
#include <stdint.h>

#define MAX_PAYLOAD 64

typedef enum {
    ST_IDLE = 0,   /* 等 0xAA */
    ST_HEAD1,      /* 已收 0xAA，等 0x55 */
    ST_LEN,        /* 等长度字节 */
    ST_DATA,       /* 收数据 */
    ST_SUM         /* 等校验和 */
} parse_state_t;

typedef struct {
    parse_state_t state;
    uint8_t  len;                    /* 本帧数据长度 */
    uint8_t  idx;                    /* 已收数据个数 */
    uint8_t  sum;                    /* 累加校验 */
    uint8_t  payload[MAX_PAYLOAD];
} uart_parser_t;

static uart_parser_t g_psr;

/* 帧处理回调：实际项目里换成消息入队/事件通知 */
static void on_frame(const uint8_t *data, uint8_t len)
{
    uint8_t i;
    printf("frame ok, len=%u data:", len);
    for (i = 0; i < len; i++) printf(" %02X", data[i]);
    printf("\n");
}

/* 逐字节喂入（在串口 ISR 或接收线程里调用） */
void uart_parse_feed(uint8_t byte)
{
    uart_parser_t *p = &g_psr;
    switch (p->state) {
    case ST_IDLE:
        if (byte == 0xAA) p->state = ST_HEAD1;
        break;                       /* 其他字节丢弃 */
    case ST_HEAD1:
        if (byte == 0x55) {
            p->state = ST_LEN;
            p->sum = 0;
            p->idx = 0;
        } else if (byte != 0xAA) {   /* 0xAA 0xAA 0x55 也能同步 */
            p->state = ST_IDLE;
        }
        break;
    case ST_LEN:
        if (byte > MAX_PAYLOAD) {    /* 长度非法：丢弃重来 */
            p->state = ST_IDLE;
            break;
        }
        p->len = byte;
        p->sum += byte;
        p->state = (byte > 0) ? ST_DATA : ST_SUM;  /* 0 长度直接等校验 */
        break;
    case ST_DATA:
        p->payload[p->idx++] = byte;
        p->sum += byte;
        if (p->idx >= p->len) p->state = ST_SUM;
        break;
    case ST_SUM:
        if (byte == p->sum)          /* 校验通过：输出完整帧 */
            on_frame(p->payload, p->len);
        else
            printf("checksum err: expect %02X got %02X\n", p->sum, byte);
        p->state = ST_IDLE;          /* 无论成败都回 IDLE */
        break;
    default:
        p->state = ST_IDLE;
        break;
    }
}

int main(void)
{
    /* 帧1：AA 55 03 01 02 03 SUM(03+01+02+03=09) */
    uint8_t f1[] = {0xAA, 0x55, 0x03, 0x01, 0x02, 0x03, 0x09};
    /* 帧2：垃圾字节 + 校验错误帧 + 一个 0 长度帧 AA 55 00 00 */
    uint8_t f2[] = {0x11, 0xAA, 0x55, 0x02, 0x05, 0x06, 0x00,  /* 校验错 */
                    0xAA, 0x55, 0x00, 0x00};                   /* 空帧 */
    unsigned i;
    for (i = 0; i < sizeof(f1); i++) uart_parse_feed(f1[i]);
    for (i = 0; i < sizeof(f2); i++) uart_parse_feed(f2[i]);
    return 0;
}

逐行讲解

  • ST_HEAD1 里 else if (byte != 0xAA)：处理 AA AA 55 的粘连——第二个 AA 可能是新帧头，留在 HEAD1 而不是回 IDLE，这是细节加分点。
  • ST_LEN 里长度上限检查：没有这个检查，一个错乱的 LEN=200 会写爆 64 字节的 payload 数组（栈/堆溢出，嵌入式安全事故）。
  • p->sum += byte 用 uint8_t 自然溢出回绕，正好实现"取低 8 位"，不用显式 & 0xFF。
  • 校验失败只丢弃本帧并回 IDLE，不影响后续重新同步。

易错点与追问

  • 易错：在 ISR 里做 printf/回调重活（应只入队，交给任务处理）；payload 长度不检查；状态机用一次性函数实现、跨调用丢进度。
  • 追问1：为什么用状态机而不是"等够一整帧再解析"？因为串口无法保证一次收齐一帧，状态机天然支持任意切分。
  • 追问2：0xAA 出现在数据里怎么办？状态机按位置解析，数据区不参与帧头匹配，所以没问题——这正是"帧头+长度"协议优于"帧头+帧尾扫描"的原因。
  • 追问3：校验和太弱怎么办？升级 CRC8/CRC16（可以给出现成的查表法思路）。

10.3.4 串口粘包处理：环形缓冲区 + 帧同步

面试原题：串口数据可能一次来多个包、也可能一个包分多次来（粘包/拆包），怎么处理？写代码。

思路

架构上把"收"和"解"解耦：ISR/DMA 只负责把字节塞进环形缓冲区（ring buffer），应用层循环从缓冲区取字节喂给 10.3.3 的状态机。环形缓冲区本身用"读指针/写指针 + 满空判断"实现。这样：

  • 粘包（一次来两帧）：状态机解析完第一帧自动回 IDLE，接着解析第二帧，天然支持。
  • 拆包（半帧）：状态机停在中间状态，等下一批字节，天然支持。

TCP 粘包与串口粘包异同：成因不同——TCP 是字节流无消息边界（Nagle 合并、MSS 切分），串口是物理层中断/DMA 批次不可控；但解法相同：在字节流之上定义带"帧头+长度+校验"的应用层协议，用状态机按协议切分。区别是串口帧更小、常有 IDLE 空闲中断可辅助分帧；TCP 没有帧间隔概念，只能靠协议字段。

#include <stdio.h>
#include <stdint.h>

#define RB_SIZE 256            /* 取 2 的幂，可用位与代替取模 */

typedef struct {
    uint8_t  buf[RB_SIZE];
    volatile uint16_t head;    /* 读指针（消费者动） */
    volatile uint16_t tail;    /* 写指针（ISR 动） */
} ringbuf_t;

static ringbuf_t g_rb;

/* 入队：ISR 里调用；满则丢弃（也可覆盖，按需求定） */
static int rb_put(ringbuf_t *rb, uint8_t b)
{
    uint16_t next = (uint16_t)((rb->tail + 1) % RB_SIZE);
    if (next == rb->head) return -1;      /* 满 */
    rb->buf[rb->tail] = b;
    rb->tail = next;
    return 0;
}

/* 出队：应用层调用；空返回 -1 */
static int rb_get(ringbuf_t *rb, uint8_t *b)
{
    if (rb->head == rb->tail) return -1;  /* 空 */
    *b = rb->buf[rb->head];
    rb->head = (uint16_t)((rb->head + 1) % RB_SIZE);
    return 0;
}

/* —— 下面复用 10.3.3 的状态机，此处给出精简声明 —— */
extern void uart_parse_feed(uint8_t byte);

/* 模拟 ISR：硬件收到一段字节（可能粘两帧或只有半帧） */
static void fake_uart_isr(const uint8_t *data, unsigned n)
{
    unsigned i;
    for (i = 0; i < n; i++)
        rb_put(&g_rb, data[i]);
}

/* 应用层主循环：取出多少解多少 */
static void app_task(void)
{
    uint8_t b;
    while (rb_get(&g_rb, &b) == 0)
        uart_parse_feed(b);      /* 逐字节喂状态机，自动处理粘包/拆包 */
}

int main(void)
{
    /* 模拟"一次中断来了 1.5 帧"：帧A完整 + 帧B的前半 */
    uint8_t chunk1[] = {0xAA, 0x55, 0x02, 0x11, 0x22, 0x35,   /* 帧A: 02+11+22=35 */
                        0xAA, 0x55, 0x03, 0x01};               /* 帧B 只来一半 */
    /* 第二次中断补全帧B */
    uint8_t chunk2[] = {0x02, 0x03, 0x09};                     /* 03+01+02+03=09 */
    /* 第三次：两帧粘一起 */
    uint8_t chunk3[] = {0xAA, 0x55, 0x01, 0x0A, 0x0B,
                        0xAA, 0x55, 0x01, 0x0C, 0x0D};

    fake_uart_isr(chunk1, sizeof(chunk1));  app_task();  /* 解出帧A，帧B等下次 */
    fake_uart_isr(chunk2, sizeof(chunk2));  app_task();  /* 解出帧B */
    fake_uart_isr(chunk3, sizeof(chunk3));  app_task();  /* 解出两帧 */
    return 0;
}
/* 编译时与 10.3.3 的解析器一起链接即可运行 */

逐行讲解

  • head == tail 判空、(tail+1)%SIZE == head 判满：牺牲一格换取满/空判断无歧义；单生产单消费下读写指针各归一方，无锁安全（所以 volatile）。
  • ISR 里只做 rb_put，绝不在中断里跑状态机——中断要尽快返回，解析留给任务级。
  • 应用层 app_task 把缓冲取空为止，粘包拆包全部由状态机消化，主循环代码不需要知道"包"的概念。

易错点与追问

  • 易错：环形缓冲用"计数器"代替牺牲一格时，ISR 与任务同时改计数造成竞态（单生产单消费下 head/tail 分离才是无锁写法）。
  • 追问1：缓冲区满了怎么办？按业务选：丢弃新数据并统计溢出计数（推荐，保留旧帧）、或覆盖最旧数据；一定要加溢出统计变量方便现场排查。
  • 追问2：有 IDLE 空闲中断/DMA 半满中断怎么优化？DMA + IDLE 中断一次搬一批，比逐字节中断省 CPU；解析侧不变。
  • 追问3：和 TCP 粘包处理代码能复用吗？状态机部分可以直接复用，只是字节来源从 ring buffer 换成 recv() 返回的流。

10.3.5 触摸屏应用层：读数据 + 按结构体解析

面试原题：触摸屏驱动通过文件描述符上报数据，报文结构体为 struct touch_point { uint16_t x; uint16_t y; uint8_t pressed; uint8_t id; }（小端，6 字节/触点，可能一次报多个触点）。实现：①从设备读取数据的函数（返回实际字节数、处理短读）；②解析函数（字节序转换、有效性检查、多触点遍历）。

思路

  • read() 不保证一次读满（短读），要循环读到期望长度或 EOF/出错；非阻塞 fd 还要处理 EAGAIN。
  • 协议字节序与 CPU 字节序可能不同，按"小端协议"显式拼 lo | (hi<<8)，不要用强制类型转换——强转依赖本机字节序且可能触发未对齐访问 UB。
  • 有效性检查：坐标超屏、pressed 非 0/1、id 超上限、长度不是 6 的整数倍，都要防御。
#include <stdio.h>
#include <stdint.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>

#define TOUCH_MAX_POINTS 5
#define SCREEN_W 800
#define SCREEN_H 480
#define TP_PKT_SIZE 6          /* sizeof(struct touch_point) 在线上的大小 */

struct touch_point {
    uint16_t x;                /* 协议：小端 */
    uint16_t y;                /* 协议：小端 */
    uint8_t  pressed;          /* 0=抬起 1=按下 */
    uint8_t  id;               /* 触点编号 */
};

/* ① 可靠读：循环读满 count 字节，返回实际读到的字节数，出错返回 -1 */
static ssize_t read_full(int fd, uint8_t *buf, size_t count)
{
    size_t got = 0;
    while (got < count) {
        ssize_t n = read(fd, buf + got, count - got);
        if (n > 0) {
            got += (size_t)n;
        } else if (n == 0) {
            break;                       /* EOF */
        } else {
            if (errno == EINTR)  continue;   /* 被信号打断：重试 */
            if (errno == EAGAIN) break;      /* 非阻塞无数据：返回已读部分 */
            return -1;                         /* 真错误 */
        }
    }
    return (ssize_t)got;
}

/* ② 解析：从原始字节流解出触点数组，返回有效触点数，出错返回 -1 */
static int touch_parse(const uint8_t *buf, ssize_t len,
                       struct touch_point *out, int max_points)
{
    int cnt = 0, i;
    if (len < 0 || (len % TP_PKT_SIZE) != 0)   /* 长度必须是报文整数倍 */
        return -1;

    for (i = 0; i + TP_PKT_SIZE <= len; i += TP_PKT_SIZE) {
        uint16_t x = (uint16_t)(buf[i + 0] | ((uint16_t)buf[i + 1] << 8)); /* 小端拼接 */
        uint16_t y = (uint16_t)(buf[i + 2] | ((uint16_t)buf[i + 3] << 8));
        uint8_t pressed = buf[i + 4];
        uint8_t id      = buf[i + 5];

        /* 有效性检查：脏数据丢弃 */
        if (x >= SCREEN_W || y >= SCREEN_H) { printf("drop: bad coord\n"); continue; }
        if (pressed > 1)                    { printf("drop: bad pressed\n"); continue; }
        if (id >= TOUCH_MAX_POINTS)         { printf("drop: bad id\n"); continue; }
        if (cnt >= max_points) break;

        out[cnt].x = x;
        out[cnt].y = y;
        out[cnt].pressed = pressed;
        out[cnt].id = id;
        cnt++;
    }
    return cnt;
}

int main(void)
{
    /* 模拟设备报文：两个有效触点 + 一个越界触点 */
    uint8_t raw[] = {
        0x20, 0x03, 0xE0, 0x01, 0x01, 0x00,   /* x=800? 不,0x0320=800 越界，会被丢 */
        0x2C, 0x01, 0x68, 0x01, 0x01, 0x01,   /* x=300 y=360 press id=1 */
        0x64, 0x00, 0xC8, 0x00, 0x00, 0x02    /* x=100 y=200 release id=2 */
    };
    struct touch_point pts[TOUCH_MAX_POINTS];
    int fd = open("/dev/null", O_RDONLY);   /* 演示：实际为触摸屏节点 */
    uint8_t buf[64];
    ssize_t n;
    int cnt, i;

    (void)fd;
    /* 实际使用：n = read_full(fd, buf, sizeof(buf)); */
    n = read_full(-1, buf, sizeof(buf));    /* fd=-1 立即返回 -1，仅演示容错 */
    printf("read_full(-1) = %zd (errno=%d)\n", n, errno);

    n = (ssize_t)sizeof(raw);               /* 直接用模拟报文演示解析 */
    cnt = touch_parse(raw, n, pts, TOUCH_MAX_POINTS);
    printf("valid points: %d\n", cnt);      /* 2（第1个越界被丢弃） */
    for (i = 0; i < cnt; i++)
        printf("id=%u x=%u y=%u %s\n", pts[i].id, pts[i].x, pts[i].y,
               pts[i].pressed ? "DOWN" : "UP");
    return 0;
}

逐行讲解

  • read_full 处理三类返回：n>0 累加进度；EINTR 信号打断必须重试（否则偶然丢数据）；EAGAIN 非阻塞语义下不是错误，返回已读到的部分。
  • 小端拼接 buf[i] | (buf[i+1] << 8)：显式、可移植，不依赖主机字节序；<<8 前先转 uint16_t 防止 int 提升后的符号/宽度坑。
  • 解析先查 len % 6：半包（粘包拆包）时长度不是整数倍，直接报错让上层等下一批，而不是硬解出垃圾。
  • 越界坐标用 continue 丢弃单点而不是整包失败：一个脏点不应拖垮其他好触点。

易错点与追问

  • 易错：直接 struct touch_point *p = (struct touch_point *)buf 强转——结构体可能有对齐填充（本题恰好 6 字节无填充，但加上 __attribute__((packed)) 的讨论更显功底）且依赖字节序、有未对齐风险。
  • 追问1：为什么 read 会短读？驱动缓冲区只有部分数据、信号中断、非阻塞，都可能返回少于请求的字节数，应用层必须循环。
  • 追问2：Linux 下触摸屏正规做法？用 input 子系统读 /dev/input/eventX 的 struct input_event，按 EV_ABS/ABS_MT_SLOT 协议解析；本题模型常见于 MCU 裸机/I2C 触摸芯片（如 GT911）的寄存器读取。
  • 追问3：多触点协议里 id 有什么用？跟踪同一根手指的滑动轨迹：按下→移动→抬起期间 id 不变，应用按 id 维护触点状态机。

10.4 手撕代码面试高频问答

Q1：手写代码时面试官最看重什么？

不是"一次写对"，而是四件事：①思路先行——动笔前先用一两句话讲清方案（"我用快慢指针找中点，再反转后半段"），让面试官知道你不是在碰运气；②边界意识——空指针、单节点、数组越界、长度为奇偶，主动提；③代码规范——有意义的变量名、一致的缩进、必要的判空，嵌入式岗位还会看 const、volatile、资源释放；④可沟通性——边写边讲，卡壳时说出自己的卡点，比闷头死磕强得多。面试官心里想的是"这人以后跟我做 code review 是什么体验"。

Q2：边界条件应该怎么主动提？

写完主干代码后、面试官还没开口时，自己先"过电影"：空输入（NULL、空表、len=0）、单元素（一个节点的链表反转）、首尾位置（删头删尾）、满/空（环形缓冲）、奇偶长度（找中点）、极值（int 溢出、负数取模、uint8 回绕）。每种边界用一句话说明你的代码为什么能处理，或者坦白"这里需要加一个判断"并补上。这个习惯本身就是加分项，比被追问时慌乱补救好得多。

Q3：代码写错了/卡住了怎么办？

不要装作没错硬撑——面试官早就看见了。正确姿势：①先承认"我检查一下"，用一个小用例把代码口头单步跑一遍（自己当 CPU），定位到具体哪一行不对；②说清错因（"我这里 prev 前移的顺序错了，应该先保存 next"）；③修正并重新验证。面试中写错很正常，调试过程展现的思维方式比一次写对更值钱。彻底卡住时可以说"我先写暴力解保证正确，再优化"，有保底方案远胜于交白卷。

Q4：宏和内联函数的区别？常考怎么答？

①宏是预处理期文本替换，不做类型检查、不求值顺序保证，#define SQR(x) ((x)*(x)) 少了括号就会出 SQR(a+b) 展开错误；参数带副作用 SQR(i++) 会求值两次。②内联函数是编译器建议（C99 inline），有类型检查、有作用域、参数只求值一次，可调试；缺点是代码膨胀（每个调用点展开一份）且"inline"只是建议，编译器可拒绝。③选型：简单常量/编译期开关用宏（或 static const/enum 更好）；有逻辑的"小函数"用 static inline 放头文件。嵌入式补充：宏可做 #ifdef 条件编译和泛型技巧（_Generic、statement expression），内联函数做不到。

Q5：为什么 memcpy 要考虑重叠？面试为什么常考？

memcpy 语义要求源和目的不重叠，重叠时结果是未定义的（实现可能按前向拷贝、后向拷贝、甚至按字/DMA 块拷贝，结果不可预期）。重叠场景应使用 memmove：它根据地址关系选择拷贝方向——dest < src 前向拷、dest > src 后向拷，保证源数据不被提前覆盖。面试常考因为：①写 memcpy 能考内存操作基本功（按字节/按字拷贝、对齐优化）；②"重叠怎么办"这个追问直接区分背题者和理解者；③真实嵌入式里滑动窗口、协议栈缓冲区搬移天天遇到重叠。手写 memmove 注意：指针比较前转 (uintptr_t) 或直接用 char * 运算，void* 不能做算术。

Q6：链表题为什么强调"不允许改节点的值"？

三层原因：①考指针操作——交换值谁都会，摘节点、改链接、防断链才是链表题的灵魂；②模拟真实约束——工程里节点数据往往是大结构体/不透明句柄/带锁资源，交换值代价高甚至语义错误（两个节点的值交换了，但指向它们的其他指针还认为它们是老节点）；③引导复杂度思考——不改值就逼着你用插入排序、归并排序这类"交换链接"的算法，而不是冒泡交换数据，自然引出对链表归并排序 O(n log n) 的讨论。答题时点破这一层，面试官会认为你懂工程而不仅是刷题。

Q7：递归和迭代怎么选？嵌入式面试怎么答？

算法层面等价时，嵌入式优先迭代：①栈空间有限（任务栈常 1~8 KB），递归深度不可静态确定就有栈溢出风险；②MISRA-C:2012 规则 17.2 明确禁止递归（汽车/工控项目强制）；③递归每次调用有压栈开销，RAM 同时存所有帧。但递归可读性好（树的遍历、快速排序原型），PC 端/深度有界（如平衡树 O(log n)）场景可用。面试加分话术："我先写递归版保证逻辑正确，再展示显式栈的迭代版，说明量产代码用后者"——一个回答同时展示两种实现和工程判断。

Q8：malloc 的内存忘了 free 会怎样？嵌入式里怎么用动态内存？

进程退出时 OS 会回收堆，但长期运行的嵌入式设备没有"退出"，泄漏会持续侵蚀堆直到分配失败，且堆碎片化会让"总空闲够、但没有连续大块"而分配失败。嵌入式实践：①能静态分配就静态分配（编译期可知、零碎片）；②必须动态时用内存池/块分配器（固定大小块，O(1) 分配、无碎片，FreeRTOS heap_4、lwIP memp 都是这个思路）；③每写一个 malloc 顺手写好对应 free 的路径（错误处理分支也要 free），面试官常盯着错误分支查泄漏；④面试代码里 free 了并置 NULL（防野指针/二次释放）是细节加分。

Q9：volatile 什么时候用？手撕代码会怎么考？

三种必须用 volatile 的场景：①内存映射硬件寄存器（#define UART_DR (*(volatile uint32_t *)0x40000000)）——每次读都可能被硬件改变；②ISR 与主循环共享的变量（如环形缓冲的 head/tail）——中断随时改它；③多线程共享但没用锁的标志位（严格说 C11 应用原子类型，volatile 只保证不缓存、不保证原子性和顺序，追问时要能说出这个局限）。面试考法：给一段 while (!flag); 等待硬件置位的代码，问"编译器开 O2 会怎样"——不加 volatile 时编译器认为 flag 不变，把循环优化成死循环或单次判断。再深一层：volatile 不替代内存屏障/原子操作，多核下要 atomic_flag/__sync 系列。

Q10：面试官说"这个解法还能优化吗"，应对套路是什么？

这是分层追问，按固定阶梯回答：①时间换空间/空间换时间：哈希表加速查找（O(n)→O(1)）、查表法加速 CRC/位运算；②算法升级：冒泡→快排、链表插入排序→归并排序 O(n log n)、暴力枚举→双指针/滑动窗口；③常数优化：减少遍历趟数（一趟同时求长度和尾指针）、位运算代替乘除模；④嵌入式专属维度：RAM 占用、代码体积、是否可静态分配、中断延迟影响、Cache/DMA 友好性。即使想不出更优解，也要口头分析复杂度瓶颈在哪（"瓶颈在排序的 O(n²)，n 小其实够用"）——展示权衡能力本身就是答案。

附录篇 Shell 与 Python 脚本速查

本篇写给零基础读者：不需要背语法大全，只需要达到两个目标——面试被问能答上来，真实项目里的脚本能看懂、能照着写。

在作者的智能车 Linux 项目里，脚本扮演了"胶水 + 自动化"的角色：宿主机端到端测试 test_host_e2e.sh（20 项断言）、串口部署 deploy_board.sh、长稳测试 soak_host.sh（含故障注入）、板端自启动 S99robotd、rcS 幂等补丁 patch_board_rcs.sh；Python 侧有串口文件传输 serial_push.py、PC 键盘遥控上位机 pc_controller.py（WASD → MQTT 速度命令），整个 embedded-agent 智能体也是用 Python 写的。本篇所有例子都从这些真实脚本里抽取，学到的就是项目里用的。

建议的学习顺序：先通读 A.1 建立语感，把 A.2 的技巧当成"查字典"随用随查，精读 A.3 的实战剖析直到能复述骨架，再用 A.4 把两个 Python 工具亲手敲一遍。脚本能力的提升没有捷径，就是"看懂一个 → 仿写一个 → 改出一个"的循环；本篇的目标是让第一轮循环尽快转起来。

A.1 Shell 脚本基础

A.1.1 shebang：脚本的第一行

脚本第一行的 #!/bin/bash 叫 shebang，告诉系统"用哪个解释器执行这个文件"：

#!/bin/bash        # 用 bash 解释
#!/bin/sh          # 用 sh（嵌入式板子上通常是 BusyBox 的 ash）
#!/usr/bin/env python3   # 在 PATH 里找 python3，可移植性更好

注意事项：

  • 没有 shebang 时，当前 shell 会直接把文件当命令逐行执行，语法差异可能埋雷。
  • 嵌入式板端 BusyBox 只有 /bin/sh，写板端脚本（如 S99robotd、patch_board_rcs.sh）不要用 bash 专有语法（数组、[[ ]]、local 的某些行为等），用 POSIX sh 写法最稳。
  • 执行方式：bash script.sh（不走 shebang）或 chmod +x script.sh && ./script.sh（走 shebang）。

【记忆口诀】第一行是"门牌"，告诉内核找谁家；板端 BusyBox 只有 sh，bash 语法别乱加。

A.1.2 变量与引用

NAME=robotd        # 赋值，等号两边不能有空格
echo $NAME         # 取值
echo ${NAME}       # 加花括号，拼字符串时防歧义：${NAME}_log
echo "$NAME"       # 加双引号——永远的好习惯

规则只有一条最重要：变量取值默认加双引号。不加引号时，值里的空格会把一个词拆成多个词，通配符 * 会被展开，非常危险：

DB=/tmp/robotd_e2e.db
rm -f "$DB" "$DB-wal" "$DB-shm"   # 正确：路径含空格/特殊字符也安全
rm -f $DB                          # 危险：若 DB="a b.db" 会删两个文件

常见内置变量：

变量 含义 例子
$0 脚本自身路径 cd "$(dirname "$0")/.."（脚本切到项目根目录）
$1 $2 ... 第 1、2 个命令行参数 DURATION=${1:-7200}（第 1 个参数，缺省 7200）
$# 参数个数 [ "$#" -lt 1 ] && { echo 用法; exit 1; }
$? 上一条命令的退出码（0=成功） 断言、错误判断的核心
$@ 全部参数（加引号 "$@" 保留每个参数独立） 把参数透传给内部命令
$! 最近一个后台进程的 PID robotd & PID=$!
$$ 当前脚本自身 PID 写临时文件防重名

${var:-默认值} 和 ${var:=默认值} 也是面试常客：:- 只是取值时给个默认，:= 还会把默认值写回变量。

【记忆口诀】取值加引号，空格不拆家；井号数参数，问号问成败，叹号记后台。

A.1.3 单引号与双引号的区别

NAME=robotd
echo "hello $NAME"    # 输出 hello robotd   —— 双引号内变量会展开
echo 'hello $NAME'    # 输出 hello $NAME    —— 单引号内原样输出
echo "time: $(date)"  # 双引号内 $() 命令替换也会执行
echo 'time: $(date)'  # 原样打印 $(date)

一句话：单引号是"铁板一块"，里面的 $、反引号全部失效；双引号是"半透膜"，变量和命令替换照常展开。

实战意义：项目里板端配置文件 /etc/robotd.conf 用 KEY='VALUE' 单引号格式，就是为了 source 进来时 VALUE 里的特殊字符不会被二次展开——安全。

【记忆口诀】双引号认美元，单引号装看不见。

A.1.4 命令替换 $()

把一条命令的标准输出变成字符串用：

OUT=$(mosquitto_sub -h 127.0.0.1 -t robot/v1/car01/status -C 1 -W 2)
now=$(date +%s)
N=$(sqlite3 "$DB" "SELECT COUNT(*) FROM cmd_log")
OLD_TS=$(( $(date +%s) * 1000 - 10000 ))   # $(( )) 是算术运算，常和 $() 嵌套

老式写法是反引号 `cmd`，功能相同但不能嵌套、可读性差，新脚本一律用 $()。

【记忆口诀】美元括号包命令，输出秒变字符串；反引号是爷爷辈，嵌套阅读两行泪。

A.1.5 条件判断：test / [ ] / [[ ]]

[ 其实是一条命令（等价于 test），所以它后面必须有空格，参数之间必须有空格：

[ "$OUT" = "online" ]        # 字符串相等（注意 = 两边空格）
[ "$N" -gt 0 ]               # 数值比较：-eq -ne -gt -ge -lt -le
[ -f /etc/robotd.conf ]      # 文件存在且是普通文件
[ -x /etc/init.d/S99robotd ] # 文件可执行
[ -d /proc/$pid ]            # 目录存在（常用来判断进程是否活着）
[ -z "$OUT" ]                # 字符串为空
[ -n "$OUT" ]                # 字符串非空

[[ ]] 是 bash 增强版，内部不会做分词和通配展开，更安全，还支持 == 模式匹配和 &&、||：

[[ $file == *.log ]] && echo "是日志文件"
[[ -n $OUT && $OUT != offline ]]

口诀级结论：板端 sh 脚本用 [ ]（POSIX），宿主机 bash 脚本可以用 [[ ]]（更省心）。

【记忆口诀】中括号是命令，空格是性命；字符串用等号，数字用杠 g；单中括号走天下，双中括号是 bash 外挂。

A.1.6 流程控制：if / for / while / case

# if：注意 then 和 fi
if ! kill -0 "$ROBOTD_PID" 2>/dev/null; then
    echo "[soak] 失败: robotd 进程退出!"
    exit 1
fi

# for：遍历一组词（e2e 脚本里遍历 5 张 SQLite 表）
for T in cmd_log state_log event_log perf_log rl_transition_raw; do
    N=$(sqlite3 "$DB" "SELECT COUNT(*) FROM $T" 2>/dev/null)
    [ "${N:-0}" -gt 0 ] && ok "$T 有 $N 行" || bad "$T 无数据"
done

# while：长稳测试的主循环——跑够 DURATION 秒才停
t0=$(date +%s)
while [ $(( $(date +%s) - t0 )) -lt "$DURATION" ]; do
    # 每 2 秒发一条速度命令 ...
    sleep 2
done

# case：启动脚本标配（S99robotd 的 start/stop/restart）
case "$1" in
start)   echo "启动 robotd..." ;;
stop)    echo "停止 robotd..." ;;
restart) $0 stop; $0 start ;;
*)       echo "用法: $0 {start|stop|restart}"; exit 1 ;;
esac

记住各家的"封口"：if→fi、case→esac、for/while→done。

【记忆口诀】if 倒写 fi 封口，case 倒写 esac 收；for 喂一串词，while 盯条件走。

A.1.7 函数

Shell 函数没有参数列表声明，参数在里面用 $1、$2 接；返回值用退出码（return）表示成败，用 echo 输出表示结果：

# S99robotd 里的"进程是否在跑"判断：返回码即答案
is_running() {
    [ -f "$PIDFILE" ] || return 1
    pid=$(cat "$PIDFILE")
    [ -d "/proc/$pid" ] || return 1
    grep -q robotd "/proc/$pid/cmdline" 2>/dev/null
}

if is_running; then
    echo "robotd 已在运行(pid $(cat $PIDFILE))"
fi

调用方式就是普通命令：is_running，判断它的成败用 if is_running; then。这是 Shell 函数最重要的思想：函数的成功失败用退出码表达，和命令一模一样。

【记忆口诀】函数是小命令，参数靠 $1 领；要问成不成，return 退出码来定。

A.1.8 set -euo pipefail 与退出码

每个命令执行完都有一个退出码：0 表示成功，非 0 表示失败。脚本顶部的 set 选项决定脚本遇到失败时的行为：

set -e            # 任何命令失败（退出码非 0）立即退出脚本，不再往下跑
set -u            # 使用未定义变量立即报错（防拼写错误把 rm -rf $DIR/ 变成 rm -rf /）
set -o pipefail   # 管道中任何一环失败，整条管道算失败（默认只看最后一环）
set -x            # 调试神器：执行前打印每一条命令

set -euo pipefail 被称为 bash 脚本的"安全带三件套"。但要注意边界，作者项目里就体现了取舍：

  • test_host_e2e.sh 用 set -u 而不用 -e——因为测试脚本的核心是"断言谈失败但继续跑完全部用例"，一条 grep 没匹配就退出反而收集不到完整报告。
  • patch_board_rcs.sh 用 set -e——补丁脚本任何一步失败都必须立即停，半打补丁的 rcS 比没打更危险。

被 -e 误伤时的豁免写法：cmd || true，或把命令放进 if 条件里（条件里的失败不触发 -e）。

【记忆口诀】-e 有错就刹车，-u 无名就报警，pipefail 揪出管道里的猪队友；测试要跑全，别带 -e 玩。

A.2 嵌入式高频 Shell 技巧

A.2.1 文本三板斧：grep / awk / sed 的分工

三者分工一句话：grep 找行，awk 切列，sed 改字。

grep——按模式筛行：

grep -q 'reject_dup_seq' /tmp/robotd_e2e.log   # -q 静默，只看退出码（断言神器）
grep -c '心跳停滞' "$LOG"                       # -c 计数：长稳报告里统计错误条数
grep -A3 'S99robotd' /etc/init.d/rcS           # -A3 连同后 3 行一起看（验证补丁效果）
grep -v 'DEBUG' app.log                        # -v 反选：滤掉 DEBUG 行
dmesg | grep -i can                            # -i 忽略大小写

awk——按列处理，自带计算：

# 长稳脚本里用 awk 算正弦速度（shell 本身不会浮点运算！）
v=$(awk -v t="$((now - t0))" 'BEGIN{printf "%.2f", 0.4 + 0.3 * sin(t / 30.0)}')

ps aux | awk '$3 > 50 {print $2, $11}'   # CPU 超 50% 的进程 PID 和命令
awk '{sum+=$1} END {print sum}' data.txt # 求和

sed——流编辑，改文件/替换文本：

sed 's/old/new/' file          # 每行第一次 old 换成 new（只输出不改文件）
sed -i 's/old/new/g' file      # -i 原地修改，g 全部替换
# patch_board_rcs.sh 的真实用法：在 telnetd 行前插入自启动块
sed -i '/^telnetd -l \/bin\/sh$/i\
if [ -x /etc/init.d/S99robotd ]; then\
\t/etc/init.d/S99robotd start || echo "robotd 启动失败"\
fi\
' /etc/init.d/rcS

【记忆口诀】grep 管"有没有"，awk 管"第几列"，sed 管"换成啥"；-q 静默 -c 数，-i 下手改文件。

A.2.2 xargs：把输出变成参数

管道传的是"标准输入"，但很多命令（rm、kill）只收"参数"，xargs 就是两者之间的转换器：

find /tmp -name '*.tmp' | xargs rm -f          # 批量删除
ps aux | grep robotd | grep -v grep | awk '{print $2}' | xargs kill   # 批量杀进程
echo "cmd_log state_log" | xargs -n1 echo 表:  # -n1 每次只取一个参数

处理文件名带空格的安全姿势：find ... -print0 | xargs -0 rm -f。

【记忆口诀】管道流水 stdin，xargs 把流水拧成参数链。

A.2.3 重定向与 >/dev/null 2>&1

文件描述符约定：0=stdin，1=stdout，2=stderr。组合起来：

./robotd -v > /tmp/robotd.log 2>&1   # stdout 写日志，stderr 也并入同一个文件
./robotd >> "$LOG" 2>&1              # >> 追加（长稳测试用，不覆盖旧日志）
cmd > /dev/null 2>&1                 # 全部输出丢弃（只要退出码）
sqlite3 "$DB" "..." 2>/dev/null      # 只丢错误（表不存在时保持安静）
cmd < input.txt                      # 从文件读输入

顺序敏感：> file 2>&1 是"都去 file"；写成 2>&1 > file 则 stderr 仍指向终端——面试常考这个顺序陷阱。

【记忆口诀】1 是正言 2 是错，>& 合体不分离；先指文件再合并，顺序反了白费力。

A.2.4 后台运行：& 与 jobs / kill

./stm32_sim vcan0 > /tmp/sim.log 2>&1 &   # & 放后台，脚本继续往下走
SIM_PID=$!                                # $! 拿到后台进程 PID，之后精确管理
jobs                                      # 看当前 shell 的后台任务
kill $SIM_PID                             # 发 SIGTERM，请它优雅退出
kill -9 $SIM_PID                          # 强杀（SIGKILL，进程无法捕获）
kill -0 $ROBOTD_PID                       # 发 0 号信号：不真发，只探测进程是否存活
wait $SIM_PID                             # 等后台进程退出

这套组合拳是测试脚本的骨架技能：后台起被测程序 → $! 记 PID → kill -0 探活 → 结束 kill 收尸。e2e 脚本里 kill -9 还有一个巧妙用途——故意强杀 robotd 来验证 Broker 的 LWT 遗嘱消息是否生效（模拟进程崩溃的真实场景）。

【记忆口诀】命令加 & 后台跑，$! 把 PID 抓牢；-0 探活 -9 强杀，wait 送终少不了。

A.2.5 && 与 || 短路

grep -q 'reject_dup_seq' log && ok "重复 seq 被拒绝" || bad "未被拒绝"
grep -q 'S99robotd' /etc/init.d/rcS && { echo "已存在, 跳过"; exit 0; }   # 幂等守卫
mkdir -p build && cd build && cmake ..                                    # 串行依赖

a && b：a 成功才执行 b；a || b：a 失败才执行 b。注意陷阱：A && B || C 里如果 B 失败了也会执行 C，复杂逻辑还是用 if 清晰。

【记忆口诀】&& 是"成了再说"，|| 是"败了兜底"；一左一右夹中间，就是一行 if。

A.2.6 怎么写一条"断言"（e2e 脚本的灵魂）

作者 test_host_e2e.sh 的 20 项断言，模式完全一致，拆开看只有 4 个零件：

PASS=0; FAIL=0
say() { echo "---- $* ----"; }                       # ① 分节标题，讲清"现在测什么"
ok()  { PASS=$((PASS+1)); echo "  [通过] $*"; }      # ② 通过：计数+绿字
bad() { FAIL=$((FAIL+1)); echo "  [失败] $*"; }      # ③ 失败：计数+红字（不退出！）

# ④ 断言本体：一条"检查命令"接 && ok || bad
[ "$OUT" = "online" ] && ok "status=online" || bad "status=$OUT"
grep -q '急停' /tmp/sim_e2e.log && ok "模拟器收到急停帧" || bad "未收到"
[ "${N:-0}" -gt 0 ] && ok "$T 有 $N 行" || bad "$T 无数据"

# 收尾：汇总报告，并让脚本退出码反映整体成败
echo "======== 通过 $PASS 项, 失败 $FAIL 项 ========"
[ "$FAIL" -eq 0 ]          # 最后一行的退出码就是整个脚本的退出码

写断言的三层心法：

  1. 断言要断"可观测的事实"：MQTT 抓包内容、日志关键字、SQLite 行数、CAN 帧 ID——都是外部可查证的东西，而不是程序内部状态。
  2. 失败要继续跑：单条失败只记数不退出，跑完才能看到全部失败项，一次修多个问题。
  3. 退出码留给 CI：脚本最后用 [ "$FAIL" -eq 0 ] 把统计结果翻译成退出码，Jenkins/GitLab CI 只看这个码决定流水线红绿。

【记忆口诀】断言四件套：say 报幕、ok 记功、bad 记过、判断夹中间；失败不早退，退出码算总账。

A.2.7 日志打时间戳

log() { echo "[$(date '+%F %T')] $*" ; }
log "启动 robotd"
# 输出: [2026-05-20 14:33:07] 启动 robotd

ts_ms() { echo $(( $(date +%s) * 1000 )); }   # 毫秒时间戳（%3N 在 BusyBox 上不可靠，用秒×1000 代替）

长稳/老化测试的日志没有时间戳等于白跑——出问题后无法对时间线。板端 BusyBox 的 date 功能阉割较多， %3N（毫秒）常不可用，作者 e2e 脚本里就用了 $(date +%s) * 1000 的兜底写法。

【记忆口诀】日志不带时间戳，出事只能干瞪眼；板端没有 %3N，秒乘一千来救场。

A.2.8 trap 清理现场

cleanup() {
    kill "$ROBOTD_PID" 2>/dev/null
    wait "$ROBOTD_PID" 2>/dev/null
    kill "$SIM_PID" 2>/dev/null
    pkill -f 'mosquitto_sub.*robot_e2e' 2>/dev/null
}
trap cleanup EXIT      # 无论脚本正常结束、报错退出、被 Ctrl-C，都先执行 cleanup

没有 trap 的测试脚本，跑到一半 Ctrl-C 后会留下一堆僵尸进程：下次再跑端口被占、vcan 上幽灵帧乱飞，排查半天。trap 常见用法还有 trap 'echo 出错于第 $LINENO 行' ERR（配合 set -e 定位出错行）。

【记忆口诀】trap 是"善后条款"，EXIT 一到必执行；不留僵尸不留锁，下次开跑照样灵。

A.2.9 板端排查高频命令速查

嵌入式工程师在板端串口终端里最常敲的一组命令，面试"怎么排查 xxx 问题"时按这个清单答就有条理：

# 进程与资源
ps | grep robotd                    # 板端 BusyBox 的 ps 参数少，管道 grep 最通用
top -d 1                            # 动态看 CPU/内存
free                                # 内存余量（关注 available）
df -h                               # 分区占用（日志写爆 eMMC 是经典事故）
dmesg | tail -20                    # 内核最近日志（驱动加载、Oops 都在这里）

# 文件查找与体积
find / -name '*.ko' 2>/dev/null     # 全盘找驱动模块，错误信息丢进黑洞
du -sh /root/*                      # 看每个目录占多少，揪出日志元凶

# 网络与设备
ip addr / ip link                   # 网口与 CAN 口状态（BusyBox ip 阉割时项目里部署了完整版 iproute2）
cat /proc/version /proc/cpuinfo     # 内核版本、CPU 信息
ls /dev/ttyUSB* /dev/ttymxc*        # 确认串口设备节点存在

排查心法：先问"进程在不在"（ps），再问"资源够不够"（free/df），再问"内核说什么"（dmesg），最后问"日志说什么"（应用日志）——从系统层到应用层逐级缩小包围圈。

【记忆口诀】ps 问人在不在，free df 问粮饷；dmesg 听内核诉苦，日志再把细节讲。

A.2.10 脚本的可移植性陷阱（sh 与 bash 的分界线）

同一个脚本在宿主机跑得好好的，推到板端就报错，九成是踩了 bashisms（bash 专有语法）。作者在项目中严格遵守的分界线是：宿主机脚本用 bash（#!/bin/bash，可以用 [[ ]]），板端脚本用 POSIX sh（#!/bin/sh，只用 [ ]）。对照清单：

写法 bash BusyBox sh 建议
[[ $a == b* ]] ✔ ✘ 板端用 [ ] + case 通配
数组 a=(1 2 3) ✔ ✘ 板端用空格分隔字符串模拟
echo -e / echo -n ✔ 行为不一 用 printf 最稳
source file ✔ 部分支持 用 . file（点号）最通用
$RANDOM ✔ ✘ 用 $(date +%s) 等代替
function f {} ✔ ✘ 只写 f() {}

项目里的实例：deploy_board.sh、test_host_e2e.sh 跑在宿主机，用 bash；S99robotd、patch_board_rcs.sh 跑在板端，全部 POSIX 写法。面试被问"sh 和 bash 有什么区别"，答案就是：sh 是标准接口（POSIX），bash 是功能超集；板端 /bin/sh 通常是 BusyBox ash，只认标准那部分。

【记忆口诀】宿主机上 bash 敞开了写，板端只认 POSIX 那一页；双中括号、数组、RANDOM，过了串口全得戒。

A.3 完整实战脚本剖析：宿主机 e2e 测试脚本

scripts/test_host_e2e.sh 是作者项目里含金量最高的脚本：143 行，20 项断言，把"MQTT → robotd → CAN → SQLite"整条链路在宿主机上全自动验证一遍。它的骨架分六段，每一段都是可复用的模板：

第 1 段：环境设定与计数器

#!/bin/bash
set -u                              # 用 -u 不用 -e：断言失败要继续跑
cd "$(dirname "$0")/.."             # 不管在哪调用，都切到项目根目录

BROKER=127.0.0.1
CANIF=vcan0
DB=/tmp/robotd_e2e.db
PASS=0; FAIL=0

要点：cd "$(dirname "$0")/.." 是"脚本位置无关化"的标准写法——$0 是脚本自己的路径，dirname 取目录，切到上级即项目根。这样 bash scripts/test_host_e2e.sh 和 ./test_host_e2e.sh 行为一致。

第 2 段：trap 挂清理 + 清掉上次残留

trap cleanup EXIT                                    # 见 A.2.8
rm -f "$DB" "$DB-wal" "$DB-shm" /tmp/robotd_e2e.log /tmp/sim_e2e.log

每次跑测试前把旧数据库（含 SQLite 的 WAL/SHM 伴生文件）、旧日志删干净，保证断言看到的都是本次产生的数据——测试可重复性的前提。

第 3 段：搭环境（vcan + broker + 被测程序）

./build/host/stm32_sim $CANIF > /tmp/sim_e2e.log 2>&1 &     # CAN 对端模拟器
SIM_PID=$!
./build/host/robotd -b tcp://$BROKER:1883 -c $CANIF -d "$DB" -v \
    > /tmp/robotd_e2e.log 2>&1 &                            # 被测主程序
ROBOTD_PID=$!
sleep 2                                                     # 等初始化完成

宿主机联调的思想：vcan0 虚拟 CAN 替代真 CAN 卡，mosquitto 本地 broker 替代云 broker，stm32_sim 模拟下位机——整车上才有的链路，笔记本上 1:1 复刻。面试讲"没有硬件怎么开发调试"，这就是答案。

第 4 段：驱动 + 断言（脚本主体）

按真实场景顺序打组合拳，每条命令发出去后紧跟断言：

# ① 上线检查：retained 消息是 online
OUT=$(mosquitto_sub -h $BROKER -t robot/v1/car01/status -C 1 -W 2 2>/dev/null)
[ "$OUT" = "online" ] && ok "status=online" || bad "status=$OUT"

# ② 发 start，再发速度命令
mosquitto_pub -h $BROKER -t robot/v1/car01/cmd/velocity -q 1 \
    -m '{"version":1,"robot_id":"car01","seq":2,"timestamp_ms":0,
         "ttl_ms":0,"linear_v":0.5,"angular_w":0.3}'

# ③ 断言 CAN 总线上出现了预期帧（0x100 速度帧、0x700 心跳）
CANDUMP_OUT=$(timeout 1 candump $CANIF 2>/dev/null | head -200)
echo "$CANDUMP_OUT" | grep -q '100' && ok "vcan 上存在 0x100 CMD_VEL 帧" || bad "未捕获"

# ④ 负面用例：重复 seq 应被拒（防 QoS1 重发造成重复执行）
grep -q 'reject_dup_seq' /tmp/robotd_e2e.log && ok "重复 seq 被拒绝" || bad "未被拒绝"

# ⑤ 负面用例：过期 TTL 应被拒（构造 10 秒前的时间戳）
OLD_TS=$(( $(date +%s) * 1000 - 10000 ))
...
grep -q 'reject_expired' /tmp/robotd_e2e.log && ok "过期命令被拒绝" || bad "未拒绝"

注意这里的断言渠道有四种，覆盖系统不同侧面：

断言渠道 验证什么 例子
MQTT 抓包（mosquitto_sub） 对外协议行为 status=online/offline
被测程序日志（grep） 内部判断逻辑生效 reject_dup_seq / reject_expired
CAN 抓包（candump） 总线层输出 0x100 速度帧、0x060 急停帧
SQLite 查询 持久化正确 5 张表都有数据

第 5 段：查持久化

sleep 6          # robotd 批量落盘，先等它写完
for T in cmd_log state_log event_log perf_log rl_transition_raw; do
    N=$(sqlite3 "$DB" "SELECT COUNT(*) FROM $T" 2>/dev/null)
    [ "${N:-0}" -gt 0 ] && ok "$T 有 $N 行" || bad "$T 无数据"
done

${N:-0} 的细节：表不存在时 sqlite3 输出为空，N 是空串，[ "" -gt 0 ] 会报语法错误，给个默认值 0 兜底——这就是 A.1.2 说的 ${var:-默认} 实战。

第 6 段：优雅退出 + 崩溃路径，双验证

# 正常路径：SIGTERM 后应自己退出，且 broker 上状态变 offline
kill -TERM "$ROBOTD_PID"; sleep 2
kill -0 "$ROBOTD_PID" 2>/dev/null && bad "robotd 未退出" || ok "已优雅退出"
[ "$(mosquitto_sub ... -W 2)" = "offline" ] && ok "status=offline" || bad ...

# 崩溃路径：kill -9 强杀，靠 Broker 的 LWT 遗嘱补发 offline
./build/host/robotd ... &  ROBOTD_PID=$!
kill -9 "$ROBOTD_PID"
sleep 12                   # keepalive 10s，约 1.5 倍时间内 LWT 触发
[ "$(mosquitto_sub ...)" = "offline" ] && ok "LWT offline 生效" || bad "LWT 未生效"

这段是面试高光点：不仅测"好好退出"，还测"突然暴毙"——kill -9 模拟进程崩溃，验证 MQTT LWT（Last Will）机制兜底，这正是物联网系统可靠性的核心设计。

收尾

echo "======== 通过 $PASS 项, 失败 $FAIL 项 ========"
[ "$FAIL" -eq 0 ]     # 退出码交给 CI

整个脚本面试时可以这样概括："一个 trap 保清理，两种退出路径（优雅/崩溃）都验证，四种断言渠道（MQTT/日志/CAN/SQLite）交叉确认，20 项断言跑完退出码说话。"

【记忆口诀】先清场，再搭台；发命令，马上断；正常退、强杀崩，两条路径都验完；退出码，给 CI 看。

A.4 Python 嵌入式开发速查

A.4.1 为什么嵌入式工程师要会 Python

一句话：C 写产品，Python 写工具。嵌入式工程师的日常里，大量工作不是写固件，而是写"一次性但救命"的工具：

  • 串口传文件到开发板（serial_push.py）
  • PC 遥控上位机联调（pc_controller.py）
  • 解析日志/抓包文件，统计错误
  • 生成代码或配置（gen_compile_commands.py 生成 clangd 索引）
  • 自动化测试、协议模拟器、AI 智能体（embedded-agent）

这些用 C 写要几百行还要编译，用 Python 几十行就跑。面试官问"会 Python 吗"，期待的不是你背语法，而是你说出"我用它做过什么工具"。

【记忆口诀】C 是产品的砖，Python 是开发的胶；产品里面没有它，开发过程离不了。

A.4.2 venv 与 pip：环境隔离两件套

python3 -m venv .venv          # 创建虚拟环境（一个项目一个独立环境）
source .venv/bin/activate      # 激活（之后 pip 装的包只进这个环境）
pip install pyserial paho-mqtt # 装依赖
pip freeze > requirements.txt  # 导出依赖清单，别人一键复现
deactivate                     # 退出

不隔离的后果：A 项目要 pyserial 3.4，B 项目要 3.5，系统 Python 被搅成一锅粥。venv 就是"每个项目一个独立工具箱"。

【记忆口诀】venv 一间房，pip 往里装；freeze 开清单，换机不重忙。

A.4.3 pyserial 串口收发：完整示例（serial_push.py 思路）

最小收发骨架：

import serial

port = serial.Serial("/dev/ttyUSB0", 115200, timeout=0.2)  # 端口、波特率、读超时
port.write(b"AT\r\n")          # 发：必须是 bytes
data = port.read(64)           # 读：最多 64 字节，超时返回已读到的
line = port.readline()         # 读到 \n 为止
print(data.decode(errors="replace"))
port.close()

真实项目怎么用它传文件（tools/serial_push.py，把宿主机文件经串口 shell 推到板端）：

import argparse, base64, hashlib, sys, time
import serial

def wait_marker(port, marker: bytes, timeout: float) -> bytes:
    """读串口直到出现 marker 或超时——逐包同步的核心。"""
    buf = bytearray()
    deadline = time.monotonic() + timeout
    while time.monotonic() < deadline:
        data = port.read(port.in_waiting or 1)
        if data:
            buf.extend(data)
            if marker in buf:
                break
    return bytes(buf)

def run_cmd(port, cmd: str, timeout: float = 10.0) -> bytes:
    """发一条 shell 命令，靠"结束标记"判断执行完——这就是简化版逐包 ACK。"""
    marker = b"__PUSH_DONE__"
    port.write(cmd.encode() + b"; echo " + marker + b"$?\n")
    port.flush()
    return wait_marker(port, marker, timeout)

整体传输协议（自己设计一个"穷人版 XMODEM"）：

  1. 编码：本地 base64.b64encode(raw)，二进制变纯文本——串口 shell 链路只敢传可打印字符（否则控制字符会被终端吃掉）。
  2. 分块发送：每 256 字符拼成一条 echo -n '...' >> file.tmp 命令发过去，块间 sleep(0.03) pacing 防冲爆板端缓冲。
  3. 流控与清理：先连发 3 个 \x03（Ctrl-C）杀掉板端残留进程；stty -echo ixon ixoff 关回显、开 XON/XOFF 软件流控。
  4. 解码与校验：板端 base64 -d 解码，再 md5sum 和本地 MD5 比对，不等则报错保留现场。
  5. 正式落位：校验通过才 mv 到目标路径并 chmod 755——先 .tmp 再 mv 是"原子替换"思想，断电也不会留半个文件。

经典 XMODEM 的思路一样：分包 → 每包校验（CRC）→ 收 ACK 再发下一包 → 全部传完总校验。serial_push 用"echo 标记"当 ACK、md5 当总校验，思想同源。面试被问"怎么在不可靠链路上可靠传文件"，答这套分包+校验+确认+重试的框架即可。

【记忆口诀】大包切小块，块块有回音；回显先关掉，流控别忘记；末了算 MD5，对不上就重提。

A.4.4 paho-mqtt / subprocess：PC 键盘遥控上位机（pc_controller.py 思路）

作者的上位机其实用了两种发 MQTT 的方式，都该会。

方式一：paho-mqtt 库（标准姿势）

import json, time
import paho.mqtt.client as mqtt

client = mqtt.Client()
client.username_pw_set("robot", "xxx")
client.connect("47.109.91.11", 1883, keepalive=10)

def now_ms():
    return int(time.time() * 1000)

seq = 0
def send_velocity(v, w):
    global seq
    seq += 1
    payload = {"version": 1, "robot_id": "car01", "seq": seq,
               "timestamp_ms": now_ms(), "ttl_ms": 500,
               "linear_v": v, "angular_w": w}
    client.publish("robot/v1/car01/cmd/velocity", json.dumps(payload), qos=1)

方式二：subprocess 调 mosquitto_pub（pc_controller.py 的真实选择）

import subprocess, json

def pub(broker, robot_id, topic, payload, user="", password=""):
    cmd = ["mosquitto_pub", "-h", broker,
           "-t", f"robot/v1/{robot_id}/{topic}",
           "-q", "1", "-m", json.dumps(payload)]
    if user:                                   # 有认证就插到最前面
        cmd[1:1] = ["-u", user, "-P", password]
    subprocess.run(cmd, check=False,
                   stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

为什么选方式二？零依赖——联调现场任何装了 mosquitto-clients 的机器都能跑，不用 pip install。缺点是没连接状态，每条消息都是一次性短连接。面试答法：两种方式我都会，讲得出取舍。

键盘即按即得 + 10Hz 心跳帧（上位机主循环精髓）：

import sys, termios, tty, select, time

fd = sys.stdin.fileno()
old = termios.tcgetattr(fd)
tty.setcbreak(fd)                       # 终端设非规范模式：不用回车，按键立即可读
try:
    while not quit:
        if select.select([sys.stdin], [], [], 0.02)[0]:   # 非阻塞等按键 20ms
            ch = sys.stdin.read(1).lower()
            handle_key(ch)              # w/s 加减线速度，a/d 加减角速度，空格停车，e 急停
        send_velocity(v, w)             # 不管按没按，10Hz 持续发速度帧
        time.sleep(0.08)
finally:
    termios.tcsetattr(fd, termios.TCSADRAIN, old)         # 退出必恢复终端！

设计要点（全是面试素材）：seq 单调递增防 QoS1 重发重复执行；每帧带 ttl_ms=500，robotd 收到延迟超 500ms 的帧直接丢弃；上位机断线后 STM32 侧 500ms 看门狗自动停车——层层超时兜底，没有一个环节靠"应该没问题"。

【记忆口诀】按键 cbreak 即按即得，select 轮询不阻塞；十赫兹心跳一直发，seq 递增 TTL 卡；断线看门狗来刹车。

A.4.5 struct 模块：打包/解析二进制（模拟 CAN 帧）

嵌入式脚本经常要和二进制协议打交道，struct 是标准库里的打包解包工具：

import struct

# 打包：模拟一帧 CAN 数据 —— int16 目标速度(mm/s) + int16 角速度(mrad/s) + uint32 时间戳
data = struct.pack("<hhI", 500, 300, 1710000)
# 格式串: "<"小端  h=int16  h=int16  I=uint32 → 共 8 字节，正好一帧 CAN DLC=8

# 解包：收到一帧，按同样布局拆出来
v, w, ts = struct.unpack("<hhI", data)
print(v, w, ts)        # 500 300 1710000

# 常用格式符
# < 小端  > 大端  = 本机原生
# b int8  B uint8  h int16  H uint16  i int32  I uint32  q int64  f float  d double

字节序是必考点："<h" 小端把 0x01F4(500) 存成 F4 01（低字节在前），">h" 存成 01 F4。x86/ARM 默认小端，CAN/网络协议常在帧格式里规定字节序，打包解包两边必须一致。曾经踩过的典型坑：MCU 端 C 结构体直接 memcpy 发送，上位机按另一套对齐/字节序解析，数据全错位——协议要用 struct.pack 显式定义，不要依赖结构体内存布局（C 结构体有对齐填充！）。

【记忆口诀】小于号低字节先走，h 两字节 I 四字节凑；打包解包同一格式串，字节序不对全乱套。

A.4.6 argparse / json / subprocess / logging：工具脚本四件宝

argparse——命令行参数（serial_push.py 真实用法）：

import argparse
parser = argparse.ArgumentParser(description="串口传输文件到开发板")
parser.add_argument("src", help="本地文件")                    # 位置参数，必填
parser.add_argument("dst", help="开发板目标路径")
parser.add_argument("--port", default="/dev/ttyUSB0")          # 可选参数，有默认
parser.add_argument("--baud", type=int, default=115200)        # type 自动转 int
args = parser.parse_args()
# 自动生成 -h 帮助、自动校验参数个数——比手写 sys.argv 解析体面一百倍

json——和 MQTT/REST 打交道必备：

import json
s = json.dumps({"seq": 1, "v": 0.5}, ensure_ascii=False)   # dict → 字符串（发 MQTT）
d = json.loads('{"seq":1,"v":0.5}')                         # 字符串 → dict（收 MQTT）

subprocess——调外部命令（部署脚本里调 cansend、调 ssh）：

import subprocess
r = subprocess.run(["candump", "vcan0"], capture_output=True, text=True, timeout=5)
print(r.returncode, r.stdout)          # 拿退出码和输出
# check=True 时命令失败直接抛异常；shell=True 能写管道但慎用（注入风险）

logging——别再 print 调试了：

import logging
logging.basicConfig(level=logging.INFO,
                    format="%(asctime)s [%(levelname)s] %(message)s")
log = logging.getLogger("push")
log.info("开始传输 %s", path)          # 自带时间戳、级别，可一键切 DEBUG

【记忆口诀】argparse 管进门，json 管翻译，subprocess 管叫人，logging 管记账。

A.4.7 Python 基础语法五分钟速览（给纯零基础读者）

如果之前完全没写过 Python，先记住这几条就能看懂本篇所有示例：

# 变量不用声明类型，注释用 #
name = "robotd"
count = 20

# 缩进就是代码块（通常 4 个空格），没有大括号
if count > 0:
    print("有数据")          # print 是输出
else:
    print("空的")

# 列表（数组）和字典（键值对）
tables = ["cmd_log", "state_log"]        # 列表
cfg = {"seq": 1, "v": 0.5}               # 字典，对应 JSON 对象
for t in tables:                          # 遍历列表
    print(t)
print(cfg["seq"])                         # 按键取值

# 函数：def 定义，return 返回
def now_ms():
    import time
    return int(time.time() * 1000)

# 字符串格式化：f-string 最常用（f 开头的字符串里 {} 直接写变量）
print(f"已发送 {count}/{total} ({count*100//total}%)")

# 导入库：import 放文件顶部，第三方库先 pip install
import json            # 标准库，自带
import serial          # 第三方库 pyserial，要先装

和 C 的对照感受：没有分号、没有大括号、没有 main 也能跑；if __name__ == "__main__": 这行的作用是"直接运行本文件时才执行，被别人 import 时不执行"——工具脚本的标准收尾。

【记忆口诀】缩进即括号，分号全丢掉；列表方括号，字典花括号；f 串插值快，def 把函数造。

A.4.8 一个真实工具的样子：gen_compile_commands.py

项目里还有一个典型的小工具 tools/gen_compile_commands.py：交叉编译时 Makefile 用的是 arm-linux-gnueabihf-gcc，宿主机上的 clangd（编辑器代码补全引擎）看不懂，于是用 Python 扫一遍构建日志，生成 compile_commands.json，让 clangd 正确解析头文件路径和宏定义。这类"几十行 Python 解决一个具体痛点"的脚本，是简历上"熟练使用 Python 开发工具链"的真实注脚——面试别只说"会 Python"，要说"我用 Python 做过串口传文件、键盘遥控、编译数据库生成、自动化验证"。

【记忆口诀】小工具不嫌小，解决痛点就是宝；面试别背 hello world，掏出真家伙才算好。

A.5 Python 在 AI 智能体项目中的应用

为什么 embedded-agent 智能体整体选 Python？ 三个理由，面试可直接用：

  1. LLM 生态全在 Python：OpenAI/Anthropic/各家国产大模型的官方 SDK 都是 Python 首发，调模型、流式输出、工具调用（function calling）开箱即用。
  2. 文档解析库现成：嵌入式知识库要啃 datasheet、原理图 PDF、Markdown 手册，pypdf、python-docx、markdown 等库拿来就用，C/C++ 干这个得造半年轮子。
  3. 胶水能力强：智能体要串起"调 LLM → 读文档 → 跑串口验证 → 读写文件 → 调编译器"，Python 的 subprocess/pyserial/文件 API 把这些串成一个流水线，代码量最小。

一句话介绍流水线模块划分（面试话术）：embedded-agent 按"感知—决策—执行—验证"分层——文档解析模块把芯片手册/项目文档切块建索引；流水线调度模块编排多轮 LLM 调用（生成代码/生成文档/生成测试）；串口验证模块复用 pyserial 思路，把生成的固件或脚本推到板端跑起来、抓回输出做断言，形成"生成→部署→验证"的闭环。每一层都是纯 Python，模块间用普通函数调用和 JSON 数据传递。

这个项目本身证明了 A.4.1 那句话：产品固件是 C（robotd 跑在 i.MX6ULL 上），但围绕产品的工具链、测试链、智能体全部是 Shell + Python——嵌入式工程师的"全栈"，一半在脚本里。面试被问"AI 对嵌入式开发有什么改变"时，这套组合也是很好的回答素材：模型负责生成与推理，Python 负责连接现实世界（串口、总线、文件系统），Shell 负责把流程固化成可重复的流水线，三者各就其位，工程师的价值则体现在定义验证标准和把关生成的结果上。

【记忆口诀】模型 SDK 在 Python，文档解析轮子全；胶水一粘流水线，生成验证成闭环。

A.6 面试高频问答

Q1：$? 是什么？

上一条命令的退出码，0 表示成功，非 0 表示失败。它是 Shell 里一切条件判断和断言的地基：grep -q xxx log && ok || bad 判断的就是 grep 的退出码；if cmd; then 也是看退出码。注意它只保留"上一条"，连着两条命令后取到的就是第二条的结果。

Q2：单引号和双引号有什么区别？

双引号内 $变量、$(命令) 会展开，单引号内一切原样输出。实战推论：要展开用双引号，要保护特殊字符（密码、正则、JSON）用单引号，取值默认加双引号防空格分词。

Q3：set -euo pipefail 干什么用？

三个安全开关：-e 任一命令失败立即退出（防止错误滚雪球，比如编译失败后还继续打包）；-u 引用未定义变量直接报错（防 rm -rf $TYP O/ 拼写事故）；-o pipefail 管道中任何一环失败都算失败（默认只看最后一环，cmd | grep 里 cmd 崩了也发现不了）。但测试脚本往往故意不带 -e，因为断言失败要继续跑完收集完整报告。

Q4：grep、awk、sed 怎么分工？

grep 按正则筛行（找"有没有"、-c 数次数）；awk 按列处理结构化文本（取第 N 列、求和、做浮点计算——shell 本身不会浮点）；sed 做流编辑（替换、删除、插入行，-i 原地改文件）。组合例子：candump vcan0 | grep '100' | awk '{print $3}'——先筛出 0x100 帧，再取数据段列。

Q5：pyserial 怎么收发串口数据？

serial.Serial(port, baudrate, timeout=...) 打开；write(bytes) 发（必须 bytes，str 要 .encode()）；read(n) 读 n 字节（超时返回已读到的）、readline() 读到换行；in_waiting 查缓冲区已有多少字节。工程上做可靠传输要加分包、结束标记/ACK、md5 校验、流控（XON/XOFF），如 serial_push.py 的 base64 分块 + echo 标记 + md5 比对方案。

Q6：struct 打包时字节序怎么控制？

格式串首字符决定："<" 小端（低字节在前，x86/ARM 原生）、">" 大端（网络字节序）。例：struct.pack("<hI", 500, 1000) 是 int16+uint32 小端共 6 字节。核心原则：打包和解包必须用同一格式串；跨平台协议要显式写死字节序，不能依赖 C 结构体的内存布局（有对齐填充、字节序随平台）。

Q7：为什么测试要用脚本自动化？

① 可重复：一条命令跑 20 项断言，人手工点半小时还容易漏；② 进 CI：脚本退出码直接决定流水线红绿，每次提交自动回归；③ 覆盖负面路径：脚本可以稳定复现"重复 seq、过期 TTL、kill -9 崩溃"这类手工很难做全的用例；④ 留证据：日志+报告天然是面试/评审时的成果展示。我项目里 e2e 脚本 143 行覆盖 20 项断言，宿主机无硬件就能跑全链路，这就是价值。

Q8：>/dev/null 2>&1 是什么？为什么顺序不能反？

把标准输出（1）重定向到 /dev/null（丢弃），再把标准错误（2）重定向到"当前 1 指向的地方"（也是 /dev/null）——合起来丢弃全部输出，只要退出码。顺序反了（2>&1 >/dev/null）时，2 先指向 1 当时的目标（终端），之后 1 改指 null 不影响 2，结果错误信息还是打到屏幕上。重定向是从左到右依次生效的。

【记忆口诀】八字面试题：问号问成败，引号辨展开；set 三保险，三斧各管块；串口要 ACK，struct 定序排；脚本为自动，重定向从左来。

继续阅读

正点原子 I.MX6ULL MINI 开发板学习笔记：Linux 驱动架构详解——编译、树内树外与运行时效果

这是 Linux 驱动小系列的总结篇。前三篇把 LED 驱动从内核模块写到 misc 设备，属于“会用”；这篇把背后的架构讲透：驱动到底怎么编译、内核树内和树外两种方式的区别、以及驱动里每个操作在系统跑起来之后到底产生了什么效果。内容整理自我的学习笔记（note.pdf）和实际工程 code/2026/20260803。 1. 驱动代码到底怎么编译的？ 不管哪种方式，最终都靠内核的 kbuild 系统。核心就三个文件的关系： * Kconfig：定义 menuconfig 里的选项（如 CONFIG_MYMODULE），三态 y/m/n——y 编进内核，m 编成模块，n 不编； * .config：menuconfig 的选择结果，保存在源码顶层； * Makefile：

作者：azhezhezhe

正点原子 I.MX6ULL MINI 开发板学习笔记：misc 设备——字符设备驱动的快捷方式

上两篇分别用手动 mknod 和 class_create+device_create 注册字符设备，调用链一长串。这篇用 misc（混杂）设备 一步搞定。代码来自实际工程 code/2026/20260803/05_misc_led，已验证可用。 1. 完成什么实验？ 用 misc_register 重写 LED 驱动：一步完成设备号分配、字符设备注册、/dev/myled0 节点创建，同时保留上一篇的 sysfs 属性 led_status。 2. 什么是 misc 设备？ misc（混杂）设备是 Linux 给“不好归类的小字符设备”

作者：azhezhezhe

正点原子 I.MX6ULL MINI 开发板学习笔记：自动创建 /dev 节点与 sysfs 属性

上一篇的 LED 驱动还要手动 mknod 才能用。这篇在同一驱动上加两步：用 class_create + device_create 让内核自动生成 /dev 节点，再挂一个 sysfs 属性文件，用 cat/echo 就能看灯、控灯。代码来自实际工程 code/2026/20260803/04_led_sys，已验证可用。 1. 完成什么实验？ 在 LED 字符设备驱动基础上：insmod 后自动生成 /dev/myled0（不再手动 mknod）；同时在 /sys/class/LED/myled0/ 下挂出 led_status 属性文件，

作者：azhezhezhe