应用RTC时间转换时,使用了官方例程的时间转换函数,结果2024年12月31号的秒数转换出错,转为2025年13月1号,导致上千台设备停机一天,后来测试,用标准的则不会出现此问题,又简单方便,这一次血的教训真是太惨痛了。
我的也出现了,应该是
RTC_Get这个函数的问题,
把判断里的temp1++;注释掉就好了,
if (Is_Leap_Year(temp1)) // 是闰年
{
if (temp >= 366)
temp -= 366; // 闰年的秒钟数
else
{
//temp1++;
break;
}
}
我搜索了下,307最新的库文件是改了这个函数的,为啥不说明呢,提醒用了咱这个库的提前做准备或者想办法修改,楼主上千台设备停机一天,这个损失不可估量,希望能够重视!!!!
现在改为用time.h这个了,struct tm *tm = localtime(&seconds); 简单又不会出错,损失客户还没评估出来
您好,关于EVT提供例程的解决方式,可参考2楼方法进行解决,将temp1++直接去掉或者注释掉即可。后续若有问题,可直接与我司技术支持联系,联系方式如下:
靠!靠!靠!
我能说我就是修着这个bug跨的年吗?
用的是CH32L103,同样中招:2025年13月1日
懒得分析官方代码了,直接拿自己之前在ST上的代码编译测试通过,比官方代码编译完还小一些
国产芯片的路确实很长,不光是技术工艺,还有从业者态度,这些代码包括文档的质量,还有很多路要走
关键是你们发现了后,为啥不在论坛或者网站上发出来啊,这以后你们的例程还敢用吗
归根结底,是组件的概念还没有。
比如,同样是 2.6 版的外设库,在官方提供的 EVT 代码中是一回事,到了 MRS 的模板内,又是另一个版本。
比如,现在新出了 MRS2,里面的编译器我看改成了 riscv-wch-gcc,到底只是改了个名字呢还是里子也有变动?然而通过 --version 甚至看不到 MounRiver 的改动迹象,显示的还是 xPack 的信息。
外设库应该是一个组件,它有它自己的版本,可以用在 EVT、也可以用在 Template,但它本身应该是同一个组件;
编译器也应该是IDE的组件,也应该体现它自己的版本,而不是“偷偷”改一下,用户却不知情。