Multiple PWM outputs

[davt]

Hi, I need 24 PWM outputs is this possible to do - with the right Pic of course!
I need to read in dmx 512 information and provide multiple PWM outputs.
Can it be done with just one Pic or would it be best to have one Pic dealing with the dmx info. and another dedicated to the PWM outputs?
Can someone advise me on the best way to provide multiple PWM outputs at around 2khz eg. software example or detailed explanation of how this is done - probably using the capture module?
many thanks for your time.

Dave

[Mark]

What resolution for the PWM's? How fast do they have to respond? What do they control? I have done 6 before for controlling triacs, only 120Hz though. I used the CCP module with sorted arrays and masks. So what you would have is an array of CCP values along with a mask of the outputs or just which output to turn off. This data is predetermined in the main loop. Each time the CCP ints, you load the next value and set the output(s). Can it be done with just one PIC? With an 18F running at 40MHz you may be able to do it depending on what resolution and response time you need.

[davt]

Thanks Mark!
The resolution needs to be 8 bit.
I am not an expert programmer so this would certainly be an experience for me!!
If you could be a bit more specific with regards to the structure of the process I would be most greatful.
Best regards.
Dave

[Ttelmah]

It is worth (perhaps), adding some further comments. You can (for instance), if you can accept a low 'duty cycle' (ie, the maximum value for any one PWM, is only perhaps 4%), generate a multiplexed PWM, from a single channel. Basically, you add an external counter, and multiplexor, which uses the falling edge of the PWM pulse to switch the signal to the next 'target'. In code, you rely on the fact that a new PWM value, is loaded for the next pulse. So you output the pulse required for the first channel, reset the external counter, and start the PWM. As soon as the PWM is counting, you load the next pulse. Then each time you see the interrupt flag for the counter (to say that the PWM has finished a pulse), you load the next value, and clear the flag. The first PWM pulse then gets fed out the first output of the multiplexor, then the second, goes to the second output, and so on through the cycles. The advantage of this, is that the pulse widths generated can be small (taking advantage of the hardware PWM). I have generated 8 pulses lke this from one PWM, with a repetition rate for the entire 'sequence', of over 10KHz.
Mark's solution is basically the same as this, but using a software controlled multiplexor.
For slower PWM outputs, you can generate the whole thing in software, but the maximum frequencies will be low.
You do not say what 'else' the chip needs to do. As it stands, to get any sort of reasonable frequency, the chip is going to be working very hard, and maintaining the frequency/widths accurately, if other tasks are needed, will be quite hard.

Best Wishes

[davt]

Thanks for your reply.
I did say that I would be taking in DMX 512 info via the built in uart and that is why I thought it might be best to spread the task using 2 Pics. One to take in the serial info and complete other tasks and one to take care of the critical PWM bit.
Does this seem a better option as I would think that trying to combine all tasks into one chip would be a timing nightmare! Maybe using I2c communication between Pics?
Thanks again.

Dave

[ChrisS]

Dave,

I have built several aplications in the past using PICs to recieve DMX and generate PWM among other things. I don't claim to be the worlds best programmer, but even in assembler, it will be very tricky if not impossible for you to get good results trying to do both in the same pic if you are actually creating the PWM timing in software like the other guy suggested. DMX is 250K baud, continually transmitting but its totally asyncronous, and depending on your application, you have to use processor time to pick through the bytes as they come in to sort them out. The basic problem is that the timing of your packets and the timing of your PWM are in completely seperate worlds, and not even consistant, so you cant create stable, predictable software flow of a timing-critical nature with the limited bandwidth of a PIC. If you were just feeding values into the capture/compare module and letting the PWM hardware do the timing work, then you would not have a problem. But since you need so many channels of PWM, that is not possible with a PIC.
I built a 50 channel DMX dimmer for a large christmas light display once with PICs using a software technique similar to the one the other guy was telling you about. I used one PIC to recieve DMX and handle the address sorting, and X number of other simple PICs to generate the real-time PWM which was sync'd to the AC line since I was doing AC dimming. I then created an 8 bit parallel data buss to connect all the pics with the DMX PIC. I created my own little handshaking protocol along with a little external logic to streamline the communication of the DMX PIC to the other pics so that they never had to be interrupted or thrown off timing. It worked very well, and in fact, the DMX PIC was also used to do some more fancy dimming and smoothing to the DMX data as it came in. I have since built much larger complex applications using large DSPs instead of PICs, but for small, lower budget applications, the multiple PIC design worked very well. I'd be glad to give you more info if you want. Take it easy.

[SherpaDoug]

If it were me I would use 24 PICs for the PWM outputs. Something in the 12 series would be cheap enough. Maybe even the new PIC10F20X. Digi-Key has them for as little as US$0.55 each. Then add another PIC to decode the DMX and hand it off to the little guys by SPI or something simillar. I would drive them all from one master crystal to prevent timing problems.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Mark]

With an 18F pic using the high priority, I believe you could generate the pwm's for dimming pretty easily. The problem is when you start talking about a frequency of 2KHz and 8bit resolution. At 40MHz thats about 19 instructions between each bit of resolution. Worse case of each dimmer being 1 step different is where the tough part would be. 24 times 19 instructions is just a bit more than the time required to transmit a single byte but given the double buffer on the uart it still may be possible but would be really tight. Maybe I'll see how well it can work tomorrow during lunch.

Dave,
Does the PWM freq have to be 2KHz or can it be lower?

[ChrisS]

Yes Mark...I see where your coming from...I was using PIC73's running at 10 or 20 Mhz. Even then I was able to do 8 channels of 60Hz Dimming with each PIC as long as I wasnt trying to do much else with it. I had a high priority interrupt at each zero-crossing. My big thing was I was doing a lot of other stuff with the DMX receive PIC. running some algorithms, etc. Depending on how much headroom he wants to do other stuff, and what his duty cycle needs to be...I guess thats the fine line. I wish there was a small micro like a PIC that had like 8 or 16 channels of dedicated PWM hardware in it...it seems like that would be useful for embedded applications. Even then, if you need like 20 or 30 channels of PWM I guess you either go to multiple processors, or go to more of an external bus/hardware type thing. I know there are fixed frequency PWM generator ICs for power supplies, etc. Is there actually a variable period/duty cycle PWM generator IC with a serial or parallel bus interface for a uP? I have never seen one.

[TBrandt]

I think you should realy think about a cpld - in a xilinx coolrunner or similar device you should have easily enough IO and gates to get your task done - a spi interface should also be possible to implement. so you will get away with ione device and a relatively low cost design. The software to do the task in VHDL or Verilog is availble from xilinx for free - it's called webpackage.

maybe you'll find that this is a rather convenient approach for you ....

[Mark]

We had some old design dimmers that had 18 outputs. It used 74HC592's to do the PWM's. Basically, you would just load the 8bit value into the counter and then provide a clock that was 256X the frequency.

http://moon.feld.cvut.cz/hw/st/1987.pdf

[ChrisS]

This is very true...I had forgotten about using a CPLD. I have not done any applications with them for this type of thing before, but I have worked with an XC95144 in more of a PPI type of application. I actually know of a company that has used one to receive DMX too...obviously possible but very limited in that you cant really do any processing with the data...you just basically create a UART with it. I see designers doing more and more with CPLDs these days...seems like they are becoming more sophisticated and flexible. I assume it would be fairly easy to take an external oscillator and use it to provide the time base for your PWM logic...then just create 24 state machines in the CPLD to clock the PWM out of dedicated pins. then just use one PIC to recieve your DMX and do any other processing...and connect it to your cpld with an 8 bit data bus or something.

[ChrisS]

OK....creat 24 instances of something similar to the logic in the 74HC592 device Mark mentioned inside the cpld. I guess you just need a couple external clocks or timing signals of some sort right? Cool

[TBrandt]

I would say that you could do it the following way :

you have one 8-Bit-Counter that is running at the dedicated frequency of the pwm. the relevant frequency you can get easily from an external oscilator via clock division.
on the other side you have 24 8bit-wide registers that will be simply connected to the counter via some compare/glue-logic in the macrocells - so that you will get the relevant pwm output. this could be

as input i would suggest a simple spi interface with just 3 inputs : spi-clock spi-datain an one global chip select. (dataout is not needed). furtheron i would take a 16 bit spi-dataword (this means 2 times 8 bits) as it's used for example with the max3110 spi uarts from maxim. so you can define in the first byte which pwm you select (up to 256 different ones if you like and have enough space ;)) and in the second byte you can determine the pwm-value. this would safe some pins on the pic and fit very well to the spi-concept of the pic . the approach can be implemented in one rather simple and straightforward fsm clocked either by the spi-clock or in a synchronous oversampling approach.

last but not least I would suggest not to forget one global reset - that's it.

depending on your supply voltage you should think about using if you prefer xilinx if you choose a xc95000 or a coolrunner where you will have 5V tolerant IO but will have to fiddle with 3.3V or another supply voltage ...

ok - that's it ...

[Guest]

ok - incomplete posting ....

what i wanted to add : the glue logic for the pwm can be rather simple described by a simple if statement in this case because in my opinion the pwm should work like this : when the eight bit counter has a greater value than than the 8bit-dutycycle pwmvalue the pwm-output should be 0/off otherwise it should be high - this can be described in vhdl or verilog very simple with the mentioned if statement so that the compare logic will be synthesized "automagically".

ok - that'it - hope it helps and you understand my pigeon english ;)