Reset-after-Capture delay in Timer: a lost thread
In the past, we've discussed the fact that in STM32 TIM, there's a delay between Capture and Reset through the derived from the same signal than the Capture. This delay causes period measured using the method called "PWM Input" in RM, to be a couple of timer clock periods shorter than is the real period.
@Tesla DeLorean experimentally characterized this delay and summed up his findings in a thread, which unfortunately got damaged twice - first at transition from Jive to Salesforce, as witnessed by the wildly varying "Edited by ST Community" timestamps during the first restoration attempt; and then again at the transition to Khoros. As it cannot be restored, @Lina_DABASINSKAITE and the crew kindly provided me with a pdf which contains probably screenshots from some internal database tool. Unfortunately, the original post together with the title has been already lost. I further removed personal information and some uninteresting footers:

So, the result is, the delay in question is two timer clock cycles.
This of course can be used as a compensation, but it's an experimentally determined value, with no guarantees for this being a constant, and no confirmation by ST. Indeed, ST does not even mention the existence of this delay; it surely would not look nice in the "PWM input" chapter.
So, as the second experiment shows, a sure method is to capture successive edges of the same polarity in a free running timer (i.e. without the slave-mode Reset) and calculate deltas "manually".
JW
