## Xmega with 18 PWM outputs?

35 posts / 0 new
Author
Message

Hi,

For a light control application I would need to have 18 PWM outputs from an AVR. Is there any Xmega model that can support this?

The frequency of the signal can be the same for all outputs, only the pulse width need to be individual for each output.

Any ideas welcome.

Best regards
Bjorn

How fast how good?
Perhaps they can be done in SW

Software is not an option. Will keep the AVR busy with many other tasks as well :)

The PWM will be used to dim LEDS, need to be above 100 Hz to experience it flicker free.

The atmel chip selector show 26 8 bit AVR's with 18 or more PWM's

You could use a CPLD for 18 PWM, or you could add distributed slave PWMs based on something like XMegaE5.

The E5 is low cost, and the short form says 12 PWM chans.

sparrow2 wrote:
The atmel chip selector show 26 8 bit AVR's with 18 or more PWM's

Since these AVRs do not have 18 timers there must be some restrictions to >18 PWM channel devices. For me the big question is if I can have 18 different pulse widths.

read the datasheet (I have not used them), but I guess 8 or 16 compare match on each timer.
On a normal 16MHz mega it will take about 20% of the time to do it in SW.

And if they don't need to change value fast it can be done in less than 5% if you have 512 byte RAM for the job.

Last Edited: Wed. Dec 11, 2013 - 10:34 AM

Quote:

Since these AVRs do not have 18 timers there must be some restrictions to >18 PWM channel devices. For me the big question is if I can have 18 different pulse widths.

When AVRs have multiple PWM on each timer the only restriction is that the frequency of all the outputs must be identical. However the duty on each channel is individually variable.

BTW you may be over-estimating the effort to do soft PWM (if it becomes necessary). It could only take a few % of CPU time in a couple of interrupts.

100 Hz update in 8 bit is about 25KHz interrupt with 18 compare each time.

There is 24 PWM outputs on A1(U). 16 PWM outputs on A3(U).

Maybe it would be easier and even cheaper to use a dedicated chip to do that (a dimmable LED driver generally used for backlights for example). Just a thought

Looks like a "D3" chip would have enough pwm outputs for that.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

bloody-orc wrote:
Maybe it would be easier and even cheaper to use a dedicated chip to do that (a dimmable LED driver generally used for backlights for example). Just a thought

Interesting! Do you have any suggestios on such a chip?

/Bjorn

Basically all cip makers have some. For example: http://www.ti.com/lsds/ti/power-...

Quote:

chip PWM channels
ATxmega128A1 24
ATxmega128A1U 24
ATxmega128A3 22
ATxmega128A3U 22
ATxmega128C3 18
ATxmega128D3 18
ATxmega192A3 22
ATxmega192A3U 22
ATxmega192C3 18
ATxmega192D3 18
ATxmega256A3 22
ATxmega256A3B 22
ATxmega256A3BU 22
ATxmega256A3U 22
ATxmega256C3 18
ATxmega256D3 18
ATxmega32C3 18
ATxmega32D3 18
ATxmega384C3 18
ATxmega384D3 18
ATxmega64A1 24
ATxmega64A1U 24
ATxmega64A3 22
ATxmega64A3U 22
ATxmega64C3 18
ATxmega64D3 18

this is the 26 xmega's with 18 or more PWM channels.
So unless you need high power no need for an extra chip.

From AVR support

Quote:

Dear Bjorn,
XMEGA devices has timer that features maximum four compare channels per timer. This means, using a single timer you can generate four PWM signals of same frequency and different duty cycles.
If your application has only to adjust the duty cycles of the PWM signals and the frequency of all PWM signals are the same then you can use 5 XMEGA timers to generate 18 PWM signals.
Hope this helps.

Best Regards,
Manoj Kumar
Atmel Technical Support Team

Thanks everyone for your replies! Will look into the separate driver solution as it will save much PCB space in our design.

/Bjorn

Quote:
I would need to have 18 PWM outputs from an AVR.

Eighteen or eighteen thousand?
For eighteen you need 3*8 bit independent 8-bit PWM channels which means you have to push out only 3*8=24 bytes through IO pins a 100 times per second.

Quote:
It could only take a few % of CPU time in a couple of interrupts.

I didn't test that but the IRQ runs like this:

;4 clocks for IRQ entry
; save SREG
in temp,SREG \out TEMP_SREG,temp
;then modify TOP of the 8-bit timer
in temp,TOP
lsr temp ;make IRQ last half of the previous one
out TOP,temp
;save Z and load with pointer to buffer
out TEMPZL,ZL \in ZL,PTRL
out TEMPZH,ZH \ldi ZH,high(buf)
;then push out three bytes we are interested in
ld temp,-Z \ out PORTA
ld temp,-Z \ out PORTB
ld temp,-Z \ out PORTC
;Z roll over
sbrs ZL,6 \ ldi ZL,low(buf)
;then save back ptr and restore Z
out PTRL,ZL\ in ZL,TEMPZL
in ZH,TEMPZH
;restore SREG
in TEMP_SREG, out SREG
clr temp
reti ; 4 clocks for IRQ exit

Which totals(if I counted that correctly): 35 ticks, uses 24 bytes of RAM, 4 GPIORs and one 8-bit timer with IRQ that is triggered 8 times at 100 Hz which eats up 28000 ticks out of 20e6 available each second.
So with ATMega164 running at 20MHz that would be 0.14% of CPU time.
If the uC had enough IO pins then in theory you could 8-bit PWM 17142.85 LEDs with that.

No RSTDISBL, no fun!

It would be interesting to see a tested, glitch free solution for 24 PWM channels with 100Hz PWM frequency with less than 1% CPU load. (I would prefer a little more than 8 bits resolution, say 10).

Quote:
0.14% of CPU time

if you have 8 bit resolution on the PWM @ 100Hz update you will need 25.6KHz ISR.
Unless you build a 256byte RAM buffer, I don't see any way avoid doing 18 compares in each ISR, so my calc is something like this:
15 clk in out ISR
18*4+3*1
So about 90clk @ 25.6KHz = 14.4% of a 16MHz AVR.
That is why I wrote 20% to be safe.

Quote:
if you have 8 bit resolution on the PWM @ 100Hz update you will need 25.6KHz ISR.

In this LED driving context 8-bits means that this results in one value out of 256.

No RSTDISBL, no fun!

Quote:
Quote:
if you have 8 bit resolution on the PWM @ 100Hz update you will need 25.6KHz ISR.

In this LED driving context 8-bits means that this results in one value out of 256.

_

so what is the point?
A 8 bit counter that have to overflow 100 times a sec. will have to count at a speed of 100*256= 25600 Hz.
At any value one of the 18 outputs can flip, so the ISR
has to run with 25.6KHz

Quote:
At any value one of the 18 outputs can flip, so the ISR has to run with 25.6KHz

No, IRQ does not have to run at 25.6kHz to generate that 8-bit PWM. It is enough to run this IRQ only 8 times during period(800 times at 100Hz) and that is why it occupies only 0.14% of CPU time.
- First IRQ is at T0, - second is at T0 + 1/256,
- third is at T0 + 3/256
....
- eighth one is at T0 + 127/256 (of the period).
which gives 8 IRQs for one period and then the play starts all over again.

No RSTDISBL, no fun!

Ok now I seen what you do, and I see one big problem
some lower values give more light than a higer one.
3 pulses at one value will give more light than a higher number with only one pulse!

Add: At least on a LED

Last Edited: Thu. Dec 12, 2013 - 01:59 PM

Quote:
some lower values give more light than a higer one.

Or some higher values give less light than two lower ones.
This is related to the step response of the LED.
Quote:
and I see one big problem

I think what you mention is a highly theoretical problem at 100Hz 8-bit PWM. Much bigger (also highly theoretical) problem would be a jitter of IRQ entry because of some atomic code that would make the IRQ pending for one or two clocks.
6svyf

No RSTDISBL, no fun!

I did not find it in a data sheet, but this is from a google search:

Quote:
The magic numbers here seem to be run the LED at 60Hz, with a duty cycle of 5% and it'll appear twice as bright to humans. Works better on Blue & Green than it does on Red.

So it will change something on 100Hz as well.

Quote:
So it will change something on 100Hz as well.

This is not related to the subject of a step response of a LED.
No, it does not matter if you 10% PWM a LED at 100Hz or at 1000Hz. Both frequencies are well beyond human retina bandwidth.
Yes, it does matter if you 10% PWM at 0.1Hz and at 1Hz.

No RSTDISBL, no fun!

Quote:
human retina bandwidth

That is not what I talk about, it's the heating inside the LED.
But I will make a test when I get some time.

Quote:
it's the heating inside the LED.

do not neglect the inductance of the leads :)
LEDs do heat up and their efficacy does change with temperature but on this level of 100Hz discussion I do not think you will be able to notice/measure any difference.

Give us a short report when you find some reference.
l42nf

No RSTDISBL, no fun!

Brutte wrote:

No, IRQ does not have to run at 25.6kHz to generate that 8-bit PWM. It is enough to run this IRQ only 8 times during period(800 times at 100Hz) and that is why it occupies only 0.14% of CPU time.

I can see a design that outputs conventional PWM, and needs only 9 interrupts max.

Int 1 = All to Zero
Int 2 = dTime of 1st _/= edge(s)
Int 3 = dTime of 2nd _/= edge(s)
Int 9 = dTime of possible last _/= edge
Int 9 loads the Time for all-high

So it runs like a dTime-list, and list-length can vary, from 2 items (all pins ==), to 9 (8 unique edges).
Usually you would have two lists, one playback, and one loading, and then flip at the common Int1 location.
Software is needed to (re)organize the list, for each new set of edge times.

Brutte wrote:

- First IRQ is at T0, - second is at T0 + 1/256,
- third is at T0 + 3/256
....
- eighth one is at T0 + 127/256 (of the period).
which gives 8 IRQs for one period and then the play starts all over again.

- but that is not conventional PWM ? - it looks to have binary-time slots, and outputs multiple pulses, with phase jumps at boundaries.

It also needs additional overhead to 'rotate' the bytes, for fastest pin-delivery.

Still, it is a quite interesting idea, some apps could tolerate that.
It sits between conventional PWM, and Rate Multiplier PWM in edge count.

Quote:
- but that is not conventional PWM ?

Define "conventional". It is pulse width modulation, meets the requirements, is 8-bit so what you you want more? Perhaps the other PWMs are not conventional because are not center-aligned or output 0xAA in one go instead of on/off/on/off/on/off to not overheat the LED.

Quote:
with phase jumps at boundaries.

Every PWM (except the one that runs at 100%) has it.

Quote:
Still, it is a quite interesting idea, some apps could tolerate that.

Like for example
Quote:
8-bit PWM 17142.85 LEDs

No RSTDISBL, no fun!

Brutte wrote:
Quote:
- but that is not conventional PWM ?

Define "conventional". It is pulse width modulation, meets the requirements, is 8-bit so what you you want more?

A more accurate name is Pulse Density Modulation, which is also what a Rate Multiplier output is.

Pulse Width Modulation strictly applies to a pulse whose width is modulated, aka one pulse, variable width.

The 'basket of widths', PDM you describe is a useful one for the toolbox, as it has low average CPU loading, and is useful for up to ~1000Hz repeat rates.

It also allows quite free choice of the Time-Block, constrained at one end by the INT cycles count, and at the other by fitting in 16 bits, when doubled 7 times.
( ie < 511 )

Even when the LSB slot width approaches INT time, the total average CPU loading is 2.7% on the test I did.
With such Time choice, you can also use this as a timebase tick.

I question of how flexible it is. The repeat rate (the overflow value), has to be dividable by 256. So for a 8 bit timer you can only adjust with the prescaler.

And I often have fast timer ISR's above 100KHz so I often has ISR that take 50% of the time but worst case perhaps 70% (@16MHz still leave about 5 mips for the rest)
In many cases I only have one ISR from where I pull everything others normally put in ISR's, remember that you can enable interrupt condition on "things" without enabling the interrupt bit, so a check is only to see if the unit have a hanging interrupt bit set.

Each timer counter can have up to 4 (2 if timer type 1) output compares, which can also generate PWM waveforms to separate pins. The only limitation is equal frequency of output for each timer counter.
The 64 pin xmegas for example have up to 22 PWM outputs.

Timer  PWM's  pins
TCC0   4      PC0, PC1, PC2, PC3
TCC1   2      PC4, PC5
TCD0   4      PD0, PD1, PD2, PD3
TCD1   2      PD4, PD5
TCE0   4      PE0, PE1, PE2, PE3
TCE1   2      PE4, PE5
TCF0   4      PF0, PF1, PF2, PF3

But others have said, if the PWM frequency requirement is only for light dimming then an all software solution may be just as simple to implement.

sparrow2 wrote:
I question of how flexible it is. The repeat rate (the overflow value), has to be dividable by 256. So for a 8 bit timer you can only adjust with the prescaler.

Not sure I follow. The interrupt spacing is variable, but yes the frame rate is a total of 255 time units.
Those time-units can be any value, between a lower limit of long enough for the interrupt to complete, and an upper limit that can double 7 times, and still fit into 16 bits.

The frame rate is going to be 'some milliseconds'.

sparrow2 wrote:

And I often have fast timer ISR's above 100KHz so I often has ISR that take 50% of the time but worst case perhaps 70% (@16MHz still leave about 5 mips for the rest)
In many cases I only have one ISR from where I pull everything others normally put in ISR's, remember that you can enable interrupt condition on "things" without enabling the interrupt bit, so a check is only to see if the unit have a hanging interrupt bit set.

If you already have a fast fixed rate Interrupt, then a Rate Multiplier PDM variant is probably going to merge better.

Of course, any software PWM, is going to need care with other interrupts which can result in jitter.

Quote:
and is useful for up to ~1000Hz repeat rates.

Of course not. You could chain the fastest IRQs that do 1/65536, 2/65536, .. , 2^k/65536 in one IRQ. All the rest could be serviced in a regular way. So the frequency and resolution is only limited by the F_CPU and average CPU usage.

//IRQ at T0
out PORTA,dataa0
//T1
out PORTA,dataa1
nop ;or some useful stuff
//T2
out PORTA,dataa2
nop \ nop ;or some useful stuff
//T3
out PORTA,dataa3
...

So the fastest repeat rate of update is F_CPU in this byte case (20MHz for regular AVR).
With 100Hz PWM that means that you can get an 8-channel PWM with resolution of over 2^17 bits still falling in the sub 1% average cpu usage.

No RSTDISBL, no fun!