# sys\_xbee\_tick(), xbee uart, and interrupt latency

**URL:** <https://forums.digi.com/t/sys-xbee-tick-xbee-uart-and-interrupt-latency/11244>\
**Category:** XBee Programamble (S2C & 900 HP)\
**Created:** [October 29, 2012, 7:38pm UTC](https://forums.digi.com/t/sys-xbee-tick-xbee-uart-and-interrupt-latency/11244 "2012-10-29T19:38:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![wz2b](https://avatars.discourse-cdn.com/v4/letter/w/e274bd/32.png) [@wz2b](https://forums.digi.com/u/wz2b)\
**Post date:** [October 29, 2012, 7:38pm UTC](https://forums.digi.com/t/sys-xbee-tick-xbee-uart-and-interrupt-latency/11244/1 "2012-10-29T19:38:27Z")

</div>

Does anybody know if sys\_xbee\_tick() or the default xbee-side frame processing (including uart ISR) leave interrupts disabled for a significant amount of time (microseconds) every time they are called?

---

<div class="post-metadata">

**Author:** ![spastor](https://avatars.discourse-cdn.com/v4/letter/s/35a633/32.png) [@spastor](https://forums.digi.com/u/spastor)\
**Post date:** [October 30, 2012, 11:42am UTC](https://forums.digi.com/t/sys-xbee-tick-xbee-uart-and-interrupt-latency/11244/2 "2012-10-30T11:42:10Z")

</div>

Hello Chris,

sys\_xbee\_tick() is not disabling interrupts and the xbee\_uart\_isr is disabled (frames are read by polling). Do you think it’s conflicting with something in particular?

Regards,

Sebastián.-

---

<div class="post-metadata">

**Author:** ![wz2b](https://avatars.discourse-cdn.com/v4/letter/w/e274bd/32.png) [@wz2b](https://forums.digi.com/u/wz2b)\
**Post date:** [October 31, 2012, 3:22am UTC](https://forums.digi.com/t/sys-xbee-tick-xbee-uart-and-interrupt-latency/11244/3 "2012-10-31T03:22:26Z")

</div>

I’m not sure, but I"ll get to the bottom of it. I traced the code as best I could in the xbee tick, and as you say, it looks like it’s completely polled. The SCI receiver is interrupt driven, but the ISR is short, and throws bytes into a lockless queue. The only thing xbee tick turns interrupts off for is to ensure it isn’t run concurrently, and it’s a small handful of instructions.

Part of the challenge here is I’m trying to implement a communications protocol with a bit time of 30 uS, and three bauds per bit … so I need fairly accurate timing at 10 uS. I’m convinced I an do it … but won’t be able to tolerate interrupts being off for very long. So far, all the libraries that come with the xbee sdk look pretty well thought-out in terms of not interfering with real-time (ISRs and the like).

Still working through it, 🙂