在想要作一個簡單的電子時鐘+鬧鐘的時候，手上剛好有一個買來的STM32的最小系統板，就考慮使用RTC功能完成，
硬體：
淘寶購入STM32f103c8t6最小系統板，大概長這樣
這個板子雖然沒有備份區單獨的電池供電，但是也是有低速外部晶振的，就是LED旁邊黑黑的那個小方塊，至于STM32為什么要設計兩個晶振大部分的說法是一個高速晶振給PLL倍頻后提供給CPU運行，一個低頻晶振轉門供RTC精準計時使用，**那么再多問一句，就是為什么要單獨使用一個晶振給RTC計時用，用CPU主頻分出來的時鐘給RTC使用不可以么？**當然是可以的，我個人的理解32.768KHz晶振存在的意義大概有兩點：第一是跟電源低功耗的設計有關，當MCU全功率運行時，所有時鐘振蕩器都是作業的，但為了在一些場景下實作低功耗，MCU設計了低功耗模式，此時會關閉大部分外設和高速振蕩器來降低功耗，這時候使用一個單獨的晶振單獨為后備區域供電讓在低功耗模式下也可以計時成為可能；第二個原因就是低速晶振的精度會更高一些（傳言，沒有仔細探究，同為無源晶振為什么32.768更精準還是因為不倍頻所以更容易走時精準也未知，感興趣的胖友可以探究交流，）
軟體設計：
RTC功能直接實作全套時鐘+定時的功能，使用外部低速晶振驅動，
RTC的使用步驟：
- 使能電源時鐘和備份區
- 取消備份區寫保護
- 復位備份區，開啟外部低速振蕩器
- 選擇RTC時鐘源并使能
- 設定分頻等引數
- 配置中斷
- 撰寫中斷函式，結束
測驗：
下載程式后發現RTC正常運行于是插上電就出門了，由于沒有后備區域電池，這里直接通過USB口給最小系統板供了電，等回家時候檢查了一下時鐘大吃一驚發現出門大概8個小時，計時走慢了大概兩三分鐘就是150多秒，以為對表沒對好就重新校準了一次，第二天發現依舊是這樣，沒有多想想著直接按少的秒數大概補償一下，反正我這個也不需要很準，后來晚上睡了一覺發現少計數竟然還不是線性的，補償也不好補償，于是仔細檢查了一下自己的程式，發現：沒毛病，又在網上瀏覽了一些資料，發現大家都在夸32.768的晶振如何如何準，走幾個月不差一秒，關于走時不準的問題了了無幾，懷疑是我的這個低速晶振有漂移，但是由于缺乏設備我也沒有單獨看晶振波形，就大概檢測了一下，用HSE開了一個TIMER跟RTC的走時比了一下，發現果然RTC走時差很多，每幾分鐘大概都會差1s，RTC的時鐘切換到HSE發現和TIMER的計數值對上了，說明RTC的配置并沒有問題，主要來源應該還是晶振漂移的問題，簡單拿了手機秒表和HSE驅動下的RTC時鐘對了一下覺得還比較準，由于我沒有低功耗使用的需求，因此就直接用HSE驅動RTC使用了，走時精準度大概沒24H差幾秒，也可以接受，至此完成功能，
總結：
由于網上對于RTC走時不準的問題其實分析的不多，尤其是對走的這么不準的問題，我這里簡單總結一下，如果RTC走時不準：
第一可以使用一個TIMER跟RTC的計時對比一下，看一下這兩個時鐘源驅動下計數是否有差異，然后可以將RTC時鐘源切換至HSE重新配置分頻測驗一下走時是否準確，如果差的很多考慮是配置有問題需要重新檢查一下；
第二如果走時正常只是差幾秒，考慮是晶振不準，可以采用RTC的校準功能，校準功能的核心是用一個高精度的時鐘對低精度的時鐘進行校準，兩個同時計數一段時間然后差的值就作為補償值進行補償，這個方法有兩個問題，第一是你要有一個高精度的時鐘源，第二個是只能應對時鐘不準但很穩的情況，如果時鐘不穩就沒辦法了；
第三是可以考慮從硬體上入手，在設計時候通過匹配合適的電容電阻以及走線設計上保證時鐘的盡可能的準確性，
總的說一句就是不要盲目相信RTC時鐘的精確性，買回來的成品也不一定做的很好，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/149168.html
標籤：python