1. STM32定时器原理与工程实践：从理论计算到中断回调实现

在嵌入式系统开发中，精确的时间控制是绝大多数应用的基石。无论是传感器数据采集的严格时序、电机PWM波形的周期稳定，还是用户界面的响应刷新，都依赖于一个可靠、可预测的时间基准。STM32微控制器提供了功能强大的通用定时器（TIM），它远非一个简单的“倒计时器”，而是一个集成了预分频、自动重装载、捕获/比较、输入滤波、死区生成等复杂功能的硬件外设。理解其底层工作原理并掌握其在HAL库框架下的工程化配置方法，是每一位嵌入式工程师的核心能力。

1.1 定时器时间计算的本质：时钟树与寄存器联动

所有定时器的时间基准都源于系统时钟（SYSCLK）。对于本课程所用的STM32F103C8T6（“小蓝板”），其最高主频为72MHz，但为了简化设计并降低功耗，我们通常将系统时钟配置为32MHz。这个32MHz的时钟信号，经过APB1总线（高级外设总线1）分发给TIM2和TIM3等通用定时器。

定时器的计数过程本质上是一个“分频-计数”的两级操作：
1. 预分频（Prescaler） ：对来自APB1的时钟进行第一次分频。预分频寄存器（PSC）是一个16位寄存器，其值范围为0x0000至0xFFFF。关键点在于，预分频系数并非PSC寄存器的值本身，而是 PSC + 1 。例如，若PSC = 31999，则实际分频系数为32000。
2. 自动重装载（Auto-reload） ：对经过预分频后的时钟进行第二次分频。自动重装载寄存器（ARR）同样是一个16位寄存器，其值范围为0x0000至0xFFFF。其有效计数值为 ARR + 1 。

因此，一个完整的定时周期（即定时器溢出一次所需的时间）由以下公式决定：

$$
T_{out} = \frac{(PSC + 1) \times (ARR + 1)}{f_{CLK}}
$$

其中：
* $T_{out}$ 是期望的定时周期（秒）
* $PSC$ 是预分频寄存器的配置值
* $ARR$ 是自动重装载寄存器的配置值
* $f_{CLK}$ 是定时器的输入时钟频率（Hz）

这个公式是所有定时器配置的数学基础。任何脱离此公式的“经验参数”都是不可靠的，也是调试失败的根本原因。

1.2 工程案例解析：0.2秒与1秒定时的精确配置

让我们以本课程的具体任务为例，进行一次完整的、基于公式的工程推导。

任务一：使用TIM2，每0.2秒翻转LED1（PB9）状态

已知条件：
* 定时器输入时钟 $f_{CLK} = 32\, \text{MHz} = 32,000,000\, \text{Hz}$
* 期望定时周期 $T_{out} = 0.2\, \text{s} = 200\, \text{ms}$

目标是求解满足公式的PSC和ARR值。由于PSC和ARR均为16位整数，我们需要找到一组合理的组合。一个常用且高效的策略是让其中一个寄存器取一个便于计算的值，再反推另一个。

这里，我们选择让预分频系数为32000（即PSC = 31999），这是一个非常规但极其方便的值，因为它恰好将32MHz的时钟分频为1kHz（$32,000,000 / 32000 = 1000\, \text{Hz}$），即每个计数脉冲的周期为1ms。

代入公式：
$$
0.2 = \frac{32000 \times (ARR + 1)}{32,000,000}
$$

简化得：
$$
0.2 = \frac{ARR + 1}{1000}
$$

因此：
$$
ARR + 1 = 200 \quad \Rightarrow \quad ARR = 199
$$

然而，在CubeMX的图形化界面中，我们输入的是ARR寄存器的值，即199。但字幕中提到的“1999”是一个常见的混淆点。这通常发生在开发者误将输入时钟当作了72MHz，或者在计算时忽略了单位换算。对于32MHz系统，正确的ARR值应为199，而非1999。1999对应的是约0.2秒的另一种配置（PSC=31999, ARR=1999），但这会得到2秒的周期，显然不符合要求。因此，在工程实践中，我们必须回归公式，根据自己的实际系统时钟进行精确计算。

任务二：使用TIM3，每1秒翻转LED2（PB8）状态

沿用相同的思路，保持PSC = 31999（分频至1kHz），则：
$$
1.0 = \frac{32000 \times (ARR + 1)}{32,000,000} \quad \Rightarrow \quad ARR + 1 = 1000 \quad \Rightarrow \quad ARR = 999
$$

这与字幕中给出的“999”完全一致，验证了计算逻辑的正确性。

1.3 CubeMX图形化配置：从理论到代码的桥梁

CubeMX是ST官方提供的强大配置工具，它将复杂的寄存器操作抽象为直观的图形界面，极大地提升了开发效率。但其核心价值在于“所见即所得”的代码生成，而非替代工程师的思考。配置流程如下：

1. 芯片选择与基础时钟配置 ：在“Project Manager”中选择MCU型号（如STM32F103C8Tx），在“Clock Configuration”中将HSE（外部高速晶振）设置为8MHz，并通过PLL倍频至32MHz。这是整个系统时钟的源头。
2. GPIO引脚配置 ：在“Pinout & Configuration”视图中，找到PB8和PB9引脚，将其Mode设置为“Output”（推挽输出），Speed设置为“Medium”。这是驱动LED的物理基础。
3. 定时器外设配置 ：
   • 找到TIM2，双击进入配置界面。在“Parameter Settings”中，“Clock Source”选择“Internal Clock”（内部时钟），这是最常用的模式。
   • 在下方的“Configuration”区域，设置“Prescaler”为31999，“Counter Period”为199（对应0.2秒）。
   • 关键一步：勾选“NVIC Settings”中的“TIM2 global interrupt”选项。这行操作在底层生成的代码中，会调用 HAL_NVIC_EnableIRQ(TIM2_IRQn) ，并设置中断优先级，是使能定时器中断功能的必要步骤。
   • 同样方法配置TIM3：Prescaler = 31999，Counter Period = 999，并使能其全局中断。
4. 工程生成 ：完成所有配置后，点击“GENERATE CODE”。CubeMX会自动生成包含初始化代码、中断服务函数框架和HAL库驱动的完整工程。

生成的代码中， MX_TIM2_Init() 和 MX_TIM3_Init() 函数封装了所有寄存器的初始化操作，而 tim.c 文件则包含了定时器的底层驱动。这种分工使得工程师可以专注于业务逻辑，而无需深陷寄存器细节。

2. 中断机制与回调函数：事件驱动编程的核心范式

在裸机编程中，延时函数（如 HAL_Delay() ）是一种简单直接的等待方式。然而，它存在致命缺陷：在延时期间，CPU处于空转状态，无法响应任何其他事件。这对于一个需要同时处理多个任务（如读取传感器、更新显示、响应按键）的系统而言，是完全不可接受的。中断机制正是为了解决这一问题而生。

2.1 中断的哲学：从“轮询”到“事件驱动”

我们可以将中断理解为一种硬件级别的“通知”机制。它允许外设（如定时器、串口、ADC）在特定事件发生时（如定时器溢出、串口接收完成、ADC转换结束），主动向CPU发出一个信号。CPU在收到信号后，会立即暂停当前正在执行的主程序（ main() 函数中的循环），保存当前的运行上下文（包括所有寄存器的值），然后跳转到一个预先指定的地址——即中断服务函数（ISR, Interrupt Service Routine）去执行特定的处理逻辑。处理完毕后，CPU再恢复之前保存的上下文，继续执行被中断的主程序。

这种“事件驱动”的编程范式，将CPU从无意义的等待中解放出来，使其能够高效地并发处理多个任务。定时器中断是其中最典型的应用：它不再需要主循环不停地查询时间是否到达，而是由硬件在精确的0.2秒或1秒时刻，主动“唤醒”CPU来执行LED翻转操作。

2.2 HAL库中的回调函数：面向对象思想的体现

在HAL库的设计中，中断服务函数（ISR）被进一步抽象为“回调函数”（Callback Function）。这是一种典型的面向对象编程思想。HAL库的 stm32f1xx_hal_tim.c 文件中，定义了一个名为 HAL_TIM_PeriodElapsedCallback() 的函数原型，但其函数体为空（即一个“虚函数”）。这意味着，HAL库只规定了“当定时器溢出时，应该调用一个叫这个名字的函数”，但具体这个函数里要做什么，完全由用户自己决定。

这种设计带来了巨大的灵活性和可维护性：
* 解耦 ：HAL库负责与硬件打交道（启动定时器、配置NVIC、编写底层ISR），用户负责业务逻辑（翻转哪个LED、发送什么数据）。
* 复用 ：同一个 HAL_TIM_PeriodElapsedCallback() 函数可以被多个定时器共享，通过传入的 htim 参数来区分是哪个定时器触发的中断。
* 规范 ：它强制要求开发者遵循一套清晰的接口规范，避免了在底层ISR中编写大量业务代码所带来的混乱和难以调试的问题。

2.3 回调函数的定位、声明与实现

在CubeMX生成的工程中， HAL_TIM_PeriodElapsedCallback() 函数的声明位于 stm32f1xx_hal_tim.h 头文件中。它的完整原型为：

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim);

其中， htim 是一个指向 TIM_HandleTypeDef 结构体的指针，该结构体包含了定时器的所有运行时信息，如寄存器基地址、中断状态等。正是通过这个指针，我们才能在同一个回调函数中区分不同的定时器实例。

在实际工程中，该函数的实现必须放在用户代码区域（通常是在 main.c 文件中，位于 /* USER CODE BEGIN 4 */ 和 /* USER CODE END 4 */ 之间），否则会被CubeMX在下次代码生成时覆盖。

实现步骤详解 ：
1. 定位与声明 ：首先，在 main.c 中找到 /* USER CODE BEGIN 4 */ 标记。在此处，我们手动声明并定义回调函数。
2. 参数判别 ：在函数体内，使用 if-else if 语句判断 htim 指针指向的对象。例如， if (htim->Instance == TIM2) 表示当前中断由TIM2触发； else if (htim->Instance == TIM3) 表示由TIM3触发。
3. 执行业务逻辑 ：在对应的分支内，编写具体的业务代码。对于本例，就是调用 HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_9) 或 HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_8) 。

一个标准的实现如下所示：

/* USER CODE BEGIN 4 */
/**
  * @brief  This function is executed in case of error occurrence.
  * @param  htim: TIM handle
  * @retval None
  */
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
  /* USER CODE BEGIN Callback 1 */
  if(htim->Instance == TIM2)
  {
    // LED1 (PB9) toggles every 0.2 seconds
    HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_9);
  }
  else if(htim->Instance == TIM3)
  {
    // LED2 (PB8) toggles every 1 second
    HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_8);
  }
  /* USER CODE END Callback 1 */
}
/* USER CODE END 4 */

2.4 启动定时器：使能中断的最后一步

仅仅配置好定时器并编写了回调函数还不够。定时器本身必须被“启动”，并且其产生的中断必须被CPU“接收”。这需要两个关键的HAL库API调用：

1. 启动定时器计数 ： HAL_TIM_Base_Start_IT(&htim2);
   • 此函数启动TIM2的计数器，并同时使能其更新中断（Update Interrupt）。 IT 后缀明确表示这是“中断模式”的启动。
2. 启动另一个定时器 ： HAL_TIM_Base_Start_IT(&htim3);
   • 同理，启动TIM3。

这两个函数必须在 main() 函数的 while(1) 循环 之前 调用，通常放在所有外设初始化（ MX_GPIO_Init() , MX_TIM2_Init() , MX_TIM3_Init() ）之后， while(1) 之前。这是因为它们是一次性的初始化操作，只需执行一次。

如果忘记调用 HAL_TIM_Base_Start_IT() ，即使CubeMX中已经使能了NVIC，定时器也不会产生任何中断，LED将永远不会闪烁。这是一个在初学者中极为常见的错误，其根本原因在于混淆了“中断使能”（NVIC）和“外设中断源使能”（定时器自身的中断使能位）。

3. OLED显示屏驱动：SPI通信与图形化显示原理

OLED（Organic Light-Emitting Diode，有机发光二极管）显示屏因其高对比度、宽视角、超薄、低功耗和快速响应等优势，在嵌入式人机交互界面中得到了广泛应用。与传统的LCD不同，OLED是自发光器件，每个像素点独立发光，无需背光，这使得其在显示黑色时功耗几乎为零，视觉效果也更为震撼。

3.1 OLED的硬件接口：SPI协议的选择与优势

OLED模块通常提供多种通信接口，如I2C、SPI和8080并行总线。在本课程的实验中，我们选用的是基于SPI（Serial Peripheral Interface）接口的OLED。SPI是一种高速、全双工、同步的串行通信协议，其主要优势在于：
* 速度快 ：SPI没有I2C的地址仲裁和ACK确认开销，数据传输速率远高于I2C，更适合需要频繁刷新的图形显示。
* 硬件资源占用少 ：标准SPI仅需4根线（SCLK、MOSI、CS、DC），比并行总线节省大量IO口。
* 协议简单 ：SPI是主从架构，由主设备（STM32）完全控制时钟，从设备（OLED）被动响应，软件实现逻辑清晰。

本课程所用的OLED模块（SSD1306驱动芯片）的典型引脚定义为：
* VCC/GND : 电源与地
* SCLK : SPI时钟线，由STM32提供
* SDIN/MOSI : 主机输出/从机输入数据线，由STM32驱动
* CS : 片选信号，低电平有效，用于选择该OLED设备
* DC : 数据/命令选择线，高电平表示接下来传输的是显示数据（Data），低电平表示传输的是控制命令（Command）
* RES : 复位信号，低电平有效，用于初始化OLED

在CubeMX中，我们需要将这些引脚配置为GPIO输出模式，并在后续的驱动代码中，通过软件模拟（Bit-Banging）或硬件SPI外设来控制它们。

3.2 SSD1306驱动芯片：内存映射与显示缓冲区

SSD1306是OLED屏最常用的驱动芯片之一。它的核心是一个128x64bit的显示缓冲区（Display RAM），即一个128列（X轴）、64行（Y轴）的二维数组。每一行被划分为8个页（Page），每页8行，因此整个屏幕被组织为8页（Page 0 ~ Page 7），每页有128个字节（Byte）。这种“页模式”（Page Mode）是SSD1306的固有特性，所有的显示操作最终都是对这个缓冲区的读写。

当STM32向OLED发送一个字节的数据时，这个字节会被写入当前选定的页（Page）和列（Column）所对应的8个像素点中。例如，向Page 0, Column 0写入0xFF，意味着点亮第0页（即屏幕最上方8行）的第0列（最左侧）的全部8个像素点。

因此，OLED的驱动程序本质上是一个“内存管理器”：
1. 初始化 ：通过向SSD1306发送一系列初始化命令，配置其工作模式（页模式）、扫描方向、对比度、显示开关等。
2. 清屏 ：将整个128x64bit的缓冲区清零（或置1），为新的显示内容做准备。
3. 绘制 ：将要显示的图像或字符数据，按照页和列的映射关系，写入到缓冲区的相应位置。
4. 刷新 ：将缓冲区的内容一次性发送到OLED的物理屏幕上。

3.3 图形与文本显示：BMP图像与汉字库的编译与加载

OLED的显示内容可分为两大类：静态图形（BMP）和动态文本（ASCII/汉字）。

BMP图像显示 ：
BMP（Bitmap）是一种位图格式，其核心是像素点阵。在嵌入式开发中，我们并不直接处理BMP文件，而是使用“取模软件”（如PCtoLCD2002）将其转换为C语言数组。这个过程称为“取模”。

取模的关键设置包括：
* 取模方式 ：通常选择“纵向取模，字节倒序”。这决定了像素点如何被组织成字节。
* 输出格式 ：选择“C51格式”，它会生成一个标准的 const unsigned char 数组。
* 尺寸 ：确保取模的尺寸与OLED的分辨率（128x64）匹配。

生成的C数组（如 const unsigned char gImage_logo[1024] ）就是一个128x64的完整像素点阵。在驱动程序中，我们只需要将这个数组的数据，按页（Page）为单位，逐页写入SSD1306的显示缓冲区即可。

汉字与ASCII文本显示 ：
显示文本比显示图片更复杂，因为它涉及到字体渲染。一个汉字在16x16点阵中，需要32个字节来描述（16行 x 2字节/行）。因此，我们需要一个“汉字库”，即一个包含了所有目标汉字点阵数据的大型常量数组。

在本课程中，我们使用了一个预先制作好的汉字库（ hzk16.h ）。这个库的结构是一个巨大的 const unsigned char 数组，其中每个汉字的点阵数据按顺序存放。为了能根据汉字查找其对应的点阵，我们需要一个“索引”机制。最常用的方法是利用汉字的GB2312编码。例如，“王”字的GB2312编码为 0xCE, 0xF6 ，我们可以通过计算 ((0xCE - 0xA1) * 94 + (0xF6 - 0xA1)) * 32 来得到它在汉字库中的起始偏移量，从而取出32个字节的点阵数据。

对于ASCII字符（A-Z, a-z, 0-9），其点阵通常被存放在一个独立的 asc16[] 数组中，因为其编码（0x20-0x7E）是连续的，索引计算更为简单。

4. OLED驱动工程实践：从添加驱动到显示图文

将OLED集成到STM32项目中，是一个典型的“第三方库集成”工程。其核心挑战不在于驱动本身的复杂性，而在于如何将外部的 .c 和 .h 文件无缝地融入CubeMX生成的工程框架中，并确保编译器能找到所有必要的符号定义。

4.1 驱动文件的集成与路径配置

CubeMX生成的工程目录结构非常清晰：
* Core/Src/ : 存放所有 .c 源文件。
* Core/Inc/ : 存放所有 .h 头文件。
* Drivers/ : 存放HAL库和CMSIS库。

我们的OLED驱动文件（ oled.c , oled.h , hzk16.h , asc16.h 等）属于用户自定义的“中间件”，应遵循相同的约定：
1. 将 oled.c 复制到 Core/Src/ 目录下。
2. 将 oled.h , hzk16.h , asc16.h 等所有 .h 文件复制到 Core/Inc/ 目录下。

完成文件复制后，最关键的一步是 在IDE中将这些文件添加到工程的编译列表中 。在Keil MDK中，这需要右键点击 Source Group 1 （或类似名称的源组），选择“Add Existing Files to Group ‘Source Group 1’…”，然后浏览并选中 oled.c 。如果遗漏此步，编译器会报错“undefined reference to OLED_Init ”，因为它根本不知道 oled.c 的存在。

4.2 初始化与清屏：显示前的必要准备

在 main() 函数中，OLED的使用流程是固定的：
1. 初始化 ：调用 OLED_Init() 。该函数会配置所有相关的GPIO引脚（SCLK, SDIN, CS, DC, RES），并发送一系列SSD1306初始化命令，将屏幕置于可工作状态。
2. 清屏 ：调用 OLED_Clear() 。这是一个至关重要的习惯。它将整个128x64的显示缓冲区清零，确保屏幕初始状态为空白。如果不执行此步，上一次显示的残留内容（“鬼影”）会与新内容叠加，导致显示混乱。

这两步必须在 while(1) 循环 之前 执行，且只需执行一次。

4.3 显示BMP图像：全屏与局部绘制

OLED_DrawBMP() 函数是显示图像的核心。其函数原型通常为：

void OLED_DrawBMP(unsigned char x0, unsigned char y0, unsigned char x1, unsigned char y1, const unsigned char *bmp);

• x0, y0 : 起始坐标（左上角）。
• x1, y1 : 结束坐标（右下角）。
• *bmp : 指向BMP图像数据的指针。

全屏显示 ：要显示一个完整的128x64图像，参数应为 OLED_DrawBMP(0, 0, 127, 63, gImage_logo); 。这里 x1=127 是因为X轴有128列，索引从0开始； y1=63 同理。

局部显示 ：OLED的页模式（Page Mode）允许我们只更新屏幕的一部分。例如，要将图像显示在屏幕的右半部分，可以设置 x0=64, x1=127, y0=0, y1=63 。此时，驱动程序只会将BMP数据写入X坐标64-127范围内的缓冲区，而左半部分保持不变。这种特性对于实现滚动、动画等效果至关重要。

4.4 显示文本：坐标系与点阵渲染

OLED的坐标系原点（0, 0）位于屏幕的左上角。X轴向右递增（0-127），Y轴向下递增（0-63）。但Y轴的“行”概念与页模式紧密相关。由于每页有8行，Y坐标实际上被映射到了页号（Page）和页内行号（Page Row）上。

显示ASCII字符串 ：
OLED_ShowString() 函数用于显示英文和数字。其原型为：

void OLED_ShowString(unsigned char x, unsigned char y, const char *chr);

• x : 字符串起始的X坐标（像素点）。
• y : 字符串起始的Y坐标（页号，0-7）。注意，这里的 y 不是像素行号，而是页号！例如， y=0 表示在屏幕最上方的8行（Page 0）显示； y=1 表示在接下来的8行（Page 1）显示。

显示汉字 ：
OLED_ShowCN() 函数用于显示汉字。其原型为：

void OLED_ShowCN(unsigned char x, unsigned char y, unsigned char no);

• x : 汉字起始的X坐标（像素点）。
• y : 汉字起始的Y坐标（页号，0-7）。
• no : 汉字在汉字库中的序号。例如，“王”是第0个，“子”是第1个，依此类推。

在实际应用中，我们通常会将汉字按行组织。例如，要在第一行（Page 0）显示“王子”，就调用 OLED_ShowCN(0, 0, 0); OLED_ShowCN(16, 0, 1); 。这里的 16 是X坐标的偏移量，因为一个16x16的汉字宽度为16像素，下一个汉字应从第16列开始，以避免重叠。

4.5 实际项目中的常见问题与规避策略

在将OLED集成到真实项目中时，开发者常会遇到以下问题：

• 编译错误：“identifier ‘OLED_Init’ is undefined” ：这是最常见的问题，根源在于头文件未被正确包含。解决方案是在 main.c 的顶部， #include "main.h" 之后，添加 #include "oled.h" 。此外，还需检查 oled.h 中是否包含了所有它所依赖的头文件（如 #include "stm32f1xx_hal.h" ）。
• 屏幕无反应或显示乱码 ：首要检查硬件连接，特别是 CS （片选）和 DC （数据/命令）引脚是否接对。其次，检查 OLED_Init() 函数中发送的初始化命令序列是否与所用OLED模块的规格书完全一致。一个微小的命令错误（如对比度设置值不对）就会导致屏幕不亮。
• 显示内容偏移或错位 ：这通常是坐标计算错误所致。务必牢记， OLED_ShowString() 的 y 参数是页号，而非像素行号。如果想在屏幕垂直居中显示一行文字，应将其 y 值设为 3 （Page 3，即第24-31行），而不是 32 （像素行号）。
• 中文显示为方块或问号 ：这表明汉字库文件（ hzk16.h ）未被正确加载，或者其编码格式（如UTF-8 with BOM）与编译器不兼容。应确保该文件保存为ANSI或UTF-8 without BOM格式，并在 oled.h 中正确声明了 extern const unsigned char hzk16[]; 。

5. 综合工程实践：定时器与OLED的协同工作

一个成熟的嵌入式产品，绝不会只包含单一功能。将定时器与OLED协同工作，是构建一个具有实时信息反馈的人机界面（HMI）的基础。本节将展示如何将前两部分的知识融会贯通，创建一个既能精确计时又能动态显示的综合系统。

5.1 系统需求分析：多任务并行的逻辑设计

我们的目标系统需要同时完成以下任务：
1. 后台计时任务 ：TIM2以0.2秒为周期，持续翻转LED1，作为系统运行的视觉指示。
2. 后台计时任务 ：TIM3以1秒为周期，持续翻转LED2，作为另一个独立的计时指示。
3. 前台显示任务 ：OLED屏幕需要动态显示当前的系统运行时间（秒数），并每隔一段时间切换显示内容（如开机Logo、系统信息、实时数据）。

这三个任务在逻辑上是完全独立的，但在物理上共享同一个CPU。如果我们采用传统的“轮询”方式，主循环将不得不在 HAL_Delay() 中等待，导致系统僵化。而中断机制则完美地解决了这个问题：定时器中断负责“计时”，主循环则可以专注于“显示”和“数据处理”。

5.2 状态机设计：管理OLED的多页面显示

为了实现OLED内容的动态切换，我们引入一个简单的状态机（State Machine）。定义几个全局状态变量：

typedef enum {
    STATE_LOGO,
    STATE_INFO,
    STATE_CLOCK
} DisplayState_t;

DisplayState_t current_state = STATE_LOGO;
uint32_t state_timer = 0; // 用于记录状态切换的时间戳

在 main() 函数的 while(1) 循环中，我们不再进行阻塞式延时，而是采用“非阻塞延时”的思想：

while (1)
{
    // 检查是否需要切换显示状态（例如，每5秒切换一次）
    if (HAL_GetTick() - state_timer > 5000) // 5000ms = 5s
    {
        state_timer = HAL_GetTick();
        current_state = (current_state + 1) % 3; // 循环切换
    }

    // 根据当前状态，执行相应的显示逻辑
    switch (current_state)
    {
        case STATE_LOGO:
            OLED_Clear();
            OLED_DrawBMP(0, 0, 127, 63, gImage_logo);
            break;
        case STATE_INFO:
            OLED_Clear();
            OLED_ShowString(0, 0, "STM32-OLED");
            OLED_ShowString(0, 2, "v1.0");
            break;
        case STATE_CLOCK:
            OLED_Clear();
            // 这里可以显示一个动态的秒表
            static uint32_t seconds = 0;
            if (seconds % 100 == 0) { // 每100ms更新一次，模拟10ms精度
                OLED_ShowNum(0, 0, seconds, 5); // 显示5位数字
                seconds++;
            }
            break;
    }
}

HAL_GetTick() 是HAL库提供的一个基于SysTick定时器的毫秒计数器，它是实现非阻塞延时的基石。通过记录上一次状态切换的时间戳，并与当前时间戳比较，我们就能精确地控制状态切换的节奏，而主循环始终是自由的。

5.3 全局变量与中断安全：临界区保护

在上述设计中， seconds 变量被主循环读取，而其更新又依赖于一个定时器中断（假设我们用另一个定时器来驱动它）。这就构成了一个经典的“共享资源”访问场景。如果在主循环读取 seconds 的瞬间，中断恰好发生并修改了它，就可能导致读取到一个“撕裂”的、不一致的值（例如，高位已被更新，低位还未更新）。

为了解决这个问题，我们需要对访问 seconds 的临界区进行保护。最简单有效的方法是使用 HAL_NVIC_DisableIRQ() 和 HAL_NVIC_EnableIRQ() 来临时禁用和使能该中断：

// 在需要读取seconds的地方
__disable_irq(); // 关闭所有中断（粗粒度，适用于简单场景）
uint32_t local_seconds = seconds;
__enable_irq();  // 重新开启中断

// 使用 local_seconds 进行显示
OLED_ShowNum(0, 0, local_seconds, 5);

对于更复杂的系统，应考虑使用FreeRTOS的任务间通信机制（如队列、信号量）来实现线程安全的数据传递。

5.4 真实项目经验：我踩过的那些坑

在我参与的一个工业温控仪表项目中，OLED与定时器的协同曾引发过一次严重的现场故障。现象是：仪表在运行数小时后，屏幕会突然花屏，随后系统重启。经过数天的排查，最终定位到问题根源：在 HAL_TIM_PeriodElapsedCallback() 回调函数中，我调用了 OLED_Clear() 和 OLED_DrawBMP() 等耗时较长的函数。

这是一个典型的“中断服务函数中执行耗时操作”的反模式。 OLED_Clear() 需要向OLED发送1024字节的数据，这在32MHz主频下需要数毫秒。而TIM2的中断周期仅为0.2秒，这意味着在0.2秒内，CPU有数毫秒的时间被锁定在中断中，无法响应其他更高优先级的中断（如看门狗复位中断、紧急停机信号中断）。长时间的中断屏蔽最终导致看门狗超时，触发了系统复位。

解决方案 ：
1. 缩短ISR ：将所有耗时的OLED操作移出中断服务函数，只在ISR中设置一个 volatile 标志位（如 oled_update_needed = 1; ）。
2. 主循环轮询 ：在 main() 的 while(1) 循环中，检查该标志位。如果为真，则执行OLED更新，并清除标志位。
3. 升级架构 ：在更复杂的项目中，引入RTOS，将OLED刷新作为一个独立的、低优先级的任务，由操作系统来调度。

这个教训深刻地说明，理解中断的“快进快出”原则，是编写健壮嵌入式代码的生命线。任何在ISR中执行的代码，都必须是轻量级的、确定性的，并且绝对不能包含任何可能引起阻塞的操作（如 HAL_Delay() 、 printf() 、复杂的浮点运算等）。