你好,
我需要一个精确超时功能。大概好几个月吧。
我使用app_easy_timer()具有最长的延迟(5*6000-1)，即5分钟-10ms。如果我错了，请纠正我。
在我的计时器回调中，我增加了自己的计数器，并使用app_easy_timer()重新启动计时器。
为了达到最高的精确度
#定义CFG_LP_CLK LP_CLK_XTAL32
XTAL32用于睡眠。
然而，在我看来，我的计时器跑得太快了5%。
我的问题:
当我的超时是几个月的数量级时，我应该做什么来获得最佳的计时器精度?
先谢谢你
Ciano霜
丹麦
关键词:
设备:
嗨ciano,
app_easy_timers()没有足够的精度来运行作为一个RTC和计算准确的通道的月，原因是由于基础定时器，这是内核计时器依赖，它得到补偿，每次设备唤醒，并在时间测量中引入了一个错误，我不确定是否改变当前的XTAL32与一个更准确的时钟，你将能够减少这个错误，最有可能你不会。你可以尝试为了测量时间，而不是有一个内核定时器，你可以通过一个内核定时器唤醒和轮询时间从BLE_BASETIMECNT_REG通过lld_evt_time_get()函数，也许这将给你更准确的时间测量，因为它消除了任何开销，ke定时器，但即使这样，我不确定你将得到你想要的精度RTC。
由于MT_dialog
嗨,对话框中,
谢谢你的提示。我将轮询BLE_BASETIMECNT_REG并测试它。
最好的问候,
Ciano霜
丹麦
嗨,对话框中,
还有一个问题:
如果使用一个精确的XTAL32(我们是这么做的)不能给出一个更精确的时间，那么使用XTAL32代替内部的RCX有什么好处呢?
最好的问候,
Ciano霜
嗨ciano,
XTAL32只在boost配置上是强制的，因为RCX不能正常工作，你只能在buck上使用RCX，因此XTAL32可以被省略(如数据表所示)。使用XTAL32的原因不是为了保持更精确的计时(这将提高计时的结果，相对于RCX，但我不认为整个系统将足够准确的RTC的原因我在我之前的文章中提到)。在升压模式下使用XTAL32的原因是，当设备进入休眠模式时，RCX由碱性电池供电，而不是由DCDC转换器供电，因此LP时钟上的电压不同，这将导致漂移。
由于MT_dialog
嗨,对话框中,
我没有测试你的建议，并读取BLE_BASETIEMCNT_REG通过lldevt_time_get()在我的5分钟定时器。
我计算时间开始以来的流逝秒数，并打印结果。
代码如下所示
uint32_t app_too_old_timer_cnt[NUM_SAFETY_CPY] __attribute__((section("retention_mem_area0")，zero_init));/ / @RETENTION记忆;
uint32_t app_ble_basetimecnt_reg_old[NUM_SAFETY_CPY] __attribute__((section("retention_mem_area0")，zero_init));/ / @RETENTION记忆;
．．
5分钟内回电
uint32_t ble_basetimecnt_reg;
uint32_t time_since_last_cb_in_seconds;
//计算自上次回调以来解析的时间，并以秒为单位增加总计数器。
Ble_basetimecnt_reg = lld_evt_time_get();//获取625us ticks
Time_since_last_cb_in_seconds = (ble_basetimecnt_reg - app_ble_basetimecnt_reg_old[0]) * 0.000625;
App_too_old_timer_cnt [0] += time_since_last_cb_in_seconds;
//更新basetimecnt的副本
App_ble_basetimecnt_reg_old bb0 = ble_basetimecnt_reg;
arch_printf(“我% \ r \ n”,app_too_old_timer_cnt [0]);
这给了我以下的打印输出，其中我注意到2个大的时间跳跃:
82823 [16/10/16 - 15:09:15:366]
83122 [16/10/16 - 15:14:15:355]
83421 [16/10/16 - 15:19:15:345]
* * * * * *
2684189 [16/10/16 - 15:24:15:344]
2684488 [16/10/16 - 15:29:15:333]
.．.
2767311 [17/10/16 - 14:34:12:500]
2767610 [17/10/16 - 14:39:12:499]
* * * * * * * *
5368378 [17/10/16 - 14:44:12:489]
5368677 [17/10/16 - 14:49:12:488]
为了解决这个问题，我需要知道这两次跳跃的原因。
你能解释一下为什么会发生这种事吗?
最好的问候,
Ciano霜
丹麦
嗨ciano,
我注意到，“JUMP”之前的83421值对应于((83421/60)/60)= 231725小时(您运行这个测试略少于一天，是正确的吗?)这大约是BASETIMECNT的大小，它是27位计数寄存器(在接下来的5分钟，从83421值被打印的时间开始，计数器已经过去，并将开始从开始计数)。当定时器达到最大值点会展期因此,当ke_timer击中ble_basetimecnt_reg变量的当前值将小于前一个值相同的变量,因此,减法将导致一个负数存储在一个32位无符号变量类型,然后将值添加到之前的计算值,我想这是看到这种跳跃的原因在您打印的值。
由于MT_dialog