This week David and I had a check-in for Embedded Systems where we had to demonstrate our progress on the project. I spent most of my time this week chasing a bug in the code I'd written to use the SPI (Serial Peripheral Interface) bus between the Pi and the PSoC to transmit the note data. We chose to use SPI because it's a very high speed interface, and has support for 'words' longer than 8 bits. For Beta Reviews, I had a working example of 2 analog inputs being analyzed and sent to the Pi, but it had some glitches. Bytes would occasionally get sent in the wrong order (causing values to jump wildly and make horrible noises), retransmitted, or sometimes just go missing completely. To mitigate the issues, I had to put artificial delays in the python script running on the Pi.
For the Embedded Systems check-in, David sent me some code he'd been working on that can control an analog multiplexer and convert a huge number of analog inputs using a comparatively small number of ports. I worked on modifying his code to work with the SPI code I'd written and see if I could get this data over to the Pi. However, I was getting the same kind of glitches. I pared down the tests I was doing until I was just transmitting sequential, increasing numbers from the Pi and waiting for the PSoC to echo them back. Even with the script slowed to it's minimum acceptable speed (for our purposes), the numbers were still coming back out of order, duplicated, or not at all. After a lot of careful testing it seems the culprit was the xfer2 function in the Raspberry Pi's SpiDev library. When I used the xfer function instead, the glitches went away. The difference between xfer and xfer2 is that xfer doesn't hold the chip select line between blocks of the SPI transmission while xfer2 does. In more practical terms that's like the difference between turning to your friend and saying "Hey, listen..." before each sentence and just launching a torrent of word vomit at them. It seems that letting the chip select go helps with the synchronization between the microcontrollers.
I just ordered the rest of the components we need - 20 more thumbsticks and 50 more caps (it's cheaper to buy in bulk). With 18 days to final demos, it's go time. I'm hoping to get most of the tech stuff done this week so we can get a jump on the enclosure. I think we might be able to 3D print the interior honeycomb structure. We've secured some protoboards to solder stuff into (a custom PCB is going to take too long), so hopefully we can test our circuit soon!
Here's a photo of my teammate David putting together a massive array of potentiometers to test large-scale multiplexing. Prior to this (on the breadboard in the lower right corner), he managed to get multiple multiplexers feeding data into the PSoC, verified over a UART connection to the Cypress terminal / monitoring app.