PIC unable to keep up with rotary encoder?

[FvM]

Unless working with priority, all interrupts are disabled during ISR execution automatically. In some applications, individual IE bits are manipulated in ISR, e.g. a TX send interrupt will be disbled, when the last circular buffer character has been sent out. In your application, I don't see a purpose for it. Encoder interrupts must be expected at any time, there's no reason to delay other interrupts.

[mbradley]

You can try this:

http://www.picstuff.com/index.php?route=product/product&path=37_41&product_id=56
_________________
Michael Bradley
www.mculabs.com
Open Drivers and Projects

[sseidman]

Ditto for going with one of the motor control 18Fxx31. It will make your life easier

[John P]

See the "World's Best Encoder Routine" in the code library:
http://www.ccsinfo.com/forum/viewtopic.php?t=41115

In any situation involving multiple interrupts, I always suggest setting up a timer that gives you a fast-enough response to any of the various inputs and make it the only interrupt, then poll for each of the inputs when that interrupt occurs. It means that you get a rock-solid timebase, with no delays caused by one interrupt blocking another.

[Ttelmah]

The encoder routine given here, is small and tidy, but takes more time, than the version I posted earlier. It is half the size, but takes about 50% longer to run. With the version I posted, there are separate 'routes' for the four possibilities, making the code bulky, but each does the bare minimum, a maximum of just two logic tests to find which route to go, and then just an increment/decrement. On the smaller version, the basic logic is done in 16bit arithmetic, it looses speed as a result.
The version I posted, actually takes less time to work with a 32bit value (still by over 30%...), than this version does with a 16bit one.
For interrupt response, I'd not suggest using this.

Best Wishes

[John P]

Yes, I don't know why the math in the "World's Best" routine was done in 16 bit mode. It should be 8 bits up to the point where the increment is made to the position, which can obviously be 16 bit or 32 bit or whatever's required. If that were corrected, would the times be more like equal? Then it would be the "Universe's Best".

And does the compiler (more modern versions than my ancient one) change
if (new & 0x10)
into
if (bit_test(new, 4)) ?

The test for a single bit is faster, and if speed is of the essence, it's worth making sure the test works that way.

[scottc]

Did anyone ever get the 18f2331 internal decoder to work ?
I recently tried using the 4.116 ver of the compiler but no luck thus
far. An example would be nice. The help file is really scanty on details


In thinking about using mechanical encoders and trying to decode them
the thing I have noticed is that the Pic is really good at doing one task
at a time but if you have to do something like read a mechanical rotary encoder to say increment or decrement a variable and then push the result to a LCD, you're going to find that if you spin the encoder really fast
you will miss steps or your display will not be fast enough to keep up with
the rotation of the encoder so it will appear that you missed steps.

There are workarounds to this like setting a changed flag so that the display only gets updated after the encoder was moved. The trip time
to decode the encoder is typically in the low uS range from the processor
perspective, but its the other things that are really slow like updating a lcd or writing the result out using printif routines etc.

Has anyone run into any of this ?

On the lower cost 3pin 20 indent mechanical encoders the other thing that can cause errors in reading them is the interface to MPU. If it is expected
the the encoder is to be twisted by hand then you can get away with simple RC networks to clean up the signals, but beyond that you more
than likely will have to look to a dedicated hardware decoder to condition
the encoder signals before putting the MPU to any decoding tasks.

Thanks Scott.

[sseidman]

[bkamen]

[sseidman]

[bkamen]

[temtronic]

Generally NO, unless you're writing your own ISR 'handler'.It's better to let the compiler automatically take care of it.
So bottom line, don't enable or disable interrupts inside the ISR.

[scottc]

Ben, I did take a look at the .h file, indeed the defines are there, but
the help file is a dog on how to implement something functional as there
is no example. its very much open to flying blind.

I had tried to implement the in-built qei module on the 2331 and 2431
some time ago. At the time I could not get it to work so had to resort to
a software decode scheme. I was using an older compiler ver then. I have
4.116 now so I will give that a go.

I dont want to hi-jack this thread so I will break out that code tonight and
try post what I tried asap in a new thread.

Thanks Scott

[sseidman]

I posted some old code that I can't find, but it was reposted in

http://www.ccsinfo.com/forum/viewtopic.php?t=23455

I would imagine there's better def files by now in the current ccs distributions, but that was a brute force approach.

Note somebody pointed out an underflow issue.

[bkamen]