ETHERNET IN ZigBee

Hey! You dropped Ethernet in my ZigBee!

I often wonder if the Hayes modem folks ever in their wildest dreams expected to see their AT command interface tacked on ZigBee and Bluetooth radio solutions among other things. Well, if you don’t have a need to roll your own XBee embedded application, the venerable AT command set can be used to modify and read the XBee module parameters. The XBee’s AT command set and its use of the RS-232 protocol make the XBee and XBee-Pro prime candidates for use with a UART-equipped microcontroller. So, I threw together a little microcontroller-based board complete with an RS-232 serial port to collect the data payloads from the ZigBee packets flying between the XBee modules.

(Click here to enlarge)

Photo 3—As far as 8-bit microcontroller devices go, this little concoction of electronic components is about as good as it gets for supporting the ENC28J60 Ethernet engine. I’ve designed in a PIC18F8722 running at 40-MHz, 3.3-V, and 5-V power supplies, an RS-232 port, a debugging/programming port, external SPI-driven EEPROM storage, and a 32.768-kHz-based real-time clock. Plus, all of the PIC18F8722’s I/O lines are accessible via standard 0.1" center pads.

While I was merrily soldering away on the creation shown in Photo 3 (p. 49), it came upon me as to how wonderful ZigBee is as long as you keep everything within walking distance. I thought about how neat it would be to be able to interrogate a ZigBee node from long distance. Of course, long-distance data communications translated to the Internet in my mind, and that’s how the Ethernet circuitry depicted in Figure 2 (p. 50) came to fruition as the PCB in Photo 3.

(Click here to enlarge)

Figure 2—In addition to providing the PAN-to-LAN support for the XBee modules via the serial port, this circuit can load and run the latest version of the free Microchip ENC28J60 TCP/IP stack code right out of the box.

The overall long-distance ZigBee scheme I concocted is simple. An XBee node is either running an embedded application or is under control of a host microcontroller, which is also most likely running an embedded application. Either way, data is passed from the remote XBee node to a central collection XBee node, which passes the received ZigBee node data to the microcontroller on my board in Photo 3. The receiving microcontroller can then process the data or just pass it along to the Ethernet engine encapsulated within a UDP datagram. By adding Ethernet and UDP, small data payloads can now flow from PAN to LAN to WAN and vice versa.

Let’s examine what it takes to perform the PAN-to-LAN data transfers. To keep things easy, I left the XBee modules in their out-of-the-box configurations. Thus, the serial datastream that enters the XBee module D_IN input isn’t held in a buffer; it’s transmitted as quickly as possible. The microcontroller on my ZigBee-to-Ethernet bridge is programmed to catch every incoming serial character by way of interrupt and stuff the captured characters in receive buffer. The buffered characters are then punched into the data area of a UDP datagram, which is preconstructed and lying in wait in the microcontroller’s SRAM. The details of the construction of the UDP datagram and its ultimate transmission are laid out in Listing 1 (p. 52).

The new Microchip Technology ENC28J60 is the Ethernet engine on my ZigBee bridge board. Its 8 KB of internal packet buffer area can be carved up by loading certain extent registers with the buffer extent values. I allocated 1 KB of transmit buffer area, which left the remaining 7 KB for receive buffer duty. TXSTART represents the beginning of the transmit buffer area within the ENC28J60. Rather than tie up ENC28J60 buffer space, I assembled a UDP datagram within the microcontroller memory with the send_udp_datagram function shown in Listing 1. A UDP datagram is a simple collection of destination/source hardware and IP addresses, checksums, destination/source logical port addresses, and data. I built a complete UDP datagram from top to bottom and sent it within the send_udp_datagram function’s code.

The data area of the UDP datagram is shown as static values in Listing 1.  However, I kind of put the mule behind the cart. Before I could send that little UDP datagram and do something useful with the data it carries, I needed a defined destination. So, I cooked up a little pot of code to seek out and map the destination Ethernet station.

The arp_request function shown in Listing 2 (p. 56) writes the contents of an ARP request packet directly into the ENC28J60’s transmit buffer area. There is no reason to build the ARP request packet up in microcontroller memory because it’s used only once at the beginning of the process.

I can’t show you all of the ZigBee bridge application code in this article. The complete application is posted on the Circuit Cellar FTP site. After you download the code, note that the ZigBee bridge application works using a round-robin approach. Incoming Ethernet packets are serviced in rotation with incoming characters from the XBee module, which is attached to the ZigBee bridge board’s serial port. That’s how PAN to LAN is accomplished.

The method of updating and sending the ZigBee data inside the UDP datagrams depends on your application. I’ve included real-time clock hardware as well as a real-time clock driver in the ZigBee bridge application code to allow you to send the UDP datagrams at timed intervals. You can also kick off a UDP datagram after collecting a certain amount of data. For demonstration purposes, I coded my ZigBee bridge application to gather data and send a UDP datagram every minute.