1. 先把丑话说在前面Python在嵌入式世界的边界经常有人问“Python能做嵌入式开发吗”尤其是从互联网或后端转过来的朋友习惯了一门语言打天下就想在嵌入式领域接着用Python。我的回答是能做而且能做到的事情比你想象的多但你要是拿它去和C语言抢低延迟中断响应、资源受限的底层驱动那就是找不痛快。先说结论Python在嵌入式领域扎根的最典型形态有三块——第一在MCU微控制器上跑的MicroPython/CircuitPython第二嵌入式Linux/Android系统的应用层开发比如工控屏、边缘网关、机器人上位逻辑第三硬件的伴侣工具链就是PC端配合串口、网络、USB把硬件数据拉回来做分析和上位机控制。这三块覆盖的场景非常广传感器采集、简单控制、边缘AI推理、原型验证、产测自动化Python通通能挤进去。那它到底强在哪一句话开发效率是C语言没法比的。你做一块触摸屏的交互逻辑、写一个数据分析脚本、跑一个轻量的目标检测模型Python生态现成的轮子一大把PyQt做界面、OpenCV做视觉、NumPy做矩阵、Pandas做表格、TFLite做推理都是至少十年社区沉淀的产物。一个嵌入式Linux开发老手写一个HMI逻辑可能要三天你用Python可能一个晚上就出了一个能演示的版本——这在项目立项、方案验证阶段是降维打击。但你必须清楚它的短板。Python解释器本身占内存MicroPython在ESP32这种资源上跑起来可用内存常常只有100来KB复杂点儿的HTTP服务器都容易崩。实时性也不行Python的GIL和解释执行机制注定它没法保证微秒级的响应。真要控制伺服电机做精确位置环或者做高速AD采样、飞控算法还是老老实实用C、Rust。说白了Python在嵌入式体系里的角色是“指挥官”而不是“士兵”它管调度、管逻辑、管人的交互真正的脏活累活留给更底层的语言。这篇文章就是给动手派的一份全景地图从硬件选型到生态工具从踩坑实录到可复现的实操项目全是我自己在板子上烧过的经验。建议你把它当成一份“怎么把Python用到嵌入式里”的导航而不是教科书。2. 硬件层的Python从MCU到MPU的全栈盘点2.1 MCU上的MicroPython能跑但别期待太高MicroPython是Python 3的精简实现专门为微控制器而生。它的设计目标很朴素让懂Python的人不用学寄存器、不用翻几百页芯片手册就能实现硬件控制。严格来说它不是“把Python代码编译成机器码直接跑”而是解释器先在板子上运行然后“解释”你的Python脚本。这意味着多了一层开销但换来了极大的便利。最常见的MicroPython硬件平台是ESP32和树莓派PicoRP2040。ESP32带WiFi和蓝牙MicroPython固件装好后你可以直接用machine.Pin控制GPIO用network模块连WiFi用socket开一个TCP服务代码量比C的ESP-IDF工程少了一个数量级。我自己给一个数据采集项目做的原型从烧录固件到能通过HTTP上报传感器数据只花了一个下午这在以前用C从头搭工程连CMake都编不过去。树莓派Pico则是另一种体验。RP2040芯片本身性能中规中矩但MicroPython的移植做得非常稳定还有官方文档引导适合做教学和快速验证。我建议手边常备两块Pico一块刷MicroPython做逻辑验证另一块刷C SDK做性能兜底。很多项目的正确姿势是先用Python把业务流程跑通、收集数据、验证算法再用C重写核心热路径。但如果你的目标是STM32我有一个忠告确认Flash和RAM。STM32F103这种“上古神兽”芯片只有64KB RAM的版本跑MicroPython会很憋屈经常代码还没写完内存就先报警了。STM32H7这类大内存型号会舒服很多。另外要注意MicroPython的GPIO翻转速度、定时器精度都和C有数量级差距如果你要做严苛的PWM波形输出老老实实用标准外设库。还有一个需要提前了解的限制MicroPython不是所有的第三方库都能直接装。PyPI上有几十万个包但MicroPython能用的只有官方micropython-lib和部分纯Python实现的库。凡是依赖C扩展的库基本都白搭。比如你想要numpy在标准Linux上一条命令装好在MicroPython里就得自己写循环赤裸裸的现实。2.2 嵌入式Linux上的Python真正的黄金主场把Python放在嵌入式Linux环境里才是它最能施展拳脚的地方。现在很多工业产品本质上就是一台小电脑运行着精简的Linux系统比如树莓派、瑞芯微RK3568/RK3588开发板、全志芯片方案、各种边缘计算盒子。这类设备的硬件资源通常在256MB到8GB内存之间有完整的文件系统、进程管理、网络协议栈跑Python解释器是绰绰有余的。这种场景下Python就是标准的应用层开发语言。你用PyQt或LVGL做HMI界面用FastAPI搭本地控制服务用OpenCV读摄像头做视觉定位用ONNX Runtime跑目标检测模型这些在嵌入式Linux上都是成熟的组合。我自己做过一个基于RK3568的边缘网关项目核心逻辑全是Python写的Modbus轮询传感器、规则引擎判断报警、MQTT上报云平台、OTA升级固件整个流程里Python只占用了不到120MB内存稳定运行了几个月没有重启。这里有一个关键点嵌入式Linux的Python开发本质上和服务器开发区别不大该用虚拟环境用虚拟环境该用socket用socket只是有一些特有的门槛。比如交叉编译、系统裁剪、开机自启、资源受限下的内存优化这些我会在第4部分用项目实操详细讲。为什么说这是“黄金主场”因为一旦设备跑的是Linux你就有大量现成工具可用systemd管理服务、cron定时任务、rsyslog收集日志、docker做容器化部署。Python在这些系统机制配合下写出来的代码质量、可维护性都远超裸机场景。再加上现在硬件成本持续走低一块能跑Linux的开发板几十块钱就能拿到这让Python在嵌入式的“正规军”梯队中越来越有位置。2.3 特殊形态API接入与AI边缘推理说一个很多做嵌入式的人容易忽略的点Python在硬件产品里最值钱的能力不是控制而是“接入”。现在的智能硬件都要连云、连手机、连算法平台这些事情Python的生态是最强的。你用C语言调一个云SDK可能在各种平台上编译就折腾你几天但Python只需要pip install一个包甚至直接走HTTP REST接口两个小时就能完成设备的云端接入。另一个典型的场景是AI边缘推理。硬件工程师拿到AI模型之后最常接触的部署工具就是Python那一套训练好的PyTorch模型转成ONNX或者TFLite然后用Python写推理脚本在开发板上验证结果最后再考虑用C或者TensorRT落地。很多活跃在一线的“AI硬件”产品比如缺陷检测相机、人脸识别闸机、宠物喂食器早期原型都是Python跑通的。模型转换、量化、精度对比这些工作在Python里的工具链最成熟——onnxruntime、tflite-runtime轻轻一装就能跑。所以即使你是传统意义上的嵌入式工程师完全不懂Python后面的这套工具链也会发现自己越来越难绕开它。Python在这里的角色不只是“编程语言”更是“自动化胶水层”把硬件、传感器、算法模型、云服务全都粘在一起。3. 工具链与生态开发调试的全套装备3.1 VSCode与AI辅助开发嵌入式Python的正确打开方式很多做嵌入式的老工程师对IDE有执念Keil、IAR一套流程用了十几年。但我建议如果你走Python这条路趁早切换到VSCode。原因很简单Python的整个生态都在向VSCode靠拢无论是MicroPython的烧录、REPL调试还是嵌入式Linux代码的远端编辑、断点调试VSCode都能一站搞定而且插件生态和AI辅助能力是目前所有编辑器里最成熟的。最近圈子里特别火的Claude Code、GitHub Copilot等AI编码工具跟VSCode配合之后对嵌入式Python开发的效率提升是肉眼可见的。你可能觉得AI写不了底层硬件代码但实测下来它在生成寄存器配置模板、写JSON解析逻辑、拼MQTT报文体、处理字符串编码这类“脏活”上相当能打。有次我需要给一个MCU工程写一个串口协议解析器用Claude在VSCode里直接生成了一版MicroPython代码我只需要改两处引脚编号肉眼检查一遍就烧进去能用了。这种写样板代码的活AI比人快。配置上我建议这组插件组合Python扩展必装、Pylance代码补全和类型检查、MicroPicoMicroPython的REPL和文件上传非常顺滑、Remote-SSH连远程嵌入式Linux板子调试用、REST Client测试本机API。有了这一套你从编辑、烧录到调试的链路就是完整的完全不需要在几个软件之间来回切换。有一点我要专门提一句AI辅助开发不是让你无脑复制代码。嵌入式代码跑在真实硬件上一个引脚接错就能把板子烧了。AI生成的代码尤其是涉及GPIO复用、电源管理、时序逻辑的部分一定要对照芯片手册和原理图检查一遍。我的习惯是AI生成代码之后先在脑海过一遍数据流再看关键寄存器和外设初始化部分确认无误再上板。这一点时间省不得。3.2 上位机工具链串口、波形、数据分析嵌入式开发从来不只是写板子端代码上位机工具链同样重要。这里Python的优势是碾压级的。你拿串口调试助手手动收数据的时候别人已经用Python写了个脚本把数据流实时解析、画波形、存数据库了。我强烈建议每个嵌入式工程师熟练使用pyserial。这个库是串口通信的标准工具20行代码就能实现一个自动收数据、自动解析协议的脚本。很多设备在调试阶段会输出二进制或者十六进制报文用Python解析比在串口助手里肉眼看高效十倍。加上matplotlib做实时绘图传感器数据曲线一目了然报警阈值判断也能顺手加进去。还有一个经常用的组合是socket加struct。嵌入式设备往往同时具有网络接口Python可以开一个TCP/UDP服务或者客户端模拟服务器下发指令、接收设备上报数据。你可以写一段几十行的脚本来模拟云平台设备侧的工程师没等云端开发完就能联调这个能力在项目并行开发中非常香。如果你的工作涉及硬件测试Python的自动化能力更是能省下大量时间。我有一次要做一块电源板的产测软件需求是自动控制电子负载、读取万用表读数、判断输出电压是否在误差范围内、生成测试报表。用Python连上USB转GPIB控制器再写个简单的状态机几个小时就交付了一套可以给产线用的脚本工具。同一个活如果用LabVIEW方案提交审批都得等半天。3.3 Python、C、Rust的三角关系别搞对立聊Python在嵌入式的生态绕不开“其他语言怎么看”这个问题。我见过很多C工程师一听到Python做嵌入式就摇头也见过Python阵营把Rust说得神乎其神。其实这三者根本不是一个维度的东西场景不同选择自然不同。C语言在嵌入式领域依然是基石。底层的Bootloader、设备驱动、中断服务、RTOS任务这些必须用C或者C写。芯片厂商提供的HAL库、寄存器定义、数据手册里的参考代码几乎全是C。你要做硬核的东西C的护城河非常深。Rust则是在C和Python之间另辟蹊径主打内存安全和零成本抽象。如果你写驱动层代码Rust确实比C更不容易踩内存坑但它的学习曲线陡峭而且第三方embedded库的数量和成熟度远不如C的生态。适合对安全性和可靠性有极强要求的场景比如汽车电子、航空航天某些子系统但不适合追求快速出活的项目。Python在这个生态里的位置是“灵活层”。当你在做需求验证、算法研究、自动化测试、上位工具的时候Python是效率最高的选择。它不追求极致的性能和安全追求的是人和机器打交道的效率。聪明的嵌入式团队通常会让C/Rust工程师做底层、Python工程师做上层和工具链各司其职而不是用一把锤子敲所有钉子。我自己的经验是C和Python的搭配才是“真香组合”底层用C实现可靠的驱动和控制给Python暴露一个JSON或者二进制协议接口上层全用Python写业务逻辑。这样既保住了实时性又赢得了开发效率。这种架构实践起来其实非常简单很多成熟的开源项目都是这么做的比如乐鑫的ESP-IDF里可以嵌入MicroPython组件就是典型的混合模式。4. 实操从零到一Pico传感器数据采集上位机全流程4.1 硬件准备与开发环境搭建光说不练假把式。这一节我们做一个能真正跑起来的小项目树莓派Pico通过MicroPython读取一个温湿度传感器DHT11或者SHT30通过串口上报到PCPC端用Python脚本接收并实时绘图。这个项目麻雀虽小五脏俱全覆盖了MCU端逻辑、串口通信、上位机解析、数据可视化是你进入Python嵌入式世界的第一步。硬件清单很简单一块树莓派Pico开发板约30块钱一个DHT11温湿度传感器模块几块钱几根杜邦线一个USB转Type-C数据线用于烧录和串口通信。DHT11是单总线协议传感器模块一般三根引脚VCC接3.3V、GND接GND、DATA接GPIO针脚这里我用GPIO16。第一步是刷MicroPython固件。去树莓派官网下载最新的.uf2固件文件按住Pico板子上的BOOTSEL按钮不放用USB线连接电脑它会弹出一个名为“RPI-RP2”的U盘把.uf2文件拖进去板子会自动重启固件就刷好了。整个过程没有任何风险即便刷错了也可以重新回到BOOTSEL模式再来一次。开发环境我推荐VSCode加MicroPico插件。安装插件之后在命令面板里找到“MicroPico: Connect”就能连上板子打开一个.py文件按F5上传并运行代码直接就在板子上执行了。它会自动创建main.pyMicroPython上电后会先执行这个文件所以你的主程序可以写到main.py里实现开机自启。4.2 MCU端代码MicroPython实现传感器采集与串口上报DHT11的数据手册看起来很复杂——单总线时序、40位数据帧、校验和判断。但在MicroPython里你甚至不需要用手册细节直接用现成的库就行。先把dht库导入进来然后用machine.Pin初始化GPIO再调用sensor.measure()获取数据sensor.temperature()和sensor.humidity()取出温湿度值。下面是完整的MCU端代码我直接贴能用的import machine import dht import utime import ustruct import json # 初始化DHT11挂在GPIO16上 sensor dht.DHT11(machine.Pin(16)) uart machine.UART(0, baudrate115200) uart.init(115200, bits8, parityNone, stop1) while True: try: sensor.measure() temp sensor.temperature() humi sensor.humidity() payload {t: temp, h: humi} line json.dumps(payload) \n uart.write(line) print(line.strip()) except OSError as e: print(Read failed:, e) utime.sleep(2)这段代码有几个地方值得停下来解释一下。为什么用uart.write而不是print因为PC上如果有其他程序占用串口读取print的输出也会混进REPL通道容易和调试信息搞混。单独开一个UART通道用于数据交互格式也是标准的JSON这个习惯能让你以后的协议对接少很多麻烦。ustruct库我导入了但没有用因为JSON的dumps方法在这类小数据量场景下完全够用而且可读性更好。但如果你要传二进制数据或者性能要求高ustruct.pack是更高效的选择。MicroPython的json.dumps在长字符串上会占用较多内存所以数据量上来之后要留意内存使用。utime.sleep(2)是每2秒采集一次。DHT11本身采样频率就有限制手册建议采集间隔不小于1秒连续快速读取会导致传感器返回错误。实际调的时候如果发现温度值一直是0或者报错大概率就是读取间隔太短。4.3 PC端代码串口接收、解析与实时绘图接下来写PC端的接收脚本。用pyserial接收串口数据用matplotlib做实时绘图。这里有一个很多人都会踩的坑串口读取不是按“行”来的它是一堆字节流如果你不加缓冲可能一次读到半行数据JSON解析就会报错。解决方法是按换行符切分读到一行再解析凑不齐就继续等。import serial import json import matplotlib.pyplot as plt from collections import deque PORT COM3 # Windows端口号Linux/macOS通常是/dev/ttyACM0或/dev/ttyUSB0 BAUD 115200 ser serial.Serial(PORT, BAUD, timeout1) buf b temp_history deque(maxlen100) humi_history deque(maxlen100) plt.ion() fig, (ax1, ax2) plt.subplots(2, 1, figsize(10, 6)) while True: data ser.read(256) if data: buf data while b\n in buf: line, buf buf.split(b\n, 1) line line.strip() if not line: continue try: obj json.loads(line.decode(utf-8)) t obj[t] h obj[h] temp_history.append(t) humi_history.append(h) print(ftemp{t:.1f}C humi{h:.1f}%) ax1.clear() ax1.plot(temp_history, colororangered) ax1.set_ylabel(Temperature(C)) ax2.clear() ax2.plot(humi_history, colorsteelblue) ax2.set_ylabel(Humidity(%)) plt.pause(0.01) except (json.JSONDecodeError, KeyError) as e: print(Bad line:, line, e)核心逻辑就是维护一个可变字节缓冲buf每次读串口数据先拼进去然后按\n分割出完整的一行。这个缓冲模式是我调试各类串口设备总结出来的非常通用以后你会遇到各种“半包”“粘包”问题这个套路能解决80%。数据可视化部分用matplotlib的交互模式plt.ion()每收到一条数据就更新一次曲线窗口会动态刷新。deque(maxlen100)是一个自带最大长度的队列数据超过100条就自动丢掉最旧的实现了滑动窗口效果。这样你看曲线时它只显示最近100个采样点视觉上非常清爽。运行这个脚本前注意确认串口号。Windows系统在“设备管理器-端口”里看COM几Linux/macOS用ls /dev/tty*看设备节点。如果发现打开串口失败多半是端口被MicroPico插件或者其他终端工具占用了关掉其他占用程序再试。4.4 实时性问题与采样策略调整项目跑起来之后你可能会注意到一个现象实时曲线看起来“一跳一跳”的或者上位机收数据偶尔会丢失几行。这涉及嵌入式开发者必须建立的思考维度——实时性不是绝对概念而是在具体场景中是否满足需求。在MicroPython端utime.sleep(2)意味着每2秒发送一条数据这个频率下串口带宽完全不是瓶颈115200波特率跑2KB都秒秒钟的事2秒才发几十字节。瓶颈会有两个一是MCU端传感器的读取时间本身要占用几百毫秒DHT11的时序要求等待时间较长二是PC端matplotlib刷新重绘是CPU密集操作如果窗口尺寸过大刷新会卡顿。针对不同场景采样策略要做调整。如果只是监控室温变化2秒一次足够了如果是做机械设备振动监测这频率远远不够得用定时器中断配合ADC直采再通过DMA搬运数据这种就超出了Python的应用范围需要C来实现。想提高MicroPython的上报频率可以把传感器换成I2C接口的SHT30读取速度快一个数量级然后用utime.sleep(0.1)甚至不睡循环跑但要注意别把CPU占满导致其他任务饿死。还有一个优化点如果你要长期稳定运行数据采集建议在PC端脚本里加异常恢复。串口设备有一个特点——你拔掉USB线再插回去程序里的serial.Serial对象并不会自动重连。更稳妥的做法是加一层断线检测和自动重连机制while True: try: if not ser.is_open: ser.open() # 原有读取逻辑 except serial.SerialException: print(Serial disconnected, retrying...) time.sleep(2) ser serial.Serial(PORT, BAUD, timeout1)这个逻辑看着简单实际项目里却经常被忽略。我在产测工具里见过无数因为拔插USB就崩溃的脚本加上自动重连之后产线上的可靠性立刻提升一个等级。5. 常见问题与排查技巧实录5.1 烧录和连接问题刷完固件电脑识别不到串口是最常见的新手问题。排查思路按顺序来第一检查USB线是不是“纯供电线”很多廉价USB线只有电源线没有数据线这种线能充电但识别不到设备第二检查系统是否识别到USB设备Windows在设备管理器里看“端口”下有没有设备Linux执行lsusb第三如果设备显示黄色叹号多半是驱动问题RP2040在部分Windows系统上需要手动安装驱动去树莓派官网下载即可解决。MicroPico插件连不上板子的情况也很常见。插件连接需要板子处于MicroPython模式如果你之前用C语言烧过程序板子现在跑的底层不是MicroPython固件自然连不上。解决方法是重新按住BOOTSEL进入刷机模式再烧一次.uf2固件。这个操作可以无限重来完全不用怕把板子搞坏。另外一个坑是串口端口号飘逸。你用MicroPico调试时占用了COM3之后运行自己的Python脚本串口仍然被MicroPico进程锁着打开就会失败。解决方法是调试完一个任务就把插件断开或者把VSCode整个关掉再运行独立脚本。这种“端口占用”问题我遇到至少不下十次每次都怀疑是不是串口坏了最后发现是小细节。5.2 MicroPython运行内存与性能问题“MemoryError: memory allocation failed”是MicroPython最经典也最劝退新手的报错。ESP32这种板子虽然有320KB的SRAM但MicroPython解释器、垃圾回收器和一些系统组件至少要占掉一半你实际可用的堆内存往往不到150KB。造成内存耗尽的几大元凶一是字符串拼接二是一次性读取大文件三是深度递归调用。字符串拼接这个坑非常隐蔽。在循环里做data data x每次都会创建一个新字符串旧字符串就被垃圾回收器回收但回收不及时就会导致内存峰值。我见过一个日志采集程序运行几小时后内存逐步耗尽代码里全是字符串拼接。解决办法是改用bytearray或列表收集最后统一join。性能问题的另一个体现是启动慢。MicroPython版Pico上电后先要初始化解释器再执行main.py启动时间通常在几百毫秒到一两秒。如果你的产品对上电时序有严格要求比如期望在200毫秒内输出第一帧信号这种软实时的场景用Python就会很被动。我的经验是产品化阶段要么用C重写关键路径要么干脆换方案。5.3 嵌入式Linux Python数据持久化与崩溃恢复在嵌入式Linux上跑Python常见的问题是断电导致的数据丢失和进程失控。很多设备是常电但会突然断电如果Python程序正在写文件写了一半就断了文件就会损坏。轻量级方案是写临时文件再os.replace原子替换或者用SQLite数据库做数据持久化SQLite的WAL模式对掉电场景做了很好的保护。进程崩溃自动恢复也不难。用systemd服务管理你的Python脚本配置Restartalways和RestartSec3就能实现崩溃后3秒自动拉起。这个方案比在代码里写守护进程靠谱得多。很多刚接触嵌入式Linux的人习惯用while True包住一切一旦遇到未捕获异常进程退出没有systemd的保护就只能手动重启实际上板的稳定性全靠这套服务管理机制。还有一个现象值得注意Python程序显示“死机”了其实不一定是进程挂了可能是线程阻塞或内存泄漏导致的不响应。排查手段是看系统日志journalctl -u再用top看CPU和内存用strace跟踪系统调用。有了这三板斧大部分问题都能定位。5.4 快速排查对照表为了让你在实际调试时能少走弯路我把这些年踩过的坑整理成一张速查表。相比上文的长篇分析这张表更适合放在手边随时翻阅。症状原因解决方案板子连不上串口USB线只供不传、驱动问题换数据线、装驱动、重新烧固件烧录后程序不运行main.py不存在或语法错误检查文件系统及REPL输出信息MicroPython报内存不足字符串拼接、大对象用bytearray收集、拆分批量处理串口读到乱码波特率不匹配、串口占用确认两端波特率一致、关闭其他程序接上传感器读数恒为0接线错误或读取间隔太短核对引脚定义、加长延时到1秒以上Linux下Python进程自动退出未捕获异常用systemd的Restart机制拉起来数据上报时序抖动解释器执行速度不稳定减少动态分配、预分配复杂结构对象设备重启后配置丢失文件没有落盘写临时文件再原子替换、用SQLite持久化AI生成的代码上板不工作引脚编号或者外设初始化错误对照原理图和芯片手册逐一核对这张表里的每一种情况我都真实遇到过其中“AI生成代码上板不工作”在最近的开发模式下越来越常见。不是AI写得不对而是它不理解你的具体硬件环境。遇到这种问题我最快的定位方法是分而治之——先用最小代码测试GPIO是否能翻转再逐步添加外设和逻辑。一次只验证一个变量很快就能揪出问题。6. 最后再聊几句心里话做了这么多年软硬结合的项目我最大的体会是工具和语言从来不是壁垒思维方式才是。很多人问Python能不能做嵌入式本质上是想找一个“一劳永逸”的解决方案但现实的工程世界从来没有这种答案。我见过用C语言写业务逻辑写到怀疑人生的工程师也见过用Python写了几个工具脚本就救了整个项目进度的案例。关键不是你用什么语言而是你是否清楚自己手里资源的边界。如果你正在犹豫要不要在嵌入式方向学Python我的建议非常直接学而且立刻学。不用等到“把C先学扎实了再学Python”这两个完全不冲突。C帮你理解机器如何工作Python帮你把想法快速变成能跑的东西。越早建立起这两种能力的组合越有优势。尤其是当你手头有板子想验证一个念头的时候Python会让你立刻体会到“十分钟出一个原型”的爽快感这份成就感往往就是持续学习的最大动力。最后留一个小技巧无论你用MicroPython还是嵌入式Linux Python从一开始就养成写调试日志的习惯。用print虽然简单但正式项目里应该用统一的日志级别和格式文件日志加上时间戳。别小看这件事等到设备在现场出问题时日志是你和真相之间唯一的桥梁。工具选得再好没有好的调试习惯依然会像无头苍蝇一样乱撞。动手吧选一块板子开始你的第一行嵌入式Python代码接下来的路自然会越走越宽。