next topic »

[Reply #105 on:]

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:

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...

[Reply #106 on:]

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: print(int n).  For example, Serial.print(int n) and lcd.print(int n) 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 "write(char c)" function to display one character at a time.  Now it becomes very easy to extend print to new devices: just make the write(char c) function.

analogWrite and digitalWrite are already too low level and chip dependent: there's no code that's commonly shared.

[Reply #107 on:]

Sure.

Excellent!

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

[Reply #108 on:]

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.

[Reply #109 on:]

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

[Reply #110 on:]

Shadow:
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 Tlc.set(channel, 0) = always on, Tlc.set(channel, 4095) = 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.

thoughts?

[Reply #111 on:]

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

[Reply #112 on:]

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

Check out the Fades example.

[Reply #113 on:]

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

[Reply #114 on:]

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)

[Reply #115 on:]

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)!

[Reply #116 on:]

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

Tlc5940__2009_01_26.zip

[Reply #117 on:]

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

[Reply #118 on:]

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)

[Reply #119 on:]

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