?️ 先把 Rust 工具链和 Cargo 环境支棱起来
搞嵌入式开发用 Rust，第一步得把环境搭对。这里说的环境，核心就是 Rust 工具链和 Cargo 的基础配置。普通桌面开发的 Rust 环境可能不够，嵌入式有它的特殊性，比如交叉编译、目标架构支持这些。
先装 rustup，这玩意儿是 Rust 的工具链管理器，跟嵌入式开发里的包管理工具类似，能帮你搞定不同版本的 Rust 编译器、标准库。官网那句 “curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh” 直接复制运行，按提示走就行。装完之后，rustc、cargo 这些命令就有了，输入 cargo --version 看看有没有反应，有就说明基础成了。
但嵌入式不一样，得加目标平台的标准库。比如常见的 ARM Cortex-M 系列，目标架构可能是 thumbv7m-none-eabi，这时候就得用 rustup target add thumbv7m-none-eabi。具体加哪个，得看你用的芯片，查手册或者芯片型号里的架构信息，别瞎加，加错了后面编译肯定报错。
还有些 Cargo 的辅助工具得装上，比如 cargo-generate，创建项目时能直接用模板，省得自己从头写配置；cargo-edit，能方便地加依赖、改版本，比手动改 Cargo.toml 靠谱。装的话就 cargo install cargo-generate cargo-edit，等它跑完，这些工具就进了你的路径，随时能用。
? 给嵌入式目标平台搭好 “通信桥”
嵌入式开发的核心是跟特定硬件打交道，Cargo 默认的配置是给桌面系统的，想让它认识你的芯片，得配置交叉编译工具链。这玩意儿就像个翻译，能把 Rust 代码转换成芯片能懂的机器码。
首先得确认你的芯片架构对应的目标三元组。比如 ARM Cortex-M0 是 thumbv6m-none-eabi，Cortex-M4F 带浮点的是 thumbv7em-none-eabihf，这个千万别弄错。不确定的话，查 Rust 官方的目标列表，或者芯片厂商给的开发文档，上面肯定有。
然后装对应的交叉编译工具链，比如 GNU 的 arm-none-eabi-gcc。Linux 用户直接用包管理器装，ubuntu 系的 sudo apt install gcc-arm-none-eabi，Fedora 系的 sudo dnf install arm-none-eabi-gcc。Windows 用户可能得装个 MinGW 或者直接用 MSYS2，macOS 就用 brew install arm-none-eabi-gcc。装完之后，敲 arm-none-eabi-gcc --version，有输出就说明成了。
接下来要告诉 Cargo 用这个工具链。在项目根目录建个.cargo 文件夹，里面放个 config.toml 文件，写上 [target.thumbv7m-none-eabi]，然后 linker = "arm-none-eabi-ld"，runner = "openocd"（后面调试用）。这样 Cargo 编译的时候就知道该找谁帮忙链接了，不会傻乎乎地用系统默认的编译器。
对了，有些芯片需要特定的链接脚本（.ld 文件），比如指定内存布局、程序入口这些。这时候得在 Cargo.toml 里加个 [profile.dev]，然后 rustflags = ["-C", "link-arg=-Tmemory.x", "-C", "link-arg=-Tlink.x"]，把链接脚本的路径传进去。这些脚本要么芯片厂商给，要么用社区维护的，比如 cortex-m-rt 库里就有现成的，直接引过来用就行。
? 手把手改 Cargo.toml，适配嵌入式场景
Cargo.toml 是项目的 “说明书”，嵌入式项目的这个文件跟普通 Rust 项目比，多了不少针对硬件的配置。改对了，后面编译测试才能顺顺当当。
先看 [package] 部分，name、version、edition 这些常规的填上就行，edition 建议用 2021 或更高，新特性对嵌入式开发更友好。重点是 [dependencies]，这里要加嵌入式开发的核心库。比如 cortex-m，这是 ARM Cortex-M 系列的基础库，处理中断、寄存器这些；cortex-m-rt，负责启动代码和运行时环境；还有 embedded-hal，硬件抽象层，帮你屏蔽不同芯片的差异，写跨平台代码。加的时候指定版本，比如 cortex-m = "0.7.7"，别用 *，免得自动升级出兼容问题。
然后是 [profile] 配置，嵌入式设备资源有限，内存、Flash 都小，得优化编译参数。[profile.dev] 里，debug = true 方便调试，但可以加 opt-level = 1，稍微优化一下，不然代码太大跑不起来。[profile.release] 里，opt-level = "s"（优化大小）或者 "z"（更激进的大小优化），codegen-units = 1（减少代码体积，牺牲点编译速度），debug = false（关掉调试信息）。这些参数能让生成的二进制文件小不少，尤其对 Flash 容量小的芯片来说，太重要了。
还有个 [features] 部分，有时候需要针对不同硬件型号做适配，比如同一系列的芯片，有的带蓝牙，有的不带。可以在这里定义 feature，比如 "bluetooth" = ["dep:nrf52840-bluetooth"]，编译的时候用 cargo build --features bluetooth，就能只编译带蓝牙的版本，灵活得很。
哦对了，有些嵌入式库需要启用特定的特性才能用，比如 cortex-m-rt 需要 "device" 特性来指定具体芯片，这时候得在依赖里写 cortex-m-rt = {version = "0.7.3", features = ["device"] }，然后在项目里加个 device.x 文件，指定芯片的内存布局，这些细节别漏了，不然编译肯定报错。
? 用 Cargo 构建嵌入式程序，避开这些坑
配置都弄好了，就该用 Cargo 构建程序了。嵌入式构建跟桌面不一样，步骤不多，但坑不少，踩过一次就记住了。
最基本的构建命令是 cargo build --target thumbv7m-none-eabi，这里的 target 就是前面加的目标架构。第一次跑这个命令，Cargo 会下载依赖、编译库，可能有点慢，耐心等。如果报错说 “can't find linker”，那就是.cargo/config.toml 里的 linker 没设对，或者交叉编译工具链没装好，再检查检查路径。
构建完了，生成的二进制文件在 target/thumbv7m-none-eabi/debug/（或者 release/）下面，文件名跟项目名一样。但这时候的文件是 ELF 格式，嵌入式设备一般要烧录 hex 或者 bin 格式的文件。这时候得用交叉工具链里的 objcopy 转换一下，比如 arm-none-eabi-objcopy -O ihex target/.../app app.hex，或者 - O binary 生成 bin 文件。嫌手动转换麻烦？可以装个 cargo-binutils，然后用 cargo objcopy -- -O ihex app.hex，一步到位，方便多了。
还有个常见问题是代码体积太大，超过芯片的 Flash 容量。这时候除了在 profile 里优化，还可以用 cargo bloat 看看哪些函数占空间，命令是 cargo bloat --target thumbv7m-none-eabi --release，能列出每个函数的大小，一目了然。发现某个库占太多？看看能不能换个轻量的替代库，或者自己实现简单版本。比如用 heapless 替代标准库的 Vec，内存占用能小一大截。
链接错误也经常遇到，比如 “undefined reference to `_sbrk'”，这是因为标准库的某些函数（比如 printf 相关）需要操作系统支持，嵌入式里没有，得用 libc 的嵌入式版本，或者加个 no_std 属性。在 main.rs 开头加上 #![no_std] #![no_main]，然后用 panic_handler 定义一个 panic 处理函数，比如用 panic-halt 库，直接 cargo add panic-halt，就能解决大部分链接问题。
哦对了，构建的时候最好加上 --verbose，比如 cargo build --target ... --verbose，这样能看到详细的编译和链接命令，出问题了方便排查。比如某个库没找到，从输出里能看到具体的搜索路径，就知道是依赖没装还是路径错了。
? 嵌入式环境下，Cargo 测试怎么跑通
写代码哪能不测试？但嵌入式的测试跟桌面不一样，没法直接在硬件上跑单元测试，得想点办法。Cargo 的测试功能其实能用上，就是得变通一下。
最简单的是用 “宿主测试”，就是把测试代码编译成电脑能跑的程序，模拟硬件环境。比如测试一个计算函数，不涉及硬件操作，直接用 cargo test 就行，跟普通 Rust 项目一样。这时候要注意，测试代码里别引用硬件相关的库，不然编译不过。可以用 #[cfg (test)] 把测试代码包起来，再用条件编译排除硬件依赖，比如 #[cfg (not (target_os = "none"))]，这样测试的时候就不用链接嵌入式库了。
涉及硬件交互的测试，就得用 “目标测试”，在真实硬件上跑。这时候需要调试器帮忙，比如 J-Link、ST-Link。先装个 cargo-embed 或者 cargo-flash，这些工具能把测试程序烧到硬件里，还能捕获输出。比如用 cargo embed --test my_test，它会自动烧录程序，然后通过调试接口把测试结果传回来。不过这要求芯片支持调试，而且调试器接线正确，不然要么烧不进去，要么没输出。
还有个办法是用 QEMU 模拟嵌入式环境，比如模拟一个 ARM Cortex-M3 的芯片，然后在模拟器里跑测试。先装 qemu-system-arm，然后在.cargo/config.toml 里配置 runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting -kernel"，之后用 cargo run --target ... 就能在模拟器里运行程序，测试也能用 cargo test --target ... --no-run，生成测试二进制后用 QEMU 跑。这种方式不用真实硬件，适合前期快速验证，但模拟的环境毕竟跟真实硬件有差异，复杂的外设交互还是得在硬件上测。
测试的时候经常需要打印信息，嵌入式里没有 stdout，得用 semihosting（半主机模式），让程序通过调试器把信息传到电脑上。在代码里加个 println! 不行，得用 cortex-m-semihosting 库的 hprintln! 宏，然后编译的时候加上 --features cortex-m-semihosting/std，烧录的时候确保调试器支持 semihosting。这样测试结果就能在终端里看到，跟桌面测试差不多方便。
? 调试工具链和 Cargo 的联动技巧
写嵌入式代码，调试是家常便饭。Cargo 本身不直接管调试，但能跟调试工具配合得很好，让整个流程顺起来。
最常用的调试组合是 gdb + openocd（或者 J-Link GDB Server）。先启动 openocd，加载对应芯片的配置文件，比如 openocd -f interface/stlink.cfg -f target/stm32f4x.cfg，它会在本地开个 GDB 服务器，默认端口 3333。然后用 cargo build 生成调试版本的二进制，再启动 gdb：arm-none-eabi-gdb target/.../app。在 gdb 里输入 target remote :3333，就能连接到调试器，之后就能设置断点（break main）、单步执行（step）、查看变量（print x）了。嫌手动输命令麻烦？可以写个.gdbinit 脚本，把常用命令放进去，gdb 启动时自动执行。
还有个更方便的工具是 cargo-gdb，装完之后直接 cargo gdb --target thumbv7m-none-eabi，它会自动编译程序、启动 gdb、连接调试器，一步到位。调试的时候想看寄存器状态？用 monitor reg 命令（openocd 里的），或者在 gdb 里输入 info registers，能看到 R0-R15 这些寄存器的值，对定位硬件相关的 bug 特别有用，比如中断没响应，可能就是中断使能寄存器没设对。
有时候程序跑飞了，或者进入了硬 fault，光看代码找不出问题。这时候可以用 cargo-embed 配合 rtt（实时传输技术），在代码里加 rtt 日志，比如用 segger-rtt 库，程序运行时就能实时输出日志，不用停程序。哪怕程序崩溃了，崩溃前的日志也能传出来，帮你定位是哪一步出了问题。这种方式比 printf 调试高效多了，尤其适合调试实时性要求高的代码。
烧录程序也能跟 Cargo 联动，不用每次手动用烧录工具。装个 cargo-flash，配置好调试器和芯片型号，之后 cargo flash --target ... 就能直接把程序烧进芯片，还能指定烧录地址（比如 0x08000000）。如果想在烧录后自动运行，加个 --run 参数。对量产来说，这比手动操作快多了，还能集成到 CI 流程里，自动化测试烧录。
? 实际案例：用 Cargo 搞定 STM32F4 开发
光说理论太空泛，拿 STM32F407 这款常用芯片举个例子，从头到尾走一遍，看看 Cargo 怎么玩转嵌入式开发。
先创建项目，用 cargo generate --git https://github.com/rust-embedded/cortex-m-quickstart，输入项目名 stm32f4-demo，选目标架构 thumbv7em-none-eabihf（因为 F407 是 Cortex-M4F，带浮点）。生成的项目里已经有基础配置，省了不少事。
然后改 Cargo.toml，加芯片支持库：cargo add stm32f4xx-hal --features "stm32f407,rt"，这个库封装了 F407 的外设。再加个依赖 cargo add embedded-hal，方便用硬件抽象层的接口。这时候 [dependencies] 里就有了 cortex-m、cortex-m-rt、stm32f4xx-hal 这些核心库，基本能操作 GPIO、定时器这些外设了。
接下来写代码，在 src/main.rs 里，先用 #![no_std] #![no_main] 禁用标准库和 main 函数，然后用 #[entry] 定义程序入口，这是 cortex-m-rt 提供的宏。初始化时钟、设置一个 GPIO 为输出，然后写个循环让 LED 闪烁：用 stm32f4xx_hal 的 gpio 模块，把 PA5（开发板上通常接 LED）设为推挽输出，然后每隔一段时间翻转一次电平。代码不用太长，几十行就能实现。
构建一下，cargo build --target thumbv7em-none-eabihf，这时候可能会报链接错误，说找不到内存脚本。在项目根目录建个 memory.x 文件，写上 RAM : ORIGIN = 0x20000000, LENGTH = 192K，FLASH : ORIGIN = 0x08000000, LENGTH = 1024K，这是 F407 的内存布局。然后在.cargo/config.toml 里加 rustflags = ["-C", "link-arg=-Tmemory.x"]，再编译就过了。
烧录程序，用 cargo flash --chip stm32f407vg --target thumbv7em-none-eabihf，确保 ST-Link 接好，开发板上电。工具会自动找到调试器，把程序烧进 Flash，完了之后 LED 就开始闪了，成了！
想调试一下？启动 openocd，然后 cargo gdb --target ...，在 gdb 里设个断点在翻转 LED 的地方，单步执行，看着 LED 亮灭，是不是很直观？如果想改 LED 闪烁频率，直接改代码里的延时参数，cargo build 再烧录，比用 IDE 点半天鼠标快多了。
【该文章由dudu123.com嘟嘟 ai 导航整理，嘟嘟 AI 导航汇集全网优质网址资源和最新优质 AI 工具】
