SparkFun Electronics - Button Pad Controller SPI

Products

Product Info

Button Pad Controller SPI

sku: WIG-09022

Description: The Button Pad Controller SPI was designed to compliment the Button Pad Controller USB; though it can also be used as a standalone device. The board is 4”x4” and has 16 tri-color LEDs and 16 corresponding button pads (i.e. The button pad surrounds the LED). The boards communicate via an SPI bus, and up to 10 Button Pad Controllers can be connected in a system (including one Button Pad Controller USB). The default firmware uses a 24 bit color scheme. Each board comes configured to work as a standalone unit and must be reconfigured for multiple board systems.

We do not sell the frames shown in the photograph. We put those together for our own use as a demonstration of what two units look like, boxed up together.

Unit comes fully assembled and tested as shown. Unit does not include top button pad (listed below).

Note: We're using new RGB LEDs which have the blue and green pins swapped. When setting the LED color, you'll need to swap the blue and green values in the command structure. Visually, nothing on the board has changed.

Documents:

Pricing

	15 in stock backorder allowed

$39.95	price
$35.96	10-99 (10% off)
$31.96	100+ (20% off)

	quantity

click on image to enlarge

Comments

13 comments

Log in to post comments.

	by Applekid +2.3 \| February 6, 2009 at 3:11 PM 0
This looks way cool... I don't see a bunch of diodes on it... does it have the same kind of ghosting protection that the Button Pad 4x4 - Breakout PCB has?

	by Bandtank +6.5 \| March 18, 2009 at 10:09 AM +0.19
If you look at the pictures, there are no diodes shown. Assuming they send what you see, these boards do not have ghosting protection.

	by Rex +1.6 \| June 4, 2009 at 12:36 AM 0
Could someone kindly post some code that'll get the SPI on ATMega 328 (on the Arduino Duemilanove) down to 50kHz or lower? As it stands, the ATMega's SPI's slowest speed is 250kHz (five times the max speed of the button pad controller), so if you're planning on getting one of these suckers for use with an Arduino master, I'd suggest you find a fix before dropping 40 American dollars on it...

rgm

+1.9

| January 26, 2010 at 7:45 PM

The slowest the 16 MHz Arduino hardware SPI can go is 125KHz (16MHz / 128). You could figure out how to clock it differently or use an 8MHz Arduino, with the SPI clock / 128 = 62.5 KHz, maybe this is close enough. To set the divider to 128, set bits 0 and 1 of the SPCR register (SPR1 and SPR0) to 1.

I wish these things could do faster SPI. I'm hopeful that since ryowens84 has updated the LED matrix backpack for faster SPI, that this hardware (and software!) will get some love soon.

	by Rex +1.6 \| June 5, 2009 at 7:16 AM +0.15
Word of advice - to get this to work with an Arduino, you will likely have to hand-code an SPI protocol. Luckily, the timing diagram on the User Guide above is very helpful! Here's a video of the board in action. http://www.youtube.com/watch?v=SguUqEBonNg

	by buttons +1.5 \| June 7, 2009 at 9:50 PM 0
Hi Rex, Can you post the code you used to get the SPI->Arduino function to work properly?

Bandtank

+6.5

| July 5, 2009 at 12:21 AM

Just an FYI to anyone using their firmware - it is not 24 bit color. All you get from this firmware is the equivalent of 9 bit color. COLOR_DEPTH is defined as 7 which allows only 8 possible color values per color (0-7, anything greater than or equal to 7 behaves the same way). Since 8 is 2^3, the total bit depth is 9, not 24.

Here is the relevant snippet of code:

if(row == 0) frame_num = (frame_num + 1) & (COLOR_DEPTH);

frame_num can never be greater than COLOR_DEPTH which I already showed is defined as 7.

Therefore, this line inhibits true 8 bit depth per color:

if(greenf[LED] > frame_num) lineByte |= (1 << (column + GREEN_POS));

The values of each individual LED are stored in greenf[] and should be able to vary from 0 to 255 for true 8 bit color. However, frame_num can never be greater than 7 as I showed earlier, so any value of greenf[] greater than frame_num is treated exactly the same - maximum brightness. Values between 0 and 7 are truly different, but setting any element of any of the color arrays to a value greater than 7 will yield the exact same brightness.

The firmware is capable of 24 bit color, but not the way it is currently presented. Either the define needs to be changed or the description needs to say 9 bit color.

	by BobJones +2.1 \| July 7, 2009 at 11:24 AM 0
What's the limiting factor that prevents you from using more than 10 button pads together?

Bandtank

+6.5

| August 11, 2009 at 6:21 AM

I have no idea why they say 10 either. This line of code is directly from their firmware:

if(NUMBER_OF_BOARDS == 0 || NUMBER_OF_BOARDS > 16)
NUMBER_OF_BOARDS = 1;

I also gave a quick glance over the algorithm and there is nothing limiting this to just 10 (or 16) except that line. It could be a function of speed as the main loops are somewhat clunky, but the hardware should be able to support it unless they've got something else limiting it that I didn't see.

One other thing - it's not a good programming practice to write variables as all caps. That is universally accepted as the form of a #define.

	by nezoomie +1.2 \| August 25, 2009 at 12:47 AM 0
This board, and the USB one, DOES NOT support multiple presses on the same column. Sparkfun Tech Support is not completely sure, but seems to be an hardware problem.

	by wcbri21 +2.4 \| September 30, 2009 at 0:06 AM 0
Shouldn't the diodes have series resistors to control the amount of current they will draw?

	by ryowens84 \| September 30, 2009 at 9:26 AM
Well, you're correct in that the current needs to be limited to the LEDs somehow. Rather than doing this with LEDs, though, we use pulse width modulation to light the LEDs so that the average current is still low.