Blanking Pulses in TMS320F28027

we've been looking at this, and the best method we've come up with is to use a spare ePWM timer as a "longer timer", that we switch in to do the blanking (or thinning)

We use the synchronization feature of our PWM modules to achieve such switching by loading the TBPHS register with 65535 – Pause time – TBPRD/2 (applied every other N cycles). It is much simpler if we are running fixed frequency. Also, the + ½ cycle requirement is going to make us change the TBPHS register after every N cycle and that is why the factor TBPRD/2 in the above equation. The mechanism, however, will all be in the hardware. If we didn’t have the ½ cycle requirement, then there won’t be any software involvement other than what would be needed for the changing switching frequency.

You could also potentially use a PWM at a fixed frequency to fire a TZ which could hold your PWM output low for a given number of cycles.

Hey Chris,

Let me see if I got this right... the above scheme will potentially blank pulses at arbitrary points in channel 2's waveform, correct? The example you show above is benign in that the blanking causes the waveform of channel 2 to just continue in its current state. However, there is nothing to guarantee quick transitions up and down if the sync pulse comes after a recent transition.

For my application, I am using a fixed frequency, and it is tantamount that the on and off time add to the cycle period. For example, if my cycle period is 1uS, then a duty cycle of 0.4 means 400nS of on time and 600 nS of off time. Blanking the next pulse would mean that the next cycle has 1uS of off time. The difference I am trying to illustrate is that this is not the same as 400nS of on time and 560nS of off time, at which point the sync pulse comes and blanks the next pulse for 1uS since the counter is reset. That additional 40nS of off time from the first cycle MUST be there in my application.

Was that clear? If not, please let me know, and I will attach a picture that may better illustrate what my rambling does not.

Thanks,

- Chris

let's assume you have a 100Mhz clock, just to make the math easier.

Your PWM frequency is 1000ns, so that's 100 clocks

Here's what I'm thinking:

You can have your PWM work in count up mode, with the PWM starting at timer=0,  with a time base counting up 100 ticks, then resetting.

For the first two periods you do your standard CMPA for the duty cycle turning off.

On the second period, somewhere after the CMPA but before the PRD, you would want to use the phase register to load in a new period value. You would want this to be:

MAX PERIOD - (PERIOD * #BLANKCYCLES) - (PERIOD - NEWPHASELOADTIME) =

65536 - (100 * 4) - (100 - X)

You should be able to know this X exactly.  It may take disabling interrupts and working it out on the bench, but this should be quantifiable and consistent.  You wouldn't be able to have 100% duty cycle though....probably 90% max.  This would insure you load a new time base that would finish the  current period, plus exactly 4 more blanked, then reset and start over.

If we gave you more CMPx you could do this with a single timer. Set PRD = 600, CMPA is duty cycle off for period1 PWM OFF, CMPB is 100 and ON, CMPC is duty cycle for period2 and OFF, then period match.....(we are adding more CMP registers on future devices :) )

Thoughts?

Sorry for the delayed response...

Wouldn't this still require throwing an interrupt on the second period? It might be useful to have a 16 bit register that holds a larger period with its own compare that override local compare actions.

For example, you have a local period of 100 set by the PWM module and a global period of 1000 set by the same PWM module. Then, you use the same architecture already built in for the 100 cycle period for the "global" period of 1000. This would allow pulse blanking, though the pattern would still have to be periodic (I think).

I think additional CMPs will definitely add flexibility.

- Chris

you could use an INT from the 2nd period CMPA, or you could use a CMPB based INT with a built in off-set for the delay in loading the new period register to minimize that latency.

but yes, using an INT would be safest.  You're not talking about many cycles here, it's just coming in and out of the INT and setting the period register. You could have the computation pre calculated earlier in your PWM cycle.