Nick designed and laid out a protoboard for the player module and then spent 10 hours soldering it together. We decided that soldering more modules would not be an efficient use of our time, which leaves us with only two player modules. Nick also added negative number functionality to the player module. He also drew a schematic of the player module.
Brandon added functional start and reset buttons to the host module and removed extraneous information about the touch screen from its display. He also fixed several small outstanding bugs with the interface and brought negative number functionality to the host module.
The large majority of the remaining work was done by both Nick and Brandon working together to troubleshoot issues.
The new set of Bluetooth chips arrived this week. We assembled them and were able to successfully connect and communicate over them. The host module is controlled via HCI protocols, meaning the host module needed to send, receive, and interpret specific op-code commands over the UART. Although we had the basis of a library for this, there was a significant amount of converting and additional code required before we could use it on the PIC. A major hurdle we had to overcome was that some of the op-codes contained special and reserved characters, such as line feed (\n, 0x0A) and carriage return (\r, 0x0D), which prevented directly printing the op-codes. We ended up bypassing pt_cornell_1_2.h and writing our own UART print using functions from uart.h.
Communication from the host module to the player module works well, but only when the target player module address was hard-coded into host module. We had an absurd amount of difficulty in trying to read from the player modules to the host module. The correct data was confirmed to be showing up on the RX pin into the PIC, but the onboard UART module failed us. We spent over 40 hours over the past four days trying to get just this functionality working. By jury-rigging an error check accounting for overrun errors to also poll a value from a specific location in PT_term_buffer, we were able to get it about 70% working 30% of the time.
After a some research we came to the conclusion that the combination of Protothreads and the PIC itself makes reading the particular piece of data we care about out of the notification messages from our central Bluetooth (Low Energy) chip is exceptionally difficult. An overrun error is when the UART receives new data before the old data is completely read. When the error occurs, it throws a flag that locks up the receiver and prevents any further data from being read in. Receiving large amounts of data at any baud rate very quickly will throw an overrun error and this was thrown when receiving data from the BLE chip and also when receiving multi-character data from the PC terminal. We tried several ways to fix this like manually clearing the error flag and trying to salvage what was in the buffer when it was thrown. Another way was to write our own UART read function to make sure we weren’t jumping to random places in the middle of our read to hopefully avoid the overrun error, but we had still had similar problems with freezing up mid-receive. Ultimately, time became a factor and we abandoned the attempt.
As such, we are implementing a Plan B, which while significantly less complex, should also be achievable by Tuesday morning. This Plan B is to have the host (the person, not the module) pick which player buzzed in first by eye (based on when the buzzers light up) and select that player on the LCD touch screen, which well turn off the other players’ lights and set the target module address in the software. Nick modified the player module code for Plan B. Brandon modified the host module code.
