2.4 中断与设备管理 —— 系统的 “神经” 与 “感官”⚡️

如果说 CPU 是嵌入式系统的大脑，那么中断和设备管理就是其感知世界、做出反应的神经网络和感官。中断是系统响应外部事件的 “神经反射”，而设备驱动和管理则是让大脑能够理解并控制各个 “器官”（外设）的机制。

1. 中断处理机制：暂停一切的紧急呼叫

在操作系统层面，我们不必深究中断在硬件层面的所有细节，但必须理解它的工作流程，因为它决定了系统的实时响应能力。

中断是硬件向 CPU 发出的一个 “紧急呼叫”，通知有高优先级事件发生（如数据接收完毕、定时器超时）。整个响应流程如下：

1. 中断请求：外设完成一个任务后，向中断控制器（如 ARM Cortex-M 中的 NVIC）发送一个中断请求（IRQ）。
2. 中断响应：如果该中断的优先级足够高，中断控制器就会通知 CPU。CPU 会立即暂停当前正在执行的任何代码，并自动将当前任务的 “执行现场”（如 PC 指针、寄存器值）压入栈中保存起来。
3. 执行服务程序：CPU 根据中断号，通过中断向量表找到对应的中断服务例程 (Interrupt Service Routine, ISR) 的地址，并跳转过去执行。
4. 与 OS 交互：ISR 的核心原则是 “短、平、快”。它会迅速完成最关键的硬件操作（如从数据寄存器中读取数据），然后通常会通过一个操作系统提供的机制（如释放一个信号量、发送一条消息到队列）来 “唤醒” 或通知一个正在等待该事件的上层任务。
5. 中断返回：ISR 执行完毕后，CPU 会执行一条特殊的中断返回指令。这会使它自动从栈中恢复之前保存的 “执行现场”，回到被打断的地方继续执行，仿佛一切都未发生过。

在 ARM Cortex-M 处理器中，嵌套向量中断控制器 (NVIC) 统一管理所有中断源，它允许为每个中断设置优先级，并支持中断嵌套 —— 即一个高优先级中断可以打断一个正在执行的低优先级 ISR。理解这一点对于设计复杂的实时系统至关重要。

2. 设备驱动程序：操作系统的 “翻译官”

设备驱动程序是操作系统内核中与硬件直接打交道的部分。它像一个 “翻译官”，将上层应用程序发出的标准化指令（如 “读取数据”）翻译成底层硬件能听懂的语言（如 “向寄存器 0x40013804 写入值 0x01 ”）。

根据数据传输的特性，驱动通常分为三类：

• 字符设备 (Character Devices)：以字节流的方式进行数据传输，不支持随机读写。好比一根水管，数据只能顺着流。例如：串口 (UART)、I2C、SPI、键盘。
• 块设备 (Block Devices)：以固定大小的 “块” 为单位进行数据传输，支持随机访问。好比一本书，可以直接翻到任意一页阅读。例如：SD 卡、eMMC、硬盘。文件系统就是建立在块设备之上的。
• 网络设备 (Network Devices)：专门处理数据包的收发。它不通过设备文件节点，而是通过一套专门的套接字（Socket）API 来访问，以适应网络通信的复杂协议。

3. 与外设 “对话”：不同的操作系统哲学

如何让应用程序来操作这些被驱动起来的设备？不同的操作系统提供了不同的 “对话” 哲学。

Linux 哲学：“一切皆文件”

Linux 系统有一个极其优雅的设计哲学 ——“一切皆文件”(好吧除了 Socket.. 等...)。无论是串口、I2C 设备，还是一个 GPIO 引脚，都会被抽象成 /dev 目录下的一个特殊文件。

应用程序可以像操作普通文本文件一样，使用 open() , read() , write() , ioctl() 这些标准函数来与硬件交互。

// 在Linux中控制一个LED灯（假设被映射到/dev/gpioled0）
int fd = open("/dev/gpioled0", O_RDWR); // 打开设备文件
write(fd, "1", 1); // 写入"1"，驱动程序将其解释为点亮LED
close(fd);

这种设计的巨大优势在于统一和简化了应用程序的编程模型。

实时操作系统 (RTOS) 哲学：“专用 API”

在资源受限、追求极致效率的 RTOS（如 FreeRTOS, Zephyr, RT-Thread）中，通常不采用 “一切皆文件” 的模式，因为它会带来额外的开销和复杂性。取而代之的是一套为每类设备定制的、直接的函数调用（API）。

开发者需要包含特定设备的头文件，并调用其专属的 API 来完成操作。

// 在某个RTOS中控制一个LED灯
// (此为示意代码，具体API因RTOS而异)
gpio_pin_config(gpio_dev, LED_PIN, GPIO_OUTPUT); // 配置GPIO为输出模式
gpio_pin_set(gpio_dev, LED_PIN, 1); // 设置GPIO为高电平，点亮LED

这种方式更接近硬件，开销更小，也更直观，但缺点是接口不统一，需要学习每种外设的专属 API。

裸机方式：“直接访问寄存器”

作为对比，在没有操作系统的裸机编程中，我们操作外设的方式最为原始 —— 直接读写硬件的物理地址（寄存器）。

// 在裸机（以某STM32为例）中控制一个LED灯
#define GPIOA_ODR (*(volatile unsigned int*)0x40020014) // 定义GPIOA输出数据寄存器地址
GPIOA_ODR |= (1 << 5); // 将第5位置1，点亮连接到PA5的LED

这种方式效率最高，但可移植性为零，且极度繁琐和易错。操作系统的价值，正是在于将开发者从这种原始的操作中解放出来。