Power connections: Strange, usually those should be separate. Anyway you have to use both (the logic supply and the power supply): you don't want to supply the power stage through the weak IC internal connection (if really exists).
PNP/NPN: those transistors have the bandwidth far higher above your IC internal oscillator frequency and their delay is negligible to this application. What is the resistor setup you are using (base, base to emiter)? The LED series resisto is not relevant in this picture.
SX frequency: by changing it you cannot in any way affect the holtek pwm led output. Be sure the communication (CS,RD,WR,DATA) respect the timings.
Yes, I could not beleive it either about the LED_VDD and LED_VSS. Strange that they call out (2) LED_VDD and (1) VDD (that are all connected internally). Same for the LED_VSS and VSS pins.
As far as the transistor driver chips, I am following what I saw on the bottom of page 13 of the HT1632c datasheet. I beleive I have 2.2K resistors going into the base of the NPN chips and the current limiting resistors (either 10, 47 or 100 ohm) coming out of the collectors into the cathodes. On the PNP chips, I have 1K going into the base and 2.2K between the base and the collector (although it is not needed) to the anodes.
Tonight, I will connect my Arduino with working 2416 code to my Sure Electronics 2416 (that someone else wrote on an Arduino forum). Once this works, I will modify it for my RGB display (blue LEDs only for now) - modify for the N-MOS open drain output and 16 common option in software. If this is working correctly with an Arduino board, then I know the RGB electronics are good and it is something I need to do in my code for the SX48.
Re: "similar brightness". The differences are due to a combination of the different efficiencies with which the leds convert current to light, the higher energy of the shorter wavelengths, and the sensitivity of the eye to different wavelengths.
For the scrolling problem you should check to see how long it takes to load a pattern to the HT. Could you write a loop to continuously load a pattern to the chip and toggle an unused pin once per loop to see how long it takes?
Regarding the Vss-Vdd being connected together at the chip, are you sure they are physically connected in the chip. Typically the Vss is common and the Vdd for the logic is separate from the driver Vdd so the large current/voltage pulses from the led drivers do not affect the logic. Take a look at the data sheet for a ULN2803 or TPIC6595 to see what I mean. Wish they provided something similar for the HT1632.
Thanks for the insight about the "similar Brightness".
I'm not concerned about the scrolling problem yet as I think I can work this out with efficient code writing. I need to first see if it works well with an Arduino and then go from there with the SX48.
As far as Vss-Vdd goes, I will take a new HT1632C from the package (e.g. brand new - not soldered to the board) and check those pins with a continuity·meter.
In this schematic the power connection to the pnp emitter can be also higher than the IC led_vdd. Anyway due to internal loses the IC driver can not be able to drive the com pin high enough (equal to pnp emitter voltage) so is good to have the base to emitter resistor.
Asumption is you are supplying the power stage with 5V, led current 20mA, reference 20091118_HT1632C,_52QFP_Design.pdf and transistors datasheets.
Now the concept is to drive the pnp in saturation so you need a VBE that must be greater than VBE(on) should be a little greater than VBE(sat) and must be lower than VEBO When the pnp is conducting you should have a base voltage·(voltage drop on R2) not higher than 3.75V. Assuming a·LED load (IC) of 1.5A and a hFE of 100 (IB 15mA) that mean that the resistor should be·220(E24). This will also limit the max current on COM pins to arround 20mA which is well below the datasheet limit. For the R1 value I suggest you something between 5K and 10K. This resistor serves to be sure to switch off the pnp but if it is too low it will delay the switch on and you don't want it.
For the NPN apply the same, so assuming a LED load (IC) of 350mA a suitable value for R4 resistor should be 390(E24) ohm.
This values keep the row/com currents in the datasheet specifications (worst scenario) so no damages will occur to the IC.
For the LED series resistors: both the transistors together give you a saturation voltage VCE(sat) of 0.6V to 1.5V (depending on the load so we will take 0.8V considering the PWM) so the resistance R3=(5V - 0.8V - LEDforwardVoltageDrop)/LEDcurrent. These resistors are independend from the transistor ones. As led current you can choose a value that is the sum of the nominal and max.·(refer to led datasheet) divided by 2 to 1.5 (because you are PWMing)
I made a YouTube video with Arduino code showing the only change I make is for the change from P-MOS to N-MOS Open Drain outputs.
But first...Here is how it is suposed to run on an Arduino (runs the same on my Arduino) - didn't want to make another video if one exists to show my point (It is the 9th reply down from the top - first video post): www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1225239439
AND here is my video (Blue leds only for now -with just the 1st section of 3 (8x16) to make an end display of 24x16): www.youtube.com/watch?v=a5ljun62fr4
As you can first see, the blue LEDs move from left to right on my RGB board with Arduino - not up to down on the yellow LED 2416 with the Arduino.
Next you see some almost randomness in the patterning with skipped display rows. And you also see it running at a slower rate (like I saw on my SX48 code).
Now....what could be the cause of this? Should I just continue adding the other 2 sections of LEDs and NPN drivers and resistors and "see what happens"?
I know that every output lights up on my RGB board as I tested it manually before I soldered in the HT1632C chip. Should I take the HT1632C out and solder in a replacement?
I am assuming when you state "(runs the same on my Arduino)" that you have hooked up your Arduino to the very same display that you show in the second clip at "www.youtube.com/watch?v=a5ljun62fr4" and the blue leds light in the same pattern as in the first clip.
If that is the case then the HT1632, drive transistors, and led display are working which leaves a communications or software problem. Try writing a routine where you light one led only for about 0.5 seconds, then turn it off and do the same for the next one until all 24 blue leds have been tested.
I just looked closely at the 2416 schematic and noticed that the pins were different on their HT1632 chip design and my newer chip version using the HT1632C. WOW!!!
The HT1632 chip has 4 LED_VSS pins and no LED_VDD pins while the HT1632C chip has 2 LED_VDD and 2 LED_VSS pins at DIFFERENT pinouts between the 2 different chips! I followed the HT1632C pinouts and assumed the datasheets were updated versions. Also the older HT1632 datasheet gives a bit more information on the N-MOS and P-MOS layouts that they newer HT1632C datasheet overlooked and I had to ask their application engineers for it. I can't believe the differences.
However, even with the differences, it should function identically if the correct pins were used which I did use correctly.
This leaves more questions in my mind. See attachments for the older HT1632 datasheet (used for 2416 and 0832 boards) and the latest one HT1632C datasheet (that I used).
No...When I said it runs the same on my arduino, it was refering the the 1st video in that sentence which was for the 2416 and the Arduino. So that 1st video (Arduino with a 2416), I can run that code correctly on MY 2416 with MY Arduino.
It is when I change that 1 line of code to change the outputs from P-MOS to N-MOS (and of course wire it correctly to my RGB board), is when I see that Arduino code running incorrectly on my RGB code as I would expect it to run the same as it did on a 2416 board because at this stage in the game, my RGB board is essentially a blue LED version of a 2416 (except that I am using a HT1632C chip and not a HT1632 chip like a 2416 does).
I will try to write something (on my SX48) to turn on the LEDs 1 by 1 and see what happens.
BTW: I did take a brand new (never touched) HT1632C and did a continuity against LED_VDD pins and VDD and my meter did beep (0 ohms) AND I checked LED_VSS and VSS and got the same results of continuity.
So this proves that the these VDD and LED_VDD pins are internally connected AND VSS and LED_VSS pins are internally connected.
However, the HT1632 (used on the 2416 and 0832 boards) only has 1 VDD pin and 4 LED_VSS pin and 1 VSS pin. I couldn't get a fair test on that because the 2416 and 0832 boards have all the LED_VSS pins and VSS pin connected (which did beep for continuity as I expected). Nothing to test the VDD pin as there was only the 1 pin on the HT1632.
Tim, double check the connections to the HT1632. More than half the pins are different. Mostly row/columns shifted one position, but 4 power pins are also different. See attached.
I only used the HT1632C datasheet when I designed my PCB and I can verify that on the PCB drawing (previous post tonight - PDF). I know the connections are correct and have verified them many times. I can run the code attached over the 8x16 partial RGB board and it is running but just slower than what I would get on other code running on a 2416 board via an Arduino. I will take another video and attach in a few minutes so you can see what is happening.
I understand that the HT1632 (used on the 2416 and 0832 boards) connections are different than the HT1632C (I am using this) connections. I have checked when I laid out the traces for the board to the HT1632C. Also, even if I did wire it to the HT1632 (which I did not), it would never even work because of all of the differences and VSS issues.
I agree the HT1632C would not work if wired as the HT1632 is, so your wiring is not the cause of this problem. A bit too tired right now to puzzle out the code, but I will look at it tomorrow morning. Post any progress you might make til then.
I downloaded the utube video and took a look at a few individual frames (see attachment). Hard to tell from the video since several leds may be lit in sequence during a single frame, but there does seem to be a pattern, with the same leds being lit at the top and bottom. If you look at frames 1, 6, and 11 you will notice the same pattern of leds in rows 2-4.
Try putting a long delay (500mS) in the DRAW_IT loop and see what you get.
I can do it again tonight with 500mS. I beleive the program is cycling through the ram locations but not staying on long enough and turning off to quickly before the next ram location is coming up. It's almost like the ram is not keeping the data pattern. Perhaps I need to look into the read-modify-write command.
What is troubling me the most is that this code is based off of working·code I·wrote for the 0832 display from Sure Electronics. ·The subroutines are all the same. So there must be some difference in the timing or how it writes data to the ram addresses on the newer HT1632C as compared to the HT1632. I need to look closely at·both datasheets (HT1632 and HT1632C)·and see if anything stands out. With an initial first look I did not see anything but I need to look again.
I compared the 2 datasheets (HT1632 and HT1632C) and what stands out that could be the issue here is the missing RC Master Mode command (which is in the HT1632C but not in the HT1632). It looks like on the HT1632C, the RC command is combined with the Master Mode command (both found in the HT1632 datasheet) to have a single "RC Master Mode" command. This means in my old code for the HT1632:
SLVMD· CON $10·' CMD= 0001-00xx-x Slave Mode MSTMD· CON $14·' CMD= 0001-01xx-x Master Mode
RCCLK· CON $18·' CMD= 0001-10xx-x Use on-chip clock
EXTCLK CON $1C·' CMD= 0001-11xx-x Use external clock
The MSTMD command is used ($14) but all that was needed is now the RC MasterMode (which has the same value as the HT1632 RCCLK command of $18). So...not calling out this $18 value in a command may have given me the problems. I will have to check it out tonight and see.
Notice in my last submitted (HT1632) SX48 code it is used in the SETUP subroutine as seen below:
SUB SETUP · HIGH CS_1 ' De-select chip · COMMAND SYSDIS ' Disable system · COMMAND COMS01 ' 24*16, N-MOS drivers ·COMMAND MSTMD· ' Master Mode · COMMAND SYSON· ' System on · COMMAND LEDON· ' LEDs on · FOR addr = 0 TO 95 ··· SENDDATA addr, 0 · NEXT addr · ENDSUB
Aah! ---> What we don't see here is what would be called the RC MasterMode (or at least referenced before as RCCLK of $18).
I Think if I do the following, it may work:
rename
SLVMD· CON $10·' CMD= 0001-00xx-x Slave Mode RCMSTMD· CON $18·' CMD= 0001-10xx-x RC Master Mode RCCLK· CON $18·' CMD= 0001-10xx-x Use on-chip clock
EXTCLK CON $1C·' CMD= 0001-11xx-x Use external clock
and then use this:
SUB SETUP · HIGH CS_1 ' De-select chip · COMMAND SYSDIS ' Disable system · COMMAND COMS01 ' 24*16, N-MOS drivers ·COMMAND RCMSTMD· ' RC Master Mode · COMMAND SYSON· ' System on · COMMAND LEDON· ' LEDs on · FOR addr = 0 TO 95 ··· SENDDATA addr, 0 · NEXT addr · ENDSUB ·
That did the trick. The display is now Rock Solid and no scrolling. It knows where the "master" chip is now.
So the biggest differences in this HT1632C and the older HT1632 is that the HT1632C has more driver current (less likely to have to use driver chips on the outputs on Common Cathode LED Matrixes) AND....
It combined 2 commands into 1. Lessons learned to carefully read the datasheet even for a minor change to a part by just adding a letter like "C" on the end.
Good news indeed!
I feel comfortable to start adding the remaining LED matrixes first and test out the finished 24x16 display over the Thanksgiving day break and then add the 2nd and 3rd HT1632C chips (slaves) and control the RED and GREEN displays.
Once complete, I can start looking at how to best utilize the PWM for 16 shades of blue, 16 shades of red and 16 shades of green LEDs.
Thanks so much to everyone especially Kwinn and dMajo !!!!
Post Edited (T&E Engineer) : 11/24/2009 10:56:26 PM GMT
T&E: The other IC have only led_lss connection: it seems resonable since this is the only connection with higher current. Look at the NMOS and PMOS mode configutation: both drive a common anode led (you understand this from the position of the led series resistor - never on common path); when higher currents are required on common pins you use a transistor and the NMOS mode simplifies the external transistor wiring. You can also see that the "row" led outputs are unable to drive the pin high as on the "C" version (C works also with common cathode leds)
I am happy you have reached a good point.
If you have a scope, I suggest you to look at the base to emitter voltage and at voltage drop on base series resistor of both the npn and pnp transistors to be sure you are driving them in saturation
PS. If your scope haven't differential channel input (eg. the probe alligator wire is shorted with scope ground/earth) you should remove the earth connection from the scope and of course use only one probe. I usually do this with my scopes also on live of 240/400VAC (all analogic 2ch/40,100,200M/1Hameg,2Tektronix; no differential channels - all with 2 wire VAC power supply, earth removed; I connect earth/ground to the front panel connection when needed). The only thing you should know is that by dooing this you have your scope enclosure, if metalic, on live VAC potential so you have not to touch it when the probe is connected (if you know your instrument you know how and what measures you can do with it).
PS Sorry for posting a bit late this days, pretty busy, most times I read some threads from mobile phone and probably I am to lazy (even for sms) to use its 9keys to post. For certain things you need a PC even a blackberry/palm is not confortable.
Since I was building this circuit board up in stages, I connected the 2nd set of RGB LED displays and drivers and chips. I noticed that a couple of traces were touching and I had to do a couple of cuts to them and wire with 30 gauge wire. All is working now.
It bothers me a bit that the ExpressPCB software did not·see this as it did tell me of other traces being too close and allowed me to fix them before I placed the order online. Hopefully it will be just these 2 traces and I can redesign it for any future orders. I still·have 1 other PCB·made that I will have to cut and·solder wires to when I build it up after this board is complete and·RGB software written.
I'm thinking about if this takes off offering·this project as a kit on Gadget Gangster or something although it would be expensive (min $200-$300) and may drive some away.
Anyway, I still have the last RGB LED & driver/resistor sections to solder in tonight and then one by one the 2nd and 3rd HT1632C chips as "slaves".
After long awaiting parts to come in and "taking my time"...
Finally the 3rd time is the charm in $100's later in PCB costs and parts ... it worked.
This design uses a 24x16 common anode display that is actually converted into common cathode with the use of a couple of hundred resistors and PNP and NPN driver circuits.
It also can plug into a separate HT1632C board into 2 red IDC ports, blue IDC ports or green IDC ports. A 3rd port is used for the common anode side (which is changed into common cathode).
This way (3) of these HT1632C driver boards can control the RED, GREEN and BLUE 24x16 LEDs with 16 shades of each color. Additional cascaded 24x16 RGB display boards can be cascaded I believe also.
Also the separate 24x16 RGB board can be used with other LED drivers too besides just the HT1632C. Win - Win.
Now it is time write some test code to do simple PWM 16 shades for the red, green and blue. 4096 colors possible (16x16x16) in theory.
It looks really cool. I was looking at the design and was wondering if there was a way to simplify the build. I take it the tough part was not being able to find an rgb common cathode matrix to work with this thing.
On the low-cost side though, would it seem like this would be the way to go for a dual-color board with easier to find parts? Or am I better off getting a 'pre-assembled' board from sure-electronics? Though pwm-ability and rgb sure do look sexy.
Are you using the SX chipset for this? I wouldn't mind playing around to make a propeller based version of this.
Simplifying it would be to use Common Cathode RGB display·matrix modules·next time but I needed to use what I got since each one of the 6 RGB display matrix modules per board can run between $20 to $30 for RGB modules. Adding in the additional PNP and NPN drivers and resistors added about $60 more to the cost and more soldering but it has much more current drive which may or may not be required.
You can surely save more but going with the cheaper and smaller displays as found on the Sure Electronics 2416 and even their 0832 displays. But my design offers much larger (60 mm) RGB display matrix modules and also the fact that they have RGB for color mixing. Using bi-color display matrix modules would have been much cheaper BUT only allowed 16 shades of Red, green or combined them to make yellow. Using RGB allows for 4096 possible color combinations over the 24x16 resolution of 384 LEDs displayed.
One other factor is that the Sure Electronics displays (2416 and 0832) uses the obsolete HT1632 while my 24x16 RGB display's driver board uses the newest HT1632C for more current drive capabilty on Common Cathode LEDs. Also one of the commands is different too.
I still have to figure out how to do the master and slave part to combine a master HT1632C for 1 color with 2 slave HT1632C driver boards for the other 2 colors. I'll get it.
The 24x16 RGB display baord can be used with·ANY LED driver/controller besides the HT1632C (OR even an SX-52 micro-controller directly as the LED driver and controller - but those are obsolete now).
The HT1632C driver board can be used·with·ANY micro-controller·(SX, PIC, AVR, Propellor, etc..)
Once I get some applications thought up and write some SX-48 code, I will probably write an article for Nuts and Volts on this project.
Post Edited (T&E Engineer) : 12/24/2009 2:30:12 PM GMT
The Sure boards are cheap for the small ones. Maybe I will buy a small one first to get the code in place for the propeller, then venture forth into RGB once I have a good footing.
Now it is time write some test code to do simple PWM 16 shades for the red, green and blue. 4096 colors possible (16x16x16) in theory.
Did you ever make any progress with this? I have been looking at the spec sheet and it looks like the PWM selection can only be made for an entire chip. Is this right? I don't see a way to change the PWM of an individual row/col.
I have not worked on this too much since the SX chips became obsolete but will when I get more time. The HT1632C has PWM in only 16 shades. I think with some creative programing it may be possible but generally speaking the answer is no. Setting the PWM for the chip is done via setting a register which applies to what is currently on.
However, you may want to look into Sure Electronics Latest display board that uses 4 HT1632C chips. The 3 color (green, red, orange) 32x16 display is called 3216 RG and sell for $20-$25 depending on buying the 3mm or 5mm LEDs.
Comments
PNP/NPN: those transistors have the bandwidth far higher above your IC internal oscillator frequency and their delay is negligible to this application. What is the resistor setup you are using (base, base to emiter)? The LED series resisto is not relevant in this picture.
SX frequency: by changing it you cannot in any way affect the holtek pwm led output. Be sure the communication (CS,RD,WR,DATA) respect the timings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
As far as the transistor driver chips, I am following what I saw on the bottom of page 13 of the HT1632c datasheet. I beleive I have 2.2K resistors going into the base of the NPN chips and the current limiting resistors (either 10, 47 or 100 ohm) coming out of the collectors into the cathodes. On the PNP chips, I have 1K going into the base and 2.2K between the base and the collector (although it is not needed) to the anodes.
Tonight, I will connect my Arduino with working 2416 code to my Sure Electronics 2416 (that someone else wrote on an Arduino forum). Once this works, I will modify it for my RGB display (blue LEDs only for now) - modify for the N-MOS open drain output and 16 common option in software. If this is working correctly with an Arduino board, then I know the RGB electronics are good and it is something I need to do in my code for the SX48.
For the scrolling problem you should check to see how long it takes to load a pattern to the HT. Could you write a loop to continuously load a pattern to the chip and toggle an unused pin once per loop to see how long it takes?
Regarding the Vss-Vdd being connected together at the chip, are you sure they are physically connected in the chip. Typically the Vss is common and the Vdd for the logic is separate from the driver Vdd so the large current/voltage pulses from the led drivers do not affect the logic. Take a look at the data sheet for a ULN2803 or TPIC6595 to see what I mean. Wish they provided something similar for the HT1632.
Thanks for the insight about the "similar Brightness".
I'm not concerned about the scrolling problem yet as I think I can work this out with efficient code writing. I need to first see if it works well with an Arduino and then go from there with the SX48.
As far as Vss-Vdd goes, I will take a new HT1632C from the package (e.g. brand new - not soldered to the board) and check those pins with a continuity·meter.
Thanks again for your and dMajo's support!
More to come...
Asumption is you are supplying the power stage with 5V, led current 20mA, reference 20091118_HT1632C,_52QFP_Design.pdf and transistors datasheets.
Now the concept is to drive the pnp in saturation so you need a VBE that must be greater than VBE(on) should be a little greater than VBE(sat) and must be lower than VEBO When the pnp is conducting you should have a base voltage·(voltage drop on R2) not higher than 3.75V. Assuming a·LED load (IC) of 1.5A and a hFE of 100 (IB 15mA) that mean that the resistor should be·220(E24). This will also limit the max current on COM pins to arround 20mA which is well below the datasheet limit. For the R1 value I suggest you something between 5K and 10K. This resistor serves to be sure to switch off the pnp but if it is too low it will delay the switch on and you don't want it.
For the NPN apply the same, so assuming a LED load (IC) of 350mA a suitable value for R4 resistor should be 390(E24) ohm.
This values keep the row/com currents in the datasheet specifications (worst scenario) so no damages will occur to the IC.
For the LED series resistors: both the transistors together give you a saturation voltage VCE(sat) of 0.6V to 1.5V (depending on the load so we will take 0.8V considering the PWM) so the resistance R3=(5V - 0.8V - LEDforwardVoltageDrop)/LEDcurrent. These resistors are independend from the transistor ones. As led current you can choose a value that is the sum of the nominal and max.·(refer to led datasheet) divided by 2 to 1.5 (because you are PWMing)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
But first...Here is how it is suposed to run on an Arduino (runs the same on my Arduino) - didn't want to make another video if one exists to show my point (It is the 9th reply down from the top - first video post): www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1225239439
AND here is my video (Blue leds only for now -with just the 1st section of 3 (8x16) to make an end display of 24x16): www.youtube.com/watch?v=a5ljun62fr4
As you can first see, the blue LEDs move from left to right on my RGB board with Arduino - not up to down on the yellow LED 2416 with the Arduino.
Next you see some almost randomness in the patterning with skipped display rows. And you also see it running at a slower rate (like I saw on my SX48 code).
Now....what could be the cause of this? Should I just continue adding the other 2 sections of LEDs and NPN drivers and resistors and "see what happens"?
I know that every output lights up on my RGB board as I tested it manually before I soldered in the HT1632C chip. Should I take the HT1632C out and solder in a replacement?
Comments?
If that is the case then the HT1632, drive transistors, and led display are working which leaves a communications or software problem. Try writing a routine where you light one led only for about 0.5 seconds, then turn it off and do the same for the next one until all 24 blue leds have been tested.
The HT1632 chip has 4 LED_VSS pins and no LED_VDD pins while the HT1632C chip has 2 LED_VDD and 2 LED_VSS pins at DIFFERENT pinouts between the 2 different chips! I followed the HT1632C pinouts and assumed the datasheets were updated versions. Also the older HT1632 datasheet gives a bit more information on the N-MOS and P-MOS layouts that they newer HT1632C datasheet overlooked and I had to ask their application engineers for it. I can't believe the differences.
However, even with the differences, it should function identically if the correct pins were used which I did use correctly.
This leaves more questions in my mind. See attachments for the older HT1632 datasheet (used for 2416 and 0832 boards) and the latest one HT1632C datasheet (that I used).
No...When I said it runs the same on my arduino, it was refering the the 1st video in that sentence which was for the 2416 and the Arduino. So that 1st video (Arduino with a 2416), I can run that code correctly on MY 2416 with MY Arduino.
It is when I change that 1 line of code to change the outputs from P-MOS to N-MOS (and of course wire it correctly to my RGB board), is when I see that Arduino code running incorrectly on my RGB code as I would expect it to run the same as it did on a 2416 board because at this stage in the game, my RGB board is essentially a blue LED version of a 2416 (except that I am using a HT1632C chip and not a HT1632 chip like a 2416 does).
I will try to write something (on my SX48) to turn on the LEDs 1 by 1 and see what happens.
So this proves that the these VDD and LED_VDD pins are internally connected AND VSS and LED_VSS pins are internally connected.
However, the HT1632 (used on the 2416 and 0832 boards) only has 1 VDD pin and 4 LED_VSS pin and 1 VSS pin. I couldn't get a fair test on that because the 2416 and 0832 boards have all the LED_VSS pins and VSS pin connected (which did beep for continuity as I expected). Nothing to test the VDD pin as there was only the 1 pin on the HT1632.
SO.....
Post Edited (kwinn) : 11/24/2009 2:29:01 AM GMT
I only used the HT1632C datasheet when I designed my PCB and I can verify that on the PCB drawing (previous post tonight - PDF). I know the connections are correct and have verified them many times. I can run the code attached over the 8x16 partial RGB board and it is running but just slower than what I would get on other code running on a 2416 board via an Arduino. I will take another video and attach in a few minutes so you can see what is happening.
I understand that the HT1632 (used on the 2416 and 0832 boards) connections are different than the HT1632C (I am using this) connections. I have checked when I laid out the traces for the board to the HT1632C. Also, even if I did wire it to the HT1632 (which I did not), it would never even work because of all of the differences and VSS issues.
Here is the video that relates to the code that I just posted: www.youtube.com/watch?v=6QAr8BnurvQ
Thanks for sticking with me on this. I have checked the pins on my RGB board many times over to the HT1632C datasheet.
Thanks!
Try putting a long delay (500mS) in the DRAW_IT loop and see what you get.
I can do it again tonight with 500mS. I beleive the program is cycling through the ram locations but not staying on long enough and turning off to quickly before the next ram location is coming up. It's almost like the ram is not keeping the data pattern. Perhaps I need to look into the read-modify-write command.
What is troubling me the most is that this code is based off of working·code I·wrote for the 0832 display from Sure Electronics. ·The subroutines are all the same. So there must be some difference in the timing or how it writes data to the ram addresses on the newer HT1632C as compared to the HT1632. I need to look closely at·both datasheets (HT1632 and HT1632C)·and see if anything stands out. With an initial first look I did not see anything but I need to look again.
Thanks
I compared the 2 datasheets (HT1632 and HT1632C) and what stands out that could be the issue here is the missing RC Master Mode command (which is in the HT1632C but not in the HT1632). It looks like on the HT1632C, the RC command is combined with the Master Mode command (both found in the HT1632 datasheet) to have a single "RC Master Mode" command. This means in my old code for the HT1632:
SLVMD· CON $10·' CMD= 0001-00xx-x Slave Mode
MSTMD· CON $14·' CMD= 0001-01xx-x Master Mode
RCCLK· CON $18·' CMD= 0001-10xx-x Use on-chip clock
EXTCLK CON $1C·' CMD= 0001-11xx-x Use external clock
The MSTMD command is used ($14) but all that was needed is now the RC MasterMode (which has the same value as the HT1632 RCCLK command of $18). So...not calling out this $18 value in a command may have given me the problems. I will have to check it out tonight and see.
Notice in my last submitted (HT1632) SX48 code it is used in the SETUP subroutine as seen below:
SUB SETUP
· HIGH CS_1 ' De-select chip
· COMMAND SYSDIS ' Disable system
· COMMAND COMS01 ' 24*16, N-MOS drivers
· COMMAND MSTMD· ' Master Mode
· COMMAND SYSON· ' System on
· COMMAND LEDON· ' LEDs on
· FOR addr = 0 TO 95
··· SENDDATA addr, 0
· NEXT addr
· ENDSUB
Aah! ---> What we don't see here is what would be called the RC MasterMode (or at least referenced before as RCCLK of $18).
I Think if I do the following, it may work:
rename
SLVMD· CON $10·' CMD= 0001-00xx-x Slave Mode
RCMSTMD· CON $18·' CMD= 0001-10xx-x RC Master Mode
RCCLK· CON $18·' CMD= 0001-10xx-x Use on-chip clock
EXTCLK CON $1C·' CMD= 0001-11xx-x Use external clock
and then use this:
SUB SETUP
· HIGH CS_1 ' De-select chip
· COMMAND SYSDIS ' Disable system
· COMMAND COMS01 ' 24*16, N-MOS drivers
· COMMAND RCMSTMD· ' RC Master Mode
· COMMAND SYSON· ' System on
· COMMAND LEDON· ' LEDs on
· FOR addr = 0 TO 95
··· SENDDATA addr, 0
· NEXT addr
· ENDSUB
·
So the biggest differences in this HT1632C and the older HT1632 is that the HT1632C has more driver current (less likely to have to use driver chips on the outputs on Common Cathode LED Matrixes) AND....
It combined 2 commands into 1. Lessons learned to carefully read the datasheet even for a minor change to a part by just adding a letter like "C" on the end.
Good news indeed!
I feel comfortable to start adding the remaining LED matrixes first and test out the finished 24x16 display over the Thanksgiving day break and then add the 2nd and 3rd HT1632C chips (slaves) and control the RED and GREEN displays.
Once complete, I can start looking at how to best utilize the PWM for 16 shades of blue, 16 shades of red and 16 shades of green LEDs.
Thanks so much to everyone especially Kwinn and dMajo !!!!
Post Edited (T&E Engineer) : 11/24/2009 10:56:26 PM GMT
I am happy you have reached a good point.
If you have a scope, I suggest you to look at the base to emitter voltage and at voltage drop on base series resistor of both the npn and pnp transistors to be sure you are driving them in saturation
PS. If your scope haven't differential channel input (eg. the probe alligator wire is shorted with scope ground/earth) you should remove the earth connection from the scope and of course use only one probe. I usually do this with my scopes also on live of 240/400VAC (all analogic 2ch/40,100,200M/1Hameg,2Tektronix; no differential channels - all with 2 wire VAC power supply, earth removed; I connect earth/ground to the front panel connection when needed). The only thing you should know is that by dooing this you have your scope enclosure, if metalic, on live VAC potential so you have not to touch it when the probe is connected (if you know your instrument you know how and what measures you can do with it).
PS Sorry for posting a bit late this days, pretty busy, most times I read some threads from mobile phone and probably I am to lazy (even for sms) to use its 9keys to post. For certain things you need a PC even a blackberry/palm is not confortable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
It bothers me a bit that the ExpressPCB software did not·see this as it did tell me of other traces being too close and allowed me to fix them before I placed the order online. Hopefully it will be just these 2 traces and I can redesign it for any future orders. I still·have 1 other PCB·made that I will have to cut and·solder wires to when I build it up after this board is complete and·RGB software written.
I'm thinking about if this takes off offering·this project as a kit on Gadget Gangster or something although it would be expensive (min $200-$300) and may drive some away.
Anyway, I still have the last RGB LED & driver/resistor sections to solder in tonight and then one by one the 2nd and 3rd HT1632C chips as "slaves".
Finally the 3rd time is the charm in $100's later in PCB costs and parts ... it worked.
This design uses a 24x16 common anode display that is actually converted into common cathode with the use of a couple of hundred resistors and PNP and NPN driver circuits.
It also can plug into a separate HT1632C board into 2 red IDC ports, blue IDC ports or green IDC ports. A 3rd port is used for the common anode side (which is changed into common cathode).
This way (3) of these HT1632C driver boards can control the RED, GREEN and BLUE 24x16 LEDs with 16 shades of each color. Additional cascaded 24x16 RGB display boards can be cascaded I believe also.
Also the separate 24x16 RGB board can be used with other LED drivers too besides just the HT1632C. Win - Win.
Now it is time write some test code to do simple PWM 16 shades for the red, green and blue. 4096 colors possible (16x16x16) in theory.
More to come...
On the low-cost side though, would it seem like this would be the way to go for a dual-color board with easier to find parts? Or am I better off getting a 'pre-assembled' board from sure-electronics? Though pwm-ability and rgb sure do look sexy.
Are you using the SX chipset for this? I wouldn't mind playing around to make a propeller based version of this.
You can surely save more but going with the cheaper and smaller displays as found on the Sure Electronics 2416 and even their 0832 displays. But my design offers much larger (60 mm) RGB display matrix modules and also the fact that they have RGB for color mixing. Using bi-color display matrix modules would have been much cheaper BUT only allowed 16 shades of Red, green or combined them to make yellow. Using RGB allows for 4096 possible color combinations over the 24x16 resolution of 384 LEDs displayed.
One other factor is that the Sure Electronics displays (2416 and 0832) uses the obsolete HT1632 while my 24x16 RGB display's driver board uses the newest HT1632C for more current drive capabilty on Common Cathode LEDs. Also one of the commands is different too.
I still have to figure out how to do the master and slave part to combine a master HT1632C for 1 color with 2 slave HT1632C driver boards for the other 2 colors. I'll get it.
The 24x16 RGB display baord can be used with·ANY LED driver/controller besides the HT1632C (OR even an SX-52 micro-controller directly as the LED driver and controller - but those are obsolete now).
The HT1632C driver board can be used·with·ANY micro-controller·(SX, PIC, AVR, Propellor, etc..)
Once I get some applications thought up and write some SX-48 code, I will probably write an article for Nuts and Volts on this project.
Post Edited (T&E Engineer) : 12/24/2009 2:30:12 PM GMT
The Sure boards are cheap for the small ones. Maybe I will buy a small one first to get the code in place for the propeller, then venture forth into RGB once I have a good footing.
Did you ever make any progress with this? I have been looking at the spec sheet and it looks like the PWM selection can only be made for an entire chip. Is this right? I don't see a way to change the PWM of an individual row/col.
However, you may want to look into Sure Electronics Latest display board that uses 4 HT1632C chips. The 3 color (green, red, orange) 32x16 display is called 3216 RG and sell for $20-$25 depending on buying the 3mm or 5mm LEDs.
Tim (T&E Engineer)