[Dprglist] Speed detection based on period between encoder transitions

[Christian M Netter]

Paul - 2 suggestions:

1 - 

instead of letting the most recent time delta determine the speed, you may want to consider a small degree of averaging.   

I used this type of approach before and averaging was necessary because the encoder hardware did not produce events that were evenly spaced.   So lets say there were 2 events per motor revolution - instead of getting one event every 180 degrees worth of motor revolution, I got one event after ~150 degrees and the 2nd event ~210 degrees later.   Without averaging, speed would bounce back and forth between 2 values even at constant motion.

2 -

200us inside the ISR is quite a long time in my opinion.   This could start to interfere with other interrupts.   Suppose you need to service a UART that is running at 115200 w/out FIFO,  interrupts on the UART will come in every 90us if data was sent back-to-back.  

Is this 200us number with optimizations enabled (i.e. compiler flag -O2)  or with optimizations disabled (i.e. debug build) ?


I think there is a way to address both points by doing the work inside the ISR in such a manner that you don’t need to send a message to the main loop via that RTOS API - that’s probably where the overhead is…..


Chris

On Jan 26, 2022, at 10:58 PM, Paul Bouchier via DPRGlist <dprglist at lists.dprg.org> wrote: