企业官网建设流程全解析

1. 项目概述与核心价值

最近在帮团队筛选简历和面试新人，发现一个挺有意思的现象：很多简历上写着“精通STM32”的候选人，一聊到具体的技术细节和项目难点，回答就变得含糊其辞。这让我意识到，一份好的嵌入式工程师面试题集，尤其是针对STM32这类主流MCU的，其价值远不止于“题库”本身。它更像是一张地图，清晰地标出了从“会用库函数”到“真正理解底层”所需要跨越的每一个技术沟壑。这份《嵌入式工程师面试题集-MCU_STM32》的整理，正是源于这个目的——它不是用来死记硬背的“八股文”，而是希望通过对典型问题的深度剖析，串联起STM32开发中那些必须掌握的核心知识点、设计思维和排错能力。

对于正在准备面试的工程师来说，这份题集能帮你系统性地查漏补缺，知道面试官可能会从哪个角度切入来考察你的真实水平。对于面试官而言，它提供了一套相对客观的评估框架，能更高效地甄别出候选人是“项目经历丰富”还是“代码搬运工”。无论是GPIO的推挽开漏配置、中断嵌套的优先级管理，还是DMA传输的链路设计、低功耗模式的唤醒策略，每一个问题背后，都对应着实际产品开发中可能遇到的真实挑战。接下来，我们就抛开泛泛而谈，直接切入STM32技术栈的各个核心层面，看看那些真正决定你技术深度的面试问题都长什么样，以及该如何理解它们。

2. 硬件与基础外设深度解析

2.1 GPIO配置的“为什么”而不仅仅是“怎么配”

几乎所有STM32面试都会从GPIO开始，但高手和新手的回答层次截然不同。新手可能只会说“调用HAL_GPIO_Init，设置引脚、模式、上下拉”。而资深面试官想听到的，是你对每一种模式应用场景的深刻理解。

推挽输出 vs. 开漏输出：这绝对是一个高频考点。推挽输出（Push-Pull）的优势在于它能主动输出高电平和低电平，驱动能力强，适合直接驱动LED、继电器等负载。但它的关键点在于，两个推挽的MOS管不能同时导通，否则会造成电源到地的短路，产生大电流。开漏输出（Open-Drain）则不同，它只能主动拉低到地，高电平状态需要依靠外部上拉电阻来实现。这种模式的核心价值有两个：一是便于实现“线与”逻辑，多个开漏输出的引脚可以直接连在一起，任何一个拉低，总线就是低电平，这在I2C总线中至关重要；二是可以实现电平转换，例如用3.3V的STM32通过开漏输出和上拉电阻，去驱动5V器件的高电平识别。

注意：在配置开漏输出且需要读取引脚电平时，必须开启内部上拉或连接外部上拉电阻，否则引脚会处于浮空状态，读取的值是不确定的。这是一个非常实际的坑。

上下拉电阻的选用逻辑：上拉或下拉电阻的配置，根本目的是为了在引脚空闲（未主动驱动）时，给它一个确定的电平状态，防止因静电或干扰产生误触发。例如，一个连接到按键的输入引脚，通常配置为上拉输入。按键未按下时，引脚被拉至高电平；按键按下时，引脚被接至地，变为低电平。如果不配置上拉，引脚悬空，其电平是浮动的，读取的值会随机跳动。对于输出模式，推挽输出一般不需要上下拉，因为MOS管能稳定驱动高低电平；而开漏输出高电平状态依赖上拉，所以必须配置。

2.2 中断系统：从NVIC到优先级抢占的完整链条

中断是MCU响应异步事件的核心机制，理解中断的全流程是嵌入式工程师的基本功。面试时，你需要清晰地描述从事件发生到中断服务函数（ISR）执行完毕的整个过程。

中断向量表与NVIC：当某个外设（如定时器、USART）的事件触发中断时，硬件会生成一个特定的中断请求（IRQ）。STM32内核（Cortex-M）通过嵌套向量中断控制器（NVIC）来管理所有中断。NVIC负责中断的使能、禁用、优先级管理和挂起状态查询。每个中断源在启动文件（如startup_stm32fxxx.s）中定义的中断向量表里都有一个固定的入口地址。中断发生后，CPU会暂停当前任务，保存现场（压栈），然后根据中断号跳转到对应的ISR入口地址开始执行。

优先级分组与抢占：这是中断问题的难点和重点。Cortex-M的优先级分为抢占优先级（Preemption Priority）和子优先级（Subpriority，或称响应优先级）。通过HAL_NVIC_SetPriorityGrouping函数设置优先级分组，来决定多少位用于抢占优先级，多少位用于子优先级。抢占优先级高的中断可以打断正在执行的、抢占优先级低的中断，形成中断嵌套。子优先级则用于当两个中断同时发生且抢占优先级相同时，决定谁先被响应；但子优先级不能构成嵌套。

一个常见的面试场景是：“如果一个高抢占优先级的中断ISR执行时间很长，会对系统有什么影响？” 答案是：它会阻塞所有低优先级中断的响应，导致系统实时性下降。因此，ISR的设计原则是“快进快出”，只做最紧急的状态处理（如清除标志、读取数据），将耗时的运算或处理转移到主循环或任务中。

实操心得：在复杂系统中，务必规划好中断优先级。将最紧急、最不可延迟的事件（如看门狗喂狗、安全故障）设为最高抢占优先级。通信中断（如UART DMA传输完成）可以设为中等。注意，SYSTick（系统滴答定时器）中断的优先级通常不能设得太高，否则它会频繁打断其他重要任务。

3. 通信协议与高级外设实战要点

3.1 UART通信中的稳定性设计陷阱

UART看似简单，但在高速或干扰环境下，要保证稳定可靠，细节非常多。面试官常会问：“如何提高UART通信的可靠性？”

首先，波特率误差是关键。STM32的USART波特率由APB总线时钟分频得到。计算出的波特率寄存器值可能不是整数，从而产生误差。误差过大会导致数据错位。标准是误差应控制在2.5%以内（低速时可放宽，115200及以上必须严格）。在代码中，应该计算实际配置产生的波特率，并与目标值比较。

其次，硬件流控制（RTS/CTS）的使用场景。当发送和接收设备处理速度不匹配时（例如MCU通过UART向蓝牙模块高速发送数据），就需要流控制。RTS（请求发送）和CTS（清除发送）是一对硬件握手信号。启用CTS流控后，发送方会在发送前检查CTS引脚电平，只有为低电平（表示接收方准备好）时才发送。这能有效防止因接收缓冲区满而导致的数据丢失。

第三，是中断与DMA的配合。对于不定长数据接收，经典做法是使用“空闲中断”（Idle Interrupt）。当UART总线在一帧数据后出现一个字节的空闲时间时，会触发此中断。在中断中，我们可以知道一包数据已经接收完毕，然后进行处理。更高效的方式是结合DMA：将UART接收配置为DMA循环模式，指向一个环形缓冲区。使能空闲中断。当空闲中断发生时，根据DMA的传输计数器（CNDTR）计算出本次接收到的数据长度，然后进行解包。这种方式几乎不占用CPU资源。

避坑指南：使用空闲中断时，务必注意在中断服务函数中读取USARTx->SR寄存器中的IDLE标志位，并通过读USARTx->DR来清除该标志（HAL库中调用__HAL_UART_CLEAR_IDLEFLAG）。否则，中断会持续触发。

3.2 SPI全双工通信的时钟相位与极性配置

SPI的时钟极性（CPOL）和时钟相位（CPHA）配置是面试中的经典问题，光记住0和1的组合没用，必须理解其物理意义。

CPOL（Clock Polarity）：决定了SCK时钟线在空闲时的状态。CPOL=0表示空闲时为低电平；CPOL=1表示空闲时为高电平。CPHA（Clock Phase）：决定了数据在时钟的哪个边沿被采样。CPHA=0表示在时钟的第一个边沿（如果CPOL=0，就是上升沿；CPOL=1，就是下降沿）采样；CPHA=1表示在时钟的第二个边沿采样。

关键在于，主设备和从设备的（CPOL， CPHA）模式必须完全一致，否则数据会错位。通常从设备（如传感器、Flash芯片）的模式是固定的，我们需要根据其数据手册来配置主设备STM32的模式。

一个高级技巧是关于SPI的NSS引脚管理：对于单主单从系统，可以将NSS（片选）引脚配置为软件管理（NSS = Soft），并用一个普通的GPIO来控制。这样更灵活。但在多从机系统中，或者某些特定的从设备要求严格的NSS时序时，就需要使用硬件NSS。硬件NSS模式下，发送开始时NSS自动拉低，发送完成后自动拉高。要注意的是，在全双工通信中，有时为了连续传输多帧数据而不希望NSS在中间变高，就需要将SPI配置为NSS = Hard Output，然后手动控制该引脚。

实操记录：我曾调试过一个SPI Flash，发现读写数据总是不对。最后发现是CPHA配置错了。从设备手册上明确写着“数据在时钟上升沿被采样”，根据这个描述，应该是第一个边沿采样，所以CPHA=0。再结合其空闲时SCK为低（CPOL=0），最终模式应为Mode 0（CPOL=0， CPHA=0）。这个案例说明，一定要结合波形图来理解数据手册的文字描述。

4. 定时器与时钟系统的复杂应用

4.1 定时器编码器模式与输入捕获的差异辨析

定时器是STM32中最灵活也最复杂的外设之一。面试中经常需要区分编码器模式和输入捕获模式，因为它们都用于测量信号。

输入捕获模式：主要用于测量单个脉冲信号的参数，如周期、占空比、频率。其原理是，在输入信号的边沿（上升沿、下降沿或双边沿）触发时，将当前定时器的计数器值（CNT）锁存到捕获/比较寄存器（CCRx）中。通过计算两次捕获值之差，再乘以计数周期，就能得到脉冲的时间宽度。它更侧重于“测量”一个已知或未知信号的时序参数。

编码器模式：则是专门用于读取正交编码器（如电机上的光电编码器）的信号。它需要占用定时器的两个通道（TI1和TI2），分别接编码器的A相和B相。在此模式下，定时器的计数器CNT会根据两个输入信号的边沿和相位关系自动进行递增或递减计数。例如，设置仅在TI1的上升沿计数，那么当A相超前B相时（正转），CNT递增；当B相超前A相时（反转），CNT递减。这样，CNT的值就直接反映了编码器的位置和方向。它更侧重于“跟踪”一个连续运动的位置和速度。

应用场景选择：如果你想测量一个开关按键按下的持续时间，用输入捕获。如果你想获取直流电机的转速和转向，用编码器模式接光电编码器。有时两者可以结合，例如用高级定时器的编码器模式获取电机位置，同时用另一个通用定时器的输入捕获模式来测量速度反馈信号的频率。

4.2 高级定时器生成互补PWM与死区插入

在电机控制、电源逆变等场合，需要生成一对互补的PWM信号（如H桥的上管和下管驱动信号），并且为了防止上下管同时导通（直通短路），必须在两路互补信号之间插入一段“死区时间”。

STM32的高级定时器（如TIM1， TIM8）硬件支持此功能。你需要配置定时器为PWM模式1或2，并输出到两个互补通道（如CH1和CH1N）。关键步骤在于死区时间的配置。

死区时间通过TIMx->BDTR寄存器的DTG位来设置。这个时间是基于定时器时钟的一个延迟。计算死区时间T_dtg的公式相对复杂，取决于DTG[7:5]的值，但HAL库提供了HAL_TIMEx_ConfigBreakDeadTime函数来简化配置，你只需要传入一个TIM_BreakDeadTimeConfigTypeDef结构体，在其中设置DeadTime参数（单位可以是微秒或时钟周期数）。

配置要点：

1. 使能互补输出（TIMx->CCER寄存器中的CCxNE位）。
2. 使能死区（TIMx->BDTR寄存器中的MOE、OSSI等位，通常通过库函数整体配置）。
3. 根据你使用的驱动芯片或MOSFET的开关特性，计算所需的死区时间。这个时间必须大于功率器件的开通延迟与关断延迟之差，以确保一个完全关断后，另一个才开通。
4. 刹车功能（Break）通常与死区配置在一起，用于在过流等故障时快速关闭PWM输出，保护电路。

一个真实的调试案例：在调试一个电机驱动器时，发现MOSFET发热严重。用示波器测量互补的PWM信号，发现死区时间不足，存在非常短暂的上下管同时导通的现象，导致直通电流。通过增大DeadTime参数，发热问题立刻得到缓解。这说明了硬件死区功能的重要性，它比软件延时更精确、更可靠。

5. DMA与内存管理的核心机制

5.1 DMA传输模式与循环缓冲区的实战应用

DMA是解放CPU、提高系统效率的利器。面试中常问及不同传输模式的区别和应用。

普通模式 vs. 循环模式：

• 普通模式：DMA传输完预设的数据量后，就自动停止，传输完成中断标志位被置起。需要软件重新配置参数才能启动下一次传输。适用于已知长度的单次数据传输，如从Flash拷贝一段固定长度的数据到RAM。
• 循环模式：DMA传输完预设的数据量后，硬件自动将传输计数器（CNDTR）和内存地址指针重置为初始值，然后重新开始传输，周而复始。适用于需要持续不断更新数据的场景，最典型的就是ADC的连续扫描。将ADC配置为连续转换，DMA配置为循环模式，指向一个数组。这样，ADC转换的结果就会自动、不断地填充到这个数组中，形成一个最新的数据窗口，CPU可以随时来读取这个数组进行处理，无需频繁启动/停止DMA。

双缓冲区模式：这是循环模式的一个高级变种。DMA会交替使用两个缓冲区（Buffer0和Buffer1）。当其中一个缓冲区（比如Buffer0）被DMA写满时，不仅会触发传输完成中断，还会自动切换到另一个缓冲区（Buffer1）继续写入。在中断里，CPU可以安全地处理已经写满的Buffer0的数据，而不会与DMA正在写入的Buffer1冲突。这完美解决了数据处理速度跟不上数据采集速度时的数据覆盖问题。在HAL库中，可以通过HAL_DMAEx_MultiBufferStart_IT函数来启用。

内存到内存的DMA应用：除了外设到内存，STM32的DMA也支持内存到内存的传输。这在需要搬运大量数据时非常高效，比如图像处理中拷贝一块显存。注意，内存到内存传输通常使用DMA2，且没有外设流控，传输速率取决于系统总线带宽。

5.2 内存对齐与__attribute__((packed))的取舍

在涉及DMA、通信协议（如结构体打包发送）时，内存对齐问题会突然跳出来给你制造麻烦。C编译器为了优化访问速度，默认会对结构体成员进行内存对齐。例如，在一个32位系统上，一个uint8_t变量可能仍然占用4个字节的空间。

typedef struct { uint8_t head; uint32_t data; uint8_t tail; } MyStruct;

默认情况下，这个结构体sizeof(MyStruct)很可能不是1+4+1=6字节，而是12字节，因为data成员会在4字节对齐的地址上开始存放，head后面有3字节的填充（padding）。

这对DMA和通信的影响：如果你直接用DMA发送这个结构体的地址，或者用memcpy拷贝它，这些填充字节也会被发送/拷贝过去，导致对方解析错误。

解决方案有两种：

1. 使用__attribute__((packed))：这是GCC编译器的扩展（在IAR或Keil中有类似的关键字如#pragma pack）。它告诉编译器取消结构体的对齐优化，按实际字节数紧密排列。

   typedef struct __attribute__((packed)) { uint8_t head; uint32_t data; uint8_t tail; } MyStruct;

   现在sizeof(MyStruct)就是6字节。但是，这会带来性能损失和潜在的风险。非对齐访问在Cortex-M3/M4上可能导致硬件异常（HardFault），或者至少需要多个总线周期来完成，降低效率。

2. 手动重排结构体成员：这是更推荐的做法。将结构体成员按照从大到小（或从小到大）的类型尺寸重新排列，可以最小化填充字节。

   typedef struct { uint32_t data; // 4字节，放在开头自然对齐 uint8_t head; // 1字节 uint8_t tail; // 1字节 // 编译器可能会在这里添加2字节填充，使整个结构体大小为8字节（4的倍数），但至少没有内部填充了。 } MyStruct;

   对于DMA传输，我们通常传输的是原始数据缓冲区，而不是整个结构体。所以更好的做法是，定义一个紧密排列的字节数组作为传输缓冲区，然后用一个未打包的、方便访问的结构体指针指向这个缓冲区进行读写操作（需要注意字节序问题）。这样既保证了传输效率，又保证了CPU访问的安全性和高性能。

6. 低功耗设计与系统启动流程

6.1 STM32低功耗模式的选择与唤醒源配置

对于电池供电的设备，低功耗设计是硬性要求。STM32提供了多种低功耗模式，面试官会考察你如何根据应用场景选择。

睡眠模式（Sleep）：仅内核停止，所有外设包括NVIC仍在运行。通过任意中断或事件唤醒。唤醒速度最快，功耗降低有限。适用于需要快速响应中断的间歇性工作场景。

停止模式（Stop）：所有时钟都停止，1.8V域电源保留，SRAM和寄存器内容保持。功耗可降至微安级。可被任意外部中断、RTC闹钟等唤醒。唤醒后，HSI RC振荡器会作为系统时钟源，需要重新配置系统时钟到HSE/PLL。关键点：进入停止模式前，必须处理好所有可能产生中断的外设，最好将其禁用，防止误唤醒。

待机模式（Standby）：最省电的模式，关闭1.8V域电源，SRAM和寄存器内容丢失（除了备份域）。只有特定的唤醒源可以唤醒，如WKUP引脚上升沿、RTC闹钟、NRST引脚复位等。唤醒后相当于系统复位，程序从main函数开始重新执行。适用于需要长时间待机，且唤醒后可以从头开始工作的场景。

模式选择决策流：

1. 是否需要保持SRAM数据？需要 -> 排除待机模式。
2. 唤醒后是否需要快速恢复到休眠前的状态？需要 -> 选择停止模式，并在进入前保存关键上下文到SRAM（或备份寄存器）。
3. 对唤醒延迟有多敏感？非常敏感（毫秒级）-> 选择睡眠模式。
4. 对功耗有多苛刻？极其苛刻（微安级以下）-> 优先考虑待机模式。

实操陷阱：在停止模式下，所有IO口状态会保持。如果你有一个通过IO口控制的外部电源模块，在进入低功耗前忘了将其关闭，它可能会持续耗电，使得整体功耗降不下来。因此，进入低功耗前，务必将所有不必要的外部器件断电，并将MCU的IO口配置为模拟输入或输出低电平（根据外部电路决定），以减小漏电流。

6.2 从复位到main()：启动文件的奥秘

很多工程师对启动文件startup_stm32fxxx.s避而远之，但它决定了系统上电后的第一步。了解它，有助于调试一些诡异的启动问题。

启动文件主要做了以下几件事，顺序至关重要：

1. 初始化堆栈指针（SP）：从向量表的第一个条目（0x0000_0000）加载初始主堆栈指针（MSP）值。
2. 设置PC指针：从向量表的第二个条目（0x0000_0004）加载复位向量，即Reset_Handler函数的地址，并跳转过去。
3. 执行Reset_Handler：
   • 复制.data段：将存储在Flash中的已初始化全局变量和静态变量的初值，拷贝到SRAM中的.data区域。
   • 清零.bss段：将未初始化的全局变量和静态变量所在的.bss段内存全部清零。
   • 调用SystemInit函数：这个函数在system_stm32fxxx.c中，它负责初始化FPU（如果存在）、配置中断向量表偏移（如果用了Bootloader）、最重要的是设置系统时钟（使能HSE，配置PLL，切换系统时钟源）。很多新手遇到的“程序跑得慢”的问题，根源就是忘了调用或错误配置了SystemInit，导致系统一直运行在默认的HSI（内部16MHz RC振荡器）下。
   • 跳转到main函数：C语言的入口。

一个高级话题：中断向量表重映射。在IAP（在应用编程）或带有Bootloader的系统中，用户程序的向量表通常不在0x0800_0000（Flash起始地址）。我们需要在SystemInit之后，main之前，通过设置SCB->VTOR寄存器，将向量表重映射到用户程序的实际起始地址。否则，中断发生时，CPU会跑到Bootloader的中断服务函数里去，导致程序崩溃。

排查启动失败的经验：如果程序一上电就进HardFault，除了检查堆栈溢出，还要检查：

1. 系统时钟是否配置成功？用示波器测一下主时钟输出（MCO）引脚。
2. 中断向量表地址（VTOR）是否正确？
3. .data段复制或.bss段清零是否越界，覆盖了其他数据？

7. 软件架构与调试技巧

7.1 状态机在嵌入式事件处理中的建模实践

对于复杂的业务流程（如设备启动自检、通信协议解析、用户界面交互），如果只用if-else或switch-case简单堆砌，代码会迅速变得难以维护和调试。有限状态机（FSM）是解决这类问题的利器。

以解析一个简单的串口通信协议为例，协议帧格式为：帧头0xAA+ 命令字CMD+ 数据长度Len+ 数据Data[Len]+ 校验和Checksum。

一个糟糕的实现可能会在一个大循环里，通过一堆标志位和全局变量来记录解析到了哪一步，逻辑缠绕不清。而状态机可以清晰地划分为几个状态：

• STATE_IDLE：等待帧头。
• STATE_HEADER_RECEIVED：已收到帧头，等待命令字。
• STATE_CMD_RECEIVED：已收到命令字，等待长度。
• STATE_LEN_RECEIVED：已收到长度，正在接收数据。
• STATE_DATA_RECEIVED：数据接收完毕，等待校验和。
• STATE_CHECKSUM_VALID：校验通过，处理数据包。

每个状态下，只需要关心当前接收到的字节，并根据它决定下一个状态。代码结构会变得非常清晰：

typedef enum {IDLE, HEADER, CMD, LEN, DATA, CHECKSUM} ParserState; ParserState state = IDLE; uint8_t data_len, data_index; uint8_t packet_buffer[MAX_LEN]; uint8_t expected_checksum; void parse_byte(uint8_t byte) { switch(state) { case IDLE: if(byte == 0xAA) state = HEADER; break; case HEADER: packet_buffer[0] = byte; // 存储CMD state = CMD; break; case CMD: data_len = byte; data_index = 0; if(data_len == 0) state = CHECKSUM; else state = DATA; break; case DATA: packet_buffer[1 + data_index++] = byte; // 存储数据 if(data_index >= data_len) state = CHECKSUM; break; case CHECKSUM: if(calculate_checksum() == byte) { process_packet(); // 处理有效包 } state = IDLE; // 无论校验是否通过，都回到空闲状态 reset_parser(); break; } }

状态机的优势：逻辑清晰，易于扩展（增加新状态或新事件），调试方便（打印当前状态就知道卡在哪一步）。在更复杂的场景下，可以使用状态表驱动的FSM，将状态转移逻辑数据化，进一步解耦。

7.2 高效日志系统与断言宏的自定义实现

在资源受限的嵌入式系统中，printf调试虽然方便但效率低下，且会占用大量CPU时间和内存。一个高效的日志系统至关重要。

分级日志系统：定义不同的日志级别，如LOG_ERROR,LOG_WARN,LOG_INFO,LOG_DEBUG。在编译时通过宏定义（如LOG_LEVEL）来控制输出级别。只有高于或等于设定级别的日志才会被实际编译和输出。

#define LOG_LEVEL_DEBUG 4 #define LOG_LEVEL_INFO 3 #define LOG_LEVEL_WARN 2 #define LOG_LEVEL_ERROR 1 #define LOG_LEVEL_NONE 0 #ifndef CURRENT_LOG_LEVEL #define CURRENT_LOG_LEVEL LOG_LEVEL_INFO #endif #define LOG_E(fmt, ...) do { if(CURRENT_LOG_LEVEL >= LOG_LEVEL_ERROR) \ log_output("[E]%s:%d " fmt, __FILE__, __LINE__, ##__VA_ARGS__); } while(0) // 类似定义 LOG_W, LOG_I, LOG_D

log_output函数：这是关键。它可以实现为：

1. 串口输出：最常用，但注意要做好缓冲，防止阻塞。可以使用DMA或中断+环形缓冲区。
2. 内存缓冲区：将日志写入一块固定的SRAM区域，通过调试器（如J-Link）的RTT（Real Time Transfer）技术实时读取，完全不占用串口，速度极快。
3. 离线存储：写入外部Flash或SD卡，用于记录设备运行时的关键事件，便于售后分析。

断言宏assert的自定义：标准库的assert在失败时会调用abort()并可能输出到标准错误，这在嵌入式环境中不适用。我们需要一个自定义的、更友好的断言。

#ifdef DEBUG #define MY_ASSERT(expr) \ do { \ if(!(expr)) { \ LOG_E("Assertion failed: %s, file %s, line %d", #expr, __FILE__, __LINE__); \ /* 这里可以触发软件断点（如 __BKPT(0)），或者让程序进入一个安全循环 */ \ while(1) { /* 等待调试器连接 */ } \ } \ } while(0) #else #define MY_ASSERT(expr) ((void)0) #endif

这个自定义断言在调试版本（DEBUG定义时）会输出详细的错误信息（文件名、行号、表达式），并挂起程序，方便定位问题。在发布版本中，它会被完全移除，不影响性能和代码大小。

调试心得：在关键的函数入口、内存操作（malloc/free）、硬件初始化完成后，加入断言检查，可以极大提高代码的健壮性。例如，在DMA启动前断言缓冲区地址是否对齐，在指针使用前断言是否非空。这比程序跑飞后再去查HardFault要高效得多。