1. 从一次调试翻车说起为什么OSSR和OSSI值得单独拎出来讲前阵子帮朋友看一个三相无刷电机的驱动板现象很怪上电后电机不转但示波器挂在栅极驱动上能看到PWM波形占空比也对就是桥臂上下管的死区时间偶尔会“粘”在一起烧了两颗MOS管。他翻遍了时钟树、死区寄存器、比较值甚至怀疑是驱动芯片自举电容的问题折腾了两天没头绪。我让他把TIM1的BDTR寄存器打印出来一看OSSR和OSSI两个位都是默认的0而他的应用是互补输出带死区、需要空闲时保持确定的关断电平。问题就出在这两个位没配对——互补通道在运行和空闲状态下的输出使能逻辑没理顺导致刹车或强制输出时引脚状态不确定。这件事让我意识到STM32高级定时器TIM1里那几个名字长得像乱码的位——OSSR、OSSI、OISX、OISXN——虽然手册上每个只有一两行描述但它们直接决定了功率级在“正常跑”和“出事停机”两种状态下引脚到底输出什么电平。搞电机驱动、逆变器、数字电源、大功率LED驱动的朋友这几个位配错了轻则波形毛刺重则炸管。这篇就围绕TIM1的这四个配置位把它们的定义、作用、区别、配合关系以及我在实际项目里踩过的坑一次讲透。适合已经会用TIM1输出PWM、但还没细究过BDTR寄存器细节的嵌入式开发者也适合刚接触高级定时器、想搞明白“为什么我的互补输出空闲电平不受控”的新手。2. 先把概念地基打牢TIM1的互补输出与刹车体系2.1 高级定时器和通用定时器的本质差别在哪STM32的定时器分基本、通用、高级三档很多人用惯了TIM2/TIM3切到TIM1时觉得“不就是多几个通道嘛”这个认知会直接导致配置翻车。通用定时器的输出通道是各自独立的CH1输出什么只跟CCR1和输出极性有关而高级定时器TIM1多了一整套面向功率变换的硬件安全机制核心就是互补输出对和刹车输入BRK。具体来说TIM1的每个通道都可以配置成“主输出互补输出”的一对比如CH1和CH1N。这两个引脚在正常运行时严格互补中间插入可编程死区防止桥臂直通。而一旦刹车信号触发可以是外部BRK引脚也可以是时钟安全系统、比较器输出等内部事件硬件会立刻把输出拉到预设的安全电平不依赖软件干预。这套机制是硬件级的响应时间在纳秒到几十纳秒量级软件中断根本追不上。理解了这一点就能明白OSSR、OSSI、OISX、OISXN这四个位为什么存在它们回答的是两个问题——输出使能信号OE在什么条件下才真正驱动引脚以及当输出被关闭时引脚应该停在什么电平。前者是OSSR和OSSI管的后者是OISX和OISXN管的。2.2 输出使能OE到底是个什么东西看手册时经常见到“OE”这个词容易一头雾水。你可以把TIM1的每个输出通道想象成一个水龙头CCR比较产生的PWM波形是水源但水源能不能流到引脚上中间还有一个总阀门这个阀门就是输出使能OE。OE为1阀门打开PWM送到引脚OE为0阀门关闭引脚输出由OISX/OISXN决定的空闲电平。关键在于这个OE信号不是单一来源它由多个条件“与”起来通道使能位CCxE、互补通道使能位CCxNE、刹车状态BRK、主输出使能MOE等等。OSSR和OSSI的作用就是在这套逻辑里插入两个“旁路开关”改变OE在特定状态下的行为。不把OE的来源理清看OSSR/OSSI的描述就是天书。2.3 运行状态与空闲状态的划分TIM1的输出状态可以粗分为两类。运行状态指定时器正在计数、通道使能、MOE为1、没有刹车触发此时PWM正常输出。空闲状态指定时器停止CEN0、或者通道被禁用、或者刹车触发导致MOE被硬件清零此时输出应该处于安全电平。OSSR管的是运行状态下互补通道的使能逻辑OSSI管的是空闲状态下输出使能的保持逻辑。这两个位名字里的“SR”和“SI”可以记成“Run”和“Idle”的变体虽然官方命名来源不是这个但这样记不容易混。下面逐个拆。3. OSSR与OSSI两个“旁路开关”的作用与区别3.1 OSSR运行模式下互补输出的“免检通行证”OSSR全称是Off-State Selection for Run mode运行模式下的关闭状态选择。它的作用场景是定时器正在运行CEN1通道使能了但某个通道的互补输出需要被关闭时这个关闭动作要不要经过“标准流程”。标准流程是什么当CCxE1、CCxNE0时按常理CHxN应该关闭。但OSSR0时CHxN的关闭还额外受MOE和刹车状态影响逻辑链更长OSSR1时只要CCxNE0CHxN立刻进入空闲电平不再看其他条件。换句话说OSSR1相当于给互补通道的关闭开了一张“免检通行证”让CCxNE位对CHxN有直接、快速的控制权。这个差别在什么场景下要命做互补PWM时有时需要在运行中动态关闭某一相的互补输出比如故障降级运行只保留主输出。如果OSSR0你清了CCxNE但CHxN可能因为MOE还挂着而没立刻关断出现短暂的“该关没关”OSSR1则保证清了就关行为确定。我在一个数字电源项目里做逐周期限流检测到过流就临时关互补管OSSR1让关断动作干脆利落OSSR0时示波器上能看到几十纳秒的拖尾虽然短但在大电流下就是风险。3.2 OSSI空闲模式下输出使能的“记忆保持”OSSI全称是Off-State Selection for Idle mode空闲模式下的关闭状态选择。它的作用场景是定时器停止计数CEN0或者MOE被清零进入空闲态时输出使能OE应该怎么处理。OSSI0时空闲状态下OE被强制为0所有输出通道不管CCxE/CCxNE配成什么一律关闭引脚输出OISX/OISXN设定的电平。这是“一刀切”的安全策略。OSSI1时空闲状态下OE保持为1前提是MOE1此时引脚输出不再由OISX决定而是由CCxE/CCxNE和CCR比较结果决定——也就是说定时器虽然停了但输出还“记着”停之前的状态。这个位的典型用途是刹车后的状态保持。有些应用在刹车触发后希望桥臂保持刹车瞬间的电平组合而不是全部拉到某个默认电平OSSI1配合OISX/OISXN可以实现更精细的停机姿态。但要注意OSSI1时如果CCR值停在某个危险位置停机后引脚可能输出非预期的电平所以用之前必须想清楚CCR在停机时刻的值。3.3 两者的核心区别一个管“跑的时候怎么关”一个管“停的时候怎么留”把OSSR和OSSI放一起对比最容易混。我用一句话概括OSSR决定运行中互补通道关闭的果断程度OSSI决定空闲时输出使能的保持程度。前者影响的是动态过程中的关断时序后者影响的是静态停机后的引脚状态。配置位作用状态置0时的行为置1时的行为典型适用场景OSSR运行模式CEN1互补通道关闭受MOE/BRK等多条件约束关断有延迟CCxNE直接控制CHxN关断果断需要动态关互补管的降级运行、逐周期保护OSSI空闲模式CEN0或MOE0OE强制为0输出全部关闭引脚走OISX/OISXNOE保持为1输出由CCxE/CCxNE和CCR决定刹车后需要保持特定停机姿态的场合实际项目里这两个位很少单独出现通常和刹车配置、MOE管理一起考虑。我个人的默认配置习惯是做电机驱动时OSSR1、OSSI0理由是运行中要果断关断停机时要绝对安全做某些需要刹车保持姿态的电源拓扑时才会把OSSI打开而且打开前一定反复确认CCR的停机值。注意OSSR和OSSI都在BDTR寄存器里而BDTR有写保护机制LOCK位。配置顺序上先配好OSSR/OSSI/OISX/OISXN再设LOCK等级否则改不动。这个顺序错了现象是“写了没反应”新手很容易卡在这里。4. OISX与OISXN空闲电平的“最后一道闸”4.1 OISX和OISXN分别对应谁OISX是通道x主输出CHx的空闲电平OISXN是通道x互补输出CHxN的空闲电平。注意这里的“空闲”指的是OE0的状态也就是输出被关闭时引脚该停在哪。置1则空闲时输出高电平置0则输出低电平。这两个位只在这个条件下生效OE0。而OE0可能来自多种原因——CEN0且OSSI0、MOE0、刹车触发、通道禁用等。所以OISX/OISXN不是“刹车专用电平”而是“所有输出关闭场景的通用电平”。理解这一点很重要因为很多人以为它只管刹车结果定时器一停引脚电平跟预期不符回头查半天。4.2 空闲电平的选择逻辑为什么不能随便填OISX/OISXN填什么取决于外部功率级的拓扑和安全策略。以最常见的半桥驱动为例安全停机状态通常是上下管都关断此时栅极驱动输入应该是什么电平取决于驱动芯片的使能极性。如果驱动芯片是高电平使能那OISX和OISXN都应该填0保证停机时两个管子都关如果驱动芯片带反相逻辑就要反过来。再考虑刹车场景。有些应用希望刹车时下管导通、上管关断让电机绕组通过下管续流形成短路制动这时候OISX主输出假设驱动上管填0OISXN互补输出驱动下管填1。这个组合不是拍脑袋定的要结合驱动芯片极性、功率管类型、续流路径一起算。我见过一个翻车案例某开发者做BLDC驱动OISX和OISXN都填了0但他的低边驱动芯片是低电平有效结果刹车时下管反而导通上管也导通因为主输出填0经过反相后变高桥臂直通。所以填这两个位之前必须把“逻辑电平→驱动芯片→功率管栅极”这条链路的极性捋一遍画个真值表别凭感觉。4.3 OISX/OISXN与OSSI的联动关系这两个配置组是联动的不能割裂看。OSSI0时空闲状态OE强制为0OISX/OISXN生效引脚输出你设定的电平行为确定。OSSI1时空闲状态OE保持为1OISX/OISXN不生效引脚输出由CCR比较结果决定——这时候你填的OISX/OISXN等于白填。这个联动关系是很多人配置出错的根源以为填了OISX/OISXN就万事大吉结果OSSI1让它们失效停机后引脚跟着CCR乱跑。所以配置逻辑应该是先决定OSSI要0还是1如果OSSI0再认真填OISX/OISXN如果OSSI1就要确保CCR在停机时刻的值是安全的或者干脆在停机前软件把CCR改到安全值。OSSIOISX/OISXN是否生效空闲时引脚电平决定因素配置建议0生效OISX/OISXN设定值推荐默认行为最确定1不生效CCxE/CCxNE与CCR比较结果仅在需要保持停机姿态时使用且需管理CCR5. 完整配置流程从寄存器到示波器验证5.1 配置前的准备工作把极性链路画清楚动手写代码前先在纸上画一条链路TIM1引脚 → 驱动芯片输入 → 驱动芯片输出 → 功率管栅极。每一级标出有效电平最后推出“要让功率管关断TIM1引脚应该输出高还是低”。这个真值表决定了OISX/OISXN的取值也决定了CCR的有效极性配置CCxP/CCxNP。以某半桥栅极驱动为例假设驱动芯片高电平输入对应高边导通低边驱动经过一个反相器。那么安全停机两管都关要求高边驱动输入为低即CHx空闲电平为0OISX0低边驱动输入为低经过反相器意味着CHxN空闲电平为高OISXN1。这个推导过程不能省省了就是赌运气。5.2 BDTR寄存器的配置顺序与代码示例BDTR寄存器的配置有个坑LOCK位一旦设定部分位就锁死。所以顺序必须是先配OSSR/OSSI/OISX/OISXN/AOE等再配死区最后设LOCK。下面是一段基于标准外设库风格的配置示例寄存器操作方便看清每个位/* 假设使用TIM1通道1互补输出电机驱动场景 */ /* 步骤1先确保MOE0避免配置过程中输出跳变 */ TIM1-BDTR ~TIM_BDTR_MOE; /* 步骤2配置OSSR1运行中互补关断果断OSSI0空闲强制关闭 */ TIM1-BDTR | TIM_BDTR_OSSR; TIM1-BDTR ~TIM_BDTR_OSSI; /* 步骤3配置空闲电平OISX0主输出低OISXN1互补输出高 */ /* 具体取值依据5.1节的极性推导此处仅为示例 */ TIM1-BDTR ~TIM_BDTR_OISX; /* OISX 0 */ TIM1-BDTR | TIM_BDTR_OISXN; /* OISXN 1 */ /* 步骤4配置死区时间假设系统时钟72MHz需要500ns死区 */ /* 死区计算见5.3节 */ TIM1-BDTR ~TIM_BDTR_DTG; TIM1-BDTR | (0x5A TIM_BDTR_DTG_Pos); /* 示例值实际按计算填 */ /* 步骤5使能自动输出AOE刹车后自动恢复需要按需配置 */ TIM1-BDTR | TIM_BDTR_AOE; /* 步骤6最后设置LOCK等级等级1只保护部分位等级3全保护 */ TIM1-BDTR | (0x1 TIM_BDTR_LOCK_Pos); /* 步骤7使能主输出 */ TIM1-BDTR | TIM_BDTR_MOE;这段代码里每一步的顺序都有讲究。步骤1先关MOE是防止配置中途引脚输出跳变步骤2和3必须在LOCK之前步骤6的LOCK等级要根据产品阶段选调试阶段建议LOCK0或1量产再锁死。5.3 死区时间的计算过程死区时间不是随便填的要结合功率管的开关时间和驱动芯片的传输延迟。以72MHz定时器时钟、目标死区500ns为例DTG的编码规则分几段0x00-0x7F对应DTG[7:5]0xx死区DTG[7:0]×tDTS0x80-0xBF对应DTG[7:5]10x死区(64DTG[5:0])×2×tDTS以此类推。tDTS1/72MHz≈13.9ns。500ns/13.9ns≈36落在第一段DTG[7:0]360x24。所以填0x24。这个计算要写进注释否则换时钟频率后死区就错了。我见过有人直接抄别人的0x5A结果时钟不一样死区变成1.2微秒电机低速时转矩脉动明显。5.4 用示波器验证四个位的实际效果配置完不能只看代码必须上示波器验证。验证方法让定时器输出互补PWM然后分别制造“运行中关互补通道”和“刹车停机”两个场景观察引脚电平。验证OSSR运行中软件清CCxNE看CHxN是否立刻关断到OISXN电平。OSSR1时应该干脆OSSR0时可能有延迟或受MOE影响。验证OSSI和OISX/OISXN触发刹车拉BRK引脚或软件置位看两个引脚是否停在设定电平。OSSI0时应该严格等于OISX/OISXNOSSI1时看是否保持刹车前的状态。我习惯把这两个场景做成测试用例每次改BDTR配置都跑一遍用示波器的单次触发抓波形截图存档。这个习惯帮我抓到过好几次“以为配了其实没生效”的问题尤其是LOCK位设早了导致后续修改无效的情况。6. 常见问题与排查实录6.1 刹车后引脚电平不对先查OSSI还是OISX这是最高频的问题。排查顺序应该是先确认OSSI的值再确认OISX/OISXN最后确认LOCK位有没有把配置锁死。如果OSSI1OISX/OISXN根本不生效查它们没意义如果LOCK设了等级3后续写BDTR全部无效现象是“改了代码没变化”。我一般用调试器直接读BDTR寄存器值和代码里写的对比一眼就能看出是没写进去还是写进去了但逻辑不对。6.2 互补输出在运行中关不断OSSR背锅现象是清了CCxNE但CHxN还有输出。原因通常是OSSR0互补通道的关闭还受MOE和刹车状态约束而MOE此时为1导致关闭逻辑没走通。改成OSSR1即可。但要注意OSSR1后运行中CCxNE对CHxN的控制是直接的如果软件逻辑里有地方误清CCxNECHxN会立刻关断没有缓冲。所以改OSSR1的同时要检查所有操作CCxNE的代码路径。6.3 定时器一停引脚就乱跳OSSI和CCR的锅CEN0后引脚电平不符合预期两个可能OSSI1导致OISX失效引脚跟着CCR走而CCR停在非安全值或者OSSI0但OISX/OISXN填反了。前者要在停机前把CCR改到安全值或者干脆用OSSI0后者重新走一遍5.1节的极性推导。6.4 常见问题速查表现象最可能原因排查动作解决方向刹车后电平与OISX设定不符OSSI1使OISX失效读BDTR确认OSSI值改OSSI0或管理CCR停机值运行中互补管关不断OSSR0关闭受多条件约束读BDTR确认OSSR值改OSSR1改了BDTR没反应LOCK位已锁死读BDTR的LOCK字段调整配置顺序LOCK最后设停机后引脚随机跳变OSSI1且CCR非安全值停机瞬间抓CCR值停机前改CCR或用OSSI0刹车时桥臂直通OISX/OISXN极性与驱动不匹配重画极性链路真值表按真值表重填OISX/OISXN6.5 几个容易忽略的细节第一AOE位自动输出使能和OSSI有交互。AOE1时刹车事件后下一个更新事件会自动恢复MOE如果OSSI1恢复瞬间的输出状态取决于CCR可能不是你想要的安全姿态。第二不同系列STM32的BDTR位定义基本一致但个别型号在LOCK等级的保护范围上有细微差别跨型号移植时要对照对应手册。第三用HAL库时HAL_TIMEx_ConfigBreakDeadTime()的配置结构体里这几个位都有对应字段但结构体初始化如果没显式赋值可能带出随机值建议用{0}初始化后再逐项填。7. 我在实际项目里的配置心得做电机驱动这几年BDTR这几个位我现在的默认起手式是OSSR1、OSSI0、OISX/OISXN按极性真值表填、LOCK调试期设1量产设3、AOE按是否需要自动恢复决定。这套组合覆盖了大多数半桥/全桥拓扑的安全需求行为最确定出问题也最好排查。唯一让我改过默认值的是一个需要刹车保持姿态的拓扑刹车时要求下管导通续流那时候把OSSI打开、OISXN设成对应电平同时严格保证刹车触发前CCR已经被软件改到安全值。这个方案跑通后我复盘觉得如果重来可能会用外部逻辑电路实现姿态保持把定时器配置保持在最简单的OSSI0因为软件管理CCR的时序在极端情况下比如刹车和更新事件同时发生还是有不确定性硬件方案更稳。另外分享一个小技巧调试这几个位时把BDTR的值实时打印到串口或者用调试器的watch窗口盯着每次触发刹车或关通道都看一眼比反复烧录快得多。还有示波器抓刹车波形时用单次触发、下降沿触发在BRK引脚上能稳定抓到刹车瞬间的电平变化过程比滚动模式看得清楚。这几个位看着不起眼但它们是功率级安全的最后一道软件闸门配之前多花十分钟画真值表能省下后面烧管子和查故障的好几天。
企业数字化 ERP 产品动态
相关推荐
大模型数据预处理实战:从数据源到动态Padding的流水线方案 「昇思 MindSpore 大模型」这句话里,真正决定一次微调能不能顺利跑通的环节,往往不是模型结构,而是那串看起来平平无奇的 mindspore.dataset 。我在好几个大模型项目里见过同一种症状:训练脚本没问题,模型结构没问题… · 2026/11/3 14:25:24
OpenClaw+React+Node.js构建AI应用新范式 1. “Paperclip”不是回形针:一个被误读的AI工程代号与真实技术图谱最近在多个技术社区和开发者群聊里,频繁看到“paperclip”这个词被当作某个新工具、框架或开源项目来讨论。有人问“paperclip怎么安装”,有人发帖求“paperclip React集成示… · 2026/11/3 14:25:24
reverse-skill:实战逆向能力的四大支柱与AI增强路径 1. “reverse-skill”不是新造词,而是安全从业者内部的暗语式共识“reverse-skill”这个词乍看像某个开源项目名或AI模型代号,但在我过去十年混迹于二进制分析、漏洞研究和红队实战的圈子里,它从来不是官方术语——而是一群人用缩写技能组合形… · 2026/11/3 14:25:24
HDMI TMDS信号完整性调试:波形捕获与眼图分析实战指南 HDMI接口从消费电子一路铺到工控、医疗显示和车载娱乐,几乎成了高清视频传输的默认选项。但真正在硬件调试一线待过的人都知道,HDMI链路出问题的概率远比想象中高——花屏、闪屏、偶发黑屏、热插拔后不识别,这些现象背后十有八九都指向同一个… · 2026/11/3 15:12:40
WeGame多账号自动登录工具开发实战 1. 项目背景与需求解析在游戏多开、账号托管等场景中,手动逐个登录WeGame账号效率极低。特别是工作室或代练团队需要同时管理数十个游戏账号时,传统登录方式耗时耗力。远程自动登录工具正是为解决这一痛点而生——通过模拟人工操作实现批量账号导入、自动… · 2026/11/3 15:12:40
TensorFlow安装避坑指南:从环境配置到GPU加速实战 上周有个读者私信问我:“哥,我刚装完TensorFlow,import都能成功,可一跑训练就提示找不到cudnn64_8.dll,整个人都懵了。”我一看就知道,他八成是在Windows上直接pip install了最新版TensorFlow,然… · 2026/11/3 15:12:40
hindsight 智能体记忆系统:从记忆回溯到 MCP 与 Docker 工程实践 1. 从“hindsight”这个词说起:为什么它值得单独拿出来聊第一次看到“hindsight”作为项目标题,我脑子里蹦出来的不是某个具体工具,而是一个很朴素的场景:你让一个智能体帮你处理一件跨天、跨会话的任务,它当时做得挺好… · 2026/11/3 15:12:40
Pattern与Mattern:字符串模式匹配的编译与执行分离设计 1. 从两个函数名说起:Pattern 与 Mattern 到底在解决什么问题第一次看到Pattern()和Mattern()这两个名字摆在一起,我下意识以为是谁把Pattern拼错了,写成了Mattern。后来翻了一圈代码库才发现,这俩函数经常成对出现在字符串匹配、… · 2026/11/3 15:12:40
图计算工程化实践:让AI应用从能跑到能维护 1. 从"能跑就行"到"能维护才行":图计算应用开发的真实分水岭做过几个AI应用之后你会发现一个挺尴尬的事实:Demo阶段跑得飞起的东西,一旦要交给别人维护、要加新功能、要排查线上问题,立刻就变成一团乱麻。模型… · 2026/11/3 15:11:34
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 13:10:28
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 6:04:24
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 5:52:46
STM32F411RE与MAX14431实现SPI隔离:工业现场抗共模干扰实战 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
ESP32+大模型AI硬件开发:从Demo到产品的8个工程问题 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
基于MAX14431BAEE+与PIC18F85J10的SPI隔离方案设计与实践 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 13:10:28
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 6:04:24
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 5:52:46