Re: PWM1 & PWM3 synchrounization problem of F2118 DSP!!

MSAD wrote:
Dear all,
Good day!!
I am setting COMPR1 and COMPR2 to produce two variable-duty cycle PWM
signals. although both signals are having the same period etc. (off
course
with different compare values). However, unfortunetly, what I am having
on
the Oscelliscope is that one signal is travelling with respect to
other
one.
on the other hand, if i use the same table (compare values) for both
COMPR1 and COMPR2 then both signals will be in sync. (tied to each
other).
hence, I can't really understand what makes one of them travelling
with
respect to the other since both of them are using the same timer1 and
same
period ,,, etc.
any comments/ suggestions would be greatly appreciated

kindes regards
MSAD

If you're going to mention specific registers you should specify what
processor you're using.

Since I have no idea what processor you're using I cannot be specific,
so here's some questions you can ask yourself.

* Are they really tied to one timer? Double check that manual!
* Is the timer a period register, or is this something perverse like
the Motorola (Freescale) 68HC11 where the timer always free runs
and the compare has to be jiggered in software?
* Some more advanced PWM generators will drive the timer in a triangle
wave, so the resulting PWM will be symmetrical around the peaks of
the triangle; this will result in PWM outputs that are centered on
each other, but who's edges are not synchronous.
* If you run the compares with different values for a while then go
back, to they become synchronous again?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/


thank you Tim for your concern, I really forgot to mentioned that I am
using F2118 DSP board. what I am doing is that setting COMPR1 and COMPR2
to generate a variable duty cycle PWM signals, and furthermore, the ISR is
trigrred whenever the period expired or compare is matched so that a new
value will be reloaded to the compare registers.... and for that I am
using the same timer GPTIMERA, so that both signals share the same timer
and have the same period etc. the only difference is that the compare
values as to generate different PWM pattern.
my problem now is that one signal is traveling with respect to the other,
however, if I reload both signals by the same compare values then I can
see they are tied to each other....I can't really understand what went
wrong??

regards

.

Relevant Pages

  • Didactic Quality of Datasheets (Texas Timers)
    ... But for the moment the Texas Instruments TMS320C24x Peripheral ... Only Timer 2&3 can be cascaded. ... its own compare function but there are also 3 full compare units and ... a hold current limited by PWM should ...
    (comp.arch.embedded)
  • Re: Didactic Quality of Datasheets (Texas Timers)
    ... > its own compare function but there are also 3 full compare units and ... > My Timer 2 is connected to an encoder. ... a hold current limited by PWM should ... This task requires 2 timer outputs one for initial pulse ...
    (comp.arch.embedded)
  • Re: PWM1 & PWM3 synchrounization problem!!
    ... I am setting COMPR1 and COMPR2 to produce two variable-duty cycle PWM ... although both signals are having the same period etc. (off course ... with different compare values). ... Is the timer a period register, or is this something perverse like ...
    (comp.dsp)
  • Re: phase comparator
    ... > I would like to compare the phase of two 1MHz sinewave and/or ... > squarewave) signals and get a output voltage proportional to their phase ... Is this because an IQ modulator/demodulator ... "Phase Lock Loop Circuit Design" by Dan Wolaver is a good book. ...
    (sci.electronics.design)
  • Re: fixed time slices?
    ... Implementation of KeWaitFor* and KeSetEvent (and other signals) doesn't ... This hasn't anything to do with hardware's timer resolution ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, ... AFAIK the scheduler does not behave this way but if the scheduler ...
    (microsoft.public.win32.programmer.kernel)