1
\$\begingroup\$

First what is my final goal: to drive 24 RGB LEDS using a microcontroller connected serially to a Micrel MM5450 LED driver. It would be nice to be able to drive all of them individually (72 LEDs), but I'll settle (as I did) for multiplexing and only driving one color at time. In the case of the MM5450, I'm using 3 outputs to drive 3 transistors, one for each color.

Now here's the problem I'm having.

I'm using the PLCC44 package, which seems to show some differences from the standard text in the datasheet. For example, the datasheet refers to 35 bits of data, but the PLCC only has 34 output pins instead of 35 in the DIP.

Just to get my feet wet, I've wired 4 LEDs to output pins 1 to 4 and left the rest disconnected. I've wired VDD and VSS (no decoupling capacitors), put a 100K pot on pin 21 (brightness control) and a 1nF on that same pin as the datasheet suggests.

I tried wiring DATAENABLE to GND, to VCC and to a pulldown resistor, but it didn't work as well.

The symptoms are that after I send data using the timing as indicated in the datasheet, I get weird results. For example, if I send all bits zero, at power on, only leds 1 3 and 4 will light up. Reset the uc and then led 2 3 and 4 light up. If I send just bit one high, then led 1 and 4 light up, and then when I reset the uc leds 3 and 4 light up. Just to clarify, when I say reset, it means that I assert the reset line of the microcontroller, which starts my program again (and sent a bitstream to the led driver).

I can't see a clear pattern of what's happening here. Anybody with more experience on this chip (or a suggestion of a completely different chip that will achieve my goals) to help me?

Cheers

Edit:

Ok, did some more tests and hooked a storage scope to data and clock. Here are my findings:

Clock and data are doing exactly what I'm telling them to do. As suggested, I placed clock and data on my PORTB and the data enable on my PORTC, if that matters.

My data sequence looks like this: data: starts low data enable: starts high data sequence: 0 - [data enable low] - 1 - 34 bits of data - 0 - 0 - [data enable high]

Right now I'm working in the 10ms pulses. Since I'm using a breadboard connected to my devboard via long clip wires, I've analyzed the shape of the clock and data signals for any ringing and signal was pretty good.

From the symptoms, it seems that my bitstream is out of sync with the chip... I'm out of ideas

\$\endgroup\$
2
\$\begingroup\$

I suspect the problem is that you need to control the data enable line with the microcontroller. Set it high at reset. Then, set it low right before (more than 100 ns) you start transmitting data. After the 35 bits, bring it high again.

Also, the datasheet explains the missing 35th pin you were wondering about in Note 1 on page 1. In the MM5450, it is replaced by the data enable line.

\$\endgroup\$
  • \$\begingroup\$ This was my thought as well. See Figure 5 in the datasheet for the timing diagram. It looks like it's using a Mode 0 SPI bus (SPI Chip select = MM5450 data enable, Clock = clock, MOSI = data, and MISO = NC), so you might try using an SPI peripheral to talk to it more easily. \$\endgroup\$ – Kevin Vermeer Aug 3 '10 at 14:18
  • \$\begingroup\$ I tried that. The problem is that when I connect DE to an output pin on my uc, it is being driven by the data line. For example, if I set DATA high, it doesn't matter if I set DE high or low, it will follow DATA. From the datasheet, it seems that DE is the rail of an internal opamp that has DATA as input? Am I going crazy? \$\endgroup\$ – Padu Merloti Aug 3 '10 at 23:30
  • \$\begingroup\$ BTW, I tried the above with both a pullup and pulldown on my output pin. \$\endgroup\$ – Padu Merloti Aug 3 '10 at 23:31
  • 1
    \$\begingroup\$ Though the symbol for an opamp is indeed a triangle, I would guess that the triangle in the datasheet represents an input buffer, and the line coming in the top represents a line that enables that buffer. Given that DE and DATA are both inputs on the MM5450, I would guess that your problem lies on the microcontroller side. I'd try to get two outputs working independently on the micro, and then verify that they still work independently when you connect them to the MM5450. You're probably close-- keep at it. \$\endgroup\$ – pingswept Aug 4 '10 at 1:15
  • \$\begingroup\$ By the way, what micro are you using? \$\endgroup\$ – pingswept Aug 4 '10 at 1:16
2
\$\begingroup\$

A few things about using the MM5540 to multiplex LEDs... The data enable line really wants a pull down resistor. Powering the chip from an Arduino, I have better luck either tying it low or connecting it to a digital output and adding a resistor (1k) to ground.

The rest of the chip is designed to SINK current, not to supply voltage. Looking closely at the data sheet, OFF sets the outputs to 3V. So the diode's positive side should be on high, 3V is enough, and the anode should be on one of the output pins, where the voltage will drop in order to sink the current running through the diode.

Finally, the brightness control is also a current sink. In my hands, tying the high end of the brightness control resistor to 5V, 2k Ohms sources about 600 microamps allowing the chip to sink 12mA/diode which is about what I usually want.

\$\endgroup\$
0
\$\begingroup\$

You have to use data enable. Upon transition the serial to parallel buffer is reset. The next 35 clockbits loads data into buffer. The 35th then transfers buffer to outputs.

If you don't use data enable then it is possible to get out of sync.

Also take note off maximum operating speed. Sounds like you may be over doing it.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.