Rainboard SysEx

Revision as of 14:28, 5 October 2012 by BrettThePark (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Musix communicates with the Rainboard via midi in order to send new colour layouts and new note information. A sysex message processing issue arose receiving larger messages: random bytes would be dropped from the communication. The colour information is transmitted in just under 256 bytes and if a single byte was lost the message would be considered garbage (via a checksum) and the Rainboard would not update. This was unacceptable for normal use and for the competition. Two options were present: slow down the communication or speed up the processing. I did not want to slow down the communication as the size of slow down is hard to determine and I did not want to have to remember to code in slowdowns in future Rainboard apps. I had previously done some work to speed up sysex (by not updating the eeprom while receiving data). I calculated that in order to keep up with a sysex message of infinite length each byte would need to be processed in less than 320 microseconds which equates to 5120 cycles (for the whole loop). Timing test were setup for the whole loop to see where the time was being taken.

The first decision was to prevent non-crucial functions from being performed during a sysex. These included accelerometer updates, slider updates, wave updated, and eeprom updates. These processes are reactivated when the sysex message ends or a button is pressed. These changes much improved the performance as the functions where taking up 27% of total clock time. The sysex code that I wrote to process the incoming data was taking 2% of the processing time in comparison to the midi processing code from the midi library. I then set about optimizing the third party midi library for sysex. By reordering some of the decision trees and reducing the calls to the Serial library, I managed to speed up the midi read call by five times. The total sysex optimization resulted in the ability to process each byte in about 600 cycles which left plenty of overhead.