Daisy-chaining 7 IC's

A stripboard isn't an option, mostly cuz I really don't get how to use one.

So I rebuild things from scratch again. Before building I used a multimeter to make sure the buses in the breadboards weren't touching. I also made sure the wire I was using worked. Everything passed.

I wrote tests meant to bring out the usual bug I see when I switch LED's on and off real fast, and tested every time I added an IC. The first 4 went fine, 5th exhibited the same problem as usual.

I was dumbfounded. I even flipped the board around and tried then. No luck. Same issue.

At this point I figure there's only one solution: The datasheet for tlc5940's say they each use about 10ma on their signal pins. This means that if I add a 5th chip, stuff is likely to go wrong since the Arduino can only send 40ma per I/O pin. I really think this is the source of my issue, and I have for a while now but people kept shooting it down. Really though, what else is there left to try? The 5th IC even has its own private connection to ground and it's not working.

I heard there are devices called "buffers" specifically meant to help in situations just like mine -- Too many IC's, not enough current. Where can I find them?

The datasheet for tlc5940's say they each use about 10ma on their signal pins.

That's totally unheard of in a modern chip, maybe 30 years ago with TTL but not these days.

I read the data sheet as saying 50uA max. The 10mA is for an input voltage of 22 volts, although I don't know that that's supposed to mean. Maybe to test latch up or something. EDIT: Looks like something to do with EEPROM programming.

I heard there are devices called "buffers" ... Where can I find them?

Search for "line buffer ic" or "line driver ic", but I really can't see that being the problem although I admit it's baffling.

How fast are you clocking the chips and how long is the clock wire? Does the clock wire daisy-chain from one chip to the next?


Rob

I have no idea how fast I'm clocking them. The library I'm using claims it's almost at 1 ghz, but people tell me I'm wrong. Nobody ever told me /why/, though..

Part of the source code in the library is as follows:

/** Determines how long each PWM period should be, in clocks.
    \f$\displaystyle f_{PWM} = \frac{f_{osc}}{2 * TLC\_PWM\_PERIOD} Hz \f$
    \f$\displaystyle TLC\_PWM\_PERIOD = \frac{f_{osc}}{2 * f_{PWM}} \f$
    This is related to TLC_GSCLK_PERIOD:
    \f$\displaystyle TLC\_PWM\_PERIOD =
       \frac{(TLC\_GSCLK\_PERIOD + 1) * 4096}{2} \f$
    \note The default of 8192 means the PWM frequency is 976.5625Hz */
#define TLC_PWM_PERIOD    8192

You can poke at the library here, Google Code Archive - Long-term storage for Google Code Project Hosting. , or download it directly over yonder: Google Code Archive - Long-term storage for Google Code Project Hosting. . The file with that code is "tlc_config.h".

I thought about using transistors. 2N2222 claims to only run up to 300 mhz but I tried it anyway. None of the IC's worked. All LED's just stayed off when the Arduino got turned on. That made me pretty sure they're too slow, but people say I'm wrong. Like I said, nobody's explained /why/..

The library warns not to use analogWrite() on some pins, and requires the use of PWM on a few pins. I'm pretty sure this means there's some wicked fast switching going on.

All five wires required to control the tlc5940's are daisy-chained to each other, with an exception. They work sort of like shift registers so there's a Serial Input and a Serial Output pin. Those aren't /technically/ daisy-chained depending how you look at it. The ground and VCC lines are a bus, but not the data lines. The chain begins with a 12 inch stranded-core wire. The rest are about 6-7 inches long, solid-core.

"I have no idea how fast I'm clocking them. "
It can't be any faster than 16 MHz as that is the processor speed.

And the clock line is from the SPI SCK line, so that's 8 MHz max.

Well, I knew that, but I figured "Somewhere between 0 and 16 mhz" wasn't very helpful.

This might be: Under "normal" circumstances I'm sending 20 events a second, and each event has 128 parameters. I still don't know how fast that is exactly but it's a start.

So slow it down to 10 events a second, if things suddenly dramatically improve then you know you have too much going on.
You have to send out 192s/device * 7 devices = 1344 bits of data.
Say the SPI clock was running at 1/4 speed, or 4 MHz. Then each bit takes 250uS x 1344 bits = 0.336mS
You are sending data out 20 times/second, or 50mS. So there's 49.6 mS for the code to do whatever it does, which seems like a lot of time.

Just tried that. Even at 1 event per second it's not working properly. Most of the LED's respond properly but a few scattered over the entire display (not just one chip anymore) don't listen. Weirder yet, they switch even when I don't tell them anything. LED's aren't flickering; they're just randomly deciding to change state. I'm not touching the wires or anything. It just happens.

I'm pretty sure it's not a clocking issue. The library supports "infinite" tlc5940's chained together. I think the speed limit is set within the library so even if I tried to send more than they can handle it wouldn't happen. On top of that, they have 30 mhz clocks. Finally, the events are not evenly spaces. They're sent as fast as the library will allow. What I'm getting at is, if it was a clock issue, it'd have been showing its self when I added the first chip.

I'm thinking about the speed of transmission as well, if it is 8MHz maybe that's too fast for the long wires and breadboards or whatever you are using.

You can lower the speed of the SPI port, I can't remember what register to write into but I'll have a look. Maybe someone else knows of the top of their head.

I thought about using transistors. 2N2222 claims to only run up to 300 mhz but I tried it anyway.

The 5490 is only rated at ~30MHz, so the transistor is 10x faster. Your problem was more likely the inversion caused by the transistor.

I read some of the library files, I can see no mention of 1GHz anywhere, can you point to the reference?. Anyway, trust us, there is no way on God's earth this sort of thing runs at that speed.

EDIT:

it'd have been showing its self when I added the first chip.

Not necessarily, more chips + more wires + more breadboards = more capacitance = slower clocks required.

You can send data once a week but if you send it too fast that can still be a problem.


Rob

My bad, I meant 300 hz, not mhz, for the 2N2222. Got so used to typing "mhz" that I didn't notice. My bad.

I already pointed to the reference. "\note The default of 8192 means the PWM frequency is 976.5625Hz */".

EDIT: I'd still like to try using transistors. Inversion makes sense since I have the "BLANK" line going through it. Is there a magical way to fix inversion? Do I just hang the chip up-side down? (Canned laughter here, please.)

976.5625Hz is less than 1000 Hz. Not sure how GHz came out of that.

Use 2 transistors to make non-inverting buffer.

...There I misread "hz" as "mhz". See above.

I don't have ten 2N2222's. Would it be 'kay if I mixed them with transistors of a different type that run at 150 hz? Or is that pushing things?

As your signals are relatively slow, I think mixing transistors would probably be fine.

Instead of daisy chaining control signals, you might also try feeding each one direct from the source.

I'll try getting transistors happy then, but it'd help if I knew what wires to stick where. I'm Googling stuff but it's bringing up not-so-useful results.

I can't control each IC directly. I'd need a total of 28 PWM pins to do that. (4 PWM pins per IC, 7 IC's).

No, instead of daisy chaining, make like a star-distribution from the control pin to the 7 end points.

Can't help you with the buffer, you need to look up the data sheets for your transistor and determine the base/emitter/collector. No mind readers here!

Yes, getting rid of the daisy-chained clock may help, and try adding this to your setup()

SPCR |= 3;

That should slow down the transmission speed.

But don't do both at once :slight_smile:


Rob

Ah. Okay, I can try that. I should have /just/ enough wires and a spare breadboard somewhere.. If that don't work I'll try changing the SPI's speed.

But what do I hook where? Do I stick the second transistor's collector to the first's emitter and tie the second's base to a constant +5v source?

I still doubt you need buffering at all, but I don't think it can be any clearer than Crossroad's schematic except there's no R values.


Rob

I LOVE YOU GUYS. o_o...

I thought of doing a bus/star formation earlier but thought it was a stupid idea. I guess I severely underestimated how much wires can screw with data. It works perfectly now! Even my tests that do far more than I'd ever do when sequenced with music (Just constant events, no delays anywhere) don't throw them off now! Gosh. Wow.

For future reference, what kinda wire should I be buying? Larger or smaller gauge? Solid or stranded?

Good stuff, remember you still have the option to slow the speed. That may allow you to go back to a daisy chain if that's easier to wire.

For breadboarding I use solid, for permanent I use stranded normally, I doubt the gauge matters for the data.


Rob

Stranded is easier to work with.
I use these when I prototype.
http://www.nkcelectronics.com/breadboard-jumper-wire-70pcs-pa70.html