Jump to content
greeeg

RGB 4x4 button thing

Recommended Posts

It's been awhile since I've done a proper project, mainly been doing alot of tinkering.

 

But I have a new project that I'd like to share. I wanted to make something like sparkfuns 2x2 Simon game. but using adafruits 4x4 silicone buttons.

Ofcourse adafruit sell a breakout board with an i2c keypad scanner/single colour led driver.

 

I thought how hard is it to replicate that design, but add SMD RGB LEDs under each button!! Now this is still a work in progress.

Here is the schematic, there isn't too much to the design. Just a MSP430F55xx 64QFN and a TLC5955 48 channel 16bit LED driver.

Because I'm using such a large MSP, I trashed a keypad multiplexing idea and went straight for direct. the same with the LEDs.

post-274-0-05093600-1434263275_thumb.png

 

The board isn't very fancy either. This was my first board with kicad, moved from altium. (I needed to make the change sometime, will not be able to afford a non-student license)

post-274-0-36166100-1434263363_thumb.png

 

I haven't doe any software for this project. and this is the first USB project I've ever made. So progress might be slow. but I'm interested if you guys have ideas for this platform.

 

I'm not sure if the stock USB bootloader can be called from software? I know that the ezFET does this, but they use custom BSL code, which I might need to look into.

I have a fair bit of leftovers and might consider placing some boards on tindie, the only downside is that the two ICs are expensive and practically double the BOM.

 

----Edit----

TLC5955, not TLC5595

Share this post


Link to post
Share on other sites

I really like working with the MSP430F550x. The ones without ADC (5500, 01, 02 and 03) are 10-20% cheaper than their equivalents with ADC. E.g the 5501 instead of 5508, though only available as QFN48.
 
As for BSL: Yes, you can enter BSL mode programmatically with this bit of code: (using MSPware driverlib and usblib)

void start_usb_boot_loader(void)
{
    typedef void (* __data16 functionpointer)(void);
    const functionpointer bsloader = (functionpointer)(0x1000);
    USB_disconnect();
    USB_disable();
    SYSBSLC &= ~(SYSBSLPE);
    __disable_interrupt();
    bsloader();          // won't return
}

Works well for my purposes. But it does not work reliably with some USB hubs which seem to power-cycle the device, i.e. reset the MCU. Maybe the USB_disconnect/disable lines are unnecessary, but I didn't bother to debug that yet. Just break out the pins to connect an ezFET in case you're stuck :)

 

Also of note is, that new chips automatically go into BSL on power-up. That's very convenient to program them over USB.

 

For programming I use the BSL_USB_GUI windows client. I find it more convenient than the Python and Java clients that come with usblib (also fewer dependencies, just an EXE and a DLL to distribute). The VisualStudio project looks simple enough to modify if one wants to reduce the number of clicks and/or include some automatic test procedures after flashing the firmware. You can find the client and source code in this package: http://www.ti.com/tool/msp430usbdevpack

 

I never got the open source msp430-usbbsl command line tool working. Looks like a half-finished project that was abandoned once it worked for a specific MCU and hex file format.

 

Hope this gets you started. Let me know if you have any questions or want to look at my complete USB source code.

Share this post


Link to post
Share on other sites

I think I could probably get away with a MSP430F550x in QFN48. It does means new stencils and boards though. I'd like to have at least assembeled a board before I do that.

 

The board does have a tagConnect footprint, even with the USB I'd never like to design a board without an ICSP socket.

 

Thanks for the info. It should be very handy. So you make heavy use of TI's driverlib? This is the transition that is dificult for me, since I'm very much used to going to the datasheet to find register and bit names, rather than to a header file or API reference.

 

I've found mspdebug works very well, and it has a usb-bsl driver. I'll be sure to check out BSL_USB_GUI when I'm on my windows PCs.

 

Right now I am waiting for digikey to update my address, (which requires a human to review it.) before I can place an order for the parts. Boards have arrived, already spotted a small problem, should be fine, just need to appy less paste to the pad.

post-274-0-24581000-1434328373_thumb.jpg

 

 

Not really and issue for testing on my workbench but.

As for drivers, I know there is considerable cost involved with signing. which is a requirement for windows 7/8 64bit. Do you bother? or just instruct people to disable driver enforcement in order to install your device?

Share this post


Link to post
Share on other sites

re driver: the driver is just a .inf file. I instruct users to click away warnings on Win 7 and XP, and point at instructions to temporarily disable signing for Win 8. Good news is that Win 10 works without drivers.

 

I only used driverlib for setting up system clocks and for USB. Still do GPIO, SPI and UART myself.

Share this post


Link to post
Share on other sites

Quick update. Parts are on their way, but I found a bug on my schematic.

 

I'd foolishly connected one size of each button to +5v. Which will cause problems since the MSP is running at 3.3v. I wanted to re-route the board anyway. so I've changed them to connect to ground and will use input pullups.

 

Secondly I had left Vcore floating, when it is supposed to have a bypass capacitor on it. Funnily enough it seems to work without it... but would probably cause some strange bugs latter on.

 

I recieved the silicone button pads and the alignment holes were off by about 1mm. Because it's silicone stretching these alignment purtrusions works, but I'd rather a perfect fit.

post-274-0-89240100-1434440414_thumb.jpg

 

In light of these bugs I have partially assembed a board to test out the USB side of the circuit.

post-274-0-63756900-1434440148_thumb.jpg

 

Low and behold it actually works! Or atleast the bootloader enumerates.

post-274-0-81053300-1434440194_thumb.jpg

 

I'll post some renders of the new board later.

Now I can slowly pace through software while I await my new boards.

Share this post


Link to post
Share on other sites

The new board that has been designed. I tidied up alot of signals. Clumping them together to ensure a larger ground plane coverage.

 

No componets have been changed. But I added the bypass capacitor onto Vcore pin. Also enabled thermal relief for all pads, but not vias.

 

Top

post-274-0-01041600-1434860094_thumb.png

 

Bottom

post-274-0-87813700-1434860115_thumb.png

 

I'm loving kicads interface. Definitly not as polished as AD. But core functionality is there. Like labeling net names on traces.

post-274-0-95830200-1434860200_thumb.png

 

It even has a 3d viewer! (not sure if gifs are supported on this forum.. but this was a gif)

post-274-0-93711600-1434860306_thumb.gif

 

So I don't have a readme or anything fancy set up on the bitbucket page yet. But all the design files are there. If you want to have a look.

https://bitbucket.org/Greeeg/4squared

Share this post


Link to post
Share on other sites

Got a package of LEDs today. Still waiting on the 2nd revision of the board. Should arrive within a week.

 

I have 3 different LED choices. 1 from digikey. (~2x2mm)

post-274-0-22023600-1435825132_thumb.jpg

 

and two from aliexpress (0402, ~1x1mm)

post-274-0-35022200-1435825161_thumb.jpg

 

and a 0603 ~1.6x1.6mm

post-274-0-77276800-1435825222_thumb.jpg

 

Now unfortunately I messed up the footprint alittle...

post-274-0-86116300-1435825578_thumb.jpg

Not entirely my fault. but if you look at the top left numbering diagram. and the recommended footprint numbering.... they don't match.

Turns out that the LEDs I recieved do infact follow the bottom right pinout and not the top left.

 

Strangely, another "almost" identical product has a diffrent pinout diagram.

post-274-0-18572500-1435825331_thumb.jpg

 

 

They'll still work, just need to be soldered at 90 degrees.

Share this post


Link to post
Share on other sites

Started looking into a enclosure for this project. ( Typically this would be done before designing the PCB.... )

But I'd like to make use of some of the rapid prototyping tools I've invested in.

 

Something I should have done before sending the board off to the fab.. Verified that the holes lined up. (they didn't on board version 1)

By exporting a copper layer as a dxf or svg, you can then import your PCB into your favorite CAD tool. Luckily Adafruit provide the 3d CAD file for the rubber elastomer buttons.

post-274-0-91153100-1436330983_thumb.png

post-274-0-39147300-1436331033_thumb.png

 

Good to see that everything lines up. Next step is a simple 2 part case.

Share this post


Link to post
Share on other sites

Received the new set of board. this one won't connect 5v to the I/O pins of the micro when you press a button. :)

Decived to place silkscreen UNDER my QFN chips.... Could be worse I guess.

post-274-0-07356400-1436530117_thumb.jpg

My design files didn't contain this silkscreen..... But I guess it kinda makes it look better... (I'll get onto emailing smart prototypes, see if they have any insight about this)

post-274-0-16523900-1436530154_thumb.jpg

 

Decided to solder one up straight away.

post-274-0-25181500-1436530307_thumb.jpg

 

Need to improve my solder paste applicator technique ( I did a new board with better results. and cleaned this board off to do later.)

post-274-0-52099900-1436530355_thumb.jpg

 

Before reflow. After the board went through my manual pick and place (i.e. me + tweezers)

post-274-0-36475900-1436530418_thumb.jpg

 

I remembered to solder down the USB post this time before plugging it in, so the connector didn't fall off. Board shows up in DFU mode by default. Which is a great initial sign of life test.

 

Now to tackle the TLC5955, Writing the driver for this will be my first software milestone.

 

 

Share this post


Link to post
Share on other sites

I've written some demo software. Hit a few roadblocks due to laziness. i.e. thinking SOUT was MOSI on my schematic instead of MISO. (Should have just used MOSI/MISO as net names...)

 

I've written some demo code, and got the LEDs up and running. lots of tweaking need to optimize the software. But I'm glad it's actually working at this point in time.

 

My TLC5955 "library" consists of the following interface if anyone is interested. and it's been added to the git repository for the project.

void dma_init( void );

/* Transfer 96 bytes, 768 bits */
void tlc5955_xmit_common( void );

/* transfer latch select bit */
void tlc5955_xmit_latch_bit( bool );

/* insert bit stream segment, of [width] from [input_data] into main bitstream [array] at [offset] */
void tlc5955_byte_insert( unsigned int* array, unsigned int width, unsigned int input_data, unsigned int bit_offset );

/* initilise MSP430 end of communications */
void tlc5955_port_init( void );

/* setupt internal registers of tlc5955 */
void tlc5955_internal_init( void );

/* set pixel i, to [r,g,b] value */
void tlc5955_set_pixel(  unsigned int idx, unsigned int r,  unsigned int g,  unsigned int b );

/* Enable GSCLK oscilator */
void tlc5955_enable_gsclk( void );
/* Disable GSCLK oscilator */
void tlc5955_disable_gsclk( void );

void tlc5955_clear_array( void );
void tlc5955_toggle_latch( void );

Some config registers are 3 or 5 or 7 bits long, but need to be placed in a continuous bitstream style array. (internally the TLC5955 has a 769 bit shift register for input data) That's where

tlc5955_byte_insert();

is used.

 

I've kept everything 16bit, since it will be more efficient for the MSP430. I'm not currently using the DMA or USCI, that is the logical next step to improve performance. I went with a SW implementation to ensure everything followed along with the datasheet's timing diagrams. To ensure that my HW was setup correctly.

 

Share this post


Link to post
Share on other sites

Built a second prototype to test out the smaller 0404 LEDs. I thought they might have better colour blending because the LED dies are closer. But the silicone buttons already do alot of that. They don't appear to make much difference.

post-274-0-68645000-1436831732_thumb.jpg

The LED dies are of similar sizes, so the 0606 size is the same brightness of the 0404.

post-274-0-55088300-1436832171_thumb.jpg

post-274-0-74033800-1436832215_thumb.jpg

At the brightness I'm running at makes the TLC a little warm, but not too much. On the next PCB rev I'll add some thermal vias on the TLC's exposed thermal pad.

post-274-0-63045500-1436832303_thumb.jpg

Share this post


Link to post
Share on other sites

Really nice project !

How did the conductivity of the buttons work out ? - I noticed that you used a slightly different pattern for your "zigzags" on the PCB.
(Did you try silver? - From what I've heard silver continues to conduct after oxidation.)

I was also wondering, how this project continued. Did you manage to build a case ?
Other people who did similar projects, also designed custom silicone button pads. - Did you ?
You don't happen to have the coordinates of a supplier of affordable custom silicone buttons, do you ? :)

How many PCB layers did you need ?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×