[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（）會導緻丢失/丢失消息，缺少資料包緩沖區以及路由資料包的延遲增加。