前阵子我在搜索框里输入“pi”这两个字母，结果刷出来一屏八竿子打不着的东西：有人问Python里怎么把圆周率精度开到小数点后一百位；有人贴出树莓派Pico驱动0.96寸OLED的接线求助；一篇电力电子的论文标题里赫然写着“MMC环流抑制器的PI参数整定”；再往下翻还有“PI仿真报告”、“pi coding agent”、“pi web导入skill”这种读不太懂的词条。那一刻我意识到，“pi”大概是我见过的最会分身术的两个字母——它既是数学常数，也是控制算法缩写，是硬件工程师口中的电源完整性，是创客手里的树莓派，现在又成了AI编程智能体的名字。这篇文章我不打算给它强行下定义，而是把这几个真正值得聊的“pi”挨个摊开，每个方向尽量给到能直接参考的思路和细节。

1. 数学世界的π：为什么工程代码里到处是2π

1.1 从圆周率到角频率：π是周期世界的翻译官

数学家眼里的π，是圆的周长和直径的比值，3.14159265……无限不循环。但工程师代码里的π，几乎从来不会以几何常数的身份单独出场。它总是和“转圈”绑定在一起：一个完整的圆是2π弧度，一秒钟转f圈，对应的角频率就是ω = 2πf。

这个“2π”才是工科生真正要天天打交道的π。拿电机控制举例，你拿到一个额定转速1500rpm、4对极的永磁同步电机，做FOC矢量控制时，电角速度就是2π × (1500 / 60) × 4 ≈ 628.3 rad/s。你写坐标变换矩阵时，等号右侧一定有它。做并网逆变器要生成50Hz正弦波参考，查表或在线计算也是sin(2π × 50 × t)。我习惯在工程代码里直接用宏定义或常量：

#define TWO_PI 6.283185307179586

因为只要涉及频率、相位、旋转，最后都会落到这个常数上。你要理解的核心认知是：π在工程里不是“圆的计算”，而是频率与相位之间的翻译官。把一个周期说成“2π”，等于给了所有周期现象一把统一的尺子。

1.2 频谱分析里的π：FFT中绕不开的那一环

如果只记得一个公式，做信号处理的会说是傅里叶变换，那里的π跑不掉：e^(-j2πft)。你直接写离散FFT代码时可能不会去手写这个指数，因为库函数都封装好了，可一旦要画频谱图、标频率轴，π就冒出来了。

举个例子，采样率1000Hz，做1024点FFT。频率分辨率Δf = fs / N ≈ 0.976Hz。在Python里你直接用：

import numpy as np freq = np.fft.fftfreq(1024, d=1/1000)

这个d参数本质上就是采样间隔，而频域坐标背后的周期延拓、旋转因子，全是从2π来的。我见过不少新人用示波器抓到波形，怀疑有50Hz工频和150Hz谐波，却不会把FFT的谱线和实际频率对上。其实就是N和fs的换算，会了之后一眼就能看出谱峰落在第几根谱线上，对应多少Hz。这个估算能力比FFT本身的实现重要得多。

1.3 浮点世界里的π：精度、相位漂移与工程取舍

新手写圆周率喜欢用3.14，写代码超过三行的都该用math.pi。原因很直接：3.14当π用，意味着每个周期的相位都在累积误差，1000个周期之后误差大到肉眼可见。

长时间运行的信号处理系统里，常见做法是相位累加器：

angle = fmod(angle + delta, TWO_PI);

每次增量后做一次模运算，把相位永远限制在[0, 2π)区间，避免浮点数无限增长。另一个容易踩的坑是嵌入式平台上的浮点精度。Pico用的RP2040是Cortex-M0+内核，MicroPython默认用单精度float，大约7位十进制精度。做PI运算时Kp、Ki用float通常够用，但如果要做长时间的频率积分用于PLL锁相，累计误差会导致相位漂移，那就需要考虑更高精度的实现或者定期校正。这个取舍，写代码时就要想清楚。

2. 控制系统里的PI：环流抑制与PLL带宽的整定逻辑

2.1 为什么控制工程偏爱PI：比例与积分的分工

比例P的作用是“当前误差有多大，立刻输出多大”。它响应快，但系统有扰动或者对象不够理想时，光靠P总会留一点“够不着”的静差。积分I则把过去所有的误差累积起来，有误差就慢慢补，最终能把静差消掉——但I动作慢，还容易“刹不住车”造成超调。

PI就是这两者的折中：P负责快，I负责准。打个比方，定速巡航里的PI就很形象：P相当于看到当前车速和设定值有差值，立刻给油或刹车；I相当于长时间发现总是差个2km/h，就持续把油门多给一点。没有I，长下坡后你永远差一口气；没有P，上坡时车半天反应不过来。

在电力电子和运动控制领域，PI几乎是统治级的存在：电流内环、电压外环、转速环、PLL环、MMC环流抑制，全是PI的剧场。所以搞控制的人说“调PI”，并不是在调一个参数，而是在同时处理“要多快”和“要多准”这一对矛盾。

2.2 MMC环流抑制器的PI参数：先搞清环流从哪来

MMC（模块化多电平换流器）的桥臂由很多子模块级联而成，桥臂之间因为电容电压波动、上下桥臂指令差异，会产生一条不经过交流侧的环流，主要在桥臂电感之间来回窜。这个环流的主要成分是二倍频——对50Hz电网来说就是100Hz。如果不抑制，桥臂电流会畸变、损耗上升、电容电压波动加剧。

抑制环流的基本思路是：在桥臂电压参考里叠加一个针对二倍频分量的校正量。热词里说“MMC环流抑制器的PI参数”，实际工程里有两种主流做法：一种是先把二倍频分量通过旋转坐标变换变成直流量，再用PI去控制；另一种是直接用PR（比例谐振）调节器，把谐振点设在100Hz。如果论文和资料里讲PI，多半是第一种。

参数整定我先给一个通用流程：

• 第一步，建模。把环流看成在桥臂电感L上由电压差驱动，控制对象近似成一阶惯性加延时。
• 第二步，定带宽。环流抑制环的带宽通常取主电流环带宽的1/5到1/10，避免两个回路打架。目标是让100Hz附近有足够增益。
• 第三步，反推参数。桥臂电感L=5mH，希望抑制环穿越频率约300Hz，ωc = 2π × 300 ≈ 1885 rad/s。粗略估算Kp ≈ ωc × L ≈ 9.4。积分时间常数Ti取对象时间常数的3到5倍，对象时间常数约L/R=50ms，按150ms算，Ki = Kp / Ti ≈ 63。这只是仿真起点，实调以波形为准。
• 第四步，离散化。数字控制器里用双线性变换或零阶保持器把连续域参数转换到z域，别忘了核对采样周期。

实调时我的习惯是：先看有没有发散和振荡，再观察环流波形里的二倍频分量有没有降下来。如果环流抑制加进去之后主电流波形反而变差，说明带宽太高、抢了主回路的“戏”，降带宽重来。

2.3 PLL的PI控制带宽fb：锁相环参数怎么选

并网逆变器、电机驱动里的电网同步，核心基本都是同步坐标系PLL（SRF-PLL）。它的结构是：三相电压经过Clarke变换、Park变换得到d/q轴分量，q轴分量输入PI，PI输出角频率修正量，再积分得到相位。锁定的本质，就是让q轴平均值收敛到0。

线性化之后，这个系统可以近似为二阶系统。按经典整定，阻尼比取0.707，自然角频率ωn由带宽决定。对50Hz电网，PLL带宽通常取20到100Hz。给一个具体例子：带宽30Hz，ωn = 2π × 30 ≈ 188.5 rad/s，Kp = 2 × 0.707 × ωn ≈ 266，Ki = ωn² ≈ 35530。注意这是连续域、归一化增益下的起点，实际还要乘电网幅值等系数。

热词里那个“pll pi控制带宽fb”，这里的fb就是带宽（bandwidth）。我要特别强调一句：PLL带宽不是越高越好。带宽高，锁相响应快，但抗扰能力差。三相不平衡会产生2倍频负序分量，在dq坐标系里表现为100Hz扰动，如果带宽设计得很高，这个100Hz扰动会透传到相位输出，造成锁相抖动。现场遇到锁相抖动的第一步，往往不是加滤波器，而是先把PLL带宽降下来看是否改善，再决定要不要上陷波器。

// PLL PI输出限幅示例 float pll_out = Kp * err_q + Ki * integral_q; if (pll_out > MAX_DW) pll_out = MAX_DW; if (pll_out < -MAX_DW) pll_out = -MAX_DW;

这个限幅很关键，它限制的是角频率修正范围，防止积分饱和把系统推飞。

2.4 现场调参的真实经历：一次环路发散排查

调PI参数这件事，最忌讳上来就凭感觉改Kp、Ki。我的经验是先定带宽，再定阻尼，然后反推参数，最后离散化验证。但理论再顺，现场也总有意外。

有一回调试某装置的环流抑制，仿真波形好得很，一上实验台就发散。查了两天，最后发现是代码里的采样周期写错了一个数量级——PI参数按10kHz采样率设计，代码实际跑的是1kHz，实际带宽虚高了一截。从那以后我养成了个死规矩：动PI之前，先核对执行周期和采样周期，再核对参数单位。这个习惯帮我省了很多次“查到最后发现是低级错误”的尴尬。

另一个常见坑是积分饱和。启动瞬间误差很大，积分项疯狂累积，等误差翻转过来时积分还顶着上限，系统就会震荡。解决方法是输出限幅加条件积分，只在输出没饱和时才允许积分累积。这些细节写进代码之前看不出来，写完之后才觉得全是必备操作。

3. 硬件人说的PI：信号完整性与电源完整性的实战认知

3.1 SI与PI：两个极易混淆的PI

硬件圈里的PI，指的是Power Integrity（电源完整性），经常和SI（Signal Integrity，信号完整性）成对出现。SI关心的是信号在PCB传输线上走完之后波形还保不保真——反射、振铃、串扰、眼图闭合；PI关心的是整块板的供电网络PDN在瞬态下的表现——电压跌落、纹波、地弹、谐振。

两者可以这样类比：SI是路况，PI是油箱和油路。处理器是收货人，信号是快递包裹，电源是汽油。快递跑得再快，油路堵了发动机熄火，一切都白搭。这几年PI的地位越来越高，原因是芯片内核电压从5V一路降到1.0V以下，允许的纹波从0.5V缩到30mV甚至更低，而负载电流反而从几百毫安涨到几十安，瞬态di/dt越来越快。一个30mV的跌落，可能就让CPU逻辑出错。于是“电源也要仿真、也要设计”成了硬件工程师的必修课。

3.2 目标阻抗法：电源完整性分析的第一课

PI分析最实用的入门方法是目标阻抗法。核心公式是：

Z_target = V_ripple_allowed / I_step

举个例子：1.0V核心供电，允许3%的跌落，也就是30mV；负载瞬态电流变化2A。那么目标阻抗就是15mΩ。设计目标是在关心的频段内，PDN的阻抗曲线全程低于15mΩ。

去耦电容怎么配，是这个公式的落地。很多人以为电容越大越好，其实不然。电容有个自谐振频率，由自身的ESL决定，大容值的贴片电容ESL大，到了几十MHz就呈感性了。所以去耦设计是分层的。

实操上，我一般先算瞬态电流幅度和允许纹波，得出目标阻抗和需要覆盖的频段，再倒推每一层需要多少电容。先算再放，而不是板子上堆满电容然后祈祷有效。这个习惯能让电源设计从“玄学”变回“工程”。

3.3 SI/PI仿真流程与常用工具

SI/PI仿真的一般流程是：先定叠层，再做二维/三维场提取，然后频域扫阻抗，再做时域瞬态和眼图，最后回来对比实测。工具方面，商业软件常用Cadence Sigrity、Mentor HyperLynx、Ansys SIwave/HFSS；开源方向KiCad近几个版本加入了部分SI/PI相关能力，配合openEMS这类场求解器可以做些基础分析，但要支撑高速数字设计还是吃力。

这里说几个实际经验。第一，模型别太干净。仿真模型里如果没建过孔、封装引脚、参考平面开槽，结果再漂亮都是假的，真实板子的反射和串扰往往就是这些不起眼的结构搞出来的。第二，频域好不代表时域好。阻抗曲线全程低于目标阻抗只是必要条件，激励源谐波丰富时，时域波形仍可能振铃。仿真完一定要用真实瞬态激励再验一遍。第三，仿真救不了错误设计。层叠没定好、回流路径被割裂，后面再怎么迭代电容布局都治标不治本。新板子回来后用TDR看特征阻抗、用网分测PDN阻抗，把仿真模型校准好，后面迭代才有意义。

4. 树莓派Pico 2040接0.96寸OLED：从接线到点亮的完整过程

4.1 为什么这个组合值得玩：RP2040与SSD1306

热词里直接出现“raspberry pi 2040 + oled 0.96”，说明这个组合是很多树莓派入门者的第一站。Pico是树莓派基金会出的微控制器开发板，主控是RP2040，双核Cortex-M0+，主频最高133MHz。0.96寸OLED是128×64分辨率、SSD1306驱动，I2C接口只要四根线就能点亮。组合起来成本很低，但能学到的知识点很完整：I2C协议、显存操作、帧率概念、嵌入式驱动写法。

为什么不选SPI版本的OLED？SPI刷新更快，但管脚多、驱动代码复杂。I2C两根线搞定，MicroPython里几行代码就能点亮，对入门者友好得多。先跑通再升级，这是我一直推荐的路子。

4.2 接线细节：四根线，但这些坑必须先避开

Pico上的I2C0默认走GPIO0和GPIO1，对应物理引脚第1脚和第2脚。OLED模块四根线这样接：

• OLED VCC → Pico 3V3(OUT)（物理第36脚），注意是3.3V不是5V
• OLED GND → Pico GND
• OLED SDA → Pico GPIO0
• OLED SCL → Pico GPIO1

接线前先确认屏的版本。0.96寸OLED有I2C和SPI两种驱动板的版本，I2C版一般是4引脚，SPI版通常是7到8引脚。买家标题和模块背面丝印都能看出来。I2C版的地址默认一般是0x3C，极少数是0x3D，不要猜，用扫描确认。

from machine import Pin, I2C i2c = I2C(0, sda=Pin(0), scl=Pin(1), freq=400_000) devices = i2c.scan() print("I2C devices:", [hex(d) for d in devices])

如果扫描结果是空的，先量OLED的VCC有没有3.3V，再检查SDA/SCL有没有接反，最后才是怀疑屏坏了。另外有些模块上电初始化慢，建议扫描前加一点延时，提高一次成功率。

4.3 点亮OLED的MicroPython代码与逐段解读

把下面的代码放进Thonny，上传ssd1306.py驱动到Pico，然后运行：

from machine import Pin, I2C, ADC import ssd1306 import time i2c = I2C(0, sda=Pin(0), scl=Pin(1), freq=400_000) devices = i2c.scan() print("I2C devices:", [hex(d) for d in devices]) oled = ssd1306.SSD1306_I2C(128, 64, i2c) oled.fill(0) oled.rect(0, 0, 127, 63, 1) oled.text("Hello Pi", 2, 2) oled.text("RP2040+0.96OLED", 2, 18) adc = ADC(4) conv = 3.3 / 65535 raw = adc.read_u16() * conv temp = 27 - (raw - 0.706) / 0.001721 oled.text("Temp: {:.1f} C".format(temp), 2, 34) oled.show()

关键点逐个说。ssd1306.SSD1306_I2C(128, 64, i2c)创建的是显存对象，所有fill、text、rect操作改的都是内存里的缓冲区，只有调用show()才会真正刷到屏上。忘了show()是新手最常犯的错误。ADC(4)是RP2040内部温度传感器，输出约0.706V对应27℃，每摄氏度变化约1.721mV，这个公式可以参考，不同批次芯片有偏差但不影响演示。库函数里text方法内置的是8×8像素英文和数字字模，没有中文，需要中文就得自己做字模或用外挂字库。

想画点和动态效果也很简单：

oled.line(0, 0, 127, 63, 1) # 对角线 oled.fill_rect(20, 40, 60, 10, 1) # 填充矩形 for i in range(1, 128, 8): oled.fill_rect(0, 56, i, 6, 1) oled.show() time.sleep(0.02)

注意fill_rect按像素坐标画矩形，做进度条、柱状图非常方便。

4.4 实测中翻车的五个瞬间

我第一次点亮这个屏的时候也踩了几个坑，复盘一下：

1. 地址不是0x3C。某块屏扫描出来是0x3D，直接把代码里写死的0x3C改掉就好，用oled = ssd1306.SSD1306_I2C(128, 64, i2c, addr=0x3D)指定地址。
2. I2C线太长。用二十厘米杜邦线问题不大，超过三十厘米或者环境里有电机、开关电源干扰，就可能在扫描时偶尔失败。解决方法是缩短线长，或者在Pico端自己加4.7k上拉电阻到3.3V。
3. 供电电压赌错了。模块上只有SSD1306和几个贴片电容、没有稳压芯片的，只能接3.3V，接5V大概率烧屏。模块上有1117-3.3稳压块的可以接5V，但Pico板载3.3V完全够用，没必要赌。
4. RES脚悬空。部分模块把RES引出来了，悬空有时也能亮，但复位时序可能不对。保险起见把RES接到GPIO2并在初始化时拉高。
5. 刷新率太低。I2C 400kHz下全屏刷新只有十几帧每秒，做动画千万不要整屏重绘，用局部更新。

4.5 从Pico到桌面：树莓派桌面生态与“oh my pi”这类热词背后

热词里有个“oh my pi 桌面版下载”，我没去考证它具体指向哪个仓库，但这个名字背后的需求我很熟悉：树莓派不只是一块单片机，它还有完整的Linux生态，玩到后面没人想天天对着黑乎乎的终端，把桌面装修得赏心悦目和把硬件跑起来一样有成就感。

如果你想走桌面路线，我的建议路径是：先用无头模式通过SSH登录树莓派，装上Raspberry Pi OS Lite；想要桌面就烧完整版系统，TF卡32GB起步，用Raspberry Pi Imager烧录；远程桌面用系统自带的RealVNC或第三方RustDesk都可以；最后再定制主题和终端美化，网上Linux桌面美化那套经验基本都能用。顺带一提，树莓派的乐趣一半在点亮硬件的瞬间，另一半在把系统调成顺手的样子。

5. AI时代的pi agent：编程智能体的能力与边界

5.1 热词里的pi agent、pi desktop与skill导入：一套新工具链的轮廓

最近一两年，“agent”成了AI编程方向最热的词。热词里出现的pi agent、pi coding agent、pi desktop、pi subagent、pi web导入skill，看起来是一套围绕桌面和IDE的编程智能体生态。我不去考证具体产品版本（这类工具迭代太快），但它们的典型形态已经比较清晰：

• 你给它一个任务，它会先拆解成子任务，必要时生成或调起子agent（subagent）去并行或异步处理。
• 它能直接读取代码文件、运行命令、看测试结果，然后决定下一步动作，而不是只输出建议。
• 它支持导入“skill”，也就是技能包——可以是提示词模板、工具调用脚本、领域规则，相当于给智能体定制内功心法。热词里说的“pi web导入skill”，大概率就是这个机制，以Web链接或文本形式把技能灌进去。

我的总体评价是：方向对了，但期望管理更重要。

5.2 能干与不能干：agent边界实测

我最大的感受是，agent和纯对话式AI的区别在于“执行闭环”——它不再只是“回答你”，而是“替你去干活”。但“替你去干活”也意味着它可能替你捅娄子：删错文件、改错配置、引入可疑依赖。所以用agent的第一原则就是让它在Git分支或沙箱里干活，别直接在主分支上裸奔。

5.3 把agent用好的几条建议

1. 任务拆小。一个大需求拆成多个小任务，每个指定具体文件和验收标准；让主agent做规划和汇总，subagent只管执行。一把梭的任务通常翻车在最后。
2. 上下文喂明白。任务描述里写清技术栈、目标文件路径、禁止做的事情，参考实现也附上。含糊其辞会放大它的“幻觉式自信”。
3. 先方案后动手。要求它在动手前先输出修改计划和影响面分析，确认了再跑。这既是约束，也是让代码审查前置的好办法。
4. 测试兜底。让它先写单测再改实现，或者改完能跑通现有测试。测试结果就是评估它改得好不好的客观标准。
5. 审代码是人的责任。agent生成的代码，尤其是涉及依赖引入、权限操作、网络请求的部分，一定要按公司规范过一遍审查。
6. 小心“技能”来源。第三方的skill文件本质上是代码和指令，引入之前先读一遍，防止供应链层面的风险。

说实话，写这篇之前我也没想到“pi”两个字母能铺开这么大的摊子。它像一面镜子，照出不同行业的人各自关心什么。如果你现在正要做一个和pi相关的项目——不管是Pico驱动屏幕还是调PI参数——我的建议很简单：先把名字写全。代码里用pi_kp、pll_bandwidth、pi_agent_skill这种带上下文的命名，别用一个光秃秃的pi。这个习惯能帮你省下不知道多少翻代码的时间。