hi 大家，
在最近调试stm32的时候，遇到了一些问题，看看大家能不能帮帮忙。
 
我写的stm32程序执行过程是这样的：
stm32处于stop低功耗模式，每次由RTC的alarm中断唤醒，唤醒之后设置RTC的CNT的值为0.这样stm32就会周期性的按照alarm的值醒来。alarm的值始终保持不变。
为了确定每个周期的时长是否会按照alarm的值按时醒来，在alarm中断处理程序中反转一个引脚，然后用逻辑分析仪观测这个周期的时间，发现程序并不是按照我设的alarm值触发。
例如：
我设为alarm值500，每个Tick值代表物理上的1秒。逻辑分析仪上观察的值为每个周期是510秒。
为了确定RTC的alarm中断是否是在500处唤醒，我在每次alarm中断触发时，在中断处理程序开始就读取RTC的CNT值，得到RTC的CNT为510。
在中断处理程序中我做的事情按顺序依次为：
alarm中断触发：
1. 系统时钟的从新配置（RCC的配置）
2. 读RTC的CNT值
3.设置RTC的CNT为0
4. 串口输出一个字符串
5. 输出结束就会进入stop模式，等待下次alarm中断唤醒stm32。
令我不解的有两点：
（1）为什么设定在500处触发的alarm中断在510处处理程序才被调用？
（2）我假设串口输出对alarm中断的触发和中断处理程序的调用有影响，我去修改发送字符串的长度。当我把输出的字符串设的比较长（例如400个Byte），读出的RTC的CNT为500。输出字符串设为200Byte时，RTC的CNT为505，当字符串为5个Byte时，读出的RTC的CNT的为510。这个说明我发的数据越长，alarm的中断处理程序调用的时间越提前（越接近本应该触发的时刻：RTC的CNT=500的时候）。这件事情是因为什么原因产生的？串口输出与alarm中断之间有什么联系吗？
 
期待大家的解释!
谢过了！

鉴于发现发帖后帖子可看性很差，我加了些回车。期待大家可以提出自己的意见啊！:-)
 
 hi 大家，

在最近调试stm32的时候，遇到了一些问题，看看大家能不能帮帮忙。

 

我写的stm32程序执行过程是这样的：

stm32处于stop低功耗模式，每次由RTC的alarm中断唤醒，唤醒之后设置RTC的CNT的值为0.这样stm32就会周期性的按照alarm的值醒来。alarm的值始终保持不变。

为了确定每个周期的时长是否会按照alarm的值按时醒来，在alarm中断处理程序中反转一个引脚，然后用逻辑分析仪观测这个周期的时间，发现程序并不是按照我设的alarm值触发。

 

例如：

我设为alarm值500，每个Tick值代表物理上的1秒。逻辑分析仪上观察的值为每个周期是510秒。

为了确定RTC的alarm中断是否是在500处唤醒，我在每次alarm中断触发时，在中断处理程序开始就读取RTC的CNT值，得到RTC的CNT为510。

 

在中断处理程序中我做的事情按顺序依次为：

alarm中断触发：

1. 系统时钟的从新配置（RCC的配置）

2. 读RTC的CNT值

3.设置RTC的CNT为0

4. 串口输出一个字符串

5. 输出结束就会进入stop模式，等待下次alarm中断唤醒stm32。

 

令我不解的有两点：

（1）为什么设定在500处触发的alarm中断在510处处理程序才被调用？

（2）我假设串口输出对alarm中断的触发和中断处理程序的调用有影响，我去修改发送字符串的长度。当我把输出的字符串设的比较长（例如400个Byte），读出的RTC的CNT为500。输出字符串设为200Byte时，RTC的CNT为505，当字符串为5个Byte时，读出的RTC的CNT的为510。这个说明我发的数据越长，alarm的中断处理程序调用的时间越提前（越接近本应该触发的时刻：RTC的CNT=500的时候）。这件事情是因为什么原因产生的？串口输出与alarm中断之间有什么联系吗？

 

期待大家的解释!

谢过了！