應用RTC時間轉換時,使用了官方例程的時間轉換函數(shù),結果2024年12月31號的秒數(shù)轉換出錯,轉為2025年13月1號,導致上千臺設備停機一天,后來測試,用標準的則不會出現(xiàn)此問題,又簡單方便,這一次血的教訓真是太慘痛了。
我的也出現(xiàn)了,應該是
RTC_Get這個函數(shù)的問題,
把判斷里的temp1++;注釋掉就好了,
if (Is_Leap_Year(temp1)) // 是閏年
? ? ? ? ? ? {
? ? ? ? ? ? ? ? if (temp >= 366)
? ? ? ? ? ? ? ? ? ? temp -= 366; // 閏年的秒鐘數(shù)
? ? ? ? ? ? ? ? else
? ? ? ? ? ? ? ? {
? ? ? ? ? ? ? ? ? ? //temp1++;
? ? ? ? ? ? ? ? ? ? break;
? ? ? ? ? ? ? ? }
? ? ? ? ? ? }
我搜索了下,307最新的庫文件是改了這個函數(shù)的,為啥不說明呢,提醒用了咱這個庫的提前做準備或者想辦法修改,樓主上千臺設備停機一天,這個損失不可估量,希望能夠重視?。。。?/strong>
現(xiàn)在改為用time.h這個了,struct tm *tm = localtime(&seconds); 簡單又不會出錯,損失客戶還沒評估出來
您好,關于EVT提供例程的解決方式,可參考2樓方法進行解決,將temp1++直接去掉或者注釋掉即可。后續(xù)若有問題,可直接與我司技術支持聯(lián)系,聯(lián)系方式如下:
靠!靠!靠!
我能說我就是修著這個bug跨的年嗎?
用的是CH32L103,同樣中招:2025年13月1日
懶得分析官方代碼了,直接拿自己之前在ST上的代碼編譯測試通過,比官方代碼編譯完還小一些
國產(chǎn)芯片的路確實很長,不光是技術工藝,還有從業(yè)者態(tài)度,這些代碼包括文檔的質量,還有很多路要走
關鍵是你們發(fā)現(xiàn)了后,為啥不在論壇或者網(wǎng)站上發(fā)出來啊,這以后你們的例程還敢用嗎
歸根結底,是組件的概念還沒有。
比如,同樣是 2.6 版的外設庫,在官方提供的 EVT 代碼中是一回事,到了 MRS 的模板內,又是另一個版本。
比如,現(xiàn)在新出了 MRS2,里面的編譯器我看改成了 riscv-wch-gcc,到底只是改了個名字呢還是里子也有變動?然而通過 --version 甚至看不到 MounRiver 的改動跡象,顯示的還是 xPack 的信息。
外設庫應該是一個組件,它有它自己的版本,可以用在 EVT、也可以用在 Template,但它本身應該是同一個組件;
編譯器也應該是IDE的組件,也應該體現(xiàn)它自己的版本,而不是“偷偷”改一下,用戶卻不知情。