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.

Scheduling timer compare with ePWM timers, ISR happens, but pin action doesnt...yet

Other Parts Discussed in Thread: TMS320F2808

 

Hello,

I decided to see if it was possible to implement a pulse scheduling system (as per an engine managment system I implemented on an 8-bit platform) using the ePWM timers of the F28XX DSP.  The DSP would make a great processor for giving me loads of time for complex control algorithms compared to the 8-bit CPU I currently use.

This is what would happen.  

The DSP would enter a timer compare ISR (say from a compare event where the pin action is to SET on compare). The code would set up the end of a pulse (a CLEAR on compare event ) to occur in the future.

Net result.  I see NO pulse at all,  but the interrupts are happening!!!   I discovered that although the DSP has generated the compare event ISR, the pin has not changed state (or SET) in this case.  After a couple of hours.......I discovered that the pin change occurs on the next timer count after the one that causes the compare match interrupt.

Should they not be the same thing?

What this means, is that if I am using a ePwm timer rate (for example) of FCPU/150 to get a 1us resolution with a maximum pulse width approaching 65msec (assuming no 16-bit roll capable code) ,   that once I get to my compare interrupt, I cannot set up the timer for the clear on compare until about 150 clock cycles later, because otherwise I will interfere with the SET event which hasnt happened yet - I have to hang around in the ISR waiting.

Why has the PIN state not changed at the point the DSP has generated an interrupt because of a compare match?  Is there a way to not waste CPU cycles?

(I mean other than assuming I having other work to do in the ISR, doing that first, and then setting up the timer compare register and action last so as to not waster too many cycles)

Regards, Nick