I'm working with some others on a domotica project. We use a Raspberry Pi for the server, and communicate with Arduino Unos with 1 Xbee each Arduino. To make everything run fast, the receivingpacket method should be in a loop, right? I can't do this in a loop because I also use an I2C bus frequently. I can't run I2C and the receiving[packet method at the same time, because the I2C interaction is also in a loop. Is using an interrupt for the receivepacket method the solution? How should I do this?
It's not clear to me yet. Any other solutions are welcome as well.
Using an interrupt would certainly not be the first choice.
But to determine the best route we need more information.
There is no categorical reason not to use I2C and also talk to the XBee via serial.
How frequently is I2C used? What is it used for?
How often are messages sent and received on the XBee?
Are there calls to the delay() function in any of the code?
The BlinkWithoutDelay example is very useful because it demonstrates how to accomplish more than one thing "simultaneously" with non-blocking code (i.e. no calls to delay).
Thanks a lot for your reply. So, interrupts are not really what we want. I use i2C for a keypad. The keypad is used to enter the code if the alarm goes off. The keypad can also be used to change the code while the alarm is off.
I only receive a packet from the server which tells me I'm allowed to send a packet to the server. Only 1 xbee is allowed to send a packet at a time, so to send a packet I use a method called myTurn() which returns a boolean. (True: allowed to send, false: not allowed to send) (This must be in a loop as well if i want to send).
Good on you for no delays! A keypad is a fairly low-data-rate device. I don't see any issue with polling it continuously in loop() along with continuously checking for data received from the XBee. 99.99% of the time both will be exceedingly fast because the answer will be, "no keys pressed" and "no packet received". When it's time to make a transmission, just do it, only milliseconds are required. If that's all the processing that goes on, I'd expect the system to be very responsive and to probably have at least 90% of its CPU capacity still available.
Jirachi:
Thanks! Thats great news! Within a day I will post the code I have in my loop(). If you would like to check it: thanks!
The best check is to run it! So do that, then if there are issues, go ahead and post it. I can't promise to have bandwidth for extensive code analysis but this is a community with considerable depth and breadth.
A fairly typical project of mine monitors an XBee for incoming transmissions, reads analog and digital sensors, sends data once per minute, polls a couple buttons, blinks some LEDs (mandatory part of any project), communicates with an RTC occasionally, and runs a seven-segment display via a MAX7219. And I still think the CPU is loafing. Which is what we want, really.