spreading out the PWM on a PIC16F627a

[foTONICS]

I have 6 sets of LED's, each set consists of around 5 LED's (give or take an LED) arranged in a circle. I wanna use the PWM pin on the PIC to fade these lights in and out but I know I can't drive that many LED's with a single pin.

Would it be feasible to use the PWM pin to source 6 transistors?

Should I try to get a bigger PIC with more PWM pins, do those exist?

Since I want each circle of lights to be able to run independantly does that cancel out my first option?

These lights will be either completely off, flashing red, or slowly fading blue/green

-Thanks again guys!

 

[(*steve*)]

With an appropriate circuit you can drive as many LEDs as you want from a single pin.

If your PIC can't supply enough current (or voltage) to turn on x transistors (bipolar or mosfet) then you build a driver circuit.

If LEDs are changing between more than 2 states, you will need more than 1 pin.

Sounds like you have at least 3 states, off, red, and blue, so maybe one pin for red and another for blue. This means at least 2 PWM channels.

 

[foTONICS]

Do you think it would be a waste of time to write a script that mimics PWM, by say using a couple of variables that represent the duty cycle?

lets say on_led is equal to how long the led is high for a period and off_led is the rest of the period, think that would work? I've been putting together some pseudo code and here is what I have so far:

if on_led = 100% of period
reset values and start again

else add 'x' to on_led
turn on led
call a delay subroutine which loads the value of on_led into a timer loop
turn off led
call a similar delay subroutine where 'y' is the rest of the period
loop program

 

[(*steve*)]

You can certainly do that, and if your program doesn't need to do anything else, that's fine.

It gets a little harder if you want to be doing lots of other stuff.

 

[CocaCola]

There are 'grey scale' LED driver chips that would make this dead simple, the driver chip would do all the PWM fading all you need to do with the micro is keep refreshing the matrix aka tell the chip what LED is doing what at any given time...

 

[KrisBlueNZ]

If you want really useful suggestions, you need to post a LOT more detail on what you want. Show us how the LEDs are going to be arranged, describe exactly how you want them to behave. Tell us what PIC you're considering. Don't worry, no one will steal and patent your idea before you've finished it! (At least, I won't.)

 

[foTONICS]

There are 'grey scale' LED driver chips that would make this dead simple, the driver chip would do all the PWM fading all you need to do with the micro is keep refreshing the matrix aka tell the chip what LED is doing what at any given time...

+1 for that idea!, I'm researching the TLC5940 and it seems to be able to drive what I need, and if I need more the datasheet says cascading can be done up to a limit of 40 chips (which is way more than the 3 I would probably use) .

The only thing that was a little confusing in that datasheet was clocking in the grey scale values, do I manually clock it in with the uprocessor or does the 5940 have it's own clock in timer?

thanks again for that info, this should help a lot when I figure out how to use it!

 

[BobK]

Adding hardware when the PIC can do it seems, well, inefficient.
A good software PWM can easily handle fading of 6 LEDs.

Bob

 

[foTONICS]

Adding hardware when the PIC can do it seems, well, inefficient.
A good software PWM can easily handle fading of 6 LEDs.

Bob

would it be able to switch fast enough for 6 rings of 6 led's a piece to fade without noticing a flicker?

 

[CocaCola]

Adding hardware when the PIC can do it seems, well, inefficient.
A good software PWM can easily handle fading of 6 LEDs.

I guess it's all how you looks at it, this is 30 LEDs (5 sets of 6) so you need transistors at minimum to drive them in addition to the PIC, possibly some form of current limiting as well... So now it becomes a tit for tat, several transistors plus whatever or a single IC... The IC will also generally offer a better linear fade with higher resolution...

Edit I see even more LEDs now...

 

[foTONICS]

Edit I see even more LEDs now...

there will be two sections, they will run independenly of each other and will be carbon copies of each other so I am just working out the one side. I just got ahead of myself with that last comment and listed ALL the led's, my mistake

 

[BobK]

would it be able to switch fast enough for 6 rings of 6 led's a piece to fade without noticing a flicker?

Yes, given a fast enough micro.

You will need to do say 100 levels at 100 updates per second. This is 10000 interrupts per second. The newest low-end 8-bit PICS run at 8 MIPs, so that gives you 800 instruction times to update 6 outputs. A piece of cake.

Bob

 

[foTONICS]

I'm currently using the PIC16F627A because it's what I have at my disposal so it should be capable of speeds up to 20MHz. but if necessity recommends I'll get a different one

 

[BobK]

That is a 5MHz instruction frequency, so you get 500 instructions (minus some overhead) to do your PWMs.

How many PWM outputs do you need?
Is the PIC doing anything else?

I have done a 3 channel PWM in a PIC running at 2 MIPs doing 100 updates per second with 256 levels and running a multitasking kernel of my own design. So I think is is likely you would do this with a '627A

Bob

 

[foTONICS]

How many PWM outputs do you need?
Bob

my project is 6 disks with a pressure sensor on each disk. If there is nothing on the disk it will flash red, if there is a cup on it it will fade in/out blue. if all sensors have weight on them the blue fading will be in sync.

I've been trying to work together a system of multiplexing the PWM output or using software to mimic PWM.

I'm trying to shoot for 60 Hz which will give me a nice steady fade w/ no flicker which means I need to sample sensors once every ~2.7ms.

I've been trying to run through the coding, counting instruction cycles and such, to see if I can sample all the sensors and be back in time to the first sensor before I need to update the software PWM with a different duty cycle

Is the PIC doing anything else?
Bob

aside from the fading blue leds it will just have regular interrupts to detect if there is still a cup on the sensor, if no switch off the blue led's and turn on the red ones which will be tied to a different timer flashing at ~ 1Hz



i know the coding will be relatively straight forward but im starting to wonder if I should just use a TLC5940 ( i managed to have T1 send me a couple sample chips ).

 

[KrisBlueNZ]

I assume you're intending to use one micro for all six plates?

This could all be done pretty cleanly in firmware. You just need to be sure you have enough I/O and enough hardware to get a usable timing reference.

I would start with a hardware definition, starting with I/O requirements. You'll want an external oscillator using a crystal or ceramic resonator, possibly a reset generator IC, and the rest is I/O.

For each disc, you'll need one input from the pressure sensor, one output to control the blue LEDs on that disc, and one output to control the red LEDs on that disc. That's 6x3 = 18 pins needed on the microcontroller.

The internal design can be done in many ways, depending on the hardware available. In this case where the firmware logic needed to decide on state changes and I/O activities is very simple, and quick, you can use a polled design to handle your time base, and avoid interrupts altogether, which I think is helpful if you're just starting out. This assumes you're coding in assembler or C, not BASIC!

Once you have your timekeeping coming in, you can update variables that relate to the pulsating of the blue light, and the flashing of the red light. Then you need some control variables that are used to gate that modulation data with enable/disable control signals for the blue and red LEDs, which in turn are driven by logic that polls the inputs and performs debouncing if necessary.

I'm proposing a design similar to an event loop, where the event is a timer tick and the maximum total amount of code executed in response to any event is small, well-defined, and well-controlled, so the MCU will always be ready to respond to the next tick before it occurs, and interrupts aren't used. The timer tick rate would probably be somewhere in the range of, say, 40 to 1000 microseconds.

If it's structured tidily, and with the realtime conderations taken into account, you can have a design that's well-defined, reliable, and relatively portable to other MCU architectures (perhaps not important to you), and can be got working easily.

I can go into a lot more detail if you reply with as much detail as possible on your application.