How to capture Position-Compare Sync time in TMS320F28335?

Hi,

I agree with your comment regarding the QCAPCTL:UPPS. Making dynamic changes to the divider could result in unpredictable behavior.
Is the input for capturing the position-compare sync time a waveform with precise defined set of pulses?
Can you evaluate if using ECAP module would be an option?
You can potentially measure the time lapse between events and if you know the precise sequence of edges expected - I think ECAP could work for your case. If possible, please share a diagram or snapshot of the exact requirement and measurements needed.

-Bharathi.

Dear Bharathi,
I can make an external connection between QEPxS out pin and ECAPx pin as usualy. But in this particular case I have the microcontroller PCB which was designed by other company, and all ECAP pins are already used for other purposes and I do not want to make any changes in PCB like soldered wires and so on.
The best solution of the problem could be the absence of the top mux, which is controlled by GPxMUX1/2 (see Fig. 4-18 in SPRS439I). If this mux will be removed and GPIO pin signal can pass to all inputs of the peripheral devices regardless of the GPxMUX1/2 state, then I'll be able to use ECAP for time capture. But it is there, thus it is impossible.
The problem of speed estimation can be explained on a simple example.
We have 10 000 impulse per revolution encoder.
We plan to achieve bandwidth of the speed estimator of 4 000 Hz.
The smallest speed for the specified bandwidth is omega = 2*pi*Fbw/N = 2*pi*4000/10000 = 2.512 rad/s or 25 rpm. This results in Fcpu/Fbw = 150 000 000 / 4 000 = 37 500 CPU timer increments.
If the speed grows then the CPU timer increments per one estimation reduces, and the relative error increases.
For example, on 250 rpm the error will be 1/3750 or 0.027%,
on 2500 rpm the error will be 1/375 or 0.27%.
On other hand if we will choose the method with measurement the number of pulses during fixed time period then we will not achieve better accuracy. The number of impulses which come from encoder during 1/4 000 s (the specified bandwidth) is only 100 increments for 2500 rpm, which gives an error of 1%.
The obvious solution for this case is to change the angle increment for a speed measurement system.
For example, we start with 4 pulses position increment (the minimal permitted value due to nonidealities of the position sensor). We achieve 4000 Hz bandwidth at 25 rpm with a good accuracy.
When the speed grows the CPU timer increment decreases, because now we pass the same angle faster.
But with reduction of the estimation time we loose accuracy, though bandwidth grows.
Thus, we have to change the position increment -- to increase it. It should be increased, for example, twice when the CPU timer increment reaches 37 500 / 2 = 18 750. So the bandwidth will return to 4000 Hz and the accuracy will remains the same.
Higher is the speed, bigger is the position increment.
And TI microcontrollers still do not have the support of the position increment change. It can be done only via position compare, and external connection of the QEPxS with ECAPx like we did 15 years ago on TMS320F240.

Hi Alecksey,

Thanks for the detailed explanation. The GPxMUX still exists and I wonder you would still have the same constraints since you are working on an existing PCB with little options for tweaking.
Just for your information, some of our newer devices - like F2837x/F2807x series, the ECAP (and several other signals) input selection is more flexible with X-Bars on the inputs enabling any of the available GPIO pins as ECAP inputs.
I'm unable to suggest better options for your case given the legacy h/w constraints.
-Bharathi.