不過，今天主要想聊聊如何通過RTC來實現該需求。了解STM32的RTC的人可能知道，RTC模塊往往還自帶一個專門的16位向下計數的喚醒定時器，即下面RTC局部框圖中紅框所在單元。我這里要分享的也不是這個專用喚醒定時器，而是想基于ALARM事件和亞秒特性來實現上面需求。

對于RTC的ALARM功能我們都不陌生，即先預設需要ALARM的時間點，當日歷時間跟設定的ALARM時間匹配時就可以觸發ALARM事件及中斷。對于ALARM時間點的報警條件可以有很多靈活的組合配置，比方我們可以設置在某月某日某時某分某秒ALARM，也可以設置在某分某秒ALARM，其它不關心，或者僅設置在某個亞秒時刻ALARM，其它不關心。

上圖中四種ALARM設置，灰色部分表示不關心項，即不參與日歷值與ALARM設定值相關項的比較。這里分別表示的警情時刻是：

第一種，只要日歷中跟ALARM設置的時、分、秒匹配時報警，其它不關心；

第二種，只要日歷中跟ALARM設置的分值、秒值匹配時報警，其它不關心；

第三種，只要日歷中跟ALARM設置的秒值和亞秒低3位值匹配時報警，其它不關心；

第四種，只要日歷中跟ALARM設置的亞秒的低4位值匹配時報警，其它不關心；

我們回到前面提到的需求，每隔50±20ms做喚醒，即30ms~70ms范圍內實現喚醒都可以接受。如果說使用ALARM中斷，相信很多人自然會想到，先設定一個ALARM點，等喚醒后再修改新的ALARM值，就這樣延續下去。

這樣操作也是可以的，即每次在ALARM中斷里修改新的ALARM時間點。下圖是對ALARM值進行編程的流程【設置時先要關閉ALARM，修改ALARM值后再手動開啟ALARM單元】：

不過，結合眼前的應用需求，我們可以不使用上面的做法，而是巧妙地使用RTC亞秒特性來實現周期性的ALARM以滿足需求。怎么個巧法呢？一起來看看。

先假定RTCCLK為32768Hz，RTC同步分頻系數和異步分頻系數分別為如下參數：

PREDIV_A=127，PREDIV_S=255。

依據現有的分頻配置，則亞秒的時間精度或者說分辨率為（1/256）秒，3.9ms的樣子，即亞秒計數器每計1個脈沖所對應的時間就是3.9ms，算4ms吧。【記住這個數據后面要用】

談到這里，我們跳躍一下思路，換個數學話題聊聊。【注：這個地方可能有點突兀。突兀的突悟往往離不開艱辛的修行。】

這里有從0開始按照從小到大排列的一批足夠多的自然數列，按10進制展現。我們來看看幾種情形：

1、如果找出只要個位數相同的數據，仍然按照從小到大排列，每相鄰兩個數的差值一定是10。對不對？

2、如果找出只要個位數與十位數都相同的數據，仍然按照從小到大排列，每相鄰兩個數的差值一定是100。沒錯吧。

3、如果找出只要個位數與十位數以及百位數都相同的數據 仍然按照從小到大排列，每相鄰兩個數的差值一定是1000。結論也沒問題。

。。。。。。

到此，我們應該發現規律了，通過關注低幾位數相同而重新有序排列而成的相鄰數據之差即為10的幾次方，其實這里相鄰數的差值也就是原自然數列中兩個數的位置間隔。【注意關鍵詞：位數，數據，相鄰】我們可以基于下圖的一批十進制數據表格做些直觀的觀察。

好，我們不妨改變下數據的進制看看。還是從0開始按照從小到大排列的一批足夠多的自然數列，按2進制展現。依然看看幾種情形并得出相應結論。

1、若找出只要低1位數相同的數據，仍按照從小到大排列，每相鄰兩個數的差值一定是2；

2、若找出只要低2位數都相同的數據，仍按照從小到大排列，每相鄰兩個數的差值一定是4；

3、若找出只要低3位數都相同的數據 仍按照從小到大排列，每相鄰兩個數的差值一定是8；

其它我們可以依次類推。

同樣，我們也發現規律，通過關注二進制數的低幾位相同而重新有序排列而成的相鄰數據之差即為2的幾次方。我們可以基于下圖的一批二進制數據表格做些直觀的觀察。【橙色代表低2位相同的數據，綠色代表低3位相同的數據，紅色代表低4位相同的數據】

上面專門聊了一段純數學話題，繼續回到我們的亞秒應用問題。

我們知道，包括亞秒在內的整個日歷數據實質上是個具有高低順序和進位關系的數據，其中，亞秒是整個日歷數據里的最低端。當我們設置ALARM參數時，如果說只關注亞秒的低1位，其它都不關心。基于前面的數學話題鋪墊可知，每當出現低1位數據相同的兩個相鄰數，總是相差2個計數單位，這里就是2個計數脈沖。換言之，每隔2個計數脈沖，結合前面分析，即每隔8ms都會觸發ALARM事件。

如果說只關注亞秒的低2位，其它都不關心，那么每當出現低2位數據相同的相鄰數，總是相差4個計數單位，即4個計數脈沖。換言之，每隔4個計數脈沖，即16ms都會觸發ALARM事件。

如果只關注亞秒的低3位，其它參數都不關心，每當出現低3位數據相同的相鄰數，總是相差8個計數單位，即8個計數脈沖，每隔32ms都會觸發ALARM事件。

其它依此類推。

談到這里，設置的只關心亞秒的位數跟ALARM周期的關系應該說很清晰了。我在下面簡單羅列了基于前面條件下亞秒的關心位數與ALARM周期的對應表：【灰色表示不關心，不參與日歷值與ALARM設定值的比較，只有綠色位參與比較】

現在期望的喚醒周期是50±20ms，我們配置亞秒計數器的低3位或者低4位作為ALARM的比較位【說關心位、參與位什么的都可以】，其它設置為不關心就可以滿足要求。我們不妨選擇亞秒計數值的低4位參與比較，即每兩次相鄰ALARM相差16個計數脈沖，周期約為64ms。

下面是我使用CubeMx進行的日歷和ALARM A的配置，重點看下ALARM配置。

這里的ALARM配置只選擇亞秒的低4位參與比較，既然這樣其它參數就無所謂了。其中那個用于比較的亞秒值我這里寫的12，這個值寫多少并不影響ALARM周期的擬定，只會影響每次發生ALARM事件時的亞秒計數器的低4位的值。其實，當我們選定只關心亞秒計數器的低4位時，重復ALARM的周期就已經定了。

完成配置、建立工程、組織測試代碼。

我在ALARM中斷里讀取每次發生ALARM事件時的亞秒值。我截取幾個連續ALARM事件的相關信息在如下幾幅圖。其中變量Sub_Value和stime1.SubSeconds是一個東西，表示發生ALARM事件時亞秒計數器的值。比如下面各截圖中的236、220、204、188、172、156幾個數，顯然兩相鄰數的間隔保持準確的16個計數脈沖，若把這幾個數轉成2進制，他們的低4位都是1100B，即我在前面ALARM設置的亞秒比較值12。

若在每次的ALARM中斷里把發生ALARM的時間點實時打印出來，可以清晰地看到相鄰兩次ALARM事件的時間間隔固定在63ms左右，這個值跟前面規劃的基本一致。

有人或許會問，相鄰ALARM事件的時間差為什么沒有計數脈沖數差值那樣穩定精準。我認為主要有兩點原因，一是我測試時并沒有使用標準的32768外部時鐘，而是選擇的內部LSI，它的頻率一般在31Khz到33KHz之間，不像LSE那么精準。還有一個原因，在做亞秒時間計算時，因為無法整除原因肯定會帶來計算偏差。

利用上面方法可以省去每次修改ALARM配置的操作，類似這種具有周期性且周期不大于1秒的應用都可以嘗試考慮上述方法，必要的時候可以考慮調整同步分頻系數即亞秒計數器的重裝值以滿足具體的時間精度要求。當然，調整同步分頻系數的同時往往要調整異步分頻系數，原則上異步分頻系數要盡量大以充分降低RTC模塊帶來的功耗，具體應用時我們可以綜合考慮后再做調整。