不过，今天主要想聊聊如何通过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模块带来的功耗，具体应用时我们可以综合考虑后再做调整。