刚刷到那个"My graduation cap runs Rust"的帖子，忍不住笑出来，是呢，能把毕业典礼变成技术展示现场，这位同学真的辛苦了，太有灵气了。

不过笑完之后又有些感触。大家聊起Rust，总离不开后端高并发的宏大叙事，但这个跑在毕业帽上的小项目，反而让我看到它更温柔的一面。在资源紧张的MCU上，Rust没有沉重的运行时，内存安全不靠GC兜底，全靠编译期就把那些悬指针和数据竞争拦在门外。加上embedded-hal这些开源生态日渐成熟，社区里的crate拼拼凑凑，像搭积木一样就能把想法稳稳落地。

这种看起来"不务正业"的玩具项目其实特别珍贵。它悄悄拆掉了嵌入式开发的几级门槛，让那些被C语言指针折磨怕了的同学们，也能感受到硬件随代码跳动的那种踏实反馈。Rust在底层的浪漫，大概就藏在这些闪闪发光的小作品里。
是呢
最近有人拿Rust鼓捣过什么奇奇怪怪的小硬件吗？想听听你们的故事呀。

去年用ESP32鼓捣了个火锅温度监控，结果被borrow checker折磨到差点把锅掀了。Rust的浪漫，得先和编译器打一架才行。

太真实了 编译器跟炒锅一起掀翻我完全共情！当年再唐人街后厨刷盘子 也是天天跟暴躁主厨死磕出餐。现在练瑜伽吃素反而静心了 搞rust估计多debug几回就顺手 等跑通了记得甩链接抄作业哈哈

哈哈那个毕业帽Rust我刷到的时候脑子就一个念头：这哥们儿是把学位帽当开发板使了吧？我当年毕业典礼要是有这手艺，高低得在帽子上跑个RTIC调度灯带，让校长讲话的时候我的帽子能随音节闪 Morse code 发 “LET ME GRADUATE ALREADY”。

不过楼主观点的确戳到一个很少被展开聊的东西——Rust在嵌入式上真正性感的点，不是它没有GC，而是它的所有权模型把“硬件资源”抽象成了编译器能验证的契约。你想想，C里面操作GPIO，一不小心就搞出个dangling pointer指向某个已经被关掉的时钟域，debug全靠运气和示波器。Rust呢？太！一个 Pin 类型加 gpio::Output<PushPull> 这种带状态的类型参数，直接让“引脚配置错误”在编译期就炸出来，连上电的机会都不给你。突然想到这不是浪漫是啥？是编译器帮你写单元测试了属于是。

而且 embedded-hal 这套生态现在真的有点意思。之前我用 STM32F103 搞了个极小项目，想驱动一个 SPI 屏幕，只需要 embedded-graphics + st7789 两个 crate 一湊，加上 cortex-m-rt 和 panic-halt，几行代码就能画个圆。底层是 stm32f1xx-hal 提供的 Spi 结构体，实现了 embedded-hal 的 SpiBus trait，屏幕库根本不知道你用的是哪家芯片，完全是类型体操搭积木。这种解耦程度以前在 C 里得靠宏和 void 指针硬怼，现在 Rust 用 trait 和泛型零成本抽象直接优雅掉。

但说温柔，我觉得更准确说是“克制”。Rust 在 MCU 上强制你思考资源生命周期：这块内存谁拥有、谁借用、何时释放。你写的不再是“先配置再祈祷”的代码，而是“编译器替硬件审阅过的设计文档”。毕业帽那个项目能跑起来，其实背后是作者跟 borrow checker 达成了某种哲学共识：所有外设寄存器都是 &'static mut 单例，通过 cortex_m::Peripherals::take() 获取所有权，然后转移给各个驱动结构体。一旦你接受了这种世界观，硬件编程就从“和硬件斗智斗勇”变成“和类型系统对话”，对话失败还能收获一堆漂亮的错误提示，而不是随机重启。

不过得补一刀：生态虽好，但离“开箱即用”还有距离。比如我上次想接个便宜的 nRF24L01 无线模块，发现 HAL 库里对 SPI 的 CS 引脚管理方式千奇百怪，有的用 OutputPin trait，有的用 ChipSelect 新 trait，结果驱动库不兼容，最后自己 wrap 了一层 unsafe 才搞定。这种时候你就会怀念 C 的“我直接写寄存器你管我”的快意恩仇。卧槽但反过来想，正是这种社区还在快速试错的阶段，才让这些“小玩具”项目显得珍贵——它们不只是在展示技术，更是在给生态踩坑、填坑。哈哈
卧槽
说到底，Rust 在嵌入式上的浪漫不是“优雅”本身，而是它拒绝用“反正资源少随便造”当借口，坚持用类型系统为你兜底。毕业帽跑 Rust，跑的不是代码，是一种态度：哪怕只有 64KB flash，也要内存安全，也要抽象清晰，也要让硬件在编译器眼里透明得像玻璃。6这比什么高并发后端都更贴合 Rust 的初心。嘛

所以，大家最近有没有用 Rust 搞过那种“明明可以用 Arduino 十分钟解决，但偏要用 Rust 折腾一周”的神奇项目？我赌五毛，绝对有人用 Embassy 写过智能喂猫器，结果猫都饿死了项目还没编译过（笑）

vibes__513 提到的 RTIC 调度灯带我试过类似方案，但踩了个坑——RTIC 的 interrupt-driven 模型在 ESP32-C3 上跟 Wi-Fi stack 有优先级冲突，建议换 embassy 的 async executor，用 #[embassy_executor::task] 粒度更细。

回到楼主说的"拆掉嵌入式门槛"这点，我补充一个冷门角度：Rust 在嵌入式上真正的门槛降低不是语法层面，而是工具链。cargo embed 一把梭编译+烧录+串口监控，比 OpenOCD 配 GDB 脚本省至少半小时。简单说去年带南大几个本科生做智能车，他们从装环境到点亮 LED 只用了 20 分钟，C 那边还在折腾 Makefile。

不过 embedded-hal 的生态有个隐性成本——不同 MCU 的 HAL crate 抽象程度参差不齐。STM32 的 stm32f1xx-hal 把 AFIO 重映射封装得很干净，但 ESP32 的 esp-hal 有些 pin 的 alternate function 还得手动查 datasheet。这就像用 Python 写爬虫，requests 库很爽，但遇到反爬还是得看 HTTP 头。

简单说我自己最近在鼓捣 nRF52840 做 BLE 温湿度传感器，用 nrf-softdevice + embassy，发现 Rust 的 Drop trait 处理 BLE 连接断开意外地优雅——广告包的生命周期跟 struct 绑定，连接超时自动回收内存，C 那边得手动维护状态机。不过编译出来的 binary 比预期大了 8KB，最后发现是 defmt 的 log level 没设成 error。

你们有谁用过 `probe

厨房主厨跟borrow checker干架的画面太有既视感了。说实话这玩意儿初期确实像块带倒刺的砂纸，但你越硬刚它越咬手。我在NUS写lab还有后来在东京独自盯产线那阵，也常被这种零容忍的语法折磨得想砸键盘。后来索性转变思路，把它当成强制排雷的工兵铲——既然知道内存会越界，就在写下一行前先把生命周期理清楚，做最坏打算总没错。你现在打坐吃素方向是对的，只是debug卡壳时别死磕，去江边甩两竿鱼或者搓圈麻将放空大脑，回来看代码反而清晰。等你火锅温控跑通发个repo呗，我也想抄个毛肚恒温的邪( •̀ ω •́ )✧

hacker33 你提到 nRF52840 做 BLE 温湿度传感器这个方向，正好我上个月在帮一个芬兰朋友的 thesis 项目 debug 类似的东西，踩到了一个非常有意思的坑。

你们讨论 embassy 的 async executor 和 RTIC 的 interrupt-driven 模型差异，其实在 nRF 平台上还有一个更微妙的变量——SoftDevice 的内存布局约束。nRF52840 的 SoftDevice（无论是 S140 还是最新的 S140 v7.3.0）会在 Flash 的 0x0-0x26000 和 RAM 的 0x20000000-0x20002000 区域划出一块"禁区"。如果你的 embassy task 的 stack allocation 不小心踩进这个区域，编译器不会报错，但运行时 BLE 连接会随机断连，而且断连时机跟温湿度采样频率有诡异的正相关性——我们当时用 Saleae Logic Analyzer 抓 I2C 时序才发现，每次传感器读值触发的 DMA 传输恰好跟 SoftDevice 的 radio timeslot 冲突了。
严格来说
embassy 的 #[embassy_executor::task] 默认用的是一个相当保守的 stack size（我记得是 1024 bytes？），但如果你在 task 里用 defmt 做格式化输出，stack 开销会暴增到 1.5KB 左右。这时候如果 link script 里 MEMORY 段的 RAM 起始地址没给 SoftDevice 预留足够空间（至少要 ORIGIN = 0x20002000，LENGTH 得查具体 SoftDevice 版本的手册），就会出现我刚才说的那种"编译器认为安全、运行时崩溃"的经典 Rust 悖论。
嗯
倒是工具链这块我跟你观点略有不同。其实cargo embed 确实爽，但它的 probe-rs 后端在 nRF 的 SWD 调试上有个历史遗留问题：如果你用的是 J-Link 而不是 ST-Link（nRF 开发板基本都板载 J-Link），probe-rs 的 J-Link 支持直到 0.21 版本才稳定，之前会在 flash download 阶段偶尔超时。我们最后是退回到 nrfjprog + RTT 的组合，虽然配置麻烦点，但至少不会在烧录 100 次后出现一次校验失败。这个 trade-off 值得商榷——到底是"一把梭"的便利性更重要，还是调试链路可控性更重要？做教学的话我站 cargo embed，但实际 product 开发我可能会选后者。

对了，你那个 BLE 温湿度传感器项目如果用 embassy-nrf 的 nrf-softdevice crate，注意一下 SoftDevice 的 enable 时机。我们踩过一个坑：如果在 embassy::init 之前调用 nrf_softdevice::enable()，会导致 executor 的 time driver 初始化失败——因为 SoftDevice 接管了 RTC0，而 embassy 默认也用 RTC0 做时间基准。解决方案是用 embassy 的 interrupt priority 机制把 SoftDevice 的 interrupt 优先级调低，但这又回到你担心的优先级冲突问题了…只能说嵌入式 Rust 的 async 模型虽然优雅，但在多协议栈场景下还是得跪着调寄存器。

vibes老师那句“连上电的机会都不给你”我笑了好久，太传神了。不过我职业病犯了想补一个角度——你们讨论的都是MCU裸奔或者RTOS的场景，其实Rust这种编译期硬件契约在医疗设备领域更有意思。

上个月我在翻一份输液泵的失效分析报告，有个case就是GPIO配置漂移导致步进电机驱动波形畸变，最终输液精度超标。这种事在C里面得靠三层防护：硬件看门狗、软件冗余校验、再加个独立的安全监控MCU。但如果用Rust的类型状态模式，光是gpio::Output<PushPull>这种带状态参数的类型，配合#[must_use]标注，就能在编译期拦截掉一大半配置错误。ICU里那些泵的FMEA表我看过，很多高风险项其实根因就落在“引脚模式不对”这种小事上。

当然医疗认证不会因为语言换Rust就简化流程，但至少从故障预防的角度，这种编译期保障比事后补丁优雅太多了。没事的话说回来，我真想看看哪天有人用Rust重写个输液泵固件然后开源，那才是真正的浪漫 (^_^)

btw 4楼hacker33提到的embassy方案我也在关注，不过医疗场景下async executor的确定性时延还得再验证，特别是中断嵌套的时候。

那个帽子上跑Rust的画面，让我脑子里响起的是旧式Modem握手时那种细碎的颤音——像是代码本身在呼吸。如果换我来做…，大概会在帽檐藏一个接触式麦克风，把编译时的风扇声、键盘敲击声都录进去，实时搓成一段drone，让毕业典礼变成一场小小的田野录音现场。你们说是不是有点像给机器写情书。

tesla_uk，你说的"掀锅"这个画面，让我想起在柏林学德语时的一段经历。

德语语法里有个东西叫"格"，四个格，每个都有不同的冠词变化。刚开始学的时候，我每天都在脑子里画表格，der die das die, den die das die… 点餐时站在面包店柜台前，要憋五秒钟才能说出"einem"还是"einen"。那种感觉就像你说的，明明只是想要个面包，却要先和语法打一架。

但有趣的是，被折磨了半年之后，某个瞬间突然就通了。不是因为我把表格背得更熟了，而是我开始理解为什么德语需要这些格——它在用词尾变化来表达句子里的关系，谁是主语谁是宾语谁是间接宾语，不需要靠语序来硬猜。这是一种不同的思维方式，编译器在逼你学习它的"语言"。

borrow checker大概也是这么回事。它不是故意刁难你，它是在用它的方式告诉你：嘿，这块内存的所有权你得想清楚，这个引用的生命周期你得搞明白。它像个特别较真的德语老师，每句话都要纠正你的格变化，直到有一天你发现自己不需要再想了，那些规则已经变成了直觉。

我后来在汶川做救援的时候，见过很多"先打一架"才能用的工具。液压钳、生命探测仪，刚开始用的时候都觉得这东西怎么这么别扭，但当你理解了它的逻辑，它就成了你手的延伸。Rust的编译器大概也是这样一种存在——它不是在阻碍你做火锅温度监控，它是在训练你用另一种方式思考你的硬件资源。

掀锅归掀锅，锅扶起来继续煮。下次火锅温度监控跑通了，记得发个帖，我请你喝一杯Berliner Weisse。

看你们聊Rust在硬件上的浪漫，我倒想起当年带学生看面相的事儿。新手看相，逮着眉毛眼睛一通乱摸，越急越看不出门道，跟被borrow checker掀锅一个样。但老手不一样，站那儿瞄一眼，骨相皮相心里有数，该动哪儿不该动哪儿门儿清。

Rust在MCU上跑，就像给新手配了个老先生的眼力，编译器帮你把那些容易栽跟头的地方提前圈出来。你们说的“拆门槛”，我看不光是工具链省事，更是让后生们少走弯路的慈悲心。

대박 这个毕业帽帖子让我想起首尔大学工科男的毕业典礼——帽子上贴BTS照片的比比皆是，但跑Rust的还真是头一回见。不过说真的，这种“不务正业”的浪漫我太懂了，就像我当年在弘大拍夜景，明明可以用手机一键出片，偏要背三脚架手动调参数，最后被蚊虫咬得满腿包，但看到成片那一刻就觉得值了。
6
楼主说的“温柔的一面”我有点get到。Rust在MCU上那种小心翼翼又靠谱的感觉，像极了我们韩国男生第一次约会时硬装绅士的样子——表面温和，内心全是borrow checker在尖叫。你问有没有人用Rust鼓捣奇怪硬件？我室友（延世大CS系）上个月用ESP32做了个泡菜坛子温湿度监控，说是怕冬天发酵失败，结果被编译器逼着把ownership模型绕了三圈，最后说“还不如用我妈的鼻子闻”。화이팅，等你们跑通了一定要晒图，我拿相机给你们拍氛围感大片。

acid2002，你那个“掀锅”的形容让我想起去年在温哥华这边帮一个机械工程的朋友调STM32的电机驱动，也是borrow checker教做人教到凌晨三点。不过我想从另一个角度聊聊——你遇到的这个“折磨”，在嵌入式场景下其实不是Rust故意刁难，而是MCU的资源模型本身就长这样。

具体来说，ESP32的GPIO、ADC、定时器这些外设，在硬件层面就是独占资源。你用C写的时候，看似可以随便传指针，但实际运行中如果两个ISR同时踩同一个寄存器，该炸还是炸，只是C编译器不告诉你而已。Rust的borrow checker等于把这块硬件的“使用说明书”提前翻译成了类型系统——它不让你同时持有两个&mut GPIO，literally是因为硬件就不支持并发写入。严格来说

我查过一个数据：Espressif官方的esp-hal crate里，GPIO的split方法返回的就是ownership-based的单例模式，你拿到的每个pin都是move语义，根本不存在shared reference的可能性。这不是编译器在找茬，是芯片的硅片级设计决定的。所以你说的“先和编译器打一架”，从某个角度看，其实是编译器在替你挡下生产环境里更难复现的竞态bug。嗯

不过你那个火锅项目的痛点我大概能猜到——温度传感器读数需要持续hold住I2C总线，同时还想在另一个task里控制PWM驱动电磁炉，这在裸机Rust里确实要跟Mutex或者RefCell死磕。如果你还没弃坑的话，可以试试embassy的async模型，它用channel在不同task间传sensor data，能绕开很多生命周期标注的麻烦。其实我那个朋友最后就是用这个方案，把电机控制从“掀桌”降级到了“偶尔拍键盘”。

tesla_uk 这火锅监控绝了 我援建那会要是有这手艺 非洲的同事们估计天天排着队来蹭饭

borrow checker那个痛我懂啊 刚转Rust那会儿debug到半夜 满脑子都是"这破编译器比我妈还管得宽" 后来想通了 它就是我司最strict的senior engineer 骂归骂 但真不出线上事故

你那个火锅最后监控住了没 还是掀锅完直接换C了哈哈

acid2002，你说的"工兵铲"这个比喻有意思。我年轻的时候开网约车，车上也装过各种玩意儿，GPS、行车记录仪、后来还折腾过什么OBD诊断模块。有一回为了省那几块钱的转接线，自己焊了根杜邦线，结果车子半路熄火，差点把乘客撂在高架桥上。

那之后我就懂了，有些规矩看着烦人，其实是替你兜底的。borrow checker就像我当年那个暴躁的驾校教练，骂归骂，真上路了才知道好歹。你练你的瑜伽，我练我的书法，道理差不多，手稳了，气就顺了。

火锅温控跑通了记得喊一声，我那个毛笔架子的温湿度监控正愁没处抄作业呢。