差不多是你说的这个意思。 Idle 是总线空闲的一帧时间， RTO 是在这个基础上设定空闲了多长时间。 出现IDLE 帧意味着一帧数据发完了，不完全代表一组数据发完，取决于发送端数据连续性。 当然在空闲时间处理数据是减轻CPU负担的一种常用方式。 另外STM32有丰富的系列产品，同样的外设在不同系列里功能丰富程度不一样，所以最好列出具体型号，方便小伙伴们准确定位哈~~
从手册的结构图上可以看出，SPI 发送本质上是通过移位寄存器发送出去的。 为了减轻软件负担，设计了 FIFO在前面。所以 1. TXP: Tx-packet space available FIFO 有空位标志，查询它，这时候可以向里面写数据，排队等待。但是不一定马上发送出去，之前的FIFO 和当前移位寄存器都有可能有数据。利用它可以最大效率发送。 2.TXC: Tx-packet space available =1: Last TxFIFO frame transmission completed FIFO 为空的标志，表示所有FIFO空了，里面的数据已经出去了，但总线上未必完成。 3. EOT: end of transfer =1: transfer complete 查询这个标志代表发送全部完成。 以上内容详细请参阅参考手册。另外库中的发送和接收函数的查询逻辑也可以参考一下。
关这个问题补充下。 后来我进一步找设计人员做了沟通、确认，STM32H763的TIM23 TIM24的确是支持中心对齐计数模式的。换言之，手册和CUBEMX配置那里是没问题的。 为什么我们基于cubeMx创建工程并选择中心对齐计数模式，TIM23/24表现出来却不支持呢？ 后来我发现是目前库代码里有bug，在TIMER初始化过程中，在涉及TIMER的中心对齐计数模式 配置时，代码里会对所用TIMER做资格检查，即看它是否支持中心对齐，在这个检查过程中，目前库代码没有把TIM23 TIM24包含进去，导致检查返回失败，进而中心对齐配置被跳过，使得TIM23/24始终使用默认的向上计数模式。这个地方bug有待后续修复。 目前可以直接修改寄存器的CMS位域 或 临时调整库代码也行。
没有截图，只能大致推测了。 估计是你没有使能RTC，所以LSE后面的选项没有连接的需要地方，用灰色提示用户要启动RTC才能选择。
从资料上看，STM32U5 系列产品能支持 UHS-I 1.8V. 外部需要一个转换器，例如 ST6G3244ME. 下面是描述的截图
库里面有个模板例程，可以参考一下，注意看一下文档。 可以找一下培训资料，熟悉它的工程原理，尤其是地址关系。 弄清楚架构原理，就可以建立自己的工程了。 STM32Cube_FW_N6_V1.3.0\Projects\STM32N6570-DK\Templates\Template_FSBL_XIP
不管怎样，你的主循环里至少应该把LwIP_Pkt_Handle() 加进去才合理。 void TcpMonCom（void） { LwIP_Pkt_Handle(); // 处理接收包 LwIP_Periodic_Handle(LocalTime); } 当然，不排除还有其它原因要查。
bootloader默认使用什么RAM区，作为我们用户不用关心的。 至于你BANK2区代码所用哪里RAM区是你组织代码过程决定的，你现在跳到BANK2无法正常运行，重点检查 MSP合法性检查是否通过了、中断矢量表是否配置正确了。 基本功能的验证可以先在BANK1验证好。
应该说，这个算式并不局限于 Fadc 的频率或 Ts 的数值，只要在手册允许范围内即可。 但公式计算结果不能超过手册规定的最大值 50k，否则结果就是不保证的。 换言之，公式可用于不同的 Fadc 或 Ts，但结果不能作为无限制可用值。 最终仍然受手册 50k 上限约束。 超过 50k 的参数不代表绝对不能用，只是厂家不保证精度指标。
微信公众号
手机版
