PWM trick

Something looks wrong there...

Jim Thomas wrote:
> Vladimir Vassilevsky wrote:
>> This is what delta sigma is for.
>>
>> Noise shaping 1:
>>
>> for(;;)
>>  {
>>  x = sample + carry_over;
>>  if(x & 0x80) set_bit();
>>  else clr_bit();
>>  carry_over = x&0x7F;
>>  }

So far, so good. Basic first order, fraction saving, whatever you want 
to call it. The integer part is always 0 or 1, which is output, and the 
fraction is saved. Result happiness.

>> Noise shaping 2:
>>
>> for(;;)
>>  {
>>  x = sample + (carry_over0<<1) - carry_over1;
>>  if(x & 0x80) set_bit();
>>  else clr_bit();
>>  carry_over1 = carry_over0;
>>  carry_over0 = x&0x7F;
>>  }

That is not so good. The second order version produces an integer part 
which is 0, 1 or -1, but it is being treated as though it can only 
produce 0 or 1. Result misery.

>> The noise shapings of the higher order are less interesting because 
>> they require multiplication.
> 
> That's pretty cool Vladimir.  Thanks for the reply.  If this ever comes 
> up again, I'll try it this way.

Regards,
Steve

Steve Underwood wrote:
> Something looks wrong there...

Wow. Eagle's eye :-)

After the posting, I noticed that the 2nd order function was wrong, but 
I didn't expect anyone to recognize.

>>> for(;;)
>>>  {
>>>  x = sample + (carry_over0<<1) - carry_over1;
>>>  if(x & 0x80) set_bit();
>>>  else clr_bit();
>>>  carry_over1 = carry_over0;
>>>  carry_over0 = x&0x7F;
>>>  }
> 
> 
> That is not so good. The second order version produces an integer part 
> which is 0, 1 or -1, but it is being treated as though it can only 
> produce 0 or 1. Result misery.

You are right. The calculations should be in signed 10 bits and X should 
be compared as higher or lower then 128, not just checked the bit.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Scott Seidman wrote:
> Jim Thomas <jthomas@bittware.com> wrote in news:13kll479jpttd22
> @corp.supernews.com:
> 
>> Since the PWM was the only thing going on at the time, I don't think an 
>> IRQ would make it go any faster - especially when the context switching 
>> overhead is taken into account.
> 
> 
> You're doing 2 comparisons, 1 increment, and a set or clear bit every pass 
> through your loop!  Compare this to two set or clear for each PWM period.  
> You should be able to go many times faster, at least, using a timer, 
> context switching or no.
> 

Ah... I see what you're getting at now.  Your approach is more like my 
first stab with two transitions per PWM period.

Also, I didn't really implement the PWM as posted (that was supposed to 
be illustrative).

In the test application I actually had to generate four different 
voltages at the same time.  All these voltages were output on pins from 
a single port.  I ended up pre-computing the values I needed and then 
blasted them out:

  for(i=0; i<sizeof(pwm_bits); i++)
  {
    PORTF = pwm_bits[i];
  }

There are still sizeof(pwm_bits) compares per PWM period (i.e., the 
check for loop termination), so perhaps using a timer would have been 
faster.

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com    (603) 226-0404 x536
A pessimist sees the glass as half-empty.  An optimist sees it as half-full.
An engineer sees it as oversized by 74%, allowing for a 15% margin of error.