Tell me more ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.
up vote 1 down vote favorite
1

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

share|improve this question

1 Answer

up vote 2 down vote

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.

share|improve this answer
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. – Kevin Vermeer Aug 3 '10 at 14:18
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? – Padu Merloti Aug 3 '10 at 23:30
BTW, I tried the above with both a pullup and pulldown on my output pin. – Padu Merloti Aug 3 '10 at 23:31
1  
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. – pingswept Aug 4 '10 at 1:15
By the way, what micro are you using? – pingswept Aug 4 '10 at 1:16
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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