TLC5925 driving different V_f and I_f LEDs

[okw]

I want to control two different types of LED with a single TLC5925. The red LED has V_f=2.04V and I_f=15mA, while the green has V_f=2.9V and I_f 5mA.
The TLC5925 has an external resistor that controls the constant current output for all 16 channels.

I'm driving 2 red in series from 4.5V (3x AA batteries) pr. channel. Might be a stretch since V_f will be total 4.08V? I don't know how to calculate the drop through the TLC5925.
For the green LEDs I'm driving 2 in parallell from 3V (picking up 3V between 2 of the 3 AA batteries) with a single shared 160R drop resistor. Which I think should be OK?
I will drive 4 channels with red and 6 channels with green. 6 channels unused.

The problem is to ensure proper 5mA for the green and 15mA for the red, since the TLC5925 gives a constant current on all channels. Would I select the external resistor for 15mA output? Then one parallell resistor with the green 5mA LEDs for each green channel? It will of course waste some energy, but if that works, I'm ok. This is only going to be a demo board for short use (5-10 min maybe).
Unless there are more elegant solutions?

[Zero999]

The TLC5925 will output 3mA, with its output voltage <0.6V and 18V, with its output voltage <1V. In other words, if you want to drive an LED, at 18mA, from a 3V supply, the maximum forward voltage it can have, before the current falls below 18mA, is 2V.

Unfortunately the TLC5925 drives all of the LEDs with the same current. A parallel resistor will reduce the current, but you could also connect two outputs in parallel for double the current.

Driving two green LEDs in parallel will result in half the current through each of them, so 2.5mA, rather than 5mA.

Why not use higher quality red LEDs, which don't need so much current, to be really bright?

Why not power the green LEDs from 4.5V? It's generally a bad idea to unevenly discharge batteries.

[okw]

Why not use higher quality red LEDs, which don't need so much current, to be really bright?

These were the ones I had. Today I received some red 1210, which was quite bright at 8-10mA with 2V. I'll use these.

Why not power the green LEDs from 4.5V? It's generally a bad idea to unevenly discharge batteries.

The larger drop will dissipate more heat? Which will drain the battery more?

[Zero999]

Why not use higher quality red LEDs, which don't need so much current, to be really bright?

These were the ones I had. Today I received some red 1210, which was quite bright at 8-10mA with 2V. I'll use these.

Why not power the green LEDs from 4.5V? It's generally a bad idea to unevenly discharge batteries.

The larger drop will dissipate more heat? Which will drain the battery more?

But with a lower voltage there's less headroom and iIt's generally bad practise to design a circuit which drains the batteries at different rates.

[okw]

I have two problems and one question. I assembled the PCB with one (out of three) TCL5925, just to test as they are out of stock everywhere. It works fine. I haven't completely figured out the communication yet, but I can light up LEDs (in quite random order, although I send a counting 16 bit stream (loop). This is what I send:

Code: [Select]

digitalWrite(OE, HIGH); //turns off output (prevent flickering while receiving data, not sure if needed?)
digitalWrite(LE, LOW); //unnecessary, just to make sure..

uint16_t value = 10; //For example 10. It is probably here I need to examine which values correspond with each LED being on or off.

//clocks in value, bit for bit:
for (uint8_t b = 0; b < 16; b++) {
  if ((value & 0x01) == 0x01) {
    digitalWrite(MOSI, HIGH);
  }
  else {
    digitalWrite(MOSI, LOW);
  }
  digitalWrite(SCK, HIGH);
  digitalWrite(SCK, LOW);
  value = value >> 1;
}
digitalWrite(LE, HIGH);
digitalWrite(LE, LOW);
digitalWrite(OE, LOW);

I initially thought it would be a 16 bit stream, where each bit corresponded to each output, high or low. But I did not get the desired output when trying.
Anyone have some tips?


Second problem is, once I solder in the second TCL5925, programming the Atmega328p fails (I use STK600). It goes between these two failures:

Code: [Select]

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: Unknown status 0x00

And:

Code: [Select]

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: RST fail

Both ends with this:

Code: [Select]

avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATmega328P is 1E 95 0F

Pulling off the second TLF5925, and it programs again.

I didn't realize SDO is only used for pushing data to the next TCL5925, so I routed them as I do with all SPI devices. I can't tell from the datasheet, does SDO push every FIFO bit out, from the moment the shift register is full (reached 16 bits)? Could this be messing up the programming? Should I cut these traces?

I also forgot in the original design to add RC on reset pin. I added a 10k pull-up, without any programming success. I'll also get a 22pF (or any other suggestion). But this would only help if noise was the problem?

My third is a question. I made a 500ms loop blinking each LED. Works fine with ISCP connected to STK600. However, when I unplug and run on AAbatteries, the blinking interval decreases dramatically.  Fuses are (E:FD, H:DA, L:E2).
But that shouldn't matter, since the ICSP doesn't provide a clock or similar when idle? Voltage is about 3.28V both with STK600 and without (only AA-batteries). What could be happening here?