TMS320F28062: Can I cut a position compare output pulse short?

Hi Radey,

Could you share some code snippets you have for this use case? I am not understanding the configuration completely.

Are you using an eQEP signal as your output signal, PCSOUT in the TRM (can be index or strobe pin), or just a regular GPIO to generate your output pulse? PCSPW in the QPOSCTL register will only have an effect if using the eQEP signal PCSOUT.

Based on the below, it sounds like it'd be better to use a regular GPIO not attached to the eQEP module and set it high/low in an interrupt.

Radey Shouman said:

I am trying to use the position compare output feature of the EQEP unit to output a pulse that rises at one position compare, and falls at a different position compare.  I can see the output pulse, and have configured an interrupt handler for the position compare event -- these work fine.

Best,

Kevin

snip.asmHi Kevin,

I have attached a snippet of asm code.  Unfortunately it does not have all the definitions needed to actually assemble it, but perhaps it will give an impression.

I am using the strobe pin as an eQEP output.  I have a requirement for less than 100 ns (8 cycles) from position match to rising edge of the output signal, so using an ISR to toggle a GPIO is not workable.

The idea behind the code attached is that an eQEP output pulse is used to generate the edges, and the ISR turns the eQEP pin into a GPIO before the end of the pulse, then busy waits until the pulse is over to turn the pin back into an eQEP pin.  I would like to eliminate that busy wait.

regards,

Radey

Hi Radey,

OK, I think I have a decent understanding of what you're trying to accomplish. Is the method you are currently using working and you're just wondering if there's a better way? I'll need to get back to you regarding if there's a better way to accomplish this, as it isn't a common use-case (or at least I haven't come across it before).

Toggling a GPIO in an ISR seems ideal, but you're right that your latency requirement would likely not be met.

Are you wanting your compare value to be the same when the output rises/falls (i.e. toggles at a set compare value)? Or do you have it rise at one compare value and fall at a completely different compare value?

Best,
Kevin

Hi Kevin,

I am not happy with the method I am currently using, because it is too sensitive to my estimate of the maximum interrupt latency.  Because of the behavior of the GPADAT register, I am not able to detect timing failures, so I cannot test my implementation under typical use conditions without some pretty fancy external test equipment.  So, yes, if there is a better way I would like to hear it.

The compare values for rise and fall will in general be different.

The main source of the heartburn was a requirement that a minimum time of 10 us between rise and fall be possible, in a system that is using most of the available processor cycles already.  The customer has since relaxed this requirement, to the point that I believe I can handle some of the hardware re-configuration in a periodic ISR.

However, if this compromise isn't necessary it would be good news.

Thank you,

Radey