time jitter

[blezalex]

It looks like the main motor driving code runs in mcpwm_foc_adc_int_handler which is assumed to run every dt sec. float dt = 1.0 / (conf_now->foc_f_sw / 2.0); I decided to validate that assumption by measuring actual time: https://gist.github.com/blezalex/f4523eb9204b1935ef29845eaa1b33ab

The results is up to 8% time deviation between two consecutive runs: loop_time: 419 min_loop_time: 403 max_loop_time: 436

It also differs from calculated time, 25khz = 40micros per iteration, measured is close to 42 micros.

What do you think?

[kubark42]

I see an additional conclusion from your measurements, and that's that the loop time is not correct on average. That's a bigger concern to me than jitter.

It's tough to draw many conclusions about the severity of the jitter from a single data point of 8%.

• Was that the worst seen across 2 days of experiments, or was it something seen in only several seconds of testing?
• What's the average jitter and the std deviation?
• What hardware platform was this on?

[kubark42]

@blezalex, one thing you might do to test if the mcpwm_foc_adc_int_handler() function is responsible for the delay, or if the jitter comes from the upstream calling of it, is to return immediately from that function.

If you move your track_time code up to the top of that function and follow it with a return, then what happens? Does the performance get more stable?

[vedderb]

Two comments:

1: The jitter does not matter, as long as the function is able to finish in time. It operates on the ADC samples that are triggered by the timer and synchronized by DMA, and the output will not be applied before the next PWM cycle starts. So as long as it finishes before that, the timing is consistent.

2. timer_time_now has a bug in master and measures the time slightly wrong. That is fixed in dev_fw_5_03, so if you make the test there the time should hopefully be correct.