Helm: helmstatemachine.c
Home The Game Water Craft Helm      Software      Electronics Communications Gems of Wisdom Media		Pseudocode helm.c helmstatemachine.c LED.c iButton.c Test harness HelmStateMachine overview: The Helm State Machine keeps track of the game state and detects the events that move between them. The event “iButton Sensed” would exit the Waiting for iButton state. The event “Serial numbers matched” would exit the waiting for paired message state. The “Start game received” would exit the waiting for game start. The “end game message received” would exit the playing game state. The only way to exit the endgame state is to receive a hard reset. At any time, a hard reset message will set the current state to “Waiting for iButton.” Timing: The heartbeat of the duck is a 200 ms timer. When it expires, a flag is set that can be consumed if the state machine implements the timer. Other timers, such as the 600 ms display refresh, the 10 s stand down timer, and the 10 s  pump timer, piggyback off of this 200 ms timer. XBee receive scheme: We needed a robust scheme to read a series of bytes from the XBee (the packet) and to reject partial packets. The problem was that if a partial packet was received, the processor would thereafter be reading an offset series of XBee bytes that would be invalid. We based our scheme on the knowledge that the first four bytes of each packet will be the same: Start Delimiter, LengthMSB, LengthLSB, and API ID. While scanning for this sequence, any incorrect byte will return to the “Scanning for Start Delimiter” state. When this sequence is received, it is assumed that the follow data is valid. The next eight bytes are recorded or discarded as necessary, and the receiver defaults to the “Scanning for Start Delimiter” state. The cost of a partial packet while receiving these eight bytes are two packets, or 400 ms in the case of the command packets. The current packet will be incorrectly received and executed, and the next packet will be flagged as invalid and discarded. However, the receiver and XBee will be properly byte aligned for the next command. If a valid packet is received, the processor can then perform an additional check that the transmission originated from the paired helm or craft. Please see the figure below for details. XBee decoding: Upon receiving a byte via the SCI from the XBee, the E128 throws an interrupt. This interrupt encapsulates the state machine described in the XBee receive scheme. At each step, this state machine records the information in a volatile byte buffer (the information is overwritten in an asynchronous manner) Upon completion, the state machine sets a “new packet present” flag that is polled for in every state machine. Upon detecting this flag, a function called “Fetch Packet” copies the state of the volatile buffer to a separate buffer to preserve the state of the received packet. This data will only change via a user function call and so is nonvolatile. This double buffered system ensures that partial packets are not misinterpreted.  The state machines all call a common function CheckCommEvent() that converts the packet into an event, which can be interpreted differently by each state machine. The full collection of C files may be found here.