question: when I call function(fs_etpu_resolver_get_outputs_extrapolated) at T1 to get angle and speed.
what angle do I get, I get real angle of T1, or the angle I get is not from T1, just a time before T1(for example T0) because of calculation delay? would eTPU compensate the calculation delay?
eTPU get the peak value of sin at tD, but the peak value happend at tB, would eTPU compensate the delay(tD-tB)?
In demo code of dual motor example, fs_etpu_resolver_get_outputs_extrapolated used when abs(pFOC->Resolver_SW.wRotEl.filt)> 100, is there any limit about calling the function(fs_etpu_resolver_get_outputs_extrapolated )? Not Applicable for low speed?
Hello,
I would like to give you the overview of how the angle calculation and timing is working in the eTPU Resolver function and this hopefully gives you answers to your questions:
Resolver function processes the entire excitation period within the ATO update thread. It oversamples the excitation signal with multiple samples and processes them and picks the most representative sample for the excitation peak value. The example illustration is on the figure below, where yellow marked sample is the one selected as representative for the peak value. Note that for illustration only 9 samples were depicted for half period, in real function we are sampling 16 samples per half period. It means we are computing updates for angle twice per period, every 16 samples. Those ATO updates are available in resolver_outputs_calculated.
Here is the illustration of the ATO update timing:
16 samples (in blue circle) start to be processed by the ATO UPD eTPU thread. At the time when eTPU thread is started the current_time is sampled. 16 Samples of the 1st half period in the blue circle are actually a prediction for the next half period – this is where the red dot is denoting the timestamp. But due to SDADC processing delay and also DMA transfer delay is larger than the half period and goes beyond the timestamp, here called as adc_delay – this is the delay between the timestamp of the predicted angle and the start of the ATO update thread. The delay has been measured and it corresponds to 19 us on MPC5777C. adc_delay is a configurable parameter of the resolver function and only has to be measured once for the device. This assumes ATO thread is not being delayed by any other eTPU thread. So, this is the explanation of the Timestamp for the calculated angle. Hopefully this answers your question related to delay compensation.
Timestamp is used for extrapolated angle calculation. On the next figure it is depicted how the extrapolated period is calculated – this is then used for extrapolated angle calculation.
When the extrapolation thread is evoked (green box), the extrapolate time is sampled and the last Timestamp of the last updated angle is used for the extrapol_period calculation. So to answer your question which angle you will get when you call the fs_etpu_resolver_get_outputs_extrapolated you will always get the last updated ATO angle extrapolated to the time when you evoked the extrapolation. What will vary is the extrapolation period. The shorter the period is the more precise the extrapolated angle you get. The picture above depicts the situation when the extrapolation is called just before the ATO updates the new angle, so the extrapolation uses the most fresh data. There are HW semaphores implemented to protect the data coherency between the ATO update and extrapolation calculation (arrow with LCK depicts the position when the ATO locks the HW semaphores while updating the new angle and speed, after UNLCK the semaphores are free and extrapolation loads the new fresh values). Hopefully this answers your second question.
Regarding your last question on limitation of extrapolation - no there are no limitations on usage.
Hello,
I would like to give you the overview of how the angle calculation and timing is working in the eTPU Resolver function and this hopefully gives you answers to your questions:
Resolver function processes the entire excitation period within the ATO update thread. It oversamples the excitation signal with multiple samples and processes them and picks the most representative sample for the excitation peak value. The example illustration is on the figure below, where yellow marked sample is the one selected as representative for the peak value. Note that for illustration only 9 samples were depicted for half period, in real function we are sampling 16 samples per half period. It means we are computing updates for angle twice per period, every 16 samples. Those ATO updates are available in resolver_outputs_calculated.
Here is the illustration of the ATO update timing:
16 samples (in blue circle) start to be processed by the ATO UPD eTPU thread. At the time when eTPU thread is started the current_time is sampled. 16 Samples of the 1st half period in the blue circle are actually a prediction for the next half period – this is where the red dot is denoting the timestamp. But due to SDADC processing delay and also DMA transfer delay is larger than the half period and goes beyond the timestamp, here called as adc_delay – this is the delay between the timestamp of the predicted angle and the start of the ATO update thread. The delay has been measured and it corresponds to 19 us on MPC5777C. adc_delay is a configurable parameter of the resolver function and only has to be measured once for the device. This assumes ATO thread is not being delayed by any other eTPU thread. So, this is the explanation of the Timestamp for the calculated angle. Hopefully this answers your question related to delay compensation.
Timestamp is used for extrapolated angle calculation. On the next figure it is depicted how the extrapolated period is calculated – this is then used for extrapolated angle calculation.
When the extrapolation thread is evoked (green box), the extrapolate time is sampled and the last Timestamp of the last updated angle is used for the extrapol_period calculation. So to answer your question which angle you will get when you call the fs_etpu_resolver_get_outputs_extrapolated you will always get the last updated ATO angle extrapolated to the time when you evoked the extrapolation. What will vary is the extrapolation period. The shorter the period is the more precise the extrapolated angle you get. The picture above depicts the situation when the extrapolation is called just before the ATO updates the new angle, so the extrapolation uses the most fresh data. There are HW semaphores implemented to protect the data coherency between the ATO update and extrapolation calculation (arrow with LCK depicts the position when the ATO locks the HW semaphores while updating the new angle and speed, after UNLCK the semaphores are free and extrapolation loads the new fresh values). Hopefully this answers your second question.
Regarding your last question on limitation of extrapolation - no there are no limitations on usage.
