3、Rust无标准库编程：#![no_std]与#![no_main]、核心库与标准库区别、panic处理、全局分配器

裸机嵌入式开发意味着我们的程序运行在没有操作系统、没有MMU、没有文件系统、甚至可能没有堆内存的裸金属硬件上。Rust 标准库（std）默认依赖操作系统提供的系统调用、线程、文件I/O和动态内存管理，这些在裸机环境中都不存在。因此，我们必须使用 #![no_std] 和 #![no_main] 两个属性，让编译器知道我们正在构建一个面向裸机的程序。本章将深入剖析这两个属性的作用、核心库（core）与标准库（std）的本质区别、panic 处理机制以及全局分配器的实现原理，帮助你建立 Rust 裸机编程的底层认知框架。

Rust 裸机程序启动与运行时组件关系图 #![no_main] 无 main 入口，使用 #[entry] #![no_std] 不链接标准库 std core 核心库 - 基础类型 (Option, Result, Iterator) - 算术/位运算/原子操作 - 切片/str/数组/函数指针 - 不依赖操作系统和堆 - 永远可用 std 标准库 - 包含 core 全部内容 - 堆分配 (Box, Vec, String) - 线程/文件/网络/时间 - 依赖操作系统内核 - 裸机不可用 包含 panic 处理机制 #[panic_handler] 必须定义 - 默认行为：无限循环 (loop {}) - 可自定义：记录日志/复位/进入低功耗 全局分配器 (Global Allocator) #[global_allocator] 静态变量 - 实现 GlobalAlloc trait - 可选：不使用堆则无需定义 裸机启动流程 复位向量 → 初始化栈指针 → 拷贝 .data / 清零 .bss → 调用 #[entry] 函数 → 初始化外设 → 进入主循环 (loop {})

3.1 核心原理：#![no_std] 与 #![no_main] 的本质

#![no_std] 是一个 crate 级属性，告诉 Rust 编译器不要自动链接标准库（std），而是仅链接核心库（core）。核心库是标准库的一个子集，它不依赖操作系统，不涉及堆内存分配、文件系统、网络、线程等高级抽象。核心库提供了语言本身所需的基础设施：基本数据类型（如 Option、Result、整数类型）、迭代器、切片、字符串切片（&str）、原子操作、内存操作（copy、swap）等。这些功能完全由编译器内建实现，不依赖任何外部运行时。

#![no_main] 则告诉编译器：这个程序没有传统的 main 函数入口。在裸机环境中，程序的入口点由链接脚本和启动代码决定，通常是一个名为 Reset 的中断向量或一个由 #[entry] 属性标记的函数。使用 #![no_main] 后，编译器不会生成对 main 的调用，而是期望开发者通过 #[entry]（来自 cortex-m-rt 或 riscv-rt 等 crate）或自定义的链接脚本指定入口。

关键区别表：core vs std

维度core 核心库std 标准库
依赖操作系统否是
堆内存分配不提供（需自定义全局分配器）提供（Box, Vec, String）
线程/进程无有
文件/网络无有
时间/时钟无（需通过外设访问）有（系统调用）
panic 处理需自定义 #[panic_handler]默认打印栈回溯并退出
适用场景裸机、内核、嵌入式应用层、桌面、服务器

3.2 判断方法与操作流程：如何正确配置裸机项目

在创建裸机 Rust 项目时，需要遵循以下步骤来确保 #![no_std] 和 #![no_main] 正确生效：

  1. 创建二进制 crate：在 Cargo.toml 中设置 [package] 和 [[bin]]，确保是二进制项目而非库项目。
  2. 添加 crate 级属性：在 main.rs 或 lib.rs 文件顶部添加 #![no_std] 和 #![no_main]。
  3. 引入运行时 crate：根据目标架构添加 cortex-m-rt（ARM Cortex-M）或 riscv-rt（RISC-V）等 crate，它们提供 #[entry] 属性和启动代码。
  4. 定义 panic handler：必须实现 #[panic_handler] 函数，否则链接失败。
  5. 配置链接脚本：使用 memory.x 或类似文件定义 Flash 和 RAM 的起始地址与大小。
  6. 交叉编译：使用 rustup target add thumbv7em-none-eabihf 等命令添加目标平台，并通过 cargo build --target 构建。
// 典型的裸机入口代码示例
#![no_std]
#![no_main]

use cortex_m_rt::entry;
use panic_halt as _; // 使用 halt 策略：panic 时进入无限循环

#[entry]
fn main() -> ! {
    // 初始化外设...
    loop {
        // 主循环
    }
}

3.3 panic 处理机制：从默认到自定义

在 no_std 环境中，panic 处理是一个必须由开发者明确提供的组件。标准库的默认 panic 行为（打印错误信息并退出进程）在裸机上不可用，因为既没有标准输出，也没有操作系统来终止进程。因此，我们需要通过 #[panic_handler] 属性定义一个函数，该函数在程序发生 panic 时被调用。

常见的 panic 策略包括：

  • 无限循环（halt）：最简单的策略，进入 loop {} 让程序停住，便于调试器查看现场。
  • 复位重启：调用 cortex_m::peripheral::SCB::sys_reset() 让系统复位，适用于需要自动恢复的场合。
  • 日志输出：通过 UART 或 SWO 输出 panic 信息，便于远程诊断。
  • 进入低功耗模式：在电池供电设备中，panic 时进入睡眠以节省电量。
// 自定义 panic handler 示例
#[panic_handler]
fn panic(info: &core::panic::PanicInfo) -> ! {
    // 关闭中断，防止嵌套 panic
    cortex_m::interrupt::disable();
    
    // 尝试通过 UART 输出错误信息（需要自行实现 put_str）
    if let Some(location) = info.location() {
        uart_put_str("Panic at ");
        uart_put_str(location.file());
        uart_put_str(":");
        uart_put_u32(location.line());
    }
    
    // 进入无限循环
    loop {}
}

重要提醒：panic handler 必须是发散函数（返回类型为 !），且不能依赖任何可能自身会 panic 的代码。在 panic handler 中调用可能 panic 的函数会导致双重 panic，通常会使系统挂死。

3.4 全局分配器：何时需要以及如何实现

全局分配器（Global Allocator）是 no_std 环境中启用堆内存分配的关键组件。如果你在裸机程序中需要使用 Box、Vec、String 等动态数据结构，就必须实现一个全局分配器。但请注意：在资源受限的嵌入式系统中，堆分配往往是不推荐的，因为它引入了不确定性（内存碎片、分配失败）和额外的运行时开销。

实现全局分配器需要以下步骤：

  1. 实现 GlobalAlloc trait：定义 alloc 和 dealloc 方法。
  2. 定义静态分配器实例：使用 #[global_allocator] 属性标记一个静态变量。
  3. 提供内存池：通常使用一个静态数组作为堆内存，配合简单的分配算法（如空闲链表、伙伴系统）。
// 一个极简的全局分配器示例（仅用于教学，不适用于生产）
use core::alloc::{GlobalAlloc, Layout};
use core::cell::UnsafeCell;

struct BumpAllocator {
    heap_start: usize,
    heap_end: usize,
    next: UnsafeCell<usize>,
}

unsafe impl GlobalAlloc for BumpAllocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        let next = self.next.get();
        let alignment = layout.align();
        let size = layout.size();
        
        // 对齐到 alignment 的倍数
        let aligned_addr = (*next + alignment - 1) & !(alignment - 1);
        
        if aligned_addr + size > self.heap_end {
            return core::ptr::null_mut(); // 内存不足
        }
        
        *next = aligned_addr + size;
        aligned_addr as *mut u8
    }
    
    unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {
        // Bump 分配器不回收内存，dealloc 为空操作
    }
}

// 在链接脚本中预留堆空间
static mut HEAP_MEMORY: [u8; 1024] = [0; 1024];

#[global_allocator]
static ALLOCATOR: BumpAllocator = BumpAllocator {
    heap_start: 0, // 实际地址在运行时初始化
    heap_end: 0,
    next: UnsafeCell::new(0),
};

经验建议：在大多数裸机 RTOS 项目中，建议尽量避免使用堆分配。优先使用静态分配（static mut）、内存池或栈上分配。如果确实需要动态内存，考虑使用 heapless crate 提供的固定容量容器（如 Vec<T, N>），它们在编译时确定大小，不会产生运行时分配失败。

3.5 案例拆解：从零构建一个最小可运行的裸机程序

下面我们通过一个完整的案例，将本章所有概念串联起来。假设我们使用 STM32F103 微控制器（ARM Cortex-M3 内核），目标是让板载 LED 闪烁。

项目结构：

my_blink/
├── Cargo.toml
├── memory.x
└── src/
    └── main.rs

Cargo.toml：

[package]
name = "my_blink"
version = "0.1.0"
edition = "2021"

[dependencies]
cortex-m = "0.7"
cortex-m-rt = "0.7"
panic-halt = "0.2"

[[bin]]
name = "my_blink"
path = "src/main.rs"

memory.x（链接脚本）：

MEMORY
{
  FLASH : ORIGIN = 0x08000000, LENGTH = 64K
  RAM   : ORIGIN = 0x20000000, LENGTH = 20K
}

src/main.rs：

#![no_std]
#![no_main]

use cortex_m::peripheral::Peripherals;
use cortex_m_rt::entry;
use panic_halt as _;

#[entry]
fn main() -> ! {
    let peripherals = Peripherals::take().unwrap();
    let rcc = &peripherals.RCC;
    let gpioa = &peripherals.GPIOA;
    
    // 使能 GPIOA 时钟
    rcc.ahbenr.write(|w| w.iopaen().set_bit());
    
    // 配置 PA5 为推挽输出（LED 通常接在 PA5）
    gpioa.crl.modify(|_, w| unsafe {
        w.mode5().output_2mhz()
         .cnf5().push_pull()
    });
    
    loop {
        // 点亮 LED
        gpioa.bsrr.write(|w| w.bs5().set_bit());
        delay(1_000_000);
        
        // 熄灭 LED
        gpioa.bsrr.write(|w| w.br5().set_bit());
        delay(1_000_000);
    }
}

fn delay(cycles: u32) {
    for _ in 0..cycles {
        unsafe { core::arch::asm!("nop"); }
    }
}

构建与运行：

rustup target add thumbv7em-none-eabihf
cargo build --target thumbv7em-none-eabihf --release
# 使用 OpenOCD 或 ST-Link 烧录生成的 ELF 文件

案例分析：这个案例展示了 #![no_std] 和 #![no_main] 的实际应用。程序没有 main 函数，而是通过 #[entry] 属性标记入口。我们使用了 panic-halt crate 提供的 panic handler，它会在 panic 时进入无限循环。整个程序没有使用任何堆内存，因此不需要定义全局分配器。如果后续需要添加动态数据结构，就必须实现 #[global_allocator]。

3.6 常见误区与总结复盘

在裸机 Rust 编程中，初学者常犯以下错误：

  • 忘记添加 #![no_main]：如果只添加 #![no_std] 而不添加 #![no_main]，编译器会尝试寻找 main 函数，导致链接错误。
  • 在 no_std 环境中使用 std 类型：如直接使用 Vec、String 而不引入 alloc crate 和全局分配器，会导致编译失败。
  • panic handler 中调用可能 panic 的函数：例如在 panic handler 中使用 unwrap()，可能导致双重 panic。
  • 忽略链接脚本：没有正确配置 memory.x，导致程序无法在目标硬件上运行。
  • 在中断处理函数中执行复杂操作：中断上下文中的 panic 处理需要特别小心，避免死锁或资源竞争。

本章核心要点回顾：

组件作用是否必须
#![no_std]禁用标准库，仅使用核心库是（裸机）
#![no_main]禁用 main 入口，使用自定义入口是（裸机）
#[panic_handler]定义 panic 时的行为是
#[global_allocator]提供堆内存分配能力否（除非需要堆）
#[entry]标记程序入口点是（使用 cortex-m-rt 时）

理解这些基础组件是裸机 Rust 开发的基石。在实际项目中，建议从最小的可运行程序开始，逐步添加功能。每添加一个依赖或特性时，都要思考它是否引入了对操作系统或堆内存的依赖。保持程序的简单性和确定性，是嵌入式系统设计的第一原则。

← 上一章 📖 返回目录 下一章 →