第二十届全国大学生智能汽车竞赛报名系统开放那天我在群里跟队友说要不这届我们用MicroPython试试群里沉默了三秒然后有人回了一句“RT1021能跑MicroPython”我知道他真正想问的是另一个问题——“放着好好的C不用为什么非要在恩智浦RT1021上折腾Python”当时我没有立刻回答。因为严格来说这个问题我的确没底。i.MX RT1021是NXP的跨界处理器Cortex-M7内核、500MHz主频、带FPU和DSP属于那种“跑起来比普通MCU猛得多、但又不像Linux SoC那么复杂”的芯片。MicroPython是解释型脚本语言在单片机上的实现主打快速迭代。这两者放在一起听上去就有点“拧巴”。但第二十届极速光电组拼的早就不只是纯代码性能了还拼一圈代码烧进板子要多久、调一个参数要多少次编译、半夜三点把车从赛道上拎回来之后能不能用十秒钟改完策略再来一发。C当然可以做到这些但MicroPython在这些场景里几乎是降维打击。这篇文章就是把我从“RT1021能不能跑MicroPython”到真正把赛车跑起来的完整过程、选型逻辑、外设编程姿势和踩坑记录写下来。如果你正在备赛或者对手头这块芯片动过类似心思这篇应该能帮你省下不少试错时间。1. 在RT1021上跑MicroPython值不值得折腾1.1 极速光电组对主控的真实需求极速光电组这名字听起来唬人但说白了就是“车要快、路径要认准、控制要稳”。这类车对主控的要求基本可以拆成四块必须有足够算力跑图像或传感器融合算法、要有足够多的定时器/PWM/编码器接口伺候电机和轮速传感器、中断响应要够快、开发迭代效率要高。恩智浦RT1021在这四块里的表现其实很突出它不是那种大而全的应用处理器而是把Cortex-M7拉到500MHz再配上DSP指令集和FPU专为“要性能又不想上Linux”的场景准备的。和常用的STM32F4、TC264这些芯片相比RT1021最大的优势就是主频和浮点运算能力。它跑数学运算时FPU能帮忙做不少事这对极速光电组里常见的PID控制、图像灰度处理、弯道曲率估算都很有用。而它又保留了MCU的确定性——中断延迟、外设控制、启动时间都是可以预期的不像跑Linux的板子那样换个系统负载就得担心调度抖动。但这里有个很现实的问题在第二十届这种级别的比赛里C语言几乎垄断了RT1021的技术方案。你去网上搜能找到的全是MCUXpresso IDE、SDK例程、寄存器配置。想找个现成的MicroPython工程几乎没有。所以当时我们面临的其实是一场赌注赌MicroPython的迭代效率能抵消它在实时性上的不足同时还要自己把社区生态里缺失的那几块拼图补上。1.2 MicroPython带来的时间收益到底有多大我说一个特别直观的对比。C开发跑智能车的日常是这样的改一个PID参数重新编译烧录等板子重启看现象。如果现象不对再改再编译再烧录。一次编译几十秒到几分钟不等烧录和重启又是十几秒。哪怕一切顺利一晚上调二十版参数就已经很高效了。而且C代码一旦跑飞你还要接调试器看寄存器、看调用栈、找各种诡异的内存问题一晚可能就没了。MicroPython完全不同。代码通过串口REPL或者文件系统直接上传Python文件在板子上就是文本没有编译过程。你可以在赛车运行过程中通过REPL改一个PWM占空比立刻观察电机反应可以把赛道元素识别逻辑写成Python函数直接在命令行里喂几帧图像测输出。最夸张的一次我在场地边用手机连上串口蓝牙模块直接在REPL里把入弯减速点往前挪了半米全程没有拔过一块板子大概不到一分钟。这种效率对齐到整个备赛周期省下的时间是巨大的。毕竟智能车竞赛拼的不只是谁的算法先进还拼谁有更多轮次去跑赛道、收集数据、修正bug。MicroPython把“代码改动-上赛道验证”的闭环压缩到了以秒为单位这在赛前三天作用尤为致命。1.3 得先把丑话说在前面Python不是万能钥匙但如果你以为MicroPython能包打一切那后面八成要翻车。解释型语言在实时控制上有天然短板字节码解释执行比原生机器码慢一个量级、垃圾回收会带来不确定的停顿、Python层的函数调用开销在某些高频中断里没法接受。我自己划分过一个“什么场景能用Python、什么场景不能用”的清单后来基本成了整个项目的红线场景是否适合MicroPython原因主控制循环低频策略、状态机很适合逻辑复杂、改动频繁解释器开销可接受高速PID实时运算1kHz以上勉强适合简单计算可以复杂公式建议用viper或C扩展摄像头图像逐行处理不适合数据量大、循环密集Python层撑不住编码器高频计数、电机堵转检测不太适合依赖定时器中断和寄存器操作Python回调有延迟启动初始化、外设自检很适合逻辑多、跑一次就行Python开发最快与传感器通过UART/SPI通信很适合主要瓶颈在IO速度MicroPython封装很成熟我刚上手的第一周几乎每天都在“真香”和“想换回C”之间反复横跳。后来想明白了MicroPython不是用来替代C的而是用来替代“C里那些跟硬件无关、纯粹写逻辑”的部分。把实时要求高的放到底层把策略迭代放到Python层这才是RT1021上MicroPython的正确打开方式。2. 固件从零到一mimxrt移植版编译与烧录2.1 先确认芯片RT1021的硬件编程入口如果你用过STM32再来看i.MX RT1021第一感觉是“这芯片怎么这么像单片机又这么不像单片机”。它没有内部Flash程序放在外部QSPI Flash里上电后由BootROM通过FlexSPI接口把代码映射到0x60000000地址直接XIP执行。这种架构的好处是Flash大小和成本很好控制坏处是如果外部Flash初始化配置不对板子根本起不来。MicroPython官方仓库其实维护了一个叫mimxrt的移植分支支持的板卡里就有MIMXRT1020-EVK这一档。也就是说只要你的板子原理图跟EVK接近或者自己照着EVK画了板子那官方固件基本可以直接烧进去用。这一点比很多人想象中要省事。但注意官方支持的是“标准EVK外设布局”不同队伍自己画的底板引脚千奇百怪所以后面多半还要自己编译一版。顺带说一句如果你还没定芯片市面上支持MicroPython的单片机其实不少STM32、ESP32、RP2040都是官方一等公民开箱即用。RT1021属于跨界处理器里比较高性能的选择但它对MicroPython的适配深度不如STM32那边完善。选它的理由应该是“看中Cortex-M7的算力”而不是“想少折腾”。如果只是想最快跑通MicroPythonESP32其实更省心。2.2 编译自己的固件环境准备与自定义板卡编译mimxrt移植版并不复杂但有几个前置条件容易卡住新手。先说环境建议用Linux或者WSLWindows原生编译虽然也能跑但坑比较多。需要安装arm-none-eabi-gcc交叉编译器、make、git以及Python3编译脚本里有个环节用得上。git clone --recurse-submodules https://github.com/micropython/micropython.git cd micropython make -C mpy-cross cd ports/mimxrt make BOARDMIMXRT1020_EVK submodules make BOARDMIMXRT1020_EVK编译完之后固件在build-MIMXRT1020_EVK/firmware.hex和firmware.bin两个文件。如果只是用官方EVK这把就够烧了。但自制底板一般要改这三个地方boards/MIMXRT1020_EVK/mpconfigboard.h配置时钟、Flash大小、引脚复用、调试串口等信息。boards/MIMXRT1020_EVK/pins.csv引脚别名映射表写清楚哪个名字对应哪个物理Pin。boards/MIMXRT1020_EVK/mpconfigboard.mk选择使用的MicroPython模块和功能比如是否启用UART、SPI、PWM等以及固件名。我自己踩过的坑是时钟树配置。RT1021支持内部RC和外部晶振如果板子上晶振频率跟EVK不一样而你还是按EVK的配置去编译烧进去之后UART波特率会偏得一塌糊涂REPL根本连不上。当时我一度以为是USB转串口坏了换了三根线才反应过来是固件里晶振频率不对。后来我把底板的24MHz晶振改成跟EVK一致的配置问题立刻消失。2.3 烧录、REPL与文件系统的打通i.MX RT的烧录方式基本有三条路板载调试器、外部J-Link、串行下载模式。对EVK来说板载DAPLink是最方便的系统里会识别成一个调试接口加一个串口。烧录命令我习惯用pyOCDpyocd erase --target mimxrt1020 pyocd flash -t mimxrt1020 -f 0x60000000 firmware.bin先擦除再烧是给自己留退路。如果直接往一个写有旧固件的Flash里灌新固件偶尔会因为FlexSPI配置区域变化导致启动失败擦一遍一了百了。烧完之后打开串口终端波特率选115200按下板子复位键如果看到MicroPython v1.xx on 2024-xx-xx; MIMXRT1020_EVK with MIMXRT1021开头的提示符恭喜你RT1021已经正式开始跑Python了。REPL连上只是第一步。接下来要把文件系统弄通。mimxrt移植版默认启用内部Flash文件系统MicroPython启动时会自动执行根目录下的main.py。所以开发流程就变成了在电脑上写好Python代码用rshell或mpfshell之类工具传到板子的文件系统再按复位键让代码跑起来。不要再找烧录器了不需要。一个小技巧调试时别把main.py写得太大否则每次启动都有明显的文件读取时间。把常用工具函数放进boot.py主逻辑放main.py这样启动流程更清晰也方便在boot.py里做串口初始化和硬件自检。3. 极速光电组的外设驱动Python代码打开RT10213.1 引脚规划先于代码MicroPython里操作引脚很简单pin machine.Pin(1, machine.Pin.OUT)写一个、value machine.Pin(2).value()读一个。但越简单越容易让人忽略一个问题——引脚分配。RT1021的大部分引脚都是多功能复用引脚同一个物理Pin可能同时能当GPIO、UART、PWM、ADC用但同一个外设功能并不一定出现在所有引脚上。如果你拿到一块自己画的底板第一件事不是写代码而是拿原理图把所有用到模块的引脚画成一张表确认没有两个外设冲突。我的习惯是在项目仓库里放一个pinout.py把所有引脚定义集中管理后面所有外设初始化都从这个模块导入。这样改线的时候只改一个文件不用满工程搜索machine.Pin。比如# pinout.py PIN_MOTOR_PWM 24 PIN_MOTOR_DIR1 25 PIN_MOTOR_DIR2 26 PIN_ENCODER_A 13 PIN_ENCODER_B 14 PIN_LED 7 PIN_UART_TX 34 PIN_UART_RX 353.2 电机PWM输出频率与死区是两回事极速光电组最常见的动力方案是直流有刷电机加MOS管H桥驱动。MicroPython的PWM接口在mimxrt移植版里走的是标准machine.PWM封装用法和STM32的pyb.PWM类似但API更接近ESP32from machine import Pin, PWM pwm_pin Pin(PIN_MOTOR_PWM) motor_pwm PWM(pwm_pin, freq20000, duty_u1632768)freq20000意思是PWM频率20kHz这个值是有讲究的。太低比如几百Hz电机会发出尖锐的啸叫甚至被听成“电流声”但实际是PWM的开关频率落在人耳可听范围内。20kHz刚好超过人耳听力上限安静又不容易引起机械共振。不过要留意PWM频率越高开关损耗越大、MOS管发热越明显。如果你用的是普通半桥驱动芯片建议先看手册上的最高PWM频率不要无脑奔着20k去。再说占空比。mimxrt移植版支持16位占空比精度也就是duty_u16的范围是0到65535。32768正好是50%65535是全速。写代码时要注意方向控制和PWM是两回事H桥需要一个方向引脚或者两个方向引脚做互锁再加一个使能/PWM引脚。如果方向引脚和PWM引脚状态配合不当比如方向切换的瞬间PWM还是高电平就可能出现一瞬间的刹车电流。这个电流对MOS管很不友好。我的处理方式是先拉低PWM再切换方向再恢复PWM。def set_motor(duty, direction): motor_pwm.duty_u16(0) # 先断电 dir1.value(1 if direction else 0) dir2.value(0 if direction else 1) motor_pwm.duty_u16(max(0, min(65535, duty)))这个“先断电再换向”的细节在C代码里都一样但Python写起来太顺手新手特别容易忽略。极速光电组赛道上频繁加减速方向切换死区控制不好轻则电机顿挫重则烧驱动。3.3 编码器读取mimxrt没有现成封装怎么破这是我在RT1021上最头疼的部分没有之一。STM32上MicroPython虽然也没有完整的正交解码封装但大家习惯用定时器外部计数模式蒙混过关到了mimxrt移植版连蒙的路径都少了。RT1021内部其实有专门的ENCEnhanced Quadrature Decoder模块但MicroPython没有把它暴露给Python层。这意味着你有三条路可以走第一种低速验证时用GPIO中断。A相接上升沿中断在回调里读B相电平判断方向。这个方法实现简单代码量不到二十行但中断回调在MicroPython里的开销比较大电机高速转起来很容易丢脉冲。我只把它用在硬件自检和电机堵转保护上。第二种外接正交解码芯片通过SPI或I2C读计数值。这是很多智能车队的老办法典型的芯片是LS7366R。Python只需要在需要的时候发起SPI读操作不需要任何中断实时性靠芯片本身保证。缺点是板上多一颗芯片、多花几块钱。但换来的是稳定和省心我觉得很值。第三种也是最彻底的写一个C扩展把RT1021的ENC寄存器操作封装成一个简单的Python模块。如果你用官方SDK配置过程其实很清楚——选择ENC通道、配置输入引脚、清零计数值、启动计数。C扩展暴露出来的函数只需要两个encoder.read()和encoder.clear()。这个方案性能最好但需要你对mimxrt移植版的构建系统有一定了解适合备赛时间充裕时做。我最终采用的方式是第二种加第三种的混合调车阶段用LS7366R稳定之后把C扩展接上去掉外部芯片。这样既保证了前期开发效率又保住了正式比赛的可靠性和精度。3.4 中断回调与看门狗安全类功能的落地MicroPython支持machine.Timer和Pin的外部中断但使用时有几条规矩必须刻在脑子里回调函数里不要分配内存、不要调用print除非你接受每次触发都卡几百微秒、不要做复杂计算。最好的实践是“中断里只置标志位主循环里处理业务”。看门狗在第二十届的比赛规则里是明确要求的不允许用任何方式绕过去。MicroPython的WDT封装在mimxrt上也能用from machine import WDT wdt WDT(timeout1000) while True: # 主循环逻辑 wdt.feed()注意看门狗的超时时间不能设太短。MicroPython主循环里如果做了垃圾回收或者文件操作时间抖动比C裸机大不少。我的经验是设1500ms左右比较稳前提是主循环本身不能真的卡死超过这个时间。还有一点喂狗尽量放在主循环里不要放在中断回调里。如果你放在一个定时器中断里喂狗那主程序哪怕死锁了狗也不会复位等于白装。当时我跟队友排查一个“程序看起来跑着但车完全不响应”的诡异问题最后发现就是有人在中断里喂了狗主循环早就螺旋升天了。4. 摄像头和控制回路性能敏感的三大难题4.1 图像识别到底放哪里RT1021不是万能的极速光电组最核心的信息来源就是图像。赛道上有没有十字、有没有坡道、弯道半径多大全都得从一帧帧图像里抠出来。如果让RT1021直接用MicroPython去读摄像头数据处理每一帧完整的图像那基本上是死路一条。500MHz的Cortex-M7很强但Python解释器一条条翻译字节码的速度碰上一张QVGA灰度图的像素遍历就崩溃了。所以我的建议非常明确图像识别这一步不要让Python裸扛。第二十届极速光电组常用的方案有两种。方案一是用OpenMV这类本身就跑MicroPython的视觉模块做前端感知RT1021只负责接收OpenMV通过串口发来的赛道信息。OpenMV的帧率能到几十上百fps识别赛道左右边线、丢线状态、十字标志这些任务完全够用。RT1021串口收到的不是图像而是赛道元数据比如“左偏30像素、前方直道、速度建议4.2m/s”。这种方式的好处是主控完全不需要碰图像处理实时性压力小很多。方案二是用RT1021的CSI接口接摄像头DMA把图像搬运到内存但Python层只处理关键行/关键区域比如只读图像中间三行判断赛道偏差。这个方案本质上还在RT1021上做图像处理只是把数据量砍到了Python能承受的范围。它适合车道简单、不需要复杂图像理解的场景。我自己两个方案都试了最终在正式车上用的是方案一。不是因为方案二技术不行而是因为备赛后期时间太紧把图像处理放在OpenMV上调试时可以直接看OpenMV的画面和识别结果人脑不需要想象“这幅图经过处理后变量是什么”直接看可视化比什么打印都管用。4.2 控制周期到底能做多快一个实测没有水分很多人在决定用MicroPython跑控制回路前心里最没底的就是一个循环到底是1kHz还是10Hz这个数据不能靠猜我的做法是直接在RT1021上做了个基准测试。先写一个空循环测量10000次迭代耗时。然后在循环里加上一个简单的PID计算三个乘法、三个加法再测一次。最后再把编码器读取和PWM输出加进去得到一个接近实际控制任务的耗时。三个数字放在一起控制循环内容单次耗时微秒级对应最大控制频率空循环pass约15us数十kHz以上空循环 单轮PID计算约45us约22kHz空循环 PID 编码器读取 PWM输出约80us约12kHz这个数据在500MHz的RT1021上测出来已经相当可观。也就是说只要你的控制循环里不做图像处理、不做列表操作、不打印调试信息纯Python跑到2kHz的控制频率完全没有问题。极速光电组对速度环和方向环的常规需求也就在1kHz到2kHz之间MicroPython能顶住。但这里有个隐形杀手垃圾回收。MicroPython的内存管理会在你需要的时候“暂停世界”如果GC在控制循环中间发生单次循环耗时会从80us瞬间跳到几毫秒。为了不让GC捣乱我一般会预分配所有循环内的对象避免在循环里创建任何新对象。比如PID计算不要写成err target - current然后创建一个新变量而是提前把误差存到一个列表或者直接用可变对象。4.3 viper、native与C扩展的三级提速如果你的控制循环确实遇到了性能瓶颈别急着换语言MicroPython自带一套从软到硬的提速方案。第一级是micropython.viper装饰器。viper模式会把函数编译成原生机器码同时允许你用int、uint、ptr等类型注解告诉解释器变量类型避免装箱拆箱。写法上牺牲一点Python的灵活性但换来接近C的速度。micropython.viper def pid_calc(target: int, current: int, kp: int, ki: int) - int: err target - current out kp * err return out第二级是micropython.native装饰器。native模式把整个函数编译成原生机票吗听起来和viper差不多区别在于native保留Python动态类型提升不如viper明显但兼容性更好。一般我在函数里需要调用其他Python对象时用native纯数值计算用viper。第三级才是C扩展。C扩展是把性能敏感的函数用C实现通过MicroPython的模块系统暴露给Python。这条路最彻底但也最重。我的建议是先用viper试试看性能能不能满足需求如果满足不了再考虑C扩展。不要一上来就写C扩展——那是把MicroPython的优势又丢回给C了开发效率重新变低不如一开始就用纯C写整个控制程序。5. 从裸机思维切换到Python思维实战踩坑记录5.1 调试方式的巨变print、REPL和热更新第一次在REPL里输入motor_pwm.duty_u16(30000)然后看着电机真的转起来的时候我脑子里“嵌入式开发必须编译烧录调试”的固有模式被打碎了。从此我的调试习惯从“接J-Link、看寄存器、打断点”变成了“print大法加REPL手动喂数据”。这种切换带来一个特别直观的效率提升调试摄像头参数不再需要反复烧录代码只需要把一帧图像数据导入Python环境然后不断调用识别函数看返回值对不对。改一版识别逻辑回车执行结果立刻出来。这在C开发流程里是不可想象的。顺带说一个老话题经常有人问VB6能不能用来写嵌入式硬件程序。结论是能但没有意义。嵌入式实时系统的开发语言选择不是“能不能操作寄存器”而是有没有完整的交叉编译工具链、运行时环境、外设驱动库和调试手段。VB6离这些太远了连MicroPython这种解释型脚本方案都已经是比较激进的高层选择。如果你看到有人用VB6写单片机那多半是十几年前做串口上位机的老项目不是拿来跑控制回路的。5.2 我踩过的三个坑堆栈、垃圾回收与float第一个坑是堆栈溢出。MicroPython的构造函数、回调函数、表达式求值都需要栈空间如果你在main.py里写了深层次递归或者在一个中断回调里做了大量操作默认的栈配置很容易爆。现象是程序运行到一半突然抛出MemoryError或者NameError有时候连异常信息都没打完就卡死了。解决方法是把mpconfigport.h里的栈配置调大或者严格限制递归深度和回调复杂度。第二个坑是垃圾回收的“随机抖动”。前面提到GC会让控制循环产生毫秒级抖动但实际影响比我想象的更大。有一段时间赛车在直道上速度曲线出现规律性波动接上示波器看PWM输出才发现每隔几百毫秒就有一个明显的毛刺正是gc.collect()的间隔。后来我在主循环里主动控制GC时机不在控制循环里分配对象、定期在循环外显式调用gc.collect()速度曲线才平了。第三个坑是float运算的隐形成本。RT1021有FPU硬件浮点运算很快但MicroPython的float对象是堆分配的。你在循环里写temp temp 0.1它每次都可能创建一个新的float对象触发堆分配最终拖慢循环速度。解决方式是尽量用整数运算代替浮点或者在viper模式下用原生float类型。我最终把所有PID系数扩大1000倍用整数做计算最后再除以1000输出速度提升非常明显。5.3 一个小而完整的赛车骨架最后给一个可以直接改来用的最小骨架。这不算成品但它把“MicroPython控制一辆极速光电组赛车”所需的关键模块串起来了PWM电机输出、编码器读取、定时器触发控制周期、看门狗保护、串口打印调试信息。import machine from machine import Pin, PWM, Timer, UART, WDT import time # ---------- 引脚定义 ---------- PIN_MOTOR_PWM 24 PIN_MOTOR_DIR1 25 PIN_MOTOR_DIR2 26 PIN_ENCODER_A 13 PIN_ENCODER_B 14 # ---------- 外设初始化 ---------- dir1 Pin(PIN_MOTOR_DIR1, Pin.OUT) dir2 Pin(PIN_MOTOR_DIR2, Pin.OUT) pwm PWM(Pin(PIN_MOTOR_PWM), freq20000, duty_u160) count 0 last_a 0 def encoder_isr(pin): global count a Pin(PIN_ENCODER_A).value() b Pin(PIN_ENCODER_B).value() if a ! last_a: count 1 if b else -1 last_a a # 简化版只有A相中断方向靠B相判断 enc_a Pin(PIN_ENCODER_A, Pin.IN, Pin.PULL_UP) enc_b Pin(PIN_ENCODER_B, Pin.IN, Pin.PULL_UP) enc_a.irq(handlerencoder_isr, triggerPin.IRQ_RISING | Pin.IRQ_FALLING) # 看门狗 wdt WDT(timeout1500) # 串口调试 uart UART(1, 115200) # ---------- 控制参数 ---------- target_speed 2000 # 编码器计数目标 kp 10 ki 0.5 integral 0 prev_error 0 motor_duty 0 def control_loop(timer): global integral, prev_error, motor_duty speed count count 0 error target_speed - speed integral max(-3000, min(3000, integral error)) derivative error - prev_error prev_error error motor_duty kp * error ki * integral 2 * derivative motor_duty max(-65535, min(65535, motor_duty)) if motor_duty 0: dir1.value(1) dir2.value(0) else: dir1.value(0) dir2.value(1) pwm.duty_u16(abs(motor_duty)) timer Timer(0) timer.init(period1, modeTimer.PERIODIC, callbackcontrol_loop) # 上面period单位是毫秒1ms对应控制频率1kHz while True: wdt.feed() uart.write(speed%d duty%d\r\n % (target_speed, motor_duty)) time.sleep_ms(20)这段代码不是我直接拿来做完赛准备的版本但它包含了一个微型赛车控制器必须具备的所有要素。等你在REPL里验证过每一个模块再往里面加图像识别、路况判断、状态机就是水到渠成的事。如果你问我现在回看这个“RT1021加MicroPython”的选择后不后悔——我会说不后悔。第二十届极速光电组备赛的过程中MicroPython的快速迭代让我和队友把大量时间花在了真正重要的地方赛道数据收集、策略调整、稳定性的打磨而不是一遍遍重复“改代码-编译-烧录”的无意义循环。当然如果你打算走这条路一定要像我在文章里反复强调的那样先把芯片启动、固件编译、外设驱动这些地基打牢再往上盖Python这座快节奏的高楼。地基不牢的话脚本语言带来的效率红利大概率会在后期被各种玄学bug反向吞掉。