精密长定时器。

7个帖子/ 0新
最后一篇文章
齐亚诺
离线
最后一次见到:2周17小时前
加入:2014-10-03 08:13
精密长定时器。

你好

我需要一个精确超时功能。大概几个月吧。

我使用了最长延迟的app_easy_timer()可能(5 * 6000-1),这是5分钟-10ms。如果问题纠正我。
在计时器回调中,我增加自己的计数器,并使用app_easy_timer()重新启动计时器。
以获得我使用的最高精度
#define cfg_lp_clk lp_clk_xtal32.
XTAL32用于睡眠。
然而,在我看来,我的计时器运行速度是5%到5%。

我的问题:
当我的超时时间大约为个月时,我应该怎么做才能获得最佳的计时器精度?

先谢谢你
西亚诺霜
丹麦

关键词:
设备:
MT_对话框
离线
最后一次见到:2个月2周前
工作人员
加入:2015-06-08 11:34
嗨,西亚诺,

嗨,西亚诺,

应用程序_easy_timers()没有足够的预见能力作为RTC运行并准确计算月数,原因是内核计时器所依赖的基本计时器在每次设备唤醒时都会得到补偿,这会在时间测量中引入错误,我不确定是否以更准确的方式更改当前的XTAL32时钟你将能够减少错误,很可能你不会。为了测量时间,你可以尝试什么,而不是使用内核计时器,你可以通过内核计时器醒来,并通过lld_evt_time_get()从BLE_BASETIMECNT_REG轮询时间功能,也许这将为您提供更精确的时间测量,因为它消除了ke计时器的任何开销,但即使这样,我也不确定您是否能获得RTC所需的精度。

谢谢你的对话

齐亚诺
离线
最后一次见到:2周17小时前
加入:2014-10-03 08:13
嗨,对话,

嗨,对话,

谢谢你的提示。。我将轮询BLE_BASETIMECNT_REG并测试它。

此致,
西亚诺霜
丹麦

齐亚诺
离线
最后一次见到:2周17小时前
加入:2014-10-03 08:13
嗨,对话,

嗨,对话,

还有一个问题:
如果使用我们的准确XTAL32,我们不会提供更精确的时间,那么使用XTAL32而不是内部RCX的好处是什么?

此致,
西亚诺霜

MT_对话框
离线
最后一次见到:2个月2周前
工作人员
加入:2015-06-08 11:34
嗨,西亚诺,

嗨,西亚诺,

由于RCX无法正常工作,因此XTAL32仅在升压配置时是强制性的,因此只能使用RCX过降压配置,因此XTAL32可以使用(如数据表所示)。使用XTAL32的原因并不是为了保持更精确的计时(相对于RCX,这将改善计时结果,但我认为整个系统对于RTC来说不够精确,原因正如我在上一篇文章中提到的)。在boost模式下使用XTAL32的原因是,当设备进入睡眠模式时,RCX由碱性电池供电,而不是由DCDC转换器供电,因此LP时钟上的电压不同,这将导致漂移。

谢谢你的对话

齐亚诺
离线
最后一次见到:2周17小时前
加入:2014-10-03 08:13
嗨,对话,

嗨,对话,

我没有测试您的建议,也没有在我的5分钟计时器中通过lldevt_time_get()读取BLE_BASETIEMCNT_REG。
我计算自时间开始以来经过的秒数,并打印结果。
代码看起来像这样

uint32应用程序太旧定时器[NUM\u SAFETY\u CPY]\uuuu属性(节(“保留内存区域0”),零初始化));//保留内存;
uint32应用程序basetimecnt注册旧[NUM\u SAFETY\u CPY]\u属性(节(“保留内存区域0”),零初始化))//@保留记忆;

..

在5分钟内回电

UINT32_T BLE_BASETIMECNT_REG;
uint32_t time_since_last_cb_in_seconds;

//计算自上次回调以来解析的时间,并以秒为单位递增总计数器。
ble_basetimecnt_reg=lld_evt_time_get();//获取625us刻度
自上次以来的时间(以秒为单位)=(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(“%i\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]

为了解决这个问题,我需要知道这两次跳跃的原因。
您是否对为什么会发生任何解释?

此致,
西亚诺霜
丹麦

MT_对话框
离线
最后一次见到:2个月2周前
工作人员
加入:2015-06-08 11:34
嗨,西亚诺,

嗨,西亚诺,

我注意到,“跳转”之前的83421值对应于((83421/60)/60)=231725小时(您运行此测试的时间不到一天,是否正确?),这近似于BASETIMECNT的大小,即27位计数寄存器(在接下来的5分钟内,从打印83421值开始,计数器将已过,并将从计数器开始计数)。因此,当计时器达到其最大值时,它将滚动。因此,当ke_计时器达到ble_basetimecnt_reg变量的当前值时,该值将小于同一变量的上一个值,因此减法将导致以无符号32位变量类型存储负数,然后将该值添加到上一个变量我们计算了一个值,我想这就是为什么在打印的值中会出现这种跳跃的原因。

谢谢你的对话