sConfig.EncoderMode 配置这个地方是不是有点问题？ 如果针对两个通道都要进行计数的话，应该配置为TIM_ENCODERMODE_TI12 。 你的IC2Filter滤波目前可以设置为0，先把数计到，后面再适当调整滤波参数。别把正常的都滤调了。 还有，要让TIM计数的话，须调用HAL_TIM_Encoder_Start()。【如果已经调用，无视此句即可。】
关于代码优化方面的专业表述相信你可以轻松得到。 但我这里还是想用通俗的比方来交流下，供参考。 比方，源代码比作某工程的原始设计方案，编译器优化过程比作将方案交给审核方检查并优化。检查优化过程中重点检查方案的工期和成本。 方案审核优化的结果，可能因为优化成本或工期使得设计方案更合理，也可能优化后的方案跟初始方案相差不微，也可能相差甚远。最终结果优化后的方案可能比原方案好、也可能差些 ，这主要取决于初始设计规范及思路与审核阶段的一致性多高。具体结合到代码方面，就取决于代码撰写者的代码规范程度及程序逻辑设计出发点与编译器所遵循的规范及理解的一致度有多高。 事实上，代码撰写者的代码写作水平参差不齐，代码逻辑中需要特别保留或遵从的地方，编译器也未毕都能完全理解到位，导致优化后的代码跟原代码有不同程度的差异，最终会体现在性能上。
1. 首先IWDG 一旦开启，是不能停下来的。 2. 其次这个系列没有其他系列通过optionbyte 设置在改变模式停止计数的功能。 3. 再次，standby 模式下，程序是停止的，不会运行，也就不存在跑飞的现象。 4. 最后，standby 不论是被外部唤醒还是IWDG唤醒，都是从复位开始的。 如果能接受第3和第4点，那么可以通过RTC备份域寄存器在进入standby前记录状态。该次 IWDG唤醒是正常休眠超时复位唤醒，并非程序运行超时引起的复位。
这个vcap 是给内核区供电的，连接不少外设呢。 过压了，如果出现大问题还好，出现小问题要耗费不少精力查找，辨别，非常不划算。 最好还是换一片吧。
记得之前的CubeMx版本这个地方是有PHY地址设置的地方，现在取消了。 现在是在生成的代码里扫描PHY设备地址。 具体是在cubeMx生成 eth_custom_phy_interface.c 中的USER_PHY_Init() 通过扫描PHY 地址，自动找到有效地址并保存。当然，你也可以代码里取消扫描操作，直接写死。 CubeMx帮我们创建了基本的框架和必要中间件，具体组织代码时我们可以参考ST公司提供的例程。
要这样的话，可以考虑同时使用rx FIFO 和 Rx buffer. 可以定义的专用RX BUFFER最多64个，即最多存64帧数据。另外，我们同时开启RX fifo ,可以 让一部分数据存到FIFO里来。每个FIFO接收的上限也是64帧数据。 当然，最终可以配置多少，还得考虑帧大小和可分配的 Message RAM。 !(data/attachment/forum/202605/15/163103a8m7nmonjcnb7a88.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
估计stm32早期的32F系列这个地方都有这个缺陷，后来新推出的STM32G/H/U等系列的SPI都支持NSSP模式，即发完一串数据后可以自动拉高，不要再手动去拉高。 我们做选型时尽量选择新推出的系列，其实性价比更高。
.png)
