Go Down

Topic: Library for TLC5940 16-channel PWM chip (Read 86573 times) previous topic - next topic


I haven't been following the discussion, but I have a philosophical question...

Would it make sense to extend existing functions like analogWrite() instead of defining a new class for specific chips?  (I may be using the wrong terms here; I'm new to C++)

So we nominally have an object called a "pin", and the current digitalWrite() and analogWrite() write to "pins", as long as they happen to be the native pins on the arduino.  Well, instead of making new objects for each chip we happen to use, how about something like:
Code: [Select]
analogWrite(int pin_num, tc5940_struct *tlc);
digialWrite(int pin_num, hc595_struct *shiftreg);

Except that doesn't seem to match what I said very closely...


The problem with "extending" functions like digitalWrite and AnalogWrite is that their functionality is very chip-dependent.

Let's look at a good example of where "extending" (I think you mean virtual) functions is beneficial: [font=Courier New]print(int n)[/font].  For example, [font=Courier New]Serial.print(int n)[/font] and [font=Courier New]lcd.print(int n)[/font] use the same underlying code to convert the integer to the human readable '12345', but to actually print '1' then '2' ..., Serial and lcd have a different "[font=Courier New]write(char c)[/font]" function to display one character at a time.  Now it becomes very easy to extend print to new devices: just make the [font=Courier New]write(char c)[/font] function.

[font=Courier New]analogWrite[/font] and [font=Courier New]digitalWrite[/font] are already too low level and chip dependent: there's no code that's commonly shared.



Excellent! :)

Thanks. It was the fading functions I was looking to use the most in my application.


Yeah...the fade function would be wonderful.

It looks like the old versions you have posted on your site don't have the fade function, either. I'd hate to use an old version of the library...plus, I'm not even sure i have it around anymore after rebuilding my workstation.


I'm a little new to this, so any suggestions on a way to get the output of these to be much higher? In the 1a range?

Thought I could use a darlington array, but the rgb led's i'm using are common anode. The only way I could get it to work was by running the output from the tlc5940 into the single emitter on the darlington array which doesn't help me much :)


Jan 26, 2009, 05:28 am Last Edit: Jan 26, 2009, 05:32 am by acleone Reason: 1
You should be able to use a darlington array (or a common anode led): put a pull-up resistor between +5V and the output pin on the tlc, then connect the output pin to whatever.  The timing will be backwards though:  always on will be 0 and always off will be 4095, eg [font=Courier New]Tlc.set(channel, 0)[/font] = always on, [font=Courier New]Tlc.set(channel, 4095)[/font] = always off.

nphillips & Mike:
Do you think you need fades longer than 67 seconds?  I'm making tlc_fades.h with:
output channel, start value, end value, duration, and start time
where duration is increments of 1.024ms and has a max of 65535 (~67 seconds) and start time is in millis()

and tlc_long_fades.h:
output channel, start value, end value, duration, and start time,
where both duration and start time is in millis()

*Edit*: I think I'll name the one with both duration and start time in millis() tlc_fades.h (less confusing), and have a tlc_short_fades.h for the people who need to save ram.



I doubt i'd need a fade anywhere near that long personally.


Ok, I haven't had a chance to test it on hardware, but here's some software that compiles:

Check out the Fades example.


67 seconds? That's a lot.

I won't say I'd "never" use a fade that long...but, never say never, yah?

What I'm doing now shouldn't be more than 1 second, I think.

Once again, you're awesome, ac! If there was an award to hand out to open source contributors, I'd hand you one ;)
But, you definitely earned your merit badge:
Open Source Contributor  ;D


Correct me if I'm wrong, but it looks like the fades automatically update themselves, yes?

In the old version, we had to do something like while(tlc.update()) in order to get them to run. This time around, it appears as though you've eliminated that.

If that's the case, what happens if I change the value for a channel that's in the middle of a fade? In other words, if I call tlc.set, will that kill the fade that's already in progress?

(I don't have my hardware in front of me, so I'm just tossing out questions that pop up in my head as I skim the code)


Yes, the new version should do everything in the background (hopefully!).  With this version, if you Tlc.set(...) a channel while a fade is running on that channel, it would assume the new value for one PWM cycle (1.024ms) and then get overridden when the fade is updated again.  Ack, I forgot tlc_deleteFade(channel)!


OK, I added a removeFade(channel) function and updated the Fades example.



Thanks for this. However, the fade example doesn't appear to do anything. The other 3 examples work fine.


Jan 27, 2009, 04:12 am Last Edit: Jan 27, 2009, 04:37 am by nphillips Reason: 1
Confirmed. I don't see anything happening, either.

I'm going to play around with it a bit more, though.

Edit: I played around with it, but I don't honestly see anything going "wrong".

random() returns long, and TLC_CHANNEL_TYPE is uint8_t, but the compiler doesn't complain about it....I'm stumped (and diving into things far beyond my skill level, too)


Ack, stupid mistake on my part.  I think I had a similar bug in tlc_animations.h.  Try this:

Go Up