我在使用 Nucleo-STM32H563ZI 开发板的时候发现,RTC 的 SSR(子秒)寄存器值的变化有时候会出现回跳的现象。如下例,值在从 29 变到 28 后,没有紧跟着变为 27,而是先回跳到 31 后,再跳到 27。 00030-->00029 00029-->00028 00028-->00031 00031-->00027 00027-->00026 00026-->00025 初步观察到这种现象出现的频率很高,一秒钟内有3、4次。每次回跳值都是3(如上例:31-28=3)。 请问下是我的配置或程序有问题吗? |
cubeIDE在运行时显示Failed to execute MI command是什么问题呢?
请问一下,我的nucleo板子连接usb线,找不到target,一直无法下载程序怎么回事呢?
stm32h5,使用jlink调试器,程序死在while (READ_BIT(RCC->CR, RCC_CR_PLL1RDY) == 0U)
关于STM32H563的STlink-V3无法识别的问题咨询
STM32H503 Nucleo-64 board下载不进去程序
STM32H745烧录异常
【STM32C0评测】3、GPIO 测试 驱动WS2812
STM32H745启动与烧录问题
STM32H562的SAI音频接口,配置GPDMA收发有异常。
stm32f302r8的ld2怎么都不亮
因为它的速度很快,所以如果调试窗口看会有一定不同步现象。
如果代码去读,注意读取是有一定方式的。并且串口输出的时间也要考虑进去。
RTC的分频采用默认值,即 SSR 分频值是 255,即一秒钟会发生256次变化,一次变化大概3.9ms。
串口波特率是115200,按照程序中一次发送的内容有14个字节,发送所需时间大概1.2ms。
而程序只做了检查寄存器值一件事情,没有其他事情。这个过程中也只有 SysTick 产生的中断需要处理
MCU主频被设置成最高的250MHz。
可以确信,这个程序运行时不会漏掉任何一个变化。串口的输出内容也验证了这一点。
RTC 的 SSR 分频配置使用的是默认值 255,即是说一秒钟会发生 256 次变化,相邻变化时间间隔大概 3.9ms。
而串口波特率设置是 115200,程序中一次发送内容是 14 字节,大概需要 1.2ms。
而整个程序只做检查 SSR 值这一件事情,没有其他线程。需要处理的中断也只有 SysTick。
可以确信,程序不会错过任何一次 SSR 值变化。而串口输出也验证了这一点。
至于您说的读取要有一定的方式,这也是我想问的:读取这个寄存器是否需要什么秘诀?
我的程序是参考了 HAL 库里的 HAL_RTC_GetTime 函数实现。但没发现里面有什么窍门……
我是使用串口打印的方式查看,不是调试窗口。
SSR分频使用默认值255,即一秒钟有256次变化,相邻变化时间间隔约3.9ms
串口波特率115200,程序一次发送数据14字节,需要时间大约1.2ms
可以确信,程序不会错过任何一次正常的变化。串口输出也验证了这一点
SSR 分频使用默认值 255,即一秒钟有256次变化,变化时间间隔约3.9ms
串口波特率115200,一次发送数据14字节,需时1.2ms
程序不会错过任何一次正常的变化。串口输出也验证了这一点
SSR 分频为255,即每秒256次变化,变化间隔3.9ms。串口波特率115200,一次发送14B,需时1.2ms。程序不会错过任何一次正常的变化。串口输出验证了这一点
现在假设你面前有个滚动盘,可以依序匀速循环滚动显示0到59,
你可以按固定时间来读显示数据,也可以不定速来读,把每次读到的
数据依次写下来,只要它的转速和你读取它的速率不同步,最后记录下
来的数据一定存在无序情况。
没有用调试窗口.看的是串口输出数据.
SSR 分频使用默认的255,正常情况大概3.9ms变化一次.
串口波特率115200,发送一次数据14个字节,用时大概1.2ms.
所以不存在不同步或漏读数据的问题
你说的情况确实在现实中经常出现.但如我在另一个回复里说明的,我已经充分考虑到运行时间的因素.
程序观察数据肯定是足够快的,不存在不同步的问题
即每7.8ms产生一次中断. 基于中断来读取,看看数据还乱不乱。
并看看相邻两次读到的时间是否固定在7.8ms样子。
另外,读取时间时遵循先TIMER后Date的规矩。
感谢你的关注!
使用中断方式试了一下,数据还是乱的。见下方实例数据,左侧是 SSR 值,右侧是 SysTick 计数。
00243:00000152
00241:00000159
00239:00000167
00237:00000175
00239:00000183
00233:00000191
00231:00000198
可以看出,正常情况下,大概7、8个SysTick(也就是7、8ms)变化一次。
本来应该紧跟在237后的235没有出现,而是回跳到了239,之后有恢复正常。
如果直接读取 SSR 值的话,数据应该是这样的:
00237:......
00236:......
00239:......
00235:......
00234:......
话说回来,就算使用中断方式数据会有序起来,也很难满足我的需要。
因为我需要更高精度的时钟,要把 SSR 的分频设为最大的32767,而不是默认的 255。
这样的话,使用中断方式会需要很大的中断开销:大概60微秒就要处理一次中断。这不是我所希望的。
下面是主程序代码: