Software Overview and Design
For our software design, we decided not to use the Event Services Framework, and opted for an interrupt-driven state machine. While the state machine ran in the main, it polled flags set by interrupts. We arrived at this decision after realizing that there were few critical events that in each anticipated state, and that we could minimize the amount of code we needed to upload to the PIC.
The key interrupts which pushed along the state machine were for bytes received via UART and timers. These interrupts set flags that are polled by the state machine. All the software timers were set internally by the state machine, and operate using the overflow feature on TMR0. The RX interrupt only sets a flag when it detects an Xbee packet of type 0x81.
The HZV required more PWM capabilities than we could source with one PIC, so we set up another PIC as a slave. As the HZV would receive commands from the LUC, it would pass on the direction and speed information bytes via SPI to the HZV slave, which would then take care of setting the left and right motor PWM and direction pins appropriately. An overview of these links are shown in the picture below. The balloon monitor was monitored on a separate PIC, with the query line being changed by a software PWM to query the status every 54 milliseconds, and data being received through the UART. We tested the balloon monitor using debugging LEDs, and then used whether one LED pin was high or low to indicate whether or not the balloon was popped, interfacing this pin with an I/O pin on the master HZV PIC.
The key interrupts which pushed along the state machine were for bytes received via UART and timers. These interrupts set flags that are polled by the state machine. All the software timers were set internally by the state machine, and operate using the overflow feature on TMR0. The RX interrupt only sets a flag when it detects an Xbee packet of type 0x81.
The HZV required more PWM capabilities than we could source with one PIC, so we set up another PIC as a slave. As the HZV would receive commands from the LUC, it would pass on the direction and speed information bytes via SPI to the HZV slave, which would then take care of setting the left and right motor PWM and direction pins appropriately. An overview of these links are shown in the picture below. The balloon monitor was monitored on a separate PIC, with the query line being changed by a software PWM to query the status every 54 milliseconds, and data being received through the UART. We tested the balloon monitor using debugging LEDs, and then used whether one LED pin was high or low to indicate whether or not the balloon was popped, interfacing this pin with an I/O pin on the master HZV PIC.