Home > Tech geeks > Interrupt-Driven Serial Communications

Interrupt-Driven Serial Communications

xbeetest2So after a few days of tinkering and a good night’s sleep, I have successfully achieved 2-way communication through the XBee wireless modules. The funny thing is that I knew exactly how to do it, it just took me longer than I wanted to properly execute it. My biggest problem was a missing +3.3V power wire to the 3V-to-5V translator circuit, which (for some bizarro reason) allowed the outgoing serial comms to pass, but the inbound ones were completely filtered out. I also had some programmatic problems with how the interrupt was being handled, but that didn’t take too long to iron out.

What happens for this test circuit and program is the 14M chip sits there and continually sends out the increment timer messages, 1 per second (as discussed in the previous post) If a communication is sent to the 14M chip, the “true” serial communication on that pin (#1) pulls it low to begin the communication, triggering the interrupt. For the test circuit I simply have it take a temperature reading from an LM34 temperature sensor and send the average of 10 readings back, as shown by the screenshot. I simply typed a “?” character, which was sent as “01100011” to the PICAXE, pulling pin 1 low on the first or fourth bit, and that prompted the 14M chip to do its thing.

In practice for the brewing sculpture, I could code the PICAXE to use a SERIN command to wait for a true communication message, such as “Turn on Pump 1” or “Set Mash Temp Control Point at 150 deg” (well, a byte equivalent of that kind of thing, anyways). I would also probably buffer the message with some “U” or “<” characters to cycle thru 0 and 1 values before the actual data is sent, triggering the interrupt in advance of the meaningful data. My intent is to have the satellite circuits like the pump skid control box handle events locally, but allow updates / overrides from the PC if necessary – basically a simple cascade process control schema, and now I think I can achieve this.

Since my proof of concept has been a success, I now have some big to-dos:

  1. Finalize the PCB design for the XBee interface circuit, etch it, and install it in the pump skid control box.
  2. Re-code the skid control box to accept and interpret the “inbound” messages from the PC, if necessary
  3. Write a VB2008 module to facilitate XBee communications from the BrewzNET app.

I am still undecided as to whether I am going to use the API or non-API functionality in the coordinator XBee. The API will give me significant flexibility for sending the outbound messages, however the learning curve and complexity drastically increases – and I’m not sure I’m ready for that just yet.

Categories: Tech geeks
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: