你好，
我需要一个精确的超时功能。像几个月。
我使用了最长延迟的app_easy_timer（）可能（5 * 6000-1），这是5分钟-10ms。如果问题纠正我。
在我的计时器回调中，我递增自己的计数器并用app_easy_timer（）重新启动计时器。
获得最高精度我使用
#define cfg_lp_clk lp_clk_xtal32.
Xtal32睡觉。
但是，它看起来像我的计时器一样快速运行5％。
我的问题：
我该怎么办才能获得最佳的计时器精度，当时我的超时时间为期月份？
先感谢您
Ciano Frost.
丹麦
关键词：
设备：
嗨Ciano，
app_easy_timers（）尚未获得足够的课程以作为RTC运行并准确计算几个月，这是因为基础定时器，即核心定时器依赖于，每次设备唤醒时都会得到补偿，并且在时间测量中引入了错误，我不确定是否使用更准确的时钟更改当前的XTAL32，您将能够减少该错误，大多数可能是您不会。您可以尝试测量时间，而不是拥有内核定时器，而不是通过内核计时器唤醒，并通过LLD_EVT_TIME_GET（）函数从BLE_BASETIMECNT_REG调查时间，也许这将为您提供更准确的时间测量它删除了ke定时器具有的任何开销，但即使是这样，我不确定您是否会得到您想要的rtc的准确性。
谢谢mt_dialog.
嗨对话框，
谢谢你的提示..我会轮询BLE_BASETIMECNT_REG并测试它。
此致，
Ciano Frost.
丹麦
嗨对话框，
还有一个问题：
如果使用我们的准确XTAL32，我们不会提供更精确的时间，那么使用XTAL32而不是内部RCX的好处是什么？
此致，
Ciano Frost.
嗨Ciano，
XTAL32仅通过升压配置强制性，因为RCX不会正常运行，因此只能使用RCX Over降压，因此可以忽略XTal32（如数据表所示）。使用XTAL32的原因是为了保持更准确的时间（它将在RCX上保持时间保持时间，但我不认为整个系统对于RTC的原因，整个系统将足够准确，因为我提到的原因是RTC的准确性在我之前的帖子中）。在升压模式下使用XTAL32的原因是因为当设备进入睡眠模式时，RCX从碱性电池供电而不是从DCDC转换器供电，因此LP时钟上的电压不同，这将导致漂移。
谢谢mt_dialog.
嗨对话框，
我没有在我的5分钟定时器中通过lldevt_time_get（）读取您的建议，adn读取ble_basetiemcnt_reg_reg。
我计算自时间开始以来的经过秒数，并打印结果。
代码看起来像这样
uint32_t app_too_old_timer_cnt [num_safety_cpy] __attribute __（（部分（“保留_mem_area0”），zero_init））;// @保留记忆;
uint32_t app_ble_basetimecnt_reg_old [num_safety_cpy] _Attribute __（（部分（“保留_mem_area0”），Zero_Init））;// @保留记忆;
..
在5分钟内回电
UINT32_T BLE_BASETIMECNT_REG;
uint32_t time_since_last_cb_in_seconds;
//计算自上次回调以来解析的时间，并以秒为单位增量总计数器。
ble_basetimecnt_reg = lld_evt_time_get（）;//获得625us蜱虫
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（“％i \ 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 Frost.
丹麦
嗨Ciano，
我注意到的东西，在“跳跃”之前的83421值对应于（（83421/60）/ 60）= 23,1725小时（你经过这次测试一点不到一天，这是正确的吗？）是近似的BasetimEcnt的大小，基于27位计数寄存器（在接下来的5分钟内，从印刷83421值时，计数器将经过，并将开始从BENGINGS计算）。因此，当计时器到达其最大点时，它将滚动，因此，当ke_timer命中时，当BLE_BASETIMECNT_REG变量的当前值将小于相同变量的先前值，因此减法将导致存储在无符号中的负数32位变量类型，然后将该值添加到先前计算的值，我认为这是看到您打印的值中的这种跳转的原因。
谢谢mt_dialog.