Searching \ for '8 channels PWM generator chip. [OT]' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/pwm/index.htm?key=pwm
Search entire site for: '8 channels PWM generator chip. [OT]'.

Truncated match.
PICList Thread
'8 channels PWM generator chip. [OT]'
2000\03\02@100649 by Edson Brusque

face
flavicon
face
Hello,

   I'm making some research for a future product and want to know if
there's a chip that can generate 8 PWM outputs at high frequency (say,
30KHz) based on a serial input. It have to work as some kind of 8-channel
DAC, but outputting PWM and not linear voltage.

   Thanks,

   Brusque

2000\03\02@101508 by WF

flavicon
face
I suggest to use the Siemens Family...SAB80C167

Miguel

----- Original Message -----
From: Edson Brusque <spam_OUTbrusqueTakeThisOuTspamFLYNET.COM.BR>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Thursday, March 02, 2000 12:01 PM
Subject: 8 channels PWM generator chip. [OT]


{Quote hidden}

2000\03\02@113449 by Dan Michaels

flavicon
face
At 12:01 PM 3/2/00 -0300, you wrote:
>Hello,
>
>    I'm making some research for a future product and want to know if
>there's a chip that can generate 8 PWM outputs at high frequency (say,
>30KHz) based on a serial input. It have to work as some kind of 8-channel
>DAC, but outputting PWM and not linear voltage.
>
>    Thanks,
>    Brusque
>

Getting a little [OT] from the PIC world, http://www.scenix.com has
8-channel PWM VP (virtual peripheral) s.w. for their chips, which
includes RS-232 comm. It's pretty flaky PWM (ie, the period
varies with duty cycle), but is something to look at, viz-a-viz
generation in s.w. versus h.w.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\03\02@125629 by Scott Dattalo

face
flavicon
face
On Thu, 2 Mar 2000, Dan Michaels wrote:

> At 12:01 PM 3/2/00 -0300, you wrote:
> >Hello,
> >
> >    I'm making some research for a future product and want to know if
> >there's a chip that can generate 8 PWM outputs at high frequency (say,
> >30KHz) based on a serial input. It have to work as some kind of 8-channel
> >DAC, but outputting PWM and not linear voltage.
> >
> >    Thanks,
> >    Brusque
> >
>
> Getting a little [OT] from the PIC world, http://www.scenix.com has
> 8-channel PWM VP (virtual peripheral) s.w. for their chips, which
> includes RS-232 comm. It's pretty flaky PWM (ie, the period
> varies with duty cycle), but is something to look at, viz-a-viz
> generation in s.w. versus h.w.

Yeah butt...

Here's one that's faster and sychronous:

http://www.dattalo.com/technical/software/pic/pwm8.asm

But even on a 100Mhz Scenix you'll only get a pwm frequency of about 15
kHz (and a dynamic range of 8 bits). If you're willing to for go a little
less dynamic range, then a vertical counter pwm can give you a faster
frequency. But I assume that you'll want at least 8 bits...

BTW, on a 20Mhz pic the pwm frequency is about 780 Hz.

Scott

(PS. I see a way to make the pwm routine referenced above three cycles
faster. Nikolai?)

2000\03\02@140829 by l.allen

picon face
>     I'm making some research for a future product and want to know if
> there's a chip that can generate 8 PWM outputs at high frequency (say,
> 30KHz) based on a serial input. It have to work as some kind of 8-channel
> DAC, but outputting PWM and not linear voltage.
>
>     Thanks,
>
>     Brusque

Sounds like a job for ... Mr           FPGA
Especially with the kind of speeds you are talking about there.


_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

2000\03\02@142107 by Dan Michaels

flavicon
face
Good, I'm glad somebody's got something better than the scenix
code, but it was offerred as one way to do 8 PWMs. The s.w. is
there for the taking, and could also be used on a PIC with mods.
It may suit the original purpose.

[OT on OT]. After 6+ months programming the scenix, my personal
opinion of the VP approach is, it is good for 1 very fast VP,
but not so great for more than 1. Lot easier to use the h.w.
built into the PIC than try to emulate everything in s.w. on
a scenix. [how about some applause now, picsters!!].

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

{Quote hidden}

2000\03\02@163006 by paulb

flavicon
face
Edson Brusque wrote:

>   I'm making some research for a future product and want to know if
> there's a chip that can generate 8 PWM outputs at high frequency (say,
> 30KHz) based on a serial input. It have to work as some kind of 8-
> channel DAC, but outputting PWM and not linear voltage.

Scott Dattalo wrote:

> Yeah butt...
> Here's one that's faster and sychronous:
> http://www.dattalo.com/technical/software/pic/pwm8.asm

> But even on a 100Mhz Scenix you'll only get a pwm frequency of about
> 15 kHz (and a dynamic range of 8 bits).  If you're willing to for go a
> little less dynamic range, then a vertical counter pwm can give you a
> faster frequency.  But I assume that you'll want at least 8 bits...

 Hey, guys, you want *speed* here.  You need an Atmel AVR.  I think an
8 MHz 90S1200 should do the job quite nicely.  *Forget* PWM hardware,
it's all in software.

 Use 8-bit vertical counters (can be extended to more bits for lower
PWM frequencies) stored in 8 working registers.  On the AVR, copying a
working register to an output port is *one* cycle at 8 MHz.

 Your code consists of a 256 instruction (branching) isosynchronous
loop.  It outputs the MSB register value for 128 cycles (bit-banging
your serial input during this time, the next Significant Bit register
for 64 cycles (more bit-banging), the next for 32 cycles until at the
end the second LSB is output followed directly by the LSB.

 Do I need to spell this out in actual code?  It uses the AVR structure
specifically - the PIC takes twice as many machine instructions to do
the same function, and is of course, nowhere near as fast.  I gather
however that the Scenix could fairly easily also.

 Caveat - the serial input would have to be synchronised to the PWM
frequency unless you use a device with a UART.  Dirt cheap though.

 Option/ extension - the MSB, or a number of MSB, can be chopped to
increase the average modulation frequency.  Just takes a few extra
instructions carefully placed.
--
 Cheers,
       Paul B.

2000\03\02@184801 by Scott Dattalo

face
flavicon
face
On Fri, 3 Mar 2000, Paul B. Webster VK2BZC wrote:

>   Use 8-bit vertical counters (can be extended to more bits for lower
> PWM frequencies) stored in 8 working registers.  On the AVR, copying a
> working register to an output port is *one* cycle at 8 MHz.
>
>   Your code consists of a 256 instruction (branching) isosynchronous
> loop.  It outputs the MSB register value for 128 cycles (bit-banging
> your serial input during this time, the next Significant Bit register
> for 64 cycles (more bit-banging), the next for 32 cycles until at the
> end the second LSB is output followed directly by the LSB.
>
>   Do I need to spell this out in actual code?  It uses the AVR structure

I'm afraid you do.

The concept I'm having trouble grasping is the '256 instruction
isochronous loop' that is capable of 8-bit pwm on 8 channels. Enlighten us
Paul. On a pic, it takes two cycles to increment one stage of a vertical
counter. Assuming no logic for PWM, you'd need a minimum of 16 cycles to
advance the counter by one. To go through all 256 pwm states would require
a minimum of 256 *(16 +2) pic cycles. I know nothing about AVR, but it has
to take at least one instruction to increment one stage of the vertical
counter. Right? So to pass through all 256 levels you'll need 256 * 8
execution cycles. I could be missing something - perhaps there's a missing
EQU somewhere.

-------


I hate to spoil the fun that Nikolai may've had, but you somewhat have
indirectly alluded to the way 3 cycles could be shaved off the routine I
posted the link to. The trick is to just use the I/O port to maintain the
state of the 'pwm_state' variable that was in the other routine:

pwm_multiple

       COMF    PWM_PORT,W      ;Get the current state of pwm outputs
                               ;
       DECFSZ  pwm0,F          ;If the first counter has not reached 0
        XORLW  00000001b       ;then we don't want to turn it off.
                               ;
       DECFSZ  pwm1,F          ;Same for the second one
        XORLW  00000010b       ;
                               ;
       DECFSZ  pwm2,F          ;and so on...
        XORLW  00000100b       ;
                               ;
       DECFSZ  pwm3,F          ;
        XORLW  00001000b       ;
                               ;
       DECFSZ  pwm4,F          ;
        XORLW  00010000b       ;
                               ;
       DECFSZ  pwm5,F          ;
        XORLW  00100000b       ;
                               ;
       DECFSZ  pwm6,F          ;
        XORLW  01000000b       ;
                               ;
       DECFSZ  pwm7,F          ;
        XORLW  10000000b       ;
                               ;
                               ;
       MOVWF   PWM_PORT        ;update the outputs
                               ;
       INCFSZ  rising_edge,F   ;
        COMF   PWM_PORT,F      ;

       RETURN


Experienced pic users will scoff at the next to the last instruction.

but for another cycle you could change the last 4 instructions to what
they were before;

       XORLW   11111111b       ;Toggle the current state.
       INCFSZ  rising_edge,F   ;If the rising edge counter has not
        XORLW  11111111b       ;rolled over then toggle them again.
                               ;Double toggle == no effect. However,
                               ;if the rising edge counter does roll
                               ;over then a single toggle will turn
                               ;the pwm bits on, unless of course the
                               ;pwm counter has just rolled over too.
                               ;
       MOVWF   PWM_PORT        ;update the outputs

So at least 2 or 3 cycles are saved. Now if I could only figure out how to
save 19 more I could save microchip from bankruptcy :).

-------------
on the 18cxxx, it'd be possible to do things like:

       movf    PWM_PORT,W
       dcfsnz  pwm0,f
        andlw  11111110b

       ...

       incsnz  rising_edge,f
        iorlw  0xff
       movwf   PWM_PORT

I count 20 cycles. There's a glitched and skewed version hardly worth
mentioning that takes only 18 cycles. But that damn AVR still kills the
18cxxx.

Scott

2000\03\02@202240 by William Chops Westfield

face picon face
>   Your code consists of a 256 instruction (branching) isosynchronous
> loop.  It outputs the MSB register value for 128 cycles (bit-banging
> your serial input during this time, the next Significant Bit register
> for 64 cycles (more bit-banging), the next for 32 cycles until at the
> end the second LSB is output followed directly by the LSB.


I don't quite understand what you're saying.  But...

To get adequate performance, you have to output one byte each instruction or
so, right?  256 instructions for the loop, at 10mips or so, is
35+kloops/sec, so you're in the right ballpark.  10mips is a (fast) 10MHz
AVR, (overclocked) 40MHz Pic, or mid-range Scenix (assuming they all do
the memory to ioport move in

Now, the data isn't random - the "MSB" will be either set or unset for
the first half of the table (on all output bits.) (I guess this is what
makes up a "vertical counter"?)  So you can output the MSB bits on all
ports, and then do 127 cycles of "other work", and your table doesn't
take a full 256 bytes  (more "vertical counter" ?)  You CAN use a simple
table for as many of the low order bits as are "too fast", though...

ie, your code on an AVR looks like:

.equ    B7, =R20                ;Most significant bit, 8 pins
.equ    B6, =R21                ; next bit
.equ    B5, =R22                ;  next bit
.equ    B4, =R23                ;   next bit
.equ    B3, =R24                ;    next bit
.equ    B2, =R25                ;     next bit
.equ    B1, =R26                ;      next bit
.equ    B0, =R27                ; Least significan bit

Loop:   out     portd, B0
       out     portd, B1
       out     portd, B1
       out     portd, B2
       out     portd, B2
       out     portd, B2
       out     portd, B2
       repeat   8, <out portd, b3>
       repeat  16, <out portd, b4>
       repeat  32, <out portd, B5>
       repeat  64, <out portd, B6>
       repeat 126, <out portd, B7>     ; leave cycles for branching
       rjmp    Loop

(actually, the avr assembler doesn't have a repeat pseudo-op.  use your
editor if you must!)

The pic architecture loses a single bit of precision for any given MIPS rate
because it doesn't have "mov f1,f2" style instructions - everything has to
go through W.

Then you can start replacing some of the larger blocks of  "out"
instructions with more useful code - after all, the ports have latches :-)

BillW

2000\03\03@005321 by Dan Michaels

flavicon
face
Scott, BillW, Paul,

Without taking the time to analyze all of your individual
algorithms, I was wondering which of these do, and which
of these don't, have the PWM period independent of the
PWM duty cycle?

The major screwup with the scenix PWM algorithm, as I
noted earlier, is that the period is not fixed, but varies
with the duty cycle value. Result - a real mess from a
practical perspective, regarding selection of smoothing
filter values, cap droop, ckt response times, etc.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\03\03@051508 by paulb

flavicon
face
Scott Dattalo wrote:

> The concept I'm having trouble grasping is the '256 instruction
> isochronous loop' that is capable of 8-bit pwm on 8 channels.
> Enlighten us Paul.  On a pic, it takes two cycles to increment one
> stage of a vertical counter.

 Bill W has twigged to it.  The trick is to use the Program Counter
itself - note *Counter* - as the PWM.  Increments with each cycle.

William Chops Westfield wrote:

> I don't quite understand what you're saying.  But...

 But your subsequent explanation is essentially perfectly correct.

> 256 instructions for the loop, at 10mips or so, is 35+kloops/sec, so
> you're in the right ballpark.  10mips is a (fast) 10MHz AVR,

 I think the specified rate was 30 kHz full PWM cycling, and a fairly
standard 8 MHz AVR does that.  I believe the Scenix operates at one
instruction cycle per clock, and can do a transfer in two instructions,
so a 16 MHz Scenix could presumably do the same.

> .equ  B7, =R20                ;Most significant bit, 8 pins
> .equ  B6, =R21                ; next bit
> .equ  B5, =R22                ;  next bit
> .equ  B4, =R23                ;   next bit
> .equ  B3, =R24                ;    next bit
> .equ  B2, =R25                ;     next bit
> .equ  B1, =R26                ;      next bit
> .equ  B0, =R27                ; Least significant bit
 .equ  Bnul, =R28              ; Null state

 So far so good.  See if you can figure what Bnul does!

Loop:   out     portd, B3
; seven instructions go here
       out     portd, B4
; fifteen instructions go here
       out     portd, B5
; thirty-one instructions go here
       out     portd, B6
; sixty-three instructions go here
       out     portd, B7
; 127 instructions go here
; Start of original loop.
       out     portd, Bnul
       out     portd, B0
       out     portd, B1
       nop
       out     portd, B2
       nop
       rjmp    Loop

 Couldn't resist an optimisation by convolution there!

 And in fact, you have at least 244 useful instructions available per
loop in the above schema, should easily be enough to input serial data,
interpret and update the vertical counters.

 Obviously you can and will loop or subroutine out to other code, use a
state machine etc., as long as it is isosynchronous.

Dan Michaels wrote:

> Without taking the time to analyze all of your individual algorithms,
> I was wondering which of these do, and which of these don't, have the
> PWM period independent of the PWM duty cycle?

 The period of the above is absolutely *fixed*.  It is in fact,
immutably 256 instruction cycles (or an integral multiple thereof).
--
 Cheers,
       Paul B.

2000\03\03@073143 by Scott Dattalo

face
flavicon
face
On Fri, 3 Mar 2000, Paul B. Webster VK2BZC wrote:

> Scott Dattalo wrote:
>
> > The concept I'm having trouble grasping is the '256 instruction
> > isochronous loop' that is capable of 8-bit pwm on 8 channels.
> > Enlighten us Paul.  On a pic, it takes two cycles to increment one
> > stage of a vertical counter.
>
>   Bill W has twigged to it.  The trick is to use the Program Counter
> itself - note *Counter* - as the PWM.  Increments with each cycle.

Got it. We discussed this before... Damn I'm getting old.

This routine is easily adaptable to a pic. However, there's an 8x hit in
performance (two for the mov instruction and 4 for the tcycles). A 20Mhz
pic would cycle through the algorithm with a 9.7kHz frequency. A 10 Mhz
AVR would be around 39khz and a 100Mhz scenix would be around 195kHz.


> Dan Michaels wrote:
>
> > Without taking the time to analyze all of your individual algorithms,
> > I was wondering which of these do, and which of these don't, have the
> > PWM period independent of the PWM duty cycle?
>
>   The period of the above is absolutely *fixed*.  It is in fact,
> immutably 256 instruction cycles (or an integral multiple thereof).

Actually that's not completely true, Paul. For example, suppose one of
your pwm outputs was specified (horizontally) as 10100000 binary. The msb,
bit 7, and bit 5 are both set. So of the 256 states of the pwm output, you
want 2^7 + 2^5 or 160 high. In the psuedo-routine you posted, these 160
high cycles will be split into two pieces. There would be a 128 cycle
pulse and a 32 cycle pulse. Now if you had a pwm output with just
10000000, or 2^7, it would be high for 128 of the 256 cycles. The latter
would have half the frequency of the former. This would be no problem if
you pwm's were low-pass filtered with a filter whose cut-off frequency was
designed for the lowest frequency output.

The routine I posted uses counters. All pulses turn on at the exact same
time and turn off at time that's proportional to the pulse width. So,
regardless of the pulse width, the frequency of the each is the same. If
you're generating analog voltages from filtered PWM, I'd use the approach
Paul has outlined. I'm not sure what Dan's application is, but it sounds
as though if he requires synchnous pwm's.

Scott

2000\03\03@081937 by paulb

flavicon
face
Scott Dattalo wrote:

> >   The period of the above is absolutely *fixed*.  It is in fact,
> > immutably 256 instruction cycles (or an integral multiple thereof).
> Actually that's not completely true, Paul.

 Strictly, it is true.  The period of the (complex) waveform is fixed.
You are of course referring to the harmonic distribution which varies
widely with this approach, as also for the Phase Accumulator approach,
as the waveform can readily approximate a predominant second or third
harmonic, even higher.

 The critical point is that it is by and large *highly desirable* for
it to do so as the filtering *must* be determined by the fundamental
frequency, or period if you so look at it, so if it must be able to
filter the lower frequencies sufficiently, will actually become smoother
at the higher harmonics.

 My earlier comment was to the effect that it might even be desirable
to sacrifice some simplicity to insert extra swaps of output status,
breaking up the MSB and nearby states and spreading these throughout the
cycle.

 The Phase Accumulator code is even better in this respect as it
always(?) maximises the frequency of state changes of the output so that
a value of $80 results in a continuously alternating output state.  I'll
leave a full analysis of this out just now...

 A contrary argument may be made that doing this, increasing the
frequency of commutations may for example in power applications, stress
the switching stage, for example charge storage in FETs.  I daresay this
can be valid, though tending to the opinion that if the stage can't
switch cleanly, it isn't suited for PWM in the first place.

 I wonder if Dan could explain the concern he has for a constant cycle
frequency vis-a-vis the above?  I didn't follow why a given PWM
algorithm would *not* have a constant period unless mark and space were
separately defined *other* than as complements?
--
 Cheers,
       Paul B.

2000\03\03@082954 by Edson Brusque

face
flavicon
face
Good morning (well, it's 10:11AM here),

   thanks all the people "engaged" in this thread.

   It seens there's no dedicated chip to make something like this actually
in production, so, I'll have to develop an application on a
microcontroller... Ok, I can live with it.

   I must say that the PWM frequency have to be constant and above 20KHz,
the duty cycle have to be controled by serial input and 8-bit resolution
(0-100% duty cycle is necessary). The serial input have to be relatively
fast (above 38400bps).

   It seens the AVRs are the best solution for this.

   Best regards,

   Brusque

2000\03\03@113353 by Dan Michaels

flavicon
face
Brusque, BillW, Paul, Edson, Scott,

I discovered while "testing" the scenix PWM algorithm (ie, looking
at it on the scope) that it had several interesting side-effects
which weren't obvious from looking at the code. Leading me to other
questions to ask re *any* algorithm for PWM:

1. Does it work as well for duty cycle values not a power of 2?

  Again, regarding the scenix algorithm, the periods were quite
  jittery for *every* duty cycle value except 2, 4, 8, 16, etc
  (based on 256). Doesn't matter for lighting bulbs, where your
  eye filters out everything above 25 hz, but for real control ???

2. What do things look like for very large and very small duty
  cycle values?

  As I recall, the scenix algorithm produced long periods for
  small/large duty, and short periods for the middle ground
  - kinda parabolic.

3. Can these s.w. algorithms be improved so as to spread the
  on-time more evenly over the entire period, rather than just
  having a variable length pulse at the beginning only? In
  other words, a 30% PWM can be either 1 30% long pulse at the
  beginning, or 6 5% long pulses spread evenly over the entire
  period.

  The even spread is much easier to deal with in post-PWM
  electronic circuitry, especially when the period tends to be
  on the slow side. Response to change is also better.

Algorithms keyed to some kind of fixed period h.w. counter (TMR0,
PC, etc) will probably do alright. Those keyed only to some kind
of s.w. counter technique *may* not.

Who knew PWM would be so durn complicated? This is all too much
math for me. Just give me a nice capacitor and I'm happy.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\03\03@114614 by Harold M Hallikainen

picon face
On Thu, 2 Mar 2000 17:22:17 PST William Chops Westfield <billwspamKILLspamCISCO.COM>
writes:
>
> The pic architecture loses a single bit of precision for any given
> MIPS rate
> because it doesn't have "mov f1,f2" style instructions - everything
> has to
> go through W.
>
>

       Until you move to the 18cxx series. The 18c452 has mov f1,f2.

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

2000\03\03@122529 by Scott Dattalo

face
flavicon
face
On Fri, 3 Mar 2000, Harold M Hallikainen wrote:

> On Thu, 2 Mar 2000 17:22:17 PST William Chops Westfield <.....billwKILLspamspam.....CISCO.COM>
> writes:
> >
> > The pic architecture loses a single bit of precision for any given
> > MIPS rate
> > because it doesn't have "mov f1,f2" style instructions - everything
> > has to
> > go through W.
> >
> >
>
>         Until you move to the 18cxx series. The 18c452 has mov f1,f2.

Which execute in two cycles instead of cycle like most all of the other
18cxxx instructions. The only benefit it provides is that W doesn't get
trashed in register to register transfers.

However, the 4x internal pll in the 18cxxx will allow one instruction to
be executed for each (external) crystal/clock cycle. So the AVR has only
2x benefit on performance (for the pwm algorithm). I bet it has more than
that for cost though.

Scott

2000\03\03@141827 by Scott Dattalo

face
flavicon
face
On Sat, 4 Mar 2000, Paul B. Webster VK2BZC wrote:

> Scott Dattalo wrote:
>
> > >   The period of the above is absolutely *fixed*.  It is in fact,
> > > immutably 256 instruction cycles (or an integral multiple thereof).
> > Actually that's not completely true, Paul.
>
>   Strictly, it is true.  The period of the (complex) waveform is fixed.

Hmm. Then what are the relative frequencies of these two wave forms:

 +------------------------+                        +---
 |                        |                        |
--+                        +------------------------+

 +------------------------+           +-----+      +---
 |                        |           |     |      |
--+                        +-----------+     +------+

?

If I interpret the algorithm correctly, the top waveform has a 50% duty
cycle and is what's produced for a pulse width that's specified to be
10000000 binary. The bottom has a DC (not duty cycle) value that is 62.5%
of the peak value and is what's produced if the pulse width is specified
to be 10100000 binary. It's true that taken by themselves, the wave forms
(or complex waveforms as you've identified), are periodic and constant.
However, the first waveform has a lower frequency component not present in
the second. (Or said differently, the second wave form's fundamental is
twice the first's.)



> You are of course referring to the harmonic distribution which varies
> widely with this approach, as also for the Phase Accumulator approach,
> as the waveform can readily approximate a predominant second or third
> harmonic, even higher.

Perhaps we're struggling with semantics...

{Quote hidden}

As you alluded and Dan experienced, the phase accumulator pwm algorithms
have the highest frequency fundamentals when the DC component is 50% of
full scale. As you approach the extremes of 0% and 100%, the fundamental
frequencies decrease. So the extremes are harder to filter.



>
>   A contrary argument may be made that doing this, increasing the
> frequency of commutations may for example in power applications, stress
> the switching stage, for example charge storage in FETs.  I daresay this
> can be valid, though tending to the opinion that if the stage can't
> switch cleanly, it isn't suited for PWM in the first place.

Should we start talking about magic sine waves again :).

Scott

2000\03\03@145157 by jamesnewton

face picon face
Yes, please; start talking about Magic Sinewaves. I've yet to see anything
useful done with them and would like to know if there is some fundamental
flaw.

---
James Newton EraseMEjamesnewtonspam_OUTspamTakeThisOuTgeocities.com 1-619-652-0593
http://techref.massmind.org NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)


{Original Message removed}

2000\03\03@150436 by Dmitry Kiryashov

flavicon
face
Hi Scott and other guys.

> Should we start talking about magic sine waves again :).

Magic sinewaves are really interesting case to produce analog signal.

So I guess it will be helpful for us to drop some light on it, for
instance discuss some math stuff around it.

Common approach is to generate it onfly without big tables.

What do you think Scott ?

WBR Dmitry.

2000\03\03@155638 by Scott Dattalo
face
flavicon
face
On Fri, 3 Mar 2000, Dmitry Kiryashov wrote:

> Hi Scott and other guys.
>
> > Should we start talking about magic sine waves again :).
>
> Magic sinewaves are really interesting case to produce analog signal.
>
> So I guess it will be helpful for us to drop some light on it, for
> instance discuss some math stuff around it.
>
> Common approach is to generate it onfly without big tables.
>
> What do you think Scott ?

I think I've opened a can of worms!

I haven't really done a whole lot of thinking about magic sine waves
lately. But if you want to get the theoretical/mathematical background,
take two aspirins and click here:

http://www.dattalo.com/technical/theory/sqwave.html

you can also try searching Lancaster's page(s)
http://www.tinaja.com/
but the last time I checked, there wasn't anything substantive on magic
sinewaves - i.e. no description in theoretical terms of the hype behind
magic sine waves.

It all boils down to harmonic cancellation though. I've got two ideas how
one could go about synthesizing optimal pulse streams for magic sine
waves, but both require much more time than I have to devote. The first
one resorts to optimal programming (in a mathematical sense, not pic
microntroller sense), or linear programming. If you're familiar with the
traveling salesman problem, then you already understand the concept.
Instead of cites, we're dealing with pulses; and instead of distance,
we're optimizing harmonics. The problem with this approach is that for
even moderately sized pulse streams, the (square) matrices are enormous.
But it is possible to mathematically express the constraints.

The other theoretical idea for synthesis involves simplification. In other
words, remove the time digitization constraint and assume that the pulse
edges can occur anywhere. Then start asking questions like: given 16
pulses, what are the most optimum locations and widths to obtain sine
waves that suppress the first blah harmonics by xx dB (with respect to the
fundamental). Once these edge locations are determined, then digitize them
(in time) and do a post analysis to see how much error the digitization
process introduces. To achieve the desired goals, you may determine that
the edges must be resolved to 1us accuracies but that 5us is okay except
for a spike at the 4th harmonic.


Scott

2000\03\03@160054 by paulb

flavicon
face
Scott Dattalo wrote:

> Hmm. Then what are the relative frequencies of these two wave forms:
>
>   +------------------------+                        +---
>   |                        |                        |
> --+                        +------------------------+
>
>   +------------------------+           +-----+      +---
>   |                        |           |     |      |
> --+                        +-----------+     +------+
>
> It's true that taken by themselves, the wave forms (or complex
> waveforms as you've identified), are periodic and constant.
> However, the first waveform has a lower frequency component not
> present in the second. (Or said differently, the second wave form's
> fundamental is twice the first's.)

 Sorry, you have that backwards.  Both have the same fundamental
frequency.  The second has a second harmonic frequency component not
present in the first.  The fundamental amplitude is slightly lower.  It
will be overall slightly better filtered by a given low-pass filter.

> As you alluded and Dan experienced, the phase accumulator pwm
> algorithms have the highest frequency fundamentals when the DC
> component is 50% of full scale. As you approach the extremes of 0% and
> 100%, the fundamental frequencies decrease. So the extremes are harder
> to filter.

 I am exactly aware of that, but there is only one solution for the
value 1 (or 255).  Just a fact of life.  I think there is usually a
value in stochastic improvement (i.e., having something work better
*most* of the time as long as the worst case is acceptable).

> Should we start talking about magic sine waves again :).

 Be my guest.  Pass.
--
 Cheers,
       Paul B.

2000\03\03@162318 by Dan Michaels

flavicon
face
At 11:45 AM 3/3/00 -0800, you wrote:
>Yes, please; start talking about Magic Sinewaves. I've yet to see anything
>useful done with them and would like to know if there is some fundamental
>flaw.
>
>James Newton jamesnewtonspamspam_OUTgeocities.com 1-619-652-0593

tinaja.com Don Lancaster first started talking about these things,
I think, in his "CMOS Cookbook", orig published 1977. He also
has mentioned them in several of his columns and has files
somewhere on his website.

I looked at this stuff, and despite what was written, it appeared
to me these things have such horrendous harmonic energy that they
aren't very useful, w/o really good lowpass filtering. But with
modern switched cap filters, who knows.

[BTW, they say it took the first fax machine 25 years to catch on,
too - it just appeared a little before its time].

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\03\03@210330 by Anthony Rudzki

flavicon
face
>
>     thanks all the people "engaged" in this thread.
>
>     It seens there's no dedicated chip to make something like this
actually
> in production, so, I'll have to develop an application on a
> microcontroller... Ok, I can live with it.
>
You could check an 82C54.  It is a timing chip that I saw used in an
application for motor control and it was using PWM for that control.  Its
right before the 82C55 PIA chip in the intel data books.


tony

2000\03\04@100628 by Scott Dattalo

face
flavicon
face
On Sat, 4 Mar 2000, Paul B. Webster VK2BZC wrote:

{Quote hidden}

Of course, you're right Paul.

This:

 +------------------------+           +-----+      +---
 |                        |           |     |      |
--+                        +-----------+     +------+

Is not the same as:

 +------------+           +------------+           +---
 |            |           |            |           |
--+            +-----------+            +-----------+

The latter's fundamental frequency is twice the former's.



Scott

2000\03\05@172650 by l.allen

picon face
>     It seens there's no dedicated chip to make something like this actually
> in production, so, I'll have to develop an application on a
> microcontroller... Ok, I can live with it.
>
Use a FPGA, ASIC etc... as they all discussed.. a micro
will struggle to do this in software with the specs you
require.
The very reason I got into FPGAs was a multiphase
PWM application that a microcontroller could not handle
but logic chips were out of the question due to high
component count and small space available.
_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

2000\03\05@223633 by Dan Michaels

flavicon
face
I apologize for sticking my nose into this discussion a
couple of times, and then not following every single e-mail,
but I just thought up a way to do 8-channel PWM - which
I don't think (????) was covered. Called:

"Math-Averse, Stupid Guy's, Hi-Speed 8-Channel PWM"

Use a lookup table.

The uC can't do anything else when it's running, and you
may get a fairly-long pause every time you change one of the
8 duty cycle values, since you have to reload or recalculate
the entire table.

**BUT**

On a 20 Mhz PIC, you could get rock-steady 8-channel PWM at
maybe 1-2 usec/step, or 1953-3906 Khz for 256 steps.

Or switching to a 50 Mhz Scenix SX18, you can get rock-steady
*7* bit 8-channel PWM at 200 nsec/step, or 39,062 Khz - limited
to 7 bits since SX RAM = 128 bytes.

; (send block to port B - 10 clocks/loop = 200 nsec).
send_block
       jmp     :L3       ; jump to re-start (initialization).

:lp1    nop               ; can insert code here for bailout.
       nop
       nop
:lp2    setb    FSR.4
       mov     w,IND
       mov     rb,w
       incsz   FSR
       jmp     :lp1      ; jmp takes 3 clocks on SX.

; (reload - re-entry takes exactly 10 clocks).
:L3     mov     w,#bufstart
       mov     FSR,w
       jmp     :lp2

[sorry to inject heretical scenix code into the PIC universe].

Better yet, you can easily spread the PWM energy evenly over
the period, to minimize external circuitry hassles. Better
yet - no need to jump into FPGA technology, if you aren't
already there.

regards,
- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\03\06@030535 by William Chops Westfield

face picon face
   "Math-Averse, Stupid Guy's, Hi-Speed 8-Channel PWM"

   Use a lookup table.

This was my initial reaction as well, until I did the math.

   On a 20 Mhz PIC, you could get rock-steady 8-channel PWM at
   maybe 1-2 usec/step, or 1953-3906 Khz for 256 steps.

A lookup table on a PIC takes two instructions per step, or 512
instructions per each (256 step) PWM cycle.  A 16 MHz pick does 4M
instruction/second, and 4M/512 is only 7812.5 cycles per second, much
lower than the 30kHz requested...

An interesting observation is that you can alway "compile" an 8 bit 256
value PWM chain into 8 port transitions per cycle ("compile" being very
similar to calculating your lookup table.)  This gives an edge to von
Neuman architectures - any vN machine that can change port bits in a
single instruction should do nicely.  This is about the first good
excuse for "self-modifying" code in a microcontroller I've seen in a
long time.  (Nah, not "self-modifying code", which is EVIL.  Rather
"incremental runtime compilation", which is OK. :-)

I *think* it ought to be possible to "compile" the 8x256 PWM setup into
a lookup table that allows for a larger number of cycles between output
transitions IFF you allow the PWM cycles to start at different times, as
long as they aren't all near maximum length (and you might be able to
treat THAT separately.)  Ie, a slow processor would not normally be able
to handle pulse lengths of 100 and 101 if the pulses started at the same
time, but you can shift one of these to START a bit later so that (for
example) one pulse runs from 0 to 99 and the next from 10 to 110...
This could double the number of transitions you make, but allow more
flexibility in the time between transitions.  Hmm.

BillW

2000\03\06@115505 by Dan Michaels

flavicon
face
BillW wrote:

>>    "Math-Averse, Stupid Guy's, Hi-Speed 8-Channel PWM"
>>
>>    Use a lookup table.
>
>This was my initial reaction as well, until I did the math.
>
>>    On a 20 Mhz PIC, you could get rock-steady 8-channel PWM at
>>    maybe 1-2 usec/step, or 1953-3906 Khz for 256 steps.
>
>A lookup table on a PIC takes two instructions per step, or 512
>instructions per each (256 step) PWM cycle.  A 16 MHz pick does 4M
>instruction/second, and 4M/512 is only 7812.5 cycles per second, much
>lower than the 30kHz requested...
>

Yeah, the PIC **is** slow, no faster than maybe 3.9 Khz as noted
[oops, I meant 3906 *HZ* above, not khz!!].

That's why I threw in the scenix stuff, which does go 39 Khz easily.
[this also supports my philosophy that "the SX is great for one
very fast VP, but not so good for more than one"].

In addition, for a dedicated app, you can code either uC as "linear
code" rather than loop code, and get lots more speed. Scenix could
do 60+ Khz rock-solid 7-bit PWM on 8 channels that way. [with linear
code you do have to account for "go back to beginning" at end of
block, to avoid skew].

{Quote hidden}

Also, I was thinking more along the lines of the lookup table
being in RAM, not compiled in. So you just modify the RAM table
for different duty cycles - although that would take a few cycles.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\03\06@131854 by Dan Michaels

flavicon
face
At 07:59 AM 3/4/00 +1100, PaulB wrote:

Scott wrote:
>> As you alluded and Dan experienced, the phase accumulator pwm
>> algorithms have the highest frequency fundamentals when the DC
>> component is 50% of full scale. As you approach the extremes of 0% and
>> 100%, the fundamental frequencies decrease. So the extremes are harder
>> to filter.
>
>  I am exactly aware of that, but there is only one solution for the
>value 1 (or 255).  Just a fact of life.  I think there is usually a
>value in stochastic improvement (i.e., having something work better
>*most* of the time as long as the worst case is acceptable).
>

The possible problem with a s.w. (scenix) algorithm, as opposed to
PIC's h.w. implementation of PWM, is that, once you pick a period
in the h.w. type, you know exactly what you have (and you can select
your filters accordingly), but with the s.w. solutions, the periods
*may* go all over the place (ala scenix), so you may be fooling
yourself as to what you think you have. You really have to fully
analyze the algorithm, before you can pick your LP filter.

And you're right, there is only one solution for value 1, but with
the PIC PWM h.w., the "fundamental" freq is always the same
regardless of duty = 1 or 128, whereas with the scenix sol'n, the
fundamental freq varied by 128 for those same duties. It may not
ultimately matter *except* that, once again, you need to know
the exact behavior so you can choose the LP filters correctly.

Worst case, your LP filter could be off by 128x. If I had simply
used the scenix algorithm without looking at the extremes, and
dumbly assuming it's fundamental freq was directly related to the
VP interrupt rate, I would have been in real trouble. [and sometimes
I do do dumb things in the heat of wanting to take off for capuccino
in the afternoon]. Looking at it on the scope saved my butt.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
==========================

2000\03\06@140951 by paulb

flavicon
face
Dan Michaels wrote:

> You really have to fully analyze the algorithm, before you can pick
> your LP filter.

 I just don't see the problem here.  Can you explain?  The word is
*low-pass* filter.  If it adequately smoothes a 1 in 256 duty cycle and
a 128 on: 128 off as for a strict PWM pattern, then it smoothes any
pattern with more frequent chopping even *more* effectively.

 What's wrong with that?
--
 Cheers,
       Paul B.

2000\03\06@150535 by William Chops Westfield

face picon face
   [self-modifying code.]

   Also, I was thinking more along the lines of the lookup table
   being in RAM, not compiled in. So you just modify the RAM table
   for different duty cycles - although that would take a few cycles.

Right.  They're very similar.  I was thinking along the lines of:

       for (i=0; i < 256; i++) {
           PWMCODE[i] = asm("NOP");    /* More fictional syntax! */
       }
       for (i=0; i < 8; i++) {
           PWMCODE[stoptime[i]] = asm("BCF port, i");
       }
       PWMCODE[256] = asm("ret");
       while (1) {
           outp(port, 255);            /* All bits on */
           asm ("call PWMCODE");       /* Call code to turn them off */
                                       /*    at appropriate times */
       }

This saves you one instruction (50%!!!) (assuming a pic) for each time you
only need to change one bit on the port, because you can put the bit number
in a single instruction instead of having to load w and then output it.

BillW

2000\03\06@170033 by paulb

flavicon
face
William Chops Westfield wrote:

> Right.  They're very similar.  I was thinking along the lines of:
>
>         for (i=0; i < 256; i++) {
>             PWMCODE[i] = asm("NOP");    /* More fictional syntax! */
>         }
>         for (i=0; i < 8; i++) {
>             PWMCODE[stoptime[i]] = asm("BCF port, i");

 .. etc..

 Along my principle of maximising the number of transitions per cycle
to optimise filtering, rather than minimising it, if one is to dedicate
a whole table to the process, it would seem desirable to use a pattern
similar in some sense to Gray code, to interleave the bits.

 The MSB should firstly (or lastly, however it works) be allocated to
every second bit, next MSB to every fourth bit between, next MSB every
8th and so on.

 Alternately, completely opposite tack, it does seem that since only
16 transitions overall would suffice to code 8 PWM waveforms, there must
be an algorithm to allocate these so no two channels ever (need to)
switch at once.  This will assist in optimisation of filtering the power
supply (EMI etc...) powering the end devices.

 Mathematical ponder - is it possible to resolve every case of eight
separate and independent PWM functions so that all 256 states contain a
transition?  If not, can 128 states always be filled?  Solution for all
successive transitions to be opposite?

 Hmmm.
--
 Cheers,
       Paul B.

2000\03\07@052406 by Dan Michaels

flavicon
face
At 08:46 AM 3/7/00 +1100, you wrote:
>Hello Dan.
>
....

{Quote hidden}

Speaking analog(ically), "a good low-pass filter is to PWM generated
in s.w. as a good coat of paint is to a do-it-yourself home-improvement
project" - I think Tim Allen from Tool Time said that.

regards,
- Dan Michaels

2000\03\07@052409 by Dan Michaels

flavicon
face
At 12:04 PM 03/06/2000 PST, you wrote:
>    [self-modifying code.]
>
>    Also, I was thinking more along the lines of the lookup table
>    being in RAM, not compiled in. So you just modify the RAM table
>    for different duty cycles - although that would take a few cycles.
>
>Right.  They're very similar.  I was thinking along the lines of:
>
>        for (i=0; i < 256; i++) {
>            PWMCODE[i] = asm("NOP");    /* More fictional syntax! */
...
...
>BillW
>

Speaking of self-modifying code, Jim Newton has been discussing
the idea of trying to get a PIC '877 to work as a single-chip,
multipurpose downloader/debugger/monitor. Sounds like it might
be able to recompile your table on the fly, too.

And speaking of modifying lookup tables in RAM, as it turns out,
this approach can be used to make a nice multi-phase, multi-pulse
function generator in s.w. On the scenix you can easily go 5 Mhz,
on the PIC maybe 500 Khz.

Besides 8-channel PWM, you can produce parallel outputs like

1   110000000000000000000000000000
2   001111111111110000000000000000
3   000111111111111000000000000000
4   000011111111111100000000000000
5   000001111111111110000000000000
6   000000111111111111000000000000
7   000000011111111111100000000000
8   000000001111111111110000000000

[although I can't for the life of me understand why anybody would
want to do something like this].

regards,
- Dan Michaels

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...