To see if this chip will work for my application I picked up the DC2254A-A evaluation board.

Here is the datasheet for the evaluation board.

For my use case, I am going to pull ONMAX to GND which will disable the timer that turns off the AWAKE timer. I will toggle the Sleep pin from low to high to low to reset the timer.

Seems to work!

The schematic is fairly simple as its just to show a typical layout of for the Propeller. The part number for the crystal is a 6MHz which will run the Propeller at 96MHz. It is a common HC-49/US package so the standard 5MHz type crystal can be used with this layout.

I made a special footprint that can use both the P8X32A-Q44 and P8X32A-M44. This way a part shortage on either package won’t hurt production. I made sure to leave plenty of room around the chip and supporting circuitry for easy fanout of the I/O. Just make sure to route away from the X0 and X1 crystal I/O to reduce EMF.

Files can be found on the GitHub repository and the footprint itself can be found in the my Eagle Library.

What if more power and current are needed though? Page 9 and 10 of the datasheet shows that a NPN transistor like a 2n2904 can be used to increase the current sinking capacity. This is all good unless you need even more power. N-type mosfets can be gated to the outputs of the WS2801 in a similar fashion.

Above is an example schematic on how to connect the mosfets to a pair of WS2801 chips. The polarity pin (POL pin3) is pulled down to put the WS2801 into driving mode. The feedback pins (XFB pin4,5,6) are pulled to ground putting the driver in constant voltage driving mode. Pull up resistors are needed on the mosfet gates as the outputs of the WS2801 are open-drain gates.

Demo layout of the dual WS2801 schematic. The WS2801 chip is a really nice chip to layout as the pinout is well thought out. Because two power sources are used (3.3V and voltage for the LEDs) the grounds must be connected to give the same reference voltage. A zero ohm resistor at R7 is used to connect these two grounds. A ferrite bead could be used here as well to reduce noise crossover if the high voltage LED power source is noisy.

The high power LEDs should be connected to the mosfet drain through a current limiting resistor. Multiple LEDs can be connected together serially if the supply voltage is high enough. The voltage drop across the mosfets can be generally ignored as the resistance is usually around .2ohms for low resistance series (RSon) mosfets.

R1 = (V_LED - (V_F x N))/ I

Where
R1 = Resistor value
V_LED = High voltage LED source
V_F = Forward voltage of the LEDs
N = Number of LEDs
I = Forward current of LEDs

Also you have to make sure your resistors are large enough to handle the current load.

RW = (V_LED - (V_F x N)) x I

Where
RW = Resistor watt rating
V_LED = High voltage LED source
V_F = Forward voltage of the LEDs
N = Number of LEDs
I = Forward current of LEDs

For example the OVSPRGBCR4 RGB LED will be used. The source voltage will be 24V and 7 LEDs will be chained together. The forward current (If) of all 3 channels is 250mA. The forward voltage (Vf) of the red channel is 2.3V and the Vf of the green and blue channel is 3.4V.

RED:
(24V - (2.3V x 7))/ .25A = 31.6ohms
(24V - (2.3V x 7)) x .25A = 1.975W

GREEN & BLUE:
(24V - (3.4V x 7))/ .25 = .8ohms
(24V - (3.4V x 7)) x .25A = .05W

Finding a resister to work with the Green and Blue channels of the LED is fairly easy but the Red channel is a bit difficult due to the high power rating needed. A quick look on mouser yields limited selection of 32ohm resistors in a big enough size to handle 2W but two 16ohm 1W resistors in series would work just as well and are much easier to find.

I am using this method to drive banks of RGB LEDs on the PinHeck Pinball System for general cabinet illumination. The Eagle files of the schematics and board layout are on GitHub. I also have some demo SPIN code for the Parallax Propeller chip to drive the WS2801 that I wrote awhile back.

The advantage of the FIFO allows the MSP430 to push that data into the FIFO as fast as it can and let the hardware UART do the rest of the job. This frees up the CPU to do allot more stuff. The only bad thing is that if the FIFO gets full you start loosing data. The code has a global flag to let the main code know that the FIFOs are full.

The Receive (RX) portions of the code also have a global mailbox flag to notify the rest of the code that the UART received something. This would be useful if you need to send commands to a robot or device.

There are 4 different flavors of the code.

1. RX TX
2. RX TX with a FIFO
3. TX only
4. TX only with a FIFO

The code without the FIFOs waits on the UART during the transmission but uses far less memory then the FIFO code. You have to sacrifice speed or memory on this one. The TX only code strips out the RX portions if you just want to have the msp-430 print to a terminal. This is useful for debugging purposes.

If you are going to use this on the MSP-430 LaunchPad then you will need to cross the RX and TX lines. This pdf I found on the internet explains on page 3 (step 6) what I am talking about.

RX TX UART Code (CCS V5)
Project File
main.c
uart.c
uart.h

RX TX UART FIFO Code (CCS V5)
Project File
main.c
uart_fifo.c
uart_fifo.h

TX UART Code (CCS V5)
Project File
main.c
uart_tx.c
uart_tx.h

TX UART FIFO Code (CCS V5)
Project File
main.c
uart_fifo_tx.c
uart_fifo_tx.h

FIFO Code (CCS V5)
Project File
fifo_.c
fifo.h

The idea would be to have the WS2801 PWM a set of mosfets which would in turn be connected to the string of LEDs. This way you could light up a bunch of RGB LEDs without allot of CPU time taken from the Propeller. The Propeller only has to mess with the WS2801 when it needs to change the PWM signals.

Where to buy the WS2801.
Demo Driver