Interrupt use with incremental encoder not executed

P

P Dobson

Active member
I have put together a small program designed to produce a velocity vector from a slowly rotating incremental encoder. In order to get the best resolution I have got interrupt routines on all edges, both rising and falling. The falling edge interrupts work fine, but the rising edge interrupts never get execute. If I comment out the falling edge interrupts then the rising edge interrupts work. The enclosed oscilloscope photo shows the LED trace in blue and you can see the interrupt routine for falling edges temporally stops the LED output which is what I would expect. The yellow and Purple traces show the incremental encoder inputs to the Teensy 3.5. I think it is clear from the scope output that the interrupts complete well before the next interrupt is due. So why do falling edge interrupts work, but rising edge interrupts don't work??

Any guidance would be very welcome.
 

Attachments

  • Low_latent_Tacho.ino
    3.3 KB · Views: 13
  • TEK00000.PNG
    TEK00000.PNG
    8.7 KB · Views: 18
I don't think you can attach two interrupts to the same pin. Probably last one wins.
You might register one per pin, with the mode: CHANGE
and then detect which edge it is.

Edit: option 2 - Register the first one you expect, lets say RISING, and in the RISING function you do an attachInterrupt(..., FALING)
and in the function for FALLING, you then call attachInterrupt(...., RISING)...

Would also suggest digitalReadFast, digitalWriteFast ...
 
Last edited:
You can get more accurate speed measurements by using library FreqMeasureMulti. It uses T3.5 hardware to measure period between RISING edges (by default), but can also do FALLING edges or both edges. I recommend starting with RISING edges to start. You can start by setting it up to measure period on either A or B. If you also connect your A (or B) signal to a second pin, you can use the Encoder library to do quadrature counting based on A and B to get position and direction, and also get period measurement on A or B via FreqMeasureMulti for your accurate speed calculation.
 
Thank you both. That is very helpful. The eventual project behind this is to produce code for a 3 axis control loading system used on a flight simulator. I have already generated one version which works quite well but the PID servo is not quite right and can be corrected by better velocity feedback. So to start with I will adopt "CHANGE" and then test in the interrupt routine which edge it is that caused the interrupt. We'll see how much processor time this consumes when I get all 3 axes running. To make things more complicated I use potentiometers for position information so I know exactly where the axis position is at start up and don't need to do a sweep to find the incremental encoder reference point or the end stop limits.

Thanks again for your help.
 
Thanks Joe, Appreciate your input. I'll try FreqMeasureMulti, though I need to change my hardware set up to use the correct pins. Not quite so easy on a proper Printed circuit board that I developed.
 
You must log in or register to reply here.
Back
Top