15 Channel RGB (45 LED) Color Wave Using PIC16F628A

[Chipwizard]

Here is a new project I have been working on. It is an expansion of my previous two versions of color wave. (9 RGB, and 12 RGB) The objective was to create a stand-alone full color (RGB) light array by using one microcontroller(PIC16F628A). The colors on 15 RGB LED's are created and moved across the board per desired color sequence and motion FX. The pcb layout is fairly compact and narrow. (1.25"x7.25") 15 Channels are multiplexed 5x3x3 (5x9).

I am currently working on the firmware given limited time I have and will post once finished.

Cheers
-Rom

 

[Sceadwian]

You could save a TON of I/O space on the PIC by using latches. If this is all you ever plan to do with it fine, a few latches will free up large amounts of I/O that could be used for other things.

 

[Chipwizard]

I am not sure what you mean by if that is all you want to do. You can program the PIC to do whatever you want. Any color you want with any FX you want.
If you add more chips such as latches (registers) you just eat up a lot of PCB space and still need to use a PIC to stream in the data. The simplicity of it is what I was after. (One chip does it all)
The additional use of port A4 with a switch also allows for program select option!

 

[Sceadwian]

But that one chip has no more I/O left when in use. A fast pic can do a LOT of work in a very short period of time controlling a large number of more static devices including the display with very little coding. You can drop in routines that use only a few dozen cycle here or there during each primary output cycle of the output latch update, which you can't do if you don't have an I/O to use. That increase in board space is software/hardware flexibility.

 

[be80be]

Really if you want to control a bunch of RGB leds you need to use some of them 595 that are high power rated.

Then you can blink at will

 

[Chipwizard]

You both have valid points in addressing large number of RGB LED's with minimum number of I/O. That has inspired me to do a near future project using expansion pcb boards (CMOS arrays) with 5 wire input/output for daisy chaining. In that case I could simply use a computer software and interface to control the whole thing. This also ties in with my other ongoing project involving stage lighting with color organ, chase, strobe, fade, bass beat auto detect, and a few other features.

For now I will stay focused on what I started and complete the original project.

 

[Pommie]

I like the idea of 15 RGB LEDs on 1 pic chip. It's simple and fun. One down side is that port B is limited to 100mA, so divided by 8 that's 12.5mA and only 20% duty cycle = 2.5mA average LED current. Not very bright. You can however double the brightness by spreading the anodes between the two ports but it will make the code more complex.

Mike.

 

[Chipwizard]

I like the idea of 15 RGB LEDs on 1 pic chip. It's simple and fun. One down side is that port B is limited to 100mA, so divided by 8 that's 12.5mA and only 20% duty cycle = 2.5mA average LED current. Not very bright. You can however double the brightness by spreading the anodes between the two ports but it will make the code more complex.

Mike.

Good Morning Senior Pommie. Per datasheet I can draw 25mA per each I/O. I have put that into the test and it does provide 25mA without any issues. Based on 25mA vs 20mA required LED amps, the RGB is slightly over-driven for a tiny split second compensating for 20% duty cycle you mentioned (Which I have no dispute). Based on this compensation RGB is lit at 75% of full brightness with simulated PWM.
33% duty cycle, simulated full brightness (Consider 100% brightness)
20% duty cycle x 25 /20 = 25% compensated duty cycle
25% / 33% = 75.75% simulated full brightness (POV)

When I did 12 RGB version at 25% duty cycle (4x9 multiplexed) visually I got the same brightness as if I was at 33% (9 RGB, 3x9 multiplexed). This could possibly be the RGB LED's I am using! I might build and program it and find out that I may not have as much brightness as I expected. If so I have to go back to the drawing board, expand from 3x3 based to 4x3 base and use the 2 remaining I/O to drive 4017 counter which I was trying to avoid. (It might be that I am limited to 12 RGB at 25% duty cycle) your thoughts...

 

[Pommie]

You can draw 25mA per pin but the total per port is 100mA, hence why splitting between two ports equals twice the current.

Mike.

 

[Chipwizard]

You can draw 25mA per pin but the total per port is 100mA, hence why splitting between two ports equals twice the current.

Mike.

I got you. I do not see any issues addressing the spreading the "drives" between two ports. But I am thinking on one hand, I will have 5-4 split which might dim the 5 and not as much the 4! Is that true? On the other hand the possibility of running all RGB LED's in white color (all R,G,B on) is very unlikely. Even so sum of 3 colors are much brighter than individual color (say R) or just two colors(say R+B). So I am not sure if 5 on one port would be visually much dimmer.

Sounds like I need to build and test first...

 

[Chipwizard]

Pommie (Mike)
I created 2 working 8-bit ports (variables). I can do the programing based on these two working variables and then translate and assign one to one bits right before I go to output subroutine. Is there an easy way of copying bits from the working ports into the actual output ports? Or do I need to test individual bits to see if they are "set" or not and acoording "set" the bit at the output port?
Regards,
Rom

 

[Chipwizard]

Here is the new pin assignment if it helps. This is the best pcb layout I can do. Otherwise I have to deal with many vias and a maze of copper.
I tried to use the first and last 4 digits of each port first, then one individual one for 9th resistor (Red11), and one individual one for 1st transistor(Q1).
B4= Red1
B5= Green1
B6= Blue1
B7= Red6
A2= Green6
A3= Blue6
A6= Red11
A0= Green11
A1= Blue11
A7= Q1
B3= Q2
B2= Q3
B1= Q4
B0= Q5

 

[Mike - K8LH]

Here is a new project I have been working on. It is an expansion of my previous two versions of color wave. (9 RGB, and 12 RGB)...

Hi Rom,

Did you finish those earlier two versions and post results somewhere?

Cheerful regards, Mike

 

[Chipwizard]

Update: I ran the 9RGB version for 10 hours yesterday. This uses the same 9 bit base sourcing multiplexed 3-sinks transistors. PIC was cool as a cucumber with no noticable temporature change or even slight warming! That tells me 15RGB version based on the original posted design should work without any problems. Although suggestion of spreading the source pins across the 2 ports is a brilliant safeguard.

Based on the PIC datasheet electrical specifications: I did notice 200mA maximum combined port currents (PortA + PortB). I did not see any indication that each port current was limited to 100mA. Something tells me that the current limitation is not necessarily related to the ports, but rather limitation of the chip in its entirety accomodating certain supply current thru it (VDD, VSS). This could be due to internal wiring (semiconductor masking).

Further testing: Although my color motion version does not use white or pastels (All 3 bits on R,G,B), I intensionally forced white color across all RGB LED's. For short period of time chip got warm and for a longer period of time the chip got even warmer. This confirms the current limitation of the PIC and contineous over-driving the chip beyond its capacity may result in failure.

Based on calculation the currents during normal operation of the color motion, with two color bits used (RG, or GB, or BR): 6 pins used on the source side, total current draw is 150mA (6x25) which is within the tolerance of the specification confirming the above findings.

 

[Chipwizard]

PCB Layout: Double sided copper clad. (1.25" x 6.25")
HEX file for test program has been added.
Color Map and Data Map has been added.
Schematics has been updated.

 

[Chipwizard]

Completed Project Photos.

 

[Chipwizard]

You could save a TON of I/O space on the PIC by using latches. If this is all you ever plan to do with it fine, a few latches will free up large amounts of I/O that could be used for other things.

Scead:
Now that I have completed the project I have time to entertain your idea of latches to create expansion cards.
I have a question for you since it sounds like you have played with the idea before. I know if I was to use latches I would want to make use of data tables and have a data engine running the latches. Given that I have limited memory space on the PIC (F628A or F88) is there a way to have an external memory holding the data and have the PIC reference it as a data bank?
Any idea similar to that you can think of to expand on having lots of data memory space?

 

[Sceadwian]

Sure large external Eeproms. You want bigger than eeproms go with flash cards, the storage space available now days is astronomic.

 

[colin55]

You need resistors on the bases.

 

[Chipwizard]

Sure large external Eeproms. You want bigger than eeproms go with flash cards, the storage space available now days is astronomic.

How do you go about interfacing eeproms with pic? Have you come across any projects involving that?
Any leads will be greatly appreciated. I will google and do a search on this forum and see what I can come across.
Regards,
Rom