68300

I am using a 68332 with the 'G' TPU stamp in two applications.  One 
application needs a variable frequency output, and the other needs a 
variable duty cycle adjustment (but set frequency) and each only has 
one TPU channel. They both require on-the-fly adjustments (operating 
in a closed-loop control application).  I have identified the Queued 
Output Match (QOM) function as the best possible candidate for both 
applications. But, from the application note, I cannot tell if when 
the TPU registers are updated, will I get a non-desired output at the 
transition point? For example, when the update is entered will it 
take affect mid-signal and possibly produce a transient with a much 
higher frequency component, or does it wait for the in-process output 
signal to complete before initiating the next update?

Thanks for any inputs, Jeff

You could always assemble and download the microcode for the PWM routine 
from the A version. That way you can also buy either processor and your 
code never knows the difference.

Andrei

At 08:01 PM 1/27/2003 +0000, you wrote:

>I am using a 68332 with the 'G' TPU stamp in two applications.  One
>application needs a variable frequency output, and the other needs a
>variable duty cycle adjustment (but set frequency) and each only has
>one TPU channel. They both require on-the-fly adjustments (operating
>in a closed-loop control application).  I have identified the Queued
>Output Match (QOM) function as the best possible candidate for both
>applications. But, from the application note, I cannot tell if when
>the TPU registers are updated, will I get a non-desired output at the
>transition point? For example, when the update is entered will it
>take affect mid-signal and possibly produce a transient with a much
>higher frequency component, or does it wait for the in-process output
>signal to complete before initiating the next update?
>
>Thanks for any inputs, Jeff
>
>
>---------------------------------------------------
>To unsubscribe from this group, send an email to:
>68300-unsubscribe@yahoogroups.com
>
>To learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Jeff,

For the variable duty cycle (PWM type) function using QOM:
It is probably best to simply write the new "on" interval parameters 
into the parameter RAM timing segments with the QOM in continuous 
mode. Worst case delay in update would be one "pwm" period + normal 
microcode latency.  I like this better than using the full host 
service with immediate update, since this could indeed cause 
considerable jitter and very narrow spikes with hi-freq content. If 
your "on" time is defined by 2 entries in the parameter RAM, then 
update with a 32-bit (atomic) write.  If more than 2 entries, then 
you might want to consider using a different T1/T2 clock rate or 
updating the value in steps.

For the variable frequency output channel:

If you're merely changing period while "on" time remains fixed, then 
use the above technique applied to the "off" time.

One thing to remember when using QOM is that the delta times per each 
entry in the parameter RAM is only 15-bits, since the low bit is used 
to determine the hi/lo pin state at the end of the interval. 

Frank  

--- In 68300@yahoogroups.com, "jeffreyslcu <jeffrey.s.sato@l...>" 
<jeffrey.s.sato@l...> wrote:
> I am using a 68332 with the 'G' TPU stamp in two applications.  One 
> application needs a variable frequency output, and the other needs 
a 
> variable duty cycle adjustment (but set frequency) and each only 
has 
> one TPU channel. They both require on-the-fly adjustments 
(operating 
> in a closed-loop control application).  I have identified the 
Queued 
> Output Match (QOM) function as the best possible candidate for both 
> applications. But, from the application note, I cannot tell if when 
> the TPU registers are updated, will I get a non-desired output at 
the 
> transition point? For example, when the update is entered will it 
> take affect mid-signal and possibly produce a transient with a much 
> higher frequency component, or does it wait for the in-process 
output 

> signal to complete before initiating the next update?
> 
> Thanks for any inputs, Jeff