This week, I accomplished 4 main tasks:
- Rehearsed and presented our design review
- Wrote code for the Teensy to parse a MIDI file and light up LEDs according to the rhythm of Twinkle Twinkle Little Star.
- Able to get the Teensy to read in a MIDI file from the RPi
- Modified the state machine design and did a first pass at implementing it on the Teensy
Able to programmatically parse MIDI file and use it to light up LEDs:
Able to get the Teensy to read in a MIDI file from the RPi over UART:
I implemented an interrupt on the Teensy to look for a signal indicating when it should start listening for bytes making up a MIDI file. I also got the Teensy to read in bytes over UART (Serial channel 2). During testing, I found some interesting behavior:
- At 9600 and 19200 baud, the Pi can reliably send a MIDI file to the Teensy:
- At 115200 baud, some bytes tend to get lost in the middle. In other words, the Teensy will receive the starting bytes of the file, most of the file’s body, and the end bytes, but the total number of bytes received is less than the file size. So, some bytes are getting lost in the middle. Somehow, faster baud rates cause bytes to be dropped either at the receiving or sending end.
I modified the state machine and implemented it on the Teensy:
Before:
After:
State Machine code:
I used 2 engineering principles while implementing this week’s tasks:
- Making the system modular: By separating the code for the state machine, parsing the MIDI file, handling interrupts, and lighting the LEDs, I could test each function separately. This was especially helpful when developing functionality that would eventually depend on external hardware and sensors that I didn’t have at the moment. For example, the state machine relies on interrupt signals from the Pi. However, by abstracting the state machine into its own class that is updated through a member function, I can avoid having the logic of the state machine strewn across the bodies of several Interrupt Service Routines.
- Considering the system as a whole when debugging: When trying to test UART communication from the Pi to the Teensy, the Teensy would not receive any bytes from the RPI. It turns out the RPi was not blocked for the duration that it was transmitting the MIDI file, so it proceeded with its program to prematurely toggle the file_transmission interrupt pin low. This caused the Teensy to think the file was done being sent, even though the RPI hardware was still transmitting the file. By realizing the hardware and software of the RPi operated on different timelines, I realized that adding a delay before toggling the pin low could help the bytes have time to leave the Pi before the interrupt when low. This ended up working.
This week’s progress is on schedule. I closed a task on the Gantt Chart – “Read in song data from Pi”.
Tasks for next week:
- Finish the state machine and test it with the rest of the interrupts from the pi
- Detect finger placements on hardware that should come in this week.