Hi, I am carrying on with this and I managed to get something that works. I ended up having two prioritized interrupts so that the ADC interrupt can interrupt the estimator one and seems to work reasonably well. I have however run into some problems when running at higher speeds and I think it is due to the way the angle delay compensation is done. Originally, we would run the CTRL_angleDelayComp function within the CTRL_run function to compensate for delays at high speeds. However in the is12_variable_pwm_frequency SDK example project this delay compensation is moved to the estimator ISR and also loos a little bit different. I am trying to understand how the new delay compensation works but I am not too sure. It basically multiplies the speed by a factor which is 0.5*USER_CTRL_PERIOD_sec. Why is this? Is it compensating from the time it reads the initial angle value at the beginning of the interrupt with respect to the point it exits the interrupt? Is this where the 0.5 comes from? Does that assume that the ISR takes 0.5*USER_CTRL_PERIOD_sec seconds to execute? Taking into account my different approach with the two ISRs. Would it be better/worth it do the delay compensation using a timer that gets reset at the time the angle is first calculated and then read at the point of running the controller using the time difference for the compensation? Also, as a side question, in the mentioned project, the pwm period is updated right before writing the duty cycle to the PWM registers in the ADC interrupt from the VSF module. Would not be better to update the pwm period after that? The reason being, if the controller has already ran thinking it had a set PWM period, and then right before writing to the PWM registers you change it, you would be using a duty cycle calculated with a previous PWM period, isn't? Thanks for the help
↧