BoostC Charlieplexed PWM 32

Status
Not open for further replies.
How would you connect a single push button switch to disconnect GP0/ICSPDAT and GP1/ICSPCLK from the LED circuitry when you push it and hold it down?
That's what I get for posting before coffee. Sure it could be done, but it would take more circuitry than it's worth. My "off the top of my head" electronics knowledge is poor. It seemed like a nice idea when I posted it, but when I actually started scratching it out on paper I realized it's not so simple.


Here's a simple little pwm animation thing for your blinky device:
Code:
	led[0] = led[19] = 31;
	led[1] = led[18] = 23;
	led[2] = led[17] = 18;
	led[3] = led[16] = 14;
	led[4] = led[15] = 11;
	led[5] = led[14] = 9;
	led[6] = led[13] = 7;
	led[7] = led[12] = 5;
	led[8] = led[11] = 3;
	led[9] = led[10] = 2;

	while(1){
		temp=led[0];
		for(x=0;x<19;x++){
			led[x]=led[x+1];
			delay_ms(3);
		}
		led[19]=temp;
		delay_ms(3);
	}
}
 
Nice effect. That's "a keeper".

I can see now how easy it will be to create hundreds of patterns and variations. We're definitely going to need that mode switch (grin).

I've still got the red led bars in mine and they're incredibly bright so I toned it down a little. I also wanted a little more dark area in there, so.....

Code:
  led[0] = led[19] = 12;
  led[1] = led[18] = 9;
  led[2] = led[17] = 7;
  led[3] = led[16] = 5;
  led[4] = led[15] = 3;
  led[5] = led[14] = 1;
  led[6] = led[13] = 0;
  led[7] = led[12] = 0;
  led[8] = led[11] = 0;
  led[9] = led[10] = 0;

  while(1)
  { temp=led[0];
    for(x=0;x<19;x++)
    { led[x]=led[x+1];
      delay_ms(3);
    }
    led[19]=temp;
    delay_ms(3);
  }
}
 
It may be difficult trying to animate the leds faster than the rather slow 62.5 Hz / 16 msec refresh rate. Also note that the BoostC delay routines will run about 42% slower due to the ISR 'overhead'.

Mike
 
I've still got the red led bars in mine and they're incredibly bright so I toned it down a little. I also wanted a little more dark area in there, so.....
Hey, that looks great!

Also note that the BoostC delay routines will run about 42% slower due to the ISR 'overhead'.
I had noticed that my delays were ridiculously short and yet worked fine. Figured (correctly) it was because it's a very busy chip.
 

after the switch provision, GP3 could also be used as Futz put it in an earlier reply. Perhaps could expand the design further,using GP3 .
 
after the switch provision, GP3 could also be used as Futz put it in an earlier reply. Perhaps could expand the design further,using GP3 .
I think what Mike was suggesting was to use a momentary switch for GP3 instead of a slider. Hold the button down for programming mode. Either way, it's still a switch and you'd still have the use of GP3 for input.
 
Hi again,

The processor isn't that busy.

When you get a chance could you try this snippet?

I removed the delay within the loop to smooth out the transitions. I also synchronized the LED update to the 16 msec frame rate. Please tell me if you notice any difference? It looks incredibly smooth here...

Code:
  led[0] = led[19] = 12;
  led[1] = led[18] = 8;
  led[2] = led[17] = 5;
  led[3] = led[16] = 3;
  led[4] = led[15] = 2;
  led[5] = led[14] = 1;
  led[6] = led[13] = 1;
  led[7] = led[12] = 0;
  led[8] = led[11] = 0;
  led[9] = led[10] = 0;

  while(1)
  {
    temp=led[0];
    while(colpos != 0b00100000);    // sync' to 16-msec frame interval
    for(x=0;x<19;x++)
    { led[x]=led[x+1];
    }
    led[19]=temp;
    delay_ms(26);
  }
}
 
I think what Mike was suggesting was to use a momentary switch for GP3 instead of a slider. Hold the button down for programming mode. Either way, it's still a switch and you'd still have the use of GP3 for input.
Sorry for the confusion guys. I installed a push button switch on my board to use within the program for selecting different modes. Then I suggested that you don't really need the ICSP/RUN slider switch because the push button switch is normally open and it won't adversely affect PICKit2 programming operations.
 
OK, now I'm really confused. Doesn't the programmer need to hit VPP with 13V to program the chip? Or does it both connect VPP to ICSP and change modes at same time when pressed?

EDIT: Oh. It's connected to VPP until you press the button? That makes sense.
 
Last edited:
Nice. Smooth as buttah!
 
Oh. It's connected to VPP until you press the button? That makes sense.
Well I don't have an ICSP jack on my board but if I did the switch would always be connected to the VPP pin on the ICSP connector so you would have to make sure you didn't press the push button while you were programming the PIC.

I suppose if I were to put an ICSP connector on the board I would just use three jumpers to isolate the GP0, GP1, and GP3 pins and ICSP signals from the rest of the circuit.

Again, sorry about the confusion.

Also updated my drawing (below) to show the new push button switch and to show the RS-232 connector which has been on the board (but not included in the schematic).

Mike
 

Attachments

  • PWM-20 schem 2.PNG
    55.9 KB · Views: 301
Last edited:
Well I can see there's a whole new set of skills I need to master to put videos up on YouTube (grin). You guys make it looks so easy (grin).

Anyway, here's a link to the video of that last program in operation; Charlieplexed PWM-32

The LEDs are still washing out or overloading the camera and I don't know how to tone it down to get good video. Those LED patterns are really very crisp and clear in person with a very nice fading effect.

I've also attached an updated program listing because the listing in the very first post is missing an instruction at the top of the ISR to clear the Timer 2 interrupt flag (oops!). Sorry guys.

Mike
 

Attachments

  • 12F683_Test_v1.txt
    7.8 KB · Views: 250
Very Nice Mike! Perhaps top row can be from left to right while bottom on the reverse. like two trains traveling in opposite directions.
 
Thank you. It looks much nicer in person than it does in the video.

Looks like Futz has also put his version up on his site and it looks very nice. He mentioned my name too. Cool. I'm famous (grin)...

**broken link removed**
 
Last edited:
The LEDs are still washing out or overloading the camera and I don't know how to tone it down to get good video. Those LED patterns are really very crisp and clear in person with a very nice fading effect.
It's the sensors they use in these digi cameras. Mine can't take a decent picture of any LED, including LCD backlights. Colors are always wrong and blown out over-bright like you say.

One thing I noticed is that the Kodak that Atomsoft uses must have a different sensor because his LCD backlight pics look great! In fact, they look oversaturated to the point that it should be toned down a bit.

Kodaks almost always come out at the bottom of the pack in reviews, but they may be good for LED pictures. If I knew anybody who owned one I'd borrow it to confirm this hypothesis.
 
Futz, your photos and videos still look much better than mine. As I look at them it seems you have much better (brighter) lighting in many of them. Perhaps I'll give that a try when I have more time.

Mike
 
Futz, your photos and videos still look much better than mine. As I look at them it seems you have much better (brighter) lighting in many of them. Perhaps I'll give that a try when I have more time.
It's vitally important to have tons of light for macro photography. Here's a quote from an older post of mine
 
Last edited by a moderator:
Mike please help me I have a problem.

I’m confused with the duty cycle & the refresh rate in a LED matrix system.

Are they are two different things or one?

In your schematic it says 20% duty cycle. Does it means each LED driving on 20% duty cycle? 20% means almost 1/5 from the brightness, which is too dim.

If I have a matrix of 5 columns & 8 rows is there any formula to calculate the best delay in between the columns? So I can display it nicely without flickering & with a decent brightness.
 

Attachments

  • FX7WSQ2FHM8R2A6.MEDIUM.jpg
    29.5 KB · Views: 217
Mike please help me I have a problem.

I’m confused with the duty cycle & the refresh rate in a LED matrix system.

Are they are two different things or one?
They are two different things.

Duty cycle is the amount of time in a period that an LED is lighted. In that 5 column display each column is updated one at a time and so each LED in that matrix can be lighted for 20% or 1/5th of the time.

Refresh rate is how often you light each LED in the display over time. It's usually expressed in Hertz (cycles per second). In that 5 column display each column is lighted for 3.2 msecs and so it will take 16 msecs to update the entire 5 column display. The refresh rate is therefor 1 / 0.016 seconds = 62.5 Hertz.

In your schematic it says 20% duty cycle. Does it means each LED driving on 20% duty cycle? 20% means almost 1/5 from the brightness, which is too dim.
Yes, each LED can be lighted 20% or 1/5th of the time. A 20% duty cycle is pretty good for a multiplexed LED display.

The duty cycle pretty much determines 'peak' current requirements to light an LED to full brightness. To get a brighter display you can increase the duty cycle and/or increase 'peak' current available to the display.

If I have a matrix of 5 columns & 8 rows is there any formula to calculate the best delay in between the columns? So I can display it nicely without flickering & with a decent brightness.
My understanding is that a refresh rate of less than about 60 Hz may cause an LED display to be perceived as flickering.

If you're updating your display one column at a time and you'd like a 60 Hz refresh rate, then;

1/"number of columns"/"refresh rate" = "update interval"
1/5/60 = 0.00333 seconds (3.33 msecs)

You can also use that formula to test different interval timing;

1/"number of columns"/"update interval" = "refresh rate"
1/5/0.002 = 100 Hertz (when using 2 msec update interval)

As I mentioned, to improve brightness you would increase duty cycle and/or increase 'peak' current available to the display.

Regards, Mike
 
Last edited:
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…