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?
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.-
1 Like
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, 