GamePlay State Machine
In order to allow the unit to operate as any one station, or any combination of stations, we opted to use a pseudo-hierarchical approach. Depending on what station the user selected, the Waiting4User and Playing state would react differently to the events posted to machine while in those states. To do this, separate response functions were written for each station and said functions we there called during those states, with the event that was posted to the machine being passed to the response function. To keep with program space efficiency, wrapper function were called when multiple station needed to be run simultaneously. This allowed us to use the same response functions for the separate stations. See the tables section for a more detailed look at the responses for each station.
Calling the functions did not involve the use of a switch statement, but rather an array of function pointers, allowing the correct pointer to be called based on which station was selected by ordering the functions pointers in an array such that index corresponding to value of the DIP switches had the correct function pointer set. The function pointers were populated by through the GP_DefsAndConfig header file.
When the response function determined that a state change was required at the game play level, the service function would return an event other than ES_NO_EVENT or ES_ERROR, and the game machine would rerun to process the event and put itself into the correct state. This implementation allowed for very versatile control of the unit without the need to employ the full hierarchical framework, which required quite a lot of program space.
Calling the functions did not involve the use of a switch statement, but rather an array of function pointers, allowing the correct pointer to be called based on which station was selected by ordering the functions pointers in an array such that index corresponding to value of the DIP switches had the correct function pointer set. The function pointers were populated by through the GP_DefsAndConfig header file.
When the response function determined that a state change was required at the game play level, the service function would return an event other than ES_NO_EVENT or ES_ERROR, and the game machine would rerun to process the event and put itself into the correct state. This implementation allowed for very versatile control of the unit without the need to employ the full hierarchical framework, which required quite a lot of program space.
Transmit State Machine
The transit machine handles transmitting the station(s) messages on the mumble channel. There are three separate tone timers per station, and the timeout event, which signals that it is time to transmit, is only handled if the station is currently selected. The machine also handles the generation of the tones, using another timer to time out the dibits to be sent. Conversion of the message from bits to tones is handled in a separate modulation library.
To prevent collisions the machine first checks to make sure the line is quiet before beginning the servo lowering action, waiting 40 ms before rechecking. This helps if another station is running a little out of sync with the TDMA protocol.
To prevent collisions the machine first checks to make sure the line is quiet before beginning the servo lowering action, waiting 40 ms before rechecking. This helps if another station is running a little out of sync with the TDMA protocol.
Receive State Machine
The receive machine handles reception of tones from the Mumble channel. The machine idles in the "Listening" state, waiting for the line to become active. It then waits for the completion of start delimiter to begin timing when to sample the tones. The RX_TIMER is used to time to points at which the value currently held in the capture register should be read and stored in a buffer for translation. Translation for tones to a message is handled in the Modulation Library.
In addition to sampling tones, the receive machine also syncs the transmit machine. Upon receiving a valid message, the machine calculates the amount of time before the stations can transmit their own messages and resets the tone timers . This done when the machine transitions for the state of "Receiving Tones" to "Listening".
In addition to sampling tones, the receive machine also syncs the transmit machine. Upon receiving a valid message, the machine calculates the amount of time before the stations can transmit their own messages and resets the tone timers . This done when the machine transitions for the state of "Receiving Tones" to "Listening".
Debounce State Machines
The debounce machines provide software deboucning for the two push buttons on the unit. The debounce time was found empirically.
statemachines_finalproject.pdf | |
File Size: | 84 kb |
File Type: |
For more details on the software implementation, see the Software page section "Other Listings"
Tables
The following tables show the event response behavior of the three stations when Game play is in the Waiting4User or Playing state. As stated previously, there were two event response routines per station, one for Waiting4User and one for Playing. If multiple stations were selected, multiple event response functions were used, thus multiple tables would run.
CONN Station:
SONAR Station:
TORPEDO Station:
statetables_finalproject.pdf | |
File Size: | 42 kb |
File Type: |