很奇怪，RTC的日历，延时越长，跳秒就越严重。我最后气的改为了10s读一次，结果开始跳分钟了。

安 发表于 2018-11-17 14:53
居然还有这个问题。我用了这么长时间也没发现。我看了一下代码，我用的是先读取time，再读取date。 ...

我今天碰巧找到具体的操作规范了，在官方的用户手册（HAL库的描述）UM1884里面ST官方具体规定了

我告诉你，STM的RTC一直有个很奇怪的问题，一定要先读time，再读date，不然time是不对的。
这么多年一直都没有改。

不确定楼主怎么操作的，哪个芯片？103吗？如果是秒计数器不准确，可能是因为晶振和实际的配置不匹配导致的。

安 发表于 2018-11-17 10:39
不确定楼主怎么操作的，哪个芯片？103吗？如果是秒计数器不准确，可能是因为晶振和实际的配置不匹配导致的 ...

感谢回复，CUBEMX配置的话是正常的（HAL_Delay），但我仿照cubeMX自己写的代码，跳秒很严重（delay_ms）

正常的意思是，跳秒正常（会跳1~2个延时），不正常是指（会跳10个左右的延时）

delay_ms代码贴一下，我感觉是因为系统时钟的问题。

安 发表于 2018-11-17 11:16
delay_ms代码贴一下，我感觉是因为系统时钟的问题。

我觉得不是delay的问题，因为我换了HAL_delay 试了下，还是会跳秒

楼主，你看一下读取时，RTC返回的结果是什么，感觉像是没有读取成功。没有将时间重新赋值。

Dandjinh 发表于 2018-11-17 10:36
我告诉你，STM的RTC一直有个很奇怪的问题，一定要先读time，再读date，不然time是不对的。
这么多年一直都 ...

改过来好了！！！！！！！！！

Dandjinh 发表于 2018-11-17 10:36
我告诉你，STM的RTC一直有个很奇怪的问题，一定要先读time，再读date，不然time是不对的。
这么多年一直都 ...

居然还有这个问题。我用了这么长时间也没发现。我看了一下代码，我用的是先读取time，再读取date。

是有个读写顺序的。
只是内置时钟的精度不够，较时候效果也不理想。