4、no_std与嵌入式Rust：核心库与标准库区别、全局分配器、panic处理、启动流程、最小可执行程序

嵌入式系统开发与桌面应用开发有着本质差异：目标硬件资源受限、无操作系统或仅有轻量级RTOS、没有文件系统和动态链接器。Rust语言通过 no_std 模式为这类环境提供了第一等公民支持。理解 no_std 并非仅仅是“去掉标准库”，而是理解Rust运行时如何分层、哪些能力被保留、哪些被替换，以及如何为裸机环境构建一个可启动、可调试、可崩溃的最小程序。本章将系统拆解核心库与标准库的边界、全局分配器的接入方式、panic处理策略、启动流程的完整链路，并最终构建一个真实可运行的最小程序。

上图展示了 no_std 模式下Rust运行时的整体架构。左侧是 core 库与 std 库的边界，右侧是 no_std 必须自行提供的运行时组件，底部则呈现了从复位到 main 的启动链路以及panic处理的不同策略。这张图是理解本章所有内容的地图，后续各节将逐一深入。

4.1 核心库与标准库的本质区别

核心原理：Rust标准库 std 建立在操作系统抽象之上，它假设存在文件系统、网络协议栈、线程调度器和动态内存分配器。而 core 库是语言本身的基石，它只包含与平台无关的类型系统、控制流、迭代器、模式匹配、原子操作和内存原语。core 库不依赖任何外部运行时，因此可以在裸机上直接编译运行。两者的关系是：std 是 core 的超集，std 内部通过 extern crate core 引入核心功能，再叠加操作系统相关的服务。

判断方法：在Cargo.toml中设置 #![no_std] 后，编译器会禁止 std 路径下的所有模块。此时若代码中使用了 Vec、String、Box、println! 等类型或宏，编译会直接报错。判断一个库是否支持 no_std，可以查看其文档或源码中是否包含 #![no_std] 属性，以及是否依赖 alloc crate（用于堆分配）。

实战场景：假设我们要为STM32F103编写一个LED闪烁程序。使用 std 模式时，编译器会尝试链接操作系统的启动代码，这在裸机上必然失败。切换到 no_std 后，我们只需要引入 cortex_m_rt（Cortex-M运行时）和 embedded_hal（硬件抽象层），即可直接操作GPIO寄存器。此时 core 库提供的 Iterator、Option、Result 等工具依然可用，但 Vec 和 String 则需要通过 alloc crate 配合全局分配器才能使用。

4.2 全局分配器：为裸机提供堆内存

核心原理：Rust的堆分配通过 GlobalAlloc trait 抽象。在 std 环境中，系统默认分配器（如malloc/free）被自动接入。在 no_std 环境中，编译器不知道如何分配内存，必须由开发者实现 GlobalAlloc trait 并通过 #[global_allocator] 属性注册。分配器需要管理一个内存池，提供 alloc 和 dealloc 方法，并保证线程安全（如果使用多线程）。

操作流程：实现一个最简单的静态分配器（Bump Allocator）需要以下步骤：

1. 定义一个静态字节数组作为内存池，例如 static mut HEAP: [u8; 1024] = [0; 1024];
2. 实现 GlobalAlloc trait，在 alloc 中返回内存池中未使用的地址，在 dealloc 中不做任何操作（因为Bump分配器不回收内存）。
3. 使用 #[global_allocator] static ALLOCATOR: BumpAllocator = BumpAllocator::new(); 注册。
4. 在Cargo.toml中引入 alloc crate：extern crate alloc;

use core::alloc::{GlobalAlloc, Layout};
use core::sync::atomic::{AtomicUsize, Ordering};

pub struct BumpAllocator {
    heap_start: usize,
    heap_end: usize,
    next: AtomicUsize,
}

unsafe impl GlobalAlloc for BumpAllocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        let size = layout.size();
        let align = layout.align();
        let current = self.next.load(Ordering::Relaxed);
        let aligned = (current + align - 1) & !(align - 1);
        if aligned + size > self.heap_end {
            return core::ptr::null_mut(); // 内存不足
        }
        self.next.store(aligned + size, Ordering::Relaxed);
        aligned as *mut u8
    }
    unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {
        // Bump分配器不回收内存
    }
}

案例拆解：在实际嵌入式项目中，更常用的是 linked_list_allocator crate，它实现了可回收的空闲链表分配器。例如在RTIC（Real-Time Interrupt-driven Concurrency）框架中，任务间通信需要 Box 传递消息，此时必须配置一个可靠的分配器。我们曾在一个基于nRF52840的BLE项目中，使用 linked_list_allocator 分配4KB堆空间，通过 cortex_m_semihosting 输出分配日志，验证了分配器的正确性。关键参数是堆大小：过小会导致分配失败，过大则浪费宝贵的RAM。通过压力测试（连续分配/释放不同大小的对象）确定最优堆大小。

4.3 panic处理：错误路径的优雅设计

核心原理：Rust的panic机制用于处理不可恢复的错误。在 std 环境中，panic会展开栈（unwind），打印错误信息并退出进程。在 no_std 环境中，没有栈展开机制（或代价过高），必须通过 #[panic_handler] 属性定义一个函数来处理panic。该函数接收 &PanicInfo 参数，包含panic位置和消息。处理策略通常有三种：死循环（halt）、触发断点（abort）、或尝试恢复（极少见）。

判断方法：选择哪种策略取决于应用场景。对于安全关键系统（如汽车ECU），panic后应进入安全状态（如关闭电机、点亮故障灯），此时使用halt并配合看门狗复位。对于开发调试阶段，可以使用 cortex_m_semihosting 将panic信息输出到主机，或者使用 panic_probe 库通过ITM（Instrumentation Trace Macrocell）输出。对于RTOS环境，panic后应挂起当前任务并通知调度器。

#[panic_handler]
fn panic(info: &core::panic::PanicInfo) -> ! {
    // 在Cortex-M上，读取LR寄存器获取返回地址
    let lr = cortex_m::register::lr::read() as usize;
    // 通过semihosting输出panic信息
    cortex_m_semihosting::hprintln!("Panic at 0x{:08x}: {}", lr, info).ok();
    // 进入死循环，等待看门狗复位
    loop {
        cortex_m::asm::wfi(); // 等待中断，降低功耗
    }
}

实战场景：在一个无人机飞控项目中，我们使用 panic_probe 库将panic信息通过SWO引脚输出到逻辑分析仪。当发生数组越界时，系统立即停止电机输出，并通过LED闪烁指示错误代码（例如闪3次表示内存错误，闪5次表示外设配置错误）。这种设计让现场调试人员无需连接调试器即可初步定位问题。

4.4 启动流程：从复位向量到main函数

核心原理：嵌入式处理器的启动流程由硬件决定。以ARM Cortex-M为例，上电后处理器从向量表偏移0处加载初始栈指针（MSP），从偏移4处加载复位向量地址，然后跳转到复位向量执行。复位向量指向的代码通常由启动文件（startup.s）或运行时crate（如 cortex_m_rt）提供。这段代码负责：初始化 .data 段（从Flash复制到RAM）、清零 .bss 段、设置系统时钟、调用 main 函数。

操作流程：使用 cortex_m_rt crate时，开发者只需定义 main 函数和异常处理函数，其余由宏自动生成。关键步骤如下：

1. 在Cargo.toml中添加 cortex-m-rt = "0.7" 依赖。
2. 在代码中引入 use cortex_m_rt::entry; 并标注 #[entry] 属性。
3. 提供链接脚本 memory.x，定义Flash和RAM的起始地址与大小。
4. 在 build.rs 中调用 cortex_m_rt::memory_x 生成链接脚本。

// memory.x 示例（STM32F103C8T6）
MEMORY
{
  FLASH : ORIGIN = 0x08000000, LENGTH = 64K
  RAM   : ORIGIN = 0x20000000, LENGTH = 20K
}

案例拆解：我们曾在一个RISC-V架构的ESP32-C3项目中使用 esp-hal 框架。该框架的启动流程与Cortex-M不同：ESP32-C3使用ROM引导程序加载二级引导程序，再由二级引导程序加载应用程序。此时 no_std 的启动代码需要与ESP-IDF的启动流程对接。通过阅读 esp-hal 源码，我们发现其内部使用了 esp_riscv_rt crate，该crate实现了RISC-V的启动协议，包括设置栈指针、初始化 .bss/.data、调用 main。这提醒我们：不同架构的启动流程差异巨大，必须使用对应架构的运行时crate。

4.5 最小可执行程序：从零构建一个能跑的固件

核心原理：一个最小的 no_std 程序需要满足三个条件：声明 #![no_std] 和 #![no_main]（不使用标准入口点）、提供panic处理函数、提供入口点（通过 #[entry] 或自定义汇编）。此外，还需要链接脚本和必要的crate依赖。这个程序虽然不能做任何有用的事，但它是验证工具链、链接脚本和运行时配置是否正确的最快方法。

操作流程：以Cortex-M为例，创建一个最小项目的步骤：

1. 创建新项目：cargo new --bin my_app
2. 编辑 Cargo.toml，添加依赖：cortex-m-rt、cortex-m、panic-halt（或自定义panic）。
3. 在 src/main.rs 中编写代码（见下方示例）。
4. 创建 memory.x 链接脚本。
5. 创建 build.rs 调用 cortex_m_rt::memory_x。
6. 使用 cargo build --target thumbv7em-none-eabihf 编译。

#![no_std]
#![no_main]

use cortex_m_rt::entry;
use panic_halt as _; // 引入panic处理，halt模式

#[entry]
fn main() -> ! {
    // 在这里初始化硬件
    loop {
        // 主循环
    }
}

实战场景：在开发板（如STM32F429 Discovery）上运行这个最小程序，通过调试器（OpenOCD + GDB）验证程序是否正确加载到Flash并执行。我们可以在 main 中设置一个断点，观察程序是否到达。如果程序没有到达 main，可能的原因包括：链接脚本错误（Flash/RAM地址不匹配）、向量表未正确放置、或者启动代码未正确初始化栈指针。通过查看反汇编（objdump -d）和内存映射（nm）可以快速定位问题。