聊到PWM我估计很多人的第一反应就是“点亮一个呼吸灯”或者“给电机调速”。说实话这类项目我做过不少但也是踩过几次坑之后才真正想明白PWM看着只是高低电平交替背后其实是一整套流程架构。如果你脑子里没有这张架构图遇到波形不对的时候就只能在各种寄存器里瞎试运气好试出来了换个板子又一脸懵。这篇文章是PWM技术理论模型基础的第一篇我打算从“流程架构”的角度把PWM从需求到波形的完整链路拆开讲清楚。无论你用的是STM32、树莓派、Arduino还是直接用NE555搭硬件这套思路都通用。我会把每一层需要做什么、为什么要这么做、最常见的坑在哪里按我实际项目里的经验一层层说透。1. 先搞清楚PWM的“流程架构”到底在讲什么1.1 PWM本质时间维度上的平均能量控制PWM的全称是脉宽调制简单说就是让输出引脚在一段固定周期里一会儿高、一会儿低。我们用“占空比”描述高电平时间占整个周期的比例占空比越高单位时间内给到负载的平均能量就越大。我经常用一个类比来给团队新人讲这件事你拿水龙头往杯子里接水如果每秒开关一次水龙头那么水流就是一阵一阵的如果你把开关频率提到很高杯子里的水面上升速度就会变得很平稳最终的水量等于“开的时间比例”乘以全开水流。PWM控制LED、电机、加热片本质上都是在做这件事。这里有一个容易忽略的点PWM并不能直接输出一个“可变的模拟电压”它输出的永远是0和电源电压两个值。之所以最终效果连续是因为负载本身有惯性比如LED的亮度响应、电机的转动惯量、RC电路的积分效应。理解这个本质后面所有参数计算和故障保护的设计逻辑都能串起来。1.2 流程分层的价值L1到L5的通用思维很多人第一次听到“流程架构”这个词是在企业流程管理的培训里。确实业界有一套经典的分层方法把业务流程从顶层战略一直拆到具体执行动作常见的L1到L5分层被很多头部公司广泛应用。我第一次意识到这套思维可以套用到嵌入式系统上是在调试一个电机驱动项目时——当时PWM波形死活出不来我抱着数据手册从头翻到尾最后发现问题是控制策略层的一个标志位没置位跟寄存器本身一点关系都没有。从那以后我开始习惯把PWM系统也看成一条分层的流程架构。大体可以分成下面五层每一层都有自己关心的问题层级在PWM系统中的含义典型的“问题现场”L1 需求层你要用PWM解决什么业务问题呼吸灯要多大周期电机要什么转速L2 策略层怎么根据需求算出目标占空比/频率PID算法、故障保护、开环/闭环选择L3 资源层用哪颗芯片的哪个定时器/引脚定时器选型、引脚重映射、驱动电路L4 参数层对应寄存器的值怎么算ARR、PSC、CCR、极性、死区时间L5 信号层物理引脚上最终输出的波形质量上升沿是否干净、能不能驱动负载现在很多调试教程一上来就是“打开CubeMX配好参数生成代码”等于直接把L1、L2、L3全跳过了。一旦波形不对你也不知道是L4计算错了还是L3引脚映射错了。所以我建议每个PWM项目动手之前先画一张这样的分层示意图哪怕只是画在草稿纸上都能避免大量无效调试。2. PWM流程架构的五层拆解从需求到波形2.1 L1需求层你要的到底是什么需求层听起来虚实际上直接决定了后面所有参数。同样是输出PWMLED呼吸灯、电机调速、TEC恒温、LED RGB混色这些场景对频率、占空比精度、更新速度的要求完全不一样。LED呼吸灯关注的是亮度的时间变化曲线周期通常在1秒到4秒占空比需要连续变化但对绝对精度要求不高更新频率只要不低于50Hz左右人眼就不会觉得闪烁。LED RGB混色这个对占空比分辨率要求高因为颜色变化需要细腻的亮度比例PWM频率一般要1kHz以上否则拍视频会有频闪。直流电机调速主要关心平均电压和电流频率太高会增加开关损耗频率太低会产生可听噪声还要保证电流连续。TEC恒温控制TEC是热电制冷器最佳PWM频率和热时间常数、器件寿命都有关并不是越高越好。RC滤波输出模拟波形PWM频率需要远高于RC低通滤波器的截止频率否则纹波会很大。我见过有人把一套PWM参数从LED项目直接搬到电机项目里结果电机嗡嗡响转速还不稳定。这就是需求层没拆清楚。做需求拆解的时候至少要回答三个问题目标物理量是什么、它的响应速度是多少、允许的波动范围有多大。这三个问题一旦有了答案频率和占空比的上下限就基本框定了。2.2 L2控制策略层开环和闭环需求层确定了“要什么”策略层解决“怎么要”。PWM的控制策略大致分两类开环和闭环。呼吸灯属于开环因为它不需要感知当前亮度只按照预先算好的曲线去更新占空比。LED RGB混色也类似只要PWM参数稳定输出颜色就基本稳定。这种场景下策略层的重点就是数据生成方式是用简单的延时循环还是查正弦表还是用DMA直接灌数据。我推荐在策略层就把数据流设计好避免在应用代码里频繁修改比较寄存器。电机调速、TEC恒温、开关量PWM恒温控制这些场景通常需要闭环也就是要有一个“误差检测—算法计算—PWM输出”的循环。最常见的算法就是PID当前转速或温度和目标值比较后PID输出一个控制量再把这个控制量映射成占空比。这里有一个关键点PID输出的是0到100%的归一化数值转换成寄存器值要在L4层完成但在L2层就要规定好映射公式和限幅值否则PID在启动时很容易积分饱和导致输出100%占空比后刹不住车。策略层还必须处理异常分支就是故障保护。正常工作时我们按照算法更新占空比一旦检测到过流、过压或者过温流程必须立刻切换到安全状态而不是慢慢把占空比降下来。很多初学者把故障保护写进普通业务代码里结果主循环一卡保护逻辑跟着失效。正确的做法是在策略层定义“运行”、“保护”、“恢复”几个状态PWM的使能/刹车信号由状态机统一控制。2.3 L3资源映射层定时器、通道和引脚策略层算出了要的占空比接下来就是选硬件资源。这一层最容易让人困惑因为不同芯片的资源差异非常大而且同样的定时器可能有多组引脚映射。以STM32F103ZET6为例它的定时器资源非常丰富TIM3是一个通用定时器有四个独立通道可以用作PWM输出。TIM3_CH1的默认引脚是PA6但通过AFIO重映射可以部分重映射到PB4或者完全重映射到PC6CH2、CH3、CH4也都有对应的映射关系。很多人在这里会混淆“复用功能”和“重映射”复用功能是让引脚连接到某个外设重映射是改变这个外设在芯片内部连接到哪个引脚。H桥PWM电路也属于这一层。如果驱动的是直流电机你需要的可能不是单路PWM而是互补的一对PWM上下桥臂必须插入死区时间否则会直通短路。有些高级定时器比如STM32的TIM1、TIM8或者英飞凌TC3xx里的CCU6可以直接输出三相六路PWM并且硬件支持死区插入非常适合BLDC电机控制。如果用普通GPIO模拟两路互补PWM就只能靠软件延时做死区可靠性很低我建议能选硬件功能就别去跟时序较劲。DMA也归在资源层考虑。如果占空比需要按一定节奏变化比如正弦波、线性呼吸灯可以用DMA把占空比数据表周期性搬到定时器的CCR寄存器里让CPU彻底解放出来。这个在HAL库工程里叫PWM DMA配置不复杂但确实能省很多事。2.4 L4参数配置层寄存器与计算资源层选好了定时器和引脚接下来就是算寄存器值。STM32定时器生成PWM核心涉及三个寄存器预分频器PSC、自动重装载值ARR、比较捕获值CCR。PWM频率的计算公式是f_PWM 定时器时钟频率 / ((PSC1) * (ARR1))占空比的计算公式是Duty CCR / (ARR1)这里要注意不同的库和参考代码写法稍有差异有的把ARR当成最终周期值的一部分有的直接使用实际装载值所以算完之后最好用逻辑分析仪或示波器确认一遍。我举个例子STM32F103ZET6的TIM3挂载在APB1上时钟一般是72MHz。如果我们想要一个20kHz的电机PWM可以取PSC71这样定时器计数频率就是1MHz再用ARR49得到50kHz这样不对。1MHz / (491) 20kHz算完发现是20kHz等一下1MHz / 50 20kHz对的ARR取49。这个配置下计数器从0数到49一共50个计数周期每个周期1微秒所以PWM周期是50微秒频率20kHz。此时分辨率是1/50也就是2%对电机调速来说可以接受。但如果是LED调光2%的分辨率有时候不够。同样是72MHz如果我们把PWM频率降到4kHz可以取PSC71ARR249分辨率变成1/250也就是0.4%表现就会细腻很多。所以高频和高分辨率是一对矛盾频率越高ARR越小分辨率越低。要同时拿到高频率和高分辨率要么用更高主频的芯片要么用带高分辨率定时器的型号。还有中心对齐和边沿对齐的区别。边沿对齐模式最简单计数器只从0数到ARR然后跳回0输出PWM的波形上下不对称。中心对齐模式下计数器从0数到ARR再递减回0输出波形左右对称适合三相BLDC这类需要平衡电流纹波的场景。TC3xx的CCU6、STM32的高级定时器都支持这种模式配置时不要选错。2.5 L5物理输出层驱动电路和负载寄存器配置正确之后引脚上确实会有PWM波形但能不能驱动负载是另一回事。STM32引脚输出能力大概在几个毫安到二十几个毫安直接驱动LED还算勉强直接驱动大功率电机基本不可能。L5层要考虑的是要不要加三极管或MOSFET驱动、需不需要光耦隔离、H桥的死区电阻怎么选、RC滤波的截止频率是多少。LED最简单串一个限流电阻就行但RGB灯如果想亮度匹配还需要计算每种颜色对应的等效阻值。RC电路是另一个经典应用PWM经过RC低通滤波器后可以平滑成模拟电压截止频率公式是1/(2πRC)。PWM频率至少要高于截止频率10倍以上才能保证纹波在可接受范围。我经常用LTSpice搭一个PWM源加RC负载的仿真先把电容电阻值验证一遍再上板。电机驱动则要复杂一些。H桥里四个开关管由PWM控制上桥和下桥两两工作如果同一桥臂上下同时导通电容会直接短路瞬间大电流就会烧管子。所以H桥必须有死区时间也就是在一路关断到另一路开启之间插入一个极短的间隔。数学上H桥PWM控制的电机电流可以简化为电感在一个周期内被PWM电压交替充放电平均电流基本由占空比决定。只要频率足够高电流纹波会很小电机转速就比较稳定。Ne555做PWM是纯硬件方案它用555定时器工作在无稳态模式通过外部电阻电容设定频率再接一路调整占空比适合对MCU不熟悉或者想要极低成本独立模块的场景。树莓派上也能输出PWM波常见方法是使用内核的pwm子系统或者借助DMA驱动GPIO实现软件PWM。这些都属于L5层物理输出的变化但魂还是同一个PWM流程架构。3. 一个完整推演STM32F103ZET6 TIM3呼吸灯3.1 需求拆解与参数计算理论讲完我自己习惯用“STM32F103ZET6的TIM3做呼吸灯”这个例子把流程走通一遍因为项目麻雀虽小但每一层都涉及到了。先做L1需求拆解。呼吸灯的目标很简单LED在2秒内由暗变亮再由亮变暗亮度变化曲线要平滑。这个需求的关键指标是周期2秒更新率至少100Hz否则亮度变化会有阶梯感。要驱动的是普通LED最大电流控制在10mA左右。L2策略层选择开环。不需要感知亮度直接输出一条正弦查表曲线即可。我用一个包含200个点的亮度表每5ms更新一次刚好1秒完成从暗到亮再用1秒倒着播放构成完整2秒周期。这里有一个经验亮度不要用线性变化表人眼对亮度的感知是对数的线性表看起来中间会偏暗。用正弦或自定义gamma曲线观感更自然。L3资源层选择TIM3_CH1通道引脚用默认的PA6不需要重映射。这样最简单也方便用示波器直接夹PA6量波形。L4参数计算前面提到STM32F103的APB1时钟是72MHz取PSC71让计数器频率为1MHz。为了呼吸灯不需要太高的PWM频率取ARR249PWM频率就是4kHz。分辨率1/250足够细腻。预装载影子寄存器为了不让CCR更新了一半被计数器锁存需要开启预装载功能让修改值在计数溢出时统一生效。3.2 引脚重映射与GPIO配置虽然这个呼吸灯不用重映射但我还是要提一下如果要用PB4替代PA6该怎么配置因为这是pwm引脚重映射最典型的场景。在STM32标准外设库时代重映射要先用GPIO_PinRemapConfig(GPIO_Remap_TIM3, ENABLE)并开启AFIO时钟。HAL库时代依然要开AFIO时钟然后调用__HAL_AFIO_REMAP_TIM3_PARTIAL()但前提是工程里没有禁用AFIO时钟。很多人重映射不生效是因为STLINK/VCC/BOOT占用了PB4的默认JTAG功能。PB4和PA15、PB3、PB4在默认情况下是JTAG调试口的一部分如果只做了AFIO重映射没有禁用JTAG引脚还是会被调试器占据输出自然不对。解决办法一般是GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE)保留SWD禁用JTAG。这一步太容易踩坑了我在实际项目里至少帮人排查过三次。GPIO配置也比较关键。PA6要复用为TIM3_CH1必须配置成复用推挽输出而不是普通推挽输出否则引脚不会连接到定时器通道。标准库例程里会设置GPIO_Mode_AF_PPHAL库里配置GPIO_InitTypeDef的Alternate为GPIO_AF2_TIM3。3.3 初始化、PWM输出与动态占空比更新下面这段是基于HAL库的核心配置其实用STM32CubeMX勾选TIM3 Channel1 PWM Generation后也会生成类似代码。TIM_HandleTypeDef htim3; TIM_OC_InitTypeDef sConfigOC; htim3.Instance TIM3; htim3.Init.Prescaler 71; // 72MHz / 72 1MHz htim3.Init.Period 249; // 1MHz / 250 4kHz htim3.Init.CounterMode TIM_COUNTERMODE_UP; htim3.Init.ClockDivision TIM_CLOCKDIVISION_DIV1; HAL_TIM_PWM_Init(htim3); sConfigOC.OCMode TIM_OCMODE_PWM1; // PWM1模式 sConfigOC.Pulse 0; // 初始占空比0 sConfigOC.OCPolarity TIM_OCPOLARITY_HIGH; // 高电平有效 sConfigOC.OCFastMode TIM_OCFAST_DISABLE; HAL_TIM_PWM_ConfigChannel(htim3, sConfigOC, TIM_CHANNEL_1); HAL_TIM_PWM_Start(htim3, TIM_CHANNEL_1);启动后主循环里只需要不断更新比较值uint16_t brightness_table[200]; uint16_t current_duty; // 假设已经生成好brightness_table数值范围0~249 while (1) { for (uint8_t i 0; i 200; i) { current_duty brightness_table[i]; __HAL_TIM_SET_COMPARE(htim3, TIM_CHANNEL_1, current_duty); HAL_Delay(5); // 5ms更新一次 } for (uint8_t i 200; i 0; i--) { current_duty brightness_table[i - 1]; __HAL_TIM_SET_COMPARE(htim3, TIM_CHANNEL_1, current_duty); HAL_Delay(5); } }这里有个小细节__HAL_TIM_SET_COMPARE底层会去写CCR寄存器而不是直接改Pulse成员。如果你用HAL_TIM_PWM_Start后又想用htim3.Init.Period去改参数那就危险了因为有些配置不会实时生效。正确做法是使用宏或者HAL_TIM_OC_ConfigChannel来修改比较值。3.4 动态占空比更新时注意100%占空比异常做呼吸灯最容易遇到的现象是LED在最高亮度和熄灭之间反复横跳或者在最高亮度时突然熄灭。很多时候不是代码逻辑问题而是占空比计算越界。如果current_duty被计算成251而ARR249那么CCR值大于ARR。在PWM1模式下部分单片机尤其STM32会遇到极性反转或者一直输出高电平的现象看起来像100%占空比异常。要避免这个问题最简单的方法是循环前先取亮度值再用一个函数做clampduty MIN(MAX(duty, 0), ARR)。如果你用查找表要确认表里的最大值不会超过ARR。另外呼吸灯从亮到暗的过程里不要让CCR直接清零后立刻进入下一次采样。某些定时器在CCR被写成0后再改成中间值需要等待一个完整的PWM周期才生效。如果你更新频率过快会出现一小段“死区”表现为LED闪烁一下。我一般会把最小占空比限制在1到3而不是0观感上几乎没区别。4. PWM流程架构里的关键参数计算与故障保护4.1 占空比、频率、分辨率怎么相互制约在流程架构里L4层的参数计算是很多问题的原点。占空比、频率、分辨率三者的关系本质就一条给定时钟频率你想要多高的PWM频率就要牺牲多少分辨率。我用STM32F103的72MHz时钟列一个表大家看得直观点目标PWM频率预分频PSCARR分辨率1kHz7171990.014%10kHz717190.14%20kHz713590.28%100kHz7891.1%1MHz0711.4%分辨率越低能控制的档位越少。比如电机PWM 20kHz时如果ARR359那么占空比档位只有360个低转速时可能出现一卡一卡的现象。解决思路有两种一是提高定时器时钟比如用主频更高的新一代MCU二是用中心对齐模式或增加定时器时基时钟这是硬件特性没法纯粹靠软件绕开。在这个基础上还要考虑死区时间。特别是H桥PWM如果互补两路PWM没有死区哪怕只有几十纳秒的直通都可能导致MOSFET过热。死区的计算通常是基于开关管的关断延迟和下降时间经验值从几百纳秒到几微秒都有具体看驱动芯片手册。4.2 频率到底怎么定RC、电机、TEC和NE555关于PWM频率怎么选这是被问得最多的问题之一。我的建议是先看你负载的物理特性。RC电路最简单。如果RC低通截止频率是1kHz你想滤掉PWM纹波那么PWM频率最好是10kHz以上否则RC输出上会有明显的台阶。你可以用LTSpice直接搭一个PWM源跑一个TRAN分析观察不同频率下的纹波幅度比纸上算直观多了。我经常用这个方法在硬件投入之前就验证好电容电阻。直流电机调速建议最低不要低于10kHz很多电机在15kHz以下会啸叫就是人耳能听到的电感噪声。20kHz以上比较安全但太高会让MOS管开关损耗上升。所以我的经验值小功率电机用20kHz大功率电机用10kHz到16kHz同时把死区时间加上。TEC温控有个“最佳PWM频率”的说法。TEC本体是个固态热泵热惯性并不大如果PWM频率太高冷热交替极其频繁焊点和内部结构容易疲劳如果太低温度波动又会很大。我做过的一些半导体制冷片项目里PWM常用1kHz到5kHz之间再配合RC吸收尖峰。但不同TEC模块的规格差异很大还是要看数据手册里有没有关于最大开关频率的描述。Ne555做25kHz固定频率可调占空比是另一种思路。555工作在无稳态模式频率由两个电阻和一个电容决定调整占空比通常改变充电和放电的时间常数。想要“固定频率可调占空比”需要让充放电路径分开常见做法是两个电阻分别接二极管这样改变其中一路电阻时频率基本不变。实测下来25kHz正好避开人耳敏感频段适合驱动变压器或感性负载。4.3 故障保护流程架构中的异常处理分支流程架构里最容易被忽略的就是异常分支。正常流程是“需求分析—控制算法—PWM输出”但故障保护必须插在输出之前并且拥有比任何业务代码都高的优先级。以电机驱动为例如果只靠软件检测电流过大再去关闭PWM可能会在几毫秒内就把MOSFET击穿这个时间窗口对软件来说太长了。更可靠的做法是使用硬件级刹车功能。STM32的TIM1/TIM8高级定时器支持刹车输入一旦刹车引脚有效PWM输出会被硬件强制拉低或高阻根本不需要CPU介入。像TC3xx的CCU6输出三相六路PWM控制BLDC时也有类似的功能能随时切断所有通道。普通定时器像TIM3没有刹车引脚这时候我会在流程架构里单独画一条保护链路电流采样信号经过比较器输出直接接到一个使能引脚或者触发外部中断在中断里调用HAL_TIM_PWM_Stop。但这还是不够快。更稳的方案是让比较器控制一个驱动芯片的EN引脚硬件直接拉掉驱动输出MCU只负责记录故障原因和恢复操作。故障保护还要考虑恢复策略。很多项目要求过流后不能自动恢复必须人工复位。这个在策略层的状态机里要显式实现否则故障消失后占空比直接从0猛跳到100%会引发二次冲击。5. 常见问题排查与实操心得5.1 100%占空比却不输出的问题先说频率最高的一个问题“我设置了PWM100%占空比时引脚反而不输出了。”这种情况在STM32上很常见我排查过很多次根因不外乎这几类第一CCR写到了ARR之外比如Pulse赋成了250或251而ARR是249。第二PWM模式选错。STM32有PWM1和PWM2两种模式PWM1模式下向上计数时CNT小于CCR输出有效电平PWM2模式正好相反。如果模式配置反了100%占空比时实际的极性行为会颠倒。第三定时器预装载和影子寄存器没有配合好导致修改CCR后一直没有更新到真正的比较寄存器。我的排查顺序很固定先看寄存器确认CCR和ARR数值再用示波器直接量引脚波形最后查超时恢复代码有没有偷偷调用PWM_Stop。不要一上来就怀疑芯片坏了绝大多数情况是流程某一步没串起来。5.2 引脚重映射配置了却不生效重映射不生效基本上绕不开两个原因一是AFIO时钟没开二是引脚被其他复用功能占用。STM32F103系列GPIO_AFIO时钟默认是关闭的。不管是标准库还是HAL库重映射之前必须手动使能。另外重映射改的是引脚连接GPIO本身还要配成复用推挽输出如果只改了重映射GPIO还是普通推挽那么引脚不会接到定时器。PB4这个特殊引脚还要额外注意。它默认是JTAG的NJTRST信号要使用它做TIM3的CH1不仅要做重映射还要把JTAG完全禁用或部分禁用。我见过最离谱的情况是重映射配了SWD也没关PB4依然拉不高最后查出来是调试器占用了这个引脚。5.3 呼吸灯不平滑、电机噪声大的背后逻辑呼吸灯不平滑多数是更新率太低或者占空比步进太大。更新率低于30Hz时人眼都能看到一亮一灭的阶梯至少做到100Hz以上。步进方面如果用线性变化每步变化不要超过3%到5%否则看起来还是跳变。电机噪声大则是另一套逻辑。一个常见原因是PWM频率落在可听范围内特别是10kHz以下电机线圈会发出明显的啸叫。另一个常见原因是死区时间设置不当导致桥臂切换时电流尖峰过大噪声和发热一起增加。还有一个隐性问题互补PWM的中心对齐和边沿对齐差异边沿对齐下电流纹波大电机会更“暴躁”。我在调试这类问题时习惯先用PWM频率扫描从低往高逐步加减同时听声音、看电流波形。一般来说能在示波器上看到电流纹波最平滑的那个频率点噪声也最小。5.4 用DMA和中心对齐模式把波形做得更稳如果呼吸灯或者任何占空比动态变化的任务占了CPU太多时间我建议把L4层的更新方式改成“PWMDMA”。思路是先把一组占空比数据放到一个数组里配置DMA把数组内容周期性搬运到定时器CCR寄存器并在传输完成时产生中断或循环传输。这样CPU只需要在初始化时启动DMA后续整个过程都不再参与。HAL库里写起来也不复杂关键是选对DMA方向是内存到外设以及外设地址是CCR寄存器。PWM DMA配合中心对齐模式可以让波形左右对称更贴近电机控制和音频类应用的需求。我在Py32F003、STM32G474、TC3xx这些不同平台上都实现过类似功能思路大同小异只是库函数名称有差异。5.5 我的几个实操心得如果只让我说一条经验那就是拿到一个PWM需求先别打开CubeMX先在纸上把流程架构画出来。把需求层的目标量化出来把策略层的开闭环和保护方式写清楚再选资源和引脚最后才去填寄存器参数。这样虽然前期慢一点但后面几乎不会出现“波形不对写一天”的情况。第二个心得是善用逻辑分析仪和示波器。PWM调试最容易犯的错是“盲猜”。你觉得自己把占空比设到了50%但实际波形可能是21%。在我的工作台上逻辑分析仪永远插着看PWM波形比任何调试器打印都准确。尤其是PWM频率比较高的时候很多逻辑分析仪采样率不够会看到乱码这时候要改用示波器。最后再说一个扩展思路单总线PWM。有些应用为了节省引脚想在一条线上既传输控制数据又传递PWM波形或者想用单总线的时序来模拟PWM输出。这类玩法本质上还是PWM模型只是把L3、L5层的实现换成了更底层的收发器方案。做之前一定要重新评估实时性和协议兼容性我在蓝牙IOT项目里试过一次牺牲了不少CPU时间后来还是换回了硬件PWM加普通GPIO曲线救国并不总是划算。