{"id":459,"date":"2011-11-25T19:10:02","date_gmt":"2011-11-25T17:10:02","guid":{"rendered":"http:\/\/tomashg.com\/?p=459"},"modified":"2012-02-15T15:57:57","modified_gmt":"2012-02-15T13:57:57","slug":"sp-button-pad-controller-act-i-latency-is-a-biatch","status":"publish","type":"post","link":"https:\/\/tomashg.com\/?p=459","title":{"rendered":"SP Button Pad Controller ACT I (latency is a biatch)"},"content":{"rendered":"

\"\"<\/a><\/p>\n

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..<\/p>\n

The USB board had two JST connectors<\/a>, one for the USB cable and one for 5V Power. To make my life slightly easier, I also got a USB breakout board<\/a> 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.<\/p>\n

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<\/em>
\n The pins (from top to bottom) are:<\/em>
\n USB Data –<\/em>
\n Vcc<\/em>
\n Gnd<\/em>
\n USB Data +<\/em><\/p><\/blockquote>\n

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\u00a0receive\u00a0to activate the command mode. After blankly staring at it for a while, I finally realized that it showed the bit sequence, 1 followed by 0x01 which is the set board command followed by 0x02 which is the command parameter ( in this case 2 boards)But the bits had to be sent in Least Significant Bit First order.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

After\u00a0aimlessly\u00a0looking for more specific documentation or code examples, I started poking around with Arduino’s SPI library<\/a> and shiftOut()<\/a> command and successfully came up with this:<\/p>\n

#define CS 10\r\n#define MISO 12\r\n#define SCK 13\r\n\r\nvoid setup()\r\n{\r\n  pinMode(CS, OUTPUT);\r\n  pinMode(MISO, OUTPUT);\r\n  pinMode(SCK, OUTPUT);\r\n  digitalWrite(CS, LOW); \r\n\r\n  delayMicroseconds(10);\r\n  shiftOut(MISO,SCK,LSBFIRST,0b01);\r\n  shiftOut(MISO,SCK,MSBFIRST,0b10000000);\r\n  shiftOut(MISO,SCK,MSBFIRST,0b01000000);\r\n}  \r\n\r\nvoid loop(){\r\n}<\/pre>\n
 <\/p>\n
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\u00a0call 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…<\/p>\n
The idea was to\u00a0analize\u00a0the\u00a0receiving 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:<\/p>\n