你好,
我需要一个精确超时功能。像几个月。
我使用了具有最长延迟(5*6000-1)的app_easy_timer()，即5分钟-10ms。如果我错了，请纠正我。
在我的计时器回调中，我增加了自己的计数器并使用app_easy_timer()重新启动计时器。
以达到我使用的最高精度
#定义CFG_LP_CLK LP_CLK_XTAL32
XTAL32睡眠。
然而，在我看来，我的计时器的运行速度是5%。
我的问题:
当我的超时时间是几个月的时候，我应该做什么来获得最好的计时器精度?
先谢谢你
Ciano霜
丹麦
关键词:
设备:
嗨ciano,
app_easy_timers()没有足够的presision RTC和运行来计算准确的个月,原因是由于基地计时器,内核计时器的依赖,它被补偿设备每次醒来,在时间测量中引入了一个错误,我不确定是否改变当前的XTAL32与一个更准确的时钟，你将能够减少这个错误，最有可能你不能。你可以尝试为了测量时间,而不是一个内核计时器,可以通过内核定时器唤醒和轮询的时间通过lld_evt_time_get BLE_BASETIMECNT_REG()函数,这也许会给你更准确的时间测量,因为它删除任何开销ke计时器,但即使是这样,我不确定你是否会得到你想要的RTC的准确性。
由于MT_dialog
嗨,对话框中,
谢谢你的提示。我将轮询BLE_BASETIMECNT_REG并测试它。
最好的问候,
Ciano霜
丹麦
嗨,对话框中,
一个问题:
如果使用一个精确的XTAL32，我们做，不能给出一个更精确的时间，那么使用XTAL32而不是内部RCX的好处是什么?
最好的问候,
Ciano霜
嗨ciano,
XTAL32是强制性的，只有过boost配置，因为RCX不能正常工作，你只能使用RCX超过buck，因此XTAL32可以省略(如数据表所示)。使用XTAL32的原因不是为了保持更精确的时间(这将改善结果及时保持,RCX,但我不认为整个系统是足够准确的RTC原因我以前我在文章中提到过)。在boost模式下使用XTAL32的原因是，当设备进入睡眠模式时，RCX是由碱性电池供电，而不是由DCDC变换器供电，所以LP时钟上的电压不同，这将导致漂移。
由于MT_dialog
嗨,对话框中,
我没有测试你的建议，并读取BLE_BASETIEMCNT_REG通过lldevt_time_get()在我的5分钟定时器。
我计算时间开始后经过的秒数，并打印结果。
代码是这样的
uint32_t app_too_old_timer_cnt [NUM_SAFETY_CPY] __attribute__(((“retention_mem_area0”)部分,zero_init));/ / @RETENTION记忆;
uint32_t app_ble_basetimecnt_reg_old [NUM_SAFETY_CPY] __attribute__(((“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 [0] = ble_basetimecnt_reg;
arch_printf(“我% \ r \ n”,app_too_old_timer_cnt [0]);
这给了我下面的打印输出，我注意到在时间上有两个大的跳跃:
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,
我已经注意到,“跳”前的83421年值对应于((83421/60)/ 60)= 23日1725小时(您已经运行这个测试一段时间不到一天,对吗?)这是approximatelly BASETIMECNT的大小27位计数寄存器(在接下来的5分钟,从83421年的价值是印刷,计数器将消失，并将开始计数从开始)。因此，当计时器到达它的最大值时，它将滚动，因此，当ke_timer到达ble_basetimecnt_reg变量的当前值将小于相同变量的前一个值，因此，减法将导致一个负数存储在unsigned 32位变量类型中，然后将该值与之前的计算值相加，我认为这就是在输出的值中看到这种跳转的原因。
由于MT_dialog