[Ember Zigbee]How often should I call emberTick()?

In lieu of app-specific, fully-qualified, field-tested recommendations, a recommendation for how often to call emberTick() is this:

 

-Call the function as much as possible to preserve stack timing and 802.15.4 MAC compliance. At minimum, this should be once per iteration of the application’s main while{ } loop.

 - 尽可能地调用该函数以保持堆栈时序和802.15.4 MAC兼容性。至少，这应该是应用程序的主要while {}循环的每次迭代一次。

 

-When heavy traffic is expected, especially on the incoming side, emberTick() should be called more often than noted above. Ideally, you would want it to be called within 500ms of receiving a packet, such that you have plenty of time to turn around an ACK before the sender’s Transport timer gets to 1.28s and times out the send attempt. At worst, you should be calling this often enough that your incoming message queue does not overflow, which is dictated by the packet buffer count. More packet buffers means more flexibility for calling emberTick() before an overflow. Failing to satisfy the ideal condition means more retries, and thus more traffic and higher potential for lost messages. Failing to satisfy the worst case condition means that you’ll lose incoming messages and potentially lose all your stack buffers, prohibiting such activities as routing and serial processing (if using buffered serial).

 - 当预计会有大量数据时，特别是在传入方面，应该比上面提到的更频繁地调用emberTick（）。理想情况下，您希望在接收数据包的500毫秒内调用它，这样您就有足够的时间在发送方的传输计时器达到1.28秒之前转换ACK并超时发送尝试。在最坏的情况下，您应该经常调用它，以使传入的消息队列不会溢出，这是由数据包缓冲区计数决定的。更多的数据包缓冲区意味着在溢出之前调用emberTick（）的灵活性更高。不满足理想条件意味着更多的重试，因此更多的流量和更高的丢失消息的可能性。无法满足最坏情况条件意味着您将丢失传入的消息并可能丢失所有堆栈缓冲区，禁止路由和串行处理等活动（如果使用缓冲串行）。

 

-Keep in mind that calling emberTick() more than needed has very few repercussions because the function will return almost immediately if no stack work is pending. However, calling emberTick() too infrequently can lead to missed/lost messages, a lack of packet buffers, and increased latency in routing packets.

 - 请记住，调用emberTick（）超过需要的影响非常少，因为如果没有挂起的堆栈工作，函数几乎会立即返回。但是，过于频繁地调用emberTick（）会导致丢失/丢失消息，缺少数据包缓冲区以及路由数据包的延迟增加。