Since things didn’t work out as smoothly as I expected, no proper information on the net, nor anyone wrote a library for it; spent few sleepless nights trying to figure it out, things seemed doomed.. I decided to contact Spark Fun for more technical info. Within an hour they answered me, was really helpful but tried to answer as much as he could and gave me a fresh set of ideas.

After going through the schematics of the board and its original firmware code, I realized that the USB board has two ATmega328 micro-controllers. As opposed to the ISP board that has only one that controls the LED and button matrix . Basically the USB board acts as an ISP board with a built in “Arduino” to control it. So the idea was to burn an Arduino bootloader onto the Master controller and just use it as an Arduino, easy I thought.

Not so much as it  turned out. I needed an AVR programmer, which of course I did not have. But fear not, to the rescue came the Arduino Mini Pro boards I got earlier, they can be rigged and used as programmers (sounds like a fun party). Furthermore, I had to do a small dirty trick to disable reset on the Mini Pro, basically put a capacitor between the Reset and Ground pins. But none of the boot loaders worked properly and I was getting desperate again. Also the board lost its USB API so I tried to re-compile and restore its original firmware.  And so it struck me, why not just modify the existing firmware to send midi data directly whenever a button is pressed and also light up that button. Of course this would be the optimal solution as I would not need a driver application to run the whole thing, just route the MIDI traffic through to my applications.

After more than 5 days of less than 3 hours sleep per day, endless testing, trial by error and just aimlessly poking around I finally get a MIDI signal and a led on! Victory! The firmware still needs a lot of optimization but at least now I know I’m on the correct track, and can finally get a good night’s sleep without commands and diagrams on my mind!

Next step for my project, were the Button Pad Controllers. There are two boards, SPI slave board, and a USB master board with USB API. Should be straight forward, or so I thought..

The USB board had two JST connectors, one for the USB cable and one for 5V Power. To make my life slightly easier, I also got a USB breakout board and finding out which was the right way to solder the cables was matter of reading through the product comments since it was not documented.

With the board oriented with the LEDs down, and the ICs facing up, turn it so that the USB JST connector is on the left side
The pins (from top to bottom) are:
USB Data -
Vcc
Gnd
USB Data +

Now the tricky part was that each board had to be individually configured for the number of boards in the whole system, for the USB, big deal, just send $0302\r over serial and job done. Now the SPI board is a different story. The documentation showed a waveform diagram of signals it had to receive to activate the command mode. After blankly staring at it for a while, I finally realized that it showed the bit sequence, 1 followed by 0×01 which is the set board command followed by 0×02 which is the command parameter ( in this case 2 boards)But the bits had to be sent in Least Significant Bit First order.

After aimlessly looking for more specific documentation or code examples, I started poking around with Arduino’s SPI library and shiftOut() command and successfully came up with this:

#define CS 10
#define MISO 12
#define SCK 13

void setup()
{
  pinMode(CS, OUTPUT);
  pinMode(MISO, OUTPUT);
  pinMode(SCK, OUTPUT);
  digitalWrite(CS, LOW); 

  delayMicroseconds(10);
  shiftOut(MISO,SCK,LSBFIRST,0b01);
  shiftOut(MISO,SCK,MSBFIRST,0b10000000);
  shiftOut(MISO,SCK,MSBFIRST,0b01000000);
}  

void loop(){
}

Now the actual USB API is quite generic, and not very usefully in my purpose. The device just sits there doing nothing, waiting for a command. So you have to manually call for buttons status and manually set led colors by sending different commands and it again, every time it would return the buttons status. Now this created a great deal of latency.. I made a Processing sketch to drive the whole thing, but it is slow, by slow I mean SLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOW…

The idea was to analize the receiving button status, send back a set color command to light up the pressed button, and then transform the parameters into MIDI data and forward it to the virtual MIDI port. Here is how all this worked out:

Part II: