The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
For the past few days I have been working with the TLC5940 PWM driver chip using 16 LEDs to illustrate the control over the PWM output. I have posted an article on my blog which discusses the initial work (there is still some expansion required). The class currently allows control of 16 LEDs and the main program implements a slow breathing algorithm as shown by this video:
http://www.youtube.com/watch?v=i-uzXx68uKU
I have attached the initial code for the Mini which implements a control basic class and demonstrates the use producing the above video.
The code and the circuit need some further work as I believe that they will benefit from the following being implemented:
- Resetting the counter when it reaches 4096. At the moment this runs on until it reaches the maximum value.
- Use the dot correction values to allow different LEDs to be used on each pin. Different LEDs have different forward currents and this can be fine tuned using the dot correction data to allow the maximum brightness to be achieved by each individual LED.
- Look at using the CS pin on the SPI interface for the BLANK signal from the Netduino Mini to the TLC5940.
- Add some error checking code to check if the TLC5940 has detected any errors.
- Link two or more TLC5940’s together.
Why blue LEDs - I have a few left over from a previous project
Mark, I must admit it's an amazing article: congrats!
Just a point about the BLANK input. It seems to me too strange that you must "count" the GSCK pulses to feed the blank. Did you try to leave the BLANK pulled to the ground?
Biggest fault of Netduino? It runs by electricity.
Mark, I must admit it's an amazing article: congrats!
Just a point about the BLANK input. It seems to me too strange that you must "count" the GSCK pulses to feed the blank. Did you try to leave the BLANK pulled to the ground?
Thanks - It's been an interesting voyage of discovery and it needed your input on the clock circuitry.
If you tie BLANK to low then the system will only act as a "one shot" display. You need to use this pin to restart the timer at the end of each PWM cycle. More information can be found in the final paragraph of page 19 of the data sheet.
Mark, are you absolutely sure about the BLANK? I mean: could you try?
If the BLANK was mandatory to reset the GS counter, it means that the formula for the brightness at page 17 is not correct. It is correct only assuming a BLANK pulse very short, but that's NOT mandatory, thus the formula should take it in account.
For instance, consider to feed the BLANK input with a perfect square wave at 1KHz, while the GSCLK is fed with a 8MHz clock. It means that the 4096-count will elapse after 512uS...
Now, upon the TI's formula, that would lead to a 100% brightness. However that's untrue, because there's no a new cycle until the BLANK starts again.
The actual brightness will not be certainly at the top.
Anyway...(anyway)...talking about the 74HC4060, it embeds an oscillator. It could be a R-C, but a crystal as well. See page 15-16 of its specs for details.
I would add for the users, that the GSCLK frequency is far from being important, thus even a quite simple R-C oscillator will be enough.
Cheers
Biggest fault of Netduino? It runs by electricity.
Mark, are you absolutely sure about the BLANK? I mean: could you try?
I don't need to try. When I was originally setting up the circuit I only set the BLANK signal to pulse once. The result is as described, the LED lit once and then went off as the counters were not being reset.
If the BLANK was mandatory to reset the GS counter, it means that the formula for the brightness at page 17 is not correct. It is correct only assuming a BLANK pulse very short, but that's NOT mandatory, thus the formula should take it in account.
You are correct that the BLANK signal can be as long or short as the designer wants it to be. The formula is correct if we assume that the designer forces the BLANK signal to happen as soon as possible and for as short a time as possible.
As noted in the first bullet point of my conclusions, this is one area where my circuit needs to be improved.
I would add for the users, that the GSCLK frequency is far from being important, thus even a quite simple R-C oscillator will be enough.
My first attempts as using this chip used a clock of 40 kHz and 78 kHz. From an LED point of view the results were not as good as using the 8 MHz clock signal. It may be that with motor circuits etc that lower clock signals are OK but I feel that the high clock is better for the LED circuit.
My first attempts as using this chip used a clock of 40 kHz and 78 kHz. From an LED point of view the results were not as good as using the 8 MHz clock signal. It may be that with motor circuits etc that lower clock signals are OK but I feel that the high clock is better for the LED circuit.
Absolutely agree on the higher frequency.
Not clear whether the oscillator used was the 74HC4060 built-in or an external one.
Anyway, I checked the Fig.12 details, and it seems the RC way cannot reach decent frequencies. So, the crystal way seems the only real solution.
At this point, I wonder whether the circuit is it worthwhile. Maybe if you design a PCB, then selling the board the users could be encouraged to use. Maybe the board could allow an optional 2nd TLC, mounted on socket.
Bah...
I'll think about it.
Cheers
Biggest fault of Netduino? It runs by electricity.
At this point, I wonder whether the circuit is it worthwhile. Maybe if you design a PCB, then selling the board the users could be encouraged to use. Maybe the board could allow an optional 2nd TLC, mounted on socket.
Interesting thought. Although the option of adding 2 TLCs to bring the count up to three would possibly be better. It would give the option of acting as a 16 RGB LED controller then.
Hey Mark,
Got all the bits now I think... for the less able of us in regards wiring things up is there any chance you could perhaps fritz the tlc with the oscillator so it is possible to easily reproduce this?
PS hows the daisy chaining going on? And is it possible to reduce the number of netduino pins used (I refer to pins 8,9,10 in your code) for example can you provide high and low logic from a shift register such as stefans bit shift example?
Thanks
Andy
Got all the bits now I think... for the less able of us in regards wiring things up is there any chance you could perhaps fritz the tlc with the oscillator so it is possible to easily reproduce this?
I'm not sure I'm going to have the time to generate a Fritzing diagram at the moment - in fact I've only managed toplay with the circuit for a couple of hours in the last week or two - Home improvements which need to be ready by Christmas.
PS hows the daisy chaining going on? And is it possible to reduce the number of netduino pins used (I refer to pins 8,9,10 in your code) for example can you provide high and low logic from
a shift register such as stefans bit shift example?
Daisy chaining works at the moment - I just need to work on dot correction and error detection.
You can reduce the number of pins with some restrictions:
- If you do not need dot correction then you can wire VPRG low and the chip will assume all serial data is greyscale data only. I'm writing the class to allow for this scenario.
- You can wire blank to the output of the counter - this will cause some interesting effects on start up but seeing as the clock is running at 8MHz then these will be brief.
- You can set BLANK to CS on the SPI interface. However, this will not save a pin as you can set the CS pin on the SPI interface to be none, so you either need a pin for BLANK or a pin for CS.
I don't see any reason why you cannot use a shift register for these pins.
Thanks for sharing, It's funny, last night I was having a discussion about this chip as I have a 10 led circuit I want to control via the net so it can eather twinkle like starts or all on at the same time (struggling to find words)
I secound a motion for a board.
Got all the bits now I think... for the less able of us in regards wiring things up is there any chance you could perhaps fritz the tlc with the oscillator so it is possible to easily reproduce this?
PS hows the daisy chaining going on? And is it possible to reduce the number of netduino pins used (I refer to pins 8,9,10 in your code) for example can you provide high and low logic from a shift register such as stefans bit shift example?
Thanks
Andy
If you feel it's above you to easily reproduce the circuit, you could use another clock source. I think you should be able to use http://www.sparkfun.com/products/9116 for this, the two clock outputs should suffice to create the clock and the blanking signal.
I believe that no discovery of fact, however trivial, can be wholly useless to the race, and that no trumpeting of falsehood, however virtuous in intent, can be anything but vicious.
-- H.L. Mencken, "What I Believe"
I have read this thread about 10 times. Unfortunately I am too new to electronics and Netduinos to fully understand what is going on here.
I have a project where I need to control around 10 RGB LEDs independently, and hopefully be able to set any color or animation on each led separately. My first round used an I2C led driver and was pretty easy to set up. Unfortunately, that i2c driver drove two LEDs at once and while I could set full power on or off in any combination, the PWM was controlled on a per *color* basis, not per channel. The I2C driver only supported four addresses, so I couldn't throw more drivers at it easily.
I looked around a bit more and decided to pick up two TLC5940s which arrived yesterday. I used the sample code here (http://tlc5490netduino.codeplex.com/), and after much mucking around I was able to get the chip wired up correctly. At this point, I'm feeling lucky that I didn't let the magic smoke out by being dumb. I can make the LEDs light up all at once, or in order, but any attempt at animating a fade is not smooth - you can see the LEDs turning on and off between cycles.
By reading this thread, and trying to follow the "Demystifying the TLC5940" ebook, I believe that I may need an external clock in order to achieve good results with this chip.
Mark, I tried to use your sample code but I am using a Netduino plus so I had to make a few changes - I hope that I wired it correctly. The Codeplex sample code has pins defined for sclk, sin, blank, xlat, vprog and gcclck, while your code only defines pins for blank, xlat, and vprg. According to the SPI section on the Netduino wiki, it looks like sin goes to pin11, and the sclk goes to pin 13. Can anyone confirm if this is correct? (I am also trying to learn the SPI interface at the same time)
There are so many different variables here, I am having trouble getting my footing. Is there a simple, cost effective way to get this to work using the Netduino itself, or a cheap oscillator? Or am I barking up the wrong tree trying to use the TLC5940 just to animate 10 RGB LEDs? In the end I need to make a few dozen of these. I am going to run a simple ethernet listener so that I can controll the LEDs over a network, but other than that the 'dunio is not going to be doing much else.
Thanks in advance for the help.
I looked around a bit more and decided to pick up two TLC5940s which arrived yesterday. I used the sample code here (http://tlc5490netduino.codeplex.com/),
-snip
By reading this thread, and trying to follow the "Demystifying the TLC5940" ebook, I believe that I may need an external clock in order to achieve good results with this chip.
Interesting - Didn't come across these - I just started by wading through the data sheet.. For those who are interested you can get the eBook here.
Mark, I tried to use your sample code but I am using a Netduino plus so I had to make a few changes - I hope that I wired it correctly. The Codeplex sample code has pins defined for sclk, sin, blank, xlat, vprog and gcclck, while your code only defines pins for blank, xlat, and vprg. According to the SPI section on the Netduino wiki, it looks like sin goes to pin11, and the sclk goes to pin 13. Can anyone confirm if this is correct? (I am also trying to learn the SPI interface at the same time)
You can find some pin out cards which I find helpful in the Wiki on the Netduino Pinout Cards page. The clock of the TLC5940 needs to be connected to the clock for the SPI interface (pin 13) and SIN on the TLC needs to be connected to MOSI (Pin 11).
The reason you do not need all of the other pins comes down to some design decisions I have made.
GSCLK - This is the greyscale clock and I have provided this with an external oscillator and so do not need this. I did this for a few reasons, firstly I wanted to take this load off of the Netduino. A few simple components will allow this circuit to be created. I initially started with an astable 555 giving me a clock of about 78KHz and this worked fine as a proof pf concept, Since then I have built a 8MHz oscillator (see this fourm thread). My second reason for providing this functionality was really the fact that I can clock higher frequencies if necessary.
In my initial version I used the CS on the SPI interface as a blank signal for the TLC. This works fine if all you want to do is send data to the TLC chip(s). There is a case which I am working on now where I need to be able to control the BLANK signal. This case is error detection. For this reason I have put the BLANK signal back in but removed the CS on the SPI interface.
Someone has suggested a cheap oscillator from SparkFun - they supply both the chip and the breakout board. I cannot comment on this board or the recommendation as I have never tried this chip.
I think what you are asking is reasonable and that this chip can do it. It's simply a case of making it work. I'm still working on my implementation at the moment so there will be some updates in the future. Not sure if you are aware but you can get a kit which allows the control of 16 RGB LEDs, it's called LED Painter in it uses three TLC5940 chips. You still need to provide the control logic and it looks like the greyscale clock. This is not a recommendation, I'm just providing this information in case it is useful.
Check out my blog posts as they may contain more information about how the project is evolving.
Hi there,
i´ve got a question concerning the clock circuit and the 74HC4060, is my understanding correct that the 74HC4060 just divides the clock signal by different values (2, 4, 8, ... 4096,....) and toggles the corresponding pins?
If so, the tlc is working for 4096 cycels and then it is stopped for 4096 cycles because BLANK is set to high for the same time!?
Therefor the LED´s are driven by a "two-stage" pwm, 1st generated by the 74HC4060 with a dutycycle of 50%, 2nd generated by the tlc according to actual greyscale data!?
To reach a higher dutycyle is it possible to throw a 74HC08 behind the 74HC4060 where the inputs of one gate are connected to the 4060-Q12 and e.g. Q9 (depending on shortest time the tlc rec. blank toggle)
Is my thinking correct?
Best Regards,
Rouven
If so, the tlc is working for 4096 cycels and then it is stopped for 4096 cycles because BLANK is set to high for the same time!?
The output from the 4060 is fed into and OR gate and the output from the OR gate is fed back into the reset pin of the 4060. This should restart the counter at zero straight away. This mean BLANK is high for a very short time. Well that is my intention anyway - please feel free to let me know if you can see an error in the design.
BTW - the reason for the OR gate is to allow the Netduino to turn off the outputs whilst the grey scale and dot correction registers are being loaded with values.
To reach a higher dutycyle is it possible to throw a 74HC08 behind the 74HC4060 where the inputs of one gate are connected to the 4060-Q12 and e.g. Q9 (depending on shortest time the tlc rec. blank toggle)
Can you please elaborate as I'm not sure what you mean.
Thanks for fast reply, Mark
Feeding back the output of the OR to the 4060 to reset it, is much better than my idea of using a AND gate (74HC08) and another pin of the 4060 to reduce time BLANK of tlc is set high.
Very good idea!
Have you already tried? Is the time BLANK is set high not to short for the tlc?
I´m really happy to find a solution for my proplem with the tlc! I tried for many times in different ways to control it with a ATMEGA feeding the GSCLK via toggling a pin by timer or directly. All attempts lead to a insufficient result. (Yes, i´m a perfectionist ) I heard about the Netduino in another forum, fascinated of coding a µc in C#, i ordered one and started to read more about it. And here i found a solution for my "old" problem... cool!!!
Unfortunately i´m on an business trip, but parts for testing are already ordered and they´ll waiting for me when i´m back at home!
Best regards,
Rouven
FANTASTIC(ish) NEWS!!!
I have done a little work resoldering the oscillator and TLC circuit and now have been able to get an LED to light.
Heres the BUT....
Currently I am having issues with a bad ground or connection on my control board so this is making my shift registers freak out a little unless I touch something on the board.
When I don't touch anything the LED just randomly flashes, when I touch something I can start to see the breathing effect the led gets brighter and dimmer, however it isn't a steady level it kind of strobes at different intesities. This is what I am currently concerned about in terms of the TLCs the ground issue is another story that I need to address.
Can anyone suggest why I am getting this flashing and how I could rectify it.
I looked at the oscillator outputs on a scope, both the Blank signal and the pin 6 output on the 74hc04.
The later produced a square wave, however I haven't worked out what to determine from this or how to read the frequency etc.
The blank signal is more like a saw tooth wave.
The TLCs output is a tight block of wave that sits within a vertical range.
Andy
Have you performed a continuity check on the circuit?
I'd be looking for all the grounds being connected. Same for the 3.3V lines. Then making sure you have good connections between the elements in the circuit, i.e. good connection between all the BLANK connections etc.
Have to checked the frequency of the BLANK pulses?
If you have an 8MHz clock divided by 4096 then you should be seeing a BLANK pulse at a frequency of about 1.9 KHz. You can make this easier to check this by reprogramming the Netduino to turn one or more of the LEDs on permanently. I'd probably just turn one on to keep the power consumption lower.
...for those that are not so experts, could we have a Fritzing schema to follow (or any equivalent mapping of the wires from Netduino to the TLC5940), NOT using an external GSCLK signal (not anyone wants to fade... maybe many want to be able to switch between different discrete predetermined levels).
I googled and find many examples using arduino, without the GSCLK set, so I would like to know if there are very simple implementations using only netduino and the chip, how to connect them, and a minimal (hence simple) sample code...
Am I asking too much? :-)))
Thanks in advance to anyone available to help...
Andrea
TLC5940.zip 2.81KB
170 downloads
) I heard about the Netduino in another forum, fascinated of coding a µc in C#, i ordered one and started to read more about it. And here i found a solution for my "old" problem... cool!!!
Unfortunately i´m on an business trip, but parts for testing are already ordered and they´ll waiting for me when i´m back at home!
Best regards,
Rouven
