Overall Software Design

To successfully play a game, our software design had to accomplish several key tasks:
  1. Obtain an ASCII RFID key when swiping an RFID card (must be coded in Assembly).
  2. Convert that ASCII key to a HEX serial number.  If necessary, get a corresponding security key from the security controller.
  3. Send and receive XBee radio messages on both the boat and bike.
Since we couldn't find one 16 series PIC that could do 2 and 3, the simplest PIC network we could design involved 3 PICs (after coding up our PICs, we did actually find dsPICs that could do 2 and 3, but it was too late to change):
Picture
The RFID PIC (16F690) did task 1.  The security PIC (16F690) did task 2.  The Main PIC (16F777) and the E128 did task 3.  We interfaced our three PICs using SPI.  For simplicity, we made the Security PIC a master - it would retrieve an RFID key and send out a serial number and security key to the Main PIC.  The RFID PIC signaled that it had a new key by lowering an I/O line tied to the Security PIC.

Process Flow Diagrams

The state machines for the RFID and security PICs were straighforward and always followed the same state progression.  Instead we've attached the process flow diagrams, which quickly communicate the basic software design:
Picture
Picture
Our RFID PIC originally had timeouts built in in case we didn't get a full RFID message, but this never occurred throughout the project and we had problems with using Timer0, so we took them out.

Note that every RFID scan proceeds through the above process diagrams.  To avoid putting in lookup tables in our Security PIC, we try to get a security key for all card swipes, even color card swipes.  On the Main PIC, once we determine that we've received a color swipe serial number, we just ignore the security key that was sent with it.

Communication State Machines

There are two communications state machines that are used in tandem to receive and transmit a message. Both of these state machines are implemented in the same form on the E128 and the PIC. The only differences are with reference to the specific differences in registers between these microcontrollers. 

The receive message state machine shown below reads a packet of variable length sent by the XBee radio to the microcontroller and stores each byte of the message into an array. As the state machine transitions from one state to another, a byte is stored into the array. Additionally, the state machine calculates the Checksum from the XBee and ensures that the message is not corrupted. If it is, the state machine will flag a Checksum error flag.
Picture
The following state machine is the transmit message state machine which will take a message stored into an array and send it out to the XBee radio.
Picture

Main PIC State Machine

Picture
After a Team Broadcast exceeds 255 transmissions, we chose to raise our team color flag halfway to signal that there was a timeout when trying to find a teammate. The state diagram shows that when this occurs there is a transition from the BROADCAST TEAM COLOR state to the GAME IDLE state. We prevented the user from actually playing the game and capturing atolls as a design choice in the software.

Within the GAME ON state, there is an event checker that responds to messages received by the XBee radio. The event checker can be viewed in the code listings and pseudocode below. 

Code Listings

Alternatively, you can download all the code in a zip file below:
CompleteCode.zip