This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How generate multiple non-overlapping PWM signal with MSP430 hardware timer



In our design we need to generate multiple PWM signals.

Each of them may have a different duty cycles, but totally it should be 100%.

Non of the signal overlaps with one another.

We already have software based solution (timer interrupt to set/reset IO pin) and it works fine.

But is it possible to do it with hardware PWM to save software overhead ?

It seems with capture and reset/set/toggle function of MSP430,

we can only generte two PWM signals to share a 100% duty cycle: using Output mode 2 and

Output mode 7. 

If we use second or third channel TBxCL2 or TBxCL3, it only generates new PWM signal

with different EQU1 point in above picutre,

but not be able to get we want we need: multiple non-overlapping PWM signals.

Any suggestions?

  • If you try very hard, you should be able to start multiple timers with desired phase differences between them. I do not know if that is worth it.

  • With the MSPs internal hardware, this i indeed very hard to do. For each signal, you need a different timer. Because the CCR units of a timer have only one 'free' trigger point, the other one (if used) is always the same: the timer overflow.

    So you'd need an MSP woth 4 timers and synchronize them (which is a bit difficult but doable).

    A different way uses some special hardware: For each signal, you need an R/S flipflop. It gets set by the falling edge of the previos signal and reset by the output of the CCR unit. So you only program the endpoint of each signal in teh CCR unit. The start point (begin of the duty cycle) is the end of the previous one.
    This is exact (rising edge of one signal happens at the same time as the falling one of the previous) since the delay by the flipflop is the same for all. And it is easy to implement. Just one 74HC or 4xxx logic chip needed.
    Well, sometimes external hardware is better and mor epoerful than the best software :)

  • Sometimes external right hardware is better. There's many (BDLC motor control) microcontrollers with way more sophisticated timers which possibly will support particular function.

  • Ilmars said:
    There's many (BDLC motor control) microcontrollers with way more sophisticated timers which possibly will suppo

    Maybe. But maybe an MSP is cheaper. Not only the cost of the CPU itself, but also the development time, whci also costs money. If you're used to the MSP, switchign to a different, especially to a specialized MCU, can be very time consuming and therefore costly.

  • Jens-Michael Gross said:
    Maybe. But maybe an MSP is cheaper. Not only the cost of the CPU itself, but also the development time, whci also costs money. If you're used to the MSP, switchign to a different, especially to a specialized MCU, can be very time consuming and therefore costly.

    Yes. You are so right. But considering that post author did not specify key requirements such as PWM cycle frequency and resolution, development team skill and capacity, BOM constraints, expected production volume and not only that - we can only guess how much msp430 is OK for this or better use other uC like TI C2000 or one of many ARM uC's.

    What I am trying to tell here - don't stick to what you have and know by all means. Look around for other available options to possibly find better one.

  • If I were doing this task I might use Timer B.  I would set up each individual pulse using ISRs.  Because the output pulses cannot overlap, you have a natural limit to the performance requirements of the CPU.

    Timer B allows latch-loading options that let you set up an entire pulse (both edges) in one ISR.  Use output mode 4 (toggle).  Make the first CCR write using CLLD_0, and make the second CCR write using CLLD_3, both in a single ISR execution.  When a channel gives an interrupt, it has either started or ended a pulse.  In the ISR determine if you should set up the next pulse now or wait for the next interrupt from this channel.  (Be careful here.)  Every channel driving an output has its interrupt enabled.

    I would guess the timer would run in UP mode since that might simplify calculating match values.  Calculations of match values should be done outside the ISRs.

    It's about the same CPU overhead as you have now, but the output timing is perfect instead of being subject to interrupt latency like the current solution.

    Jeff

  • An alternative setup could be running the tiemr in cont mode. YOu knwo the initial delay for each channel from synchronous start to the first edge, then the numbe rof ticks to  the second edge and then to teh first edge again.

    Each CCR generates an interrupt, and inside the ISR you simply add the first or second value (high or low duration) to the current CCR value. As long as you don't miss an interrupt or perform the updat etoo late, you'll properly get the required pattern.
    It is basically the same as running different intervals on the same timer.

**Attention** This is a public forum