MicroPython 是什么、值不值得用：单片机上跑 Python（v1.29.0）

MicroPython 是跑在单片机上的 Python 实现，采用 MIT 许可证，仓库在 micropython/micropython，官网 micropython.org，最新版本 v1.29.0，发布于 2026-08-24。

关于许可证有一件事值得单独说：GitHub 的接口对这个仓库返回的是 NOASSERTION，也就是"识别不出来"。这不代表它没有许可证——把仓库里的 LICENSE 文件打开，第一行写着 The MIT License (MIT)，版权行是 Copyright (c) 2013-2026 Damien P. George。机器识别失败和真的没有授权是两回事，遇到 NOASSERTION 别急着下结论，读原文两分钟就清楚了。

下面说正题。这篇不打算劝你用它，因为它是个取舍，不是升级。

先弄清楚你在用的到底是什么

很多人第一次听说"单片机能跑 Python"，脑子里的画面是：像在电脑上那样写个 .py 文件，然后有个编译器把它变成机器码烧进芯片。

不是这样的。

你烧进芯片的是 MicroPython 本身——一个固件。烧完之后，这块芯片的身份就变了：它不再是"运行你程序的芯片"，而是"运行着一个 Python 解释器的芯片"。你的代码不再是被编译的对象，而是喂给这个解释器的输入。

于是工作方式整个换了一套。你用串口连上去，会看到一个提示符，敲一行 Python 它执行一行，这就是 REPL——交互式解释器，跟你在电脑上敲 python 回车看到的是同一种东西。想让程序开机自己跑，就把脚本文件传到芯片的文件系统里。

对比一下传统 C 的流程：写代码、编译、链接、生成 bin、烧录、复位、看现象。改一个数值，这七步要重来一遍。而在 MicroPython 里，你在 REPL 里直接改，回车，现象立刻出来。

这就是它最核心的价值，也是最容易被"Python 语法简单"这个说法带偏的地方。语法简单只是入场券，真正省时间的是这个反馈回路。

要说明的是，烧固件这一步本身还是老规矩，该用烧录工具还是得用。乐鑫平台走命令行的看 esptool，想点按钮的看 Flash 下载工具。哪些板子有现成固件、怎么下载对应版本，以官方文档为准，这块变动比较频繁，我不在这里列清单。

省下来的是什么

不用配工具链。 这一条对新手的意义比老手想象的大。传统嵌入式开发的第一道坎从来不是写代码，是把环境跑起来——编译器版本、路径、构建系统、驱动。很多人是死在这一步，还没写第一行逻辑就放弃了。MicroPython 把这道坎搬到了固件里，烧一次固件之后，你面对的就只剩下"写 Python"这一件事。

改完直接跑。 上面说过了，不重复。但要强调的是这个优势在排查问题时最明显：传感器读回来的数是不是对的？在 REPL 里当场读一次就知道，不用为了看一个数字重新烧一遍。

REPL 能当探针用。 这是我觉得最被低估的一点。板子已经在跑着了，你可以直接连上去，敲几行代码去读某个引脚的当前状态、去试一次外设通信、去看看某个变量现在是几。这种"活体探查"的能力，在编译型流程里得靠加日志、重新烧录、复现现象来实现，中间隔着好几分钟。

上手门槛低。 会 Python 的人比会 C 的人多得多。如果你的目标是让一个不做嵌入式的人（产品经理、学生、做算法的同事）能自己动手改点东西，这条价值巨大。

付出去的是什么

这一半必须诚实讲，否则前面那些就成了广告。

解释执行有固定开销。 每一条语句都要经过解释器这一层，这层开销不管你怎么优化代码都在。同样一段循环，编译成机器码直接跑，和交给解释器一句句解释着跑，差距是结构性的，不是"写得好一点就能追上"的量级。

内存占用高。 单片机的 Flash 和 RAM 是以 KB 计的，跟电脑上动辄几个 GB 完全不是一个世界。解释器本身要占地方，Python 的对象模型、动态类型、每个变量背后的元信息也都要占地方。你能用的空间比同一块芯片跑 C 时少，这是明摆着的账。

GC 会带来不确定的停顿。 Python 靠垃圾回收管内存，你不用手动 free——代价是垃圾回收什么时候触发、跑多久，不完全由你决定。对于"读个温度、判断一下、发出去"这类活，停顿几毫秒没人在乎。但如果你在做电机换相、做严格节拍的采样、或者中断必须在一个很窄的窗口内响应完，这种不确定性就是致命的。实时性差在"不确定"，不是差在"慢"，这两件事要分开看。

底层控制不如 C 直接。 Python 层给你的是封装好的接口。大部分时候这是好事，省心。但当你需要贴着寄存器做点非常规操作——某个外设的特殊模式、某个时序上的精细配合——封装就成了隔阂。你要么找不到对应的入口，要么找到了但性能不够。

它和你电脑上的 Python 是什么关系

语法是 Python，这没错。但标准库是精简过的子集。

原因不难理解：电脑上的 Python 标准库有几十兆，单片机的 Flash 装不下，很多模块（文件系统深度操作、多进程、桌面相关的东西）在单片机上也没有意义。所以 MicroPython 做的是取舍——保留核心语言特性和最常用的那部分库，去掉其余。

这里有个具体的、几乎所有人都会踩的坑：别按 PyPI 的思路找包。

你在电脑上写 Python 的习惯是，遇到需求先搜有没有现成的库，pip install 一下就完事。这套思路搬到单片机上会连续碰壁：大量 PyPI 上的包依赖 CPython 的完整标准库，依赖 C 扩展，依赖操作系统提供的能力，这些在单片机上都不存在。装不上是常态，不是意外。

正确的心态是：把它当成一门"语法长得像 Python 的嵌入式语言"，而不是"能跑 Python 的板子"。 需要什么功能，先去官方文档看它提供了什么，而不是先去想电脑上是怎么做的。哪些模块可用、接口叫什么名字，以官方文档为准——版本之间会有调整，照着几年前的博客敲很容易撞上已经改掉的写法。

那到底该不该用

我给两条判据，比"性能够不够"这种模糊问题好用。

第一条：这个项目对时序和内存有多敏感？

如果你的核心逻辑里有"必须在多少微秒内响应"、"采样节拍不能抖"、"这段代码不能被打断"这类硬约束，那 GC 的不确定停顿就是个绕不开的雷，别赌。反过来，如果你的活是"隔几秒读一次、判断一下、通过网络发出去"，时序余量宽到以秒计，那 Python 慢的那点开销你根本感觉不到，白白享受开发效率的提升。

内存同理。已经在为几 KB 抠字节的项目，加一层解释器进来只会更紧张。

第二条：你在做产品，还是在做验证、原型和教学？

做验证和原型的时候，你要的是尽快知道这条路走不走得通。方案能不能成、传感器数据长什么样、通信链路通不通——这些问题的答案越早拿到越好，至于最终产品是不是用 Python 写的，那是下一阶段的事。这个阶段 MicroPython 几乎是最优解。

做教学也一样。让人理解"引脚是什么、传感器怎么读、状态机怎么写"，用 Python 讲比用 C 讲少了一大堆干扰项。

而当你在做量产产品，要抠成本（换更便宜的芯片就意味着资源更紧）、要压功耗、要保证在最差情况下也能满足时序，那么该用 C，或者上一个真正的实时内核。国产 RTOS 这条线可以看 RT-Thread，那是完全不同的取舍：控制力强、确定性好，代价是你得自己管更多事。

一个很常见也很健康的路径是：先用 MicroPython 把方案验证通，再决定要不要用 C 重写。 这不是浪费，前期省下的时间通常远多于重写花的时间，而且重写的时候你已经完全清楚要做什么了。

还有一类情况根本不需要写代码：如果你做的是常见的智能家居设备、传感器上报到家庭自动化平台这类活，配置化的方案比写脚本更省事，见 ESPHome。

上手时的几个实际问题

串口是命门。 REPL 走的是串口，串口不通就什么都做不了。看不到端口先查驱动，常见的 CH340 见 CH340 驱动。连上了但满屏乱码，多半是波特率没对上，换算用进制与波特率换算工具，串口本身的原理见 UART 串口原理。

串口是独占的。 你的串口调试助手窗口还开着，REPL 工具就连不上，反过来也一样。这条几乎每个人都会栽一次。日常收发调试见 UartAssist 或站内的串口调试工具，但记得用完关掉。

烧录失败先怀疑供电。 尤其是带无线的板子，发射瞬间的电流尖峰会让只靠 USB 供电的链路撑不住，表现出来就是"时好时坏"。这类现象的排查思路见 ESP32 供电那篇。

最后回到那句判断：MicroPython 卖的不是"简单"，是"快"——开发速度快，不是运行速度快。这两个"快"在什么项目上更值钱，你自己心里应该有数了。