CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

PIC unable to keep up with rotary encoder?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Fri Jan 21, 2011 4:09 am     Reply with quote

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



Joined: 11 Jul 2009
Posts: 118
Location: California, USA

View user's profile Send private message Visit poster's website

PostPosted: Sun Feb 13, 2011 7:49 pm     Reply with quote

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



Joined: 14 Mar 2005
Posts: 159

View user's profile Send private message

PostPosted: Mon Feb 14, 2011 9:15 am     Reply with quote

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



Joined: 17 Sep 2003
Posts: 331

View user's profile Send private message

PostPosted: Tue Feb 15, 2011 9:02 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 18123

View user's profile Send private message

PostPosted: Tue Feb 15, 2011 9:54 am     Reply with quote

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



Joined: 17 Sep 2003
Posts: 331

View user's profile Send private message

PostPosted: Tue Feb 15, 2011 11:20 am     Reply with quote

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



Joined: 16 Aug 2010
Posts: 95

View user's profile Send private message

PostPosted: Tue Feb 15, 2011 12:27 pm     Reply with quote

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
Smile

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



Joined: 14 Mar 2005
Posts: 159

View user's profile Send private message

PostPosted: Tue Feb 15, 2011 4:56 pm     Reply with quote

Ttelmah wrote:
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


I seem to recall doing something very similar, but with no decision statements--


Shift in the previous state, tag on the new state, and use that resulting number to index into an array-- the 15-element array is filled with +1,
-1, and 0, as is appropriate for the new state. You just add the indexed value into the encoder count. You might want to somehow flag impossible values for error handling.
bkamen



Joined: 07 Jan 2004
Posts: 1609
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Wed Feb 16, 2011 12:49 am     Reply with quote

scottc wrote:
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
Smile


What did you try that didn't work?


Quote:

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.


Depends on how you write your code... I have PIC's that I've maxed out doing lots of things at once. It all depends on how you write your code and what hardware resources you take advantage of.

If you think pure software is going to solve the worlds problems at 10MIPS... it's only going to be one problem at a time.

look at QEI Sample Timing in the 18Fxx31's datasheet. There's some simple math to let you figure out of the PIC will be able to keep up.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
sseidman



Joined: 14 Mar 2005
Posts: 159

View user's profile Send private message

PostPosted: Wed Feb 16, 2011 8:36 am     Reply with quote

scottc wrote:

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.



There's very little reason to update your display more than 3-4 times/second, regardless of whether the encoder is changing faster than that. Don't waste your clock ticks on an interface that updates faster than you need it.

The best way to do this stuff, in any case, is to use the xx31 series, so you don't go into your interrupt handler with every encoder transition.
bkamen



Joined: 07 Jan 2004
Posts: 1609
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Wed Feb 16, 2011 10:03 am     Reply with quote

scottc wrote:
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
Smile



Did you look at the 18F4431.h file for this?

There's all sorts of useful information that lines up pretty well with what I read in the datasheet.

Line:270 of that .H has the #defines to make your QEI life easy and happy.

No?

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
temtronic



Joined: 01 Jul 2010
Posts: 8528
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Feb 16, 2011 10:11 am     Reply with quote

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



Joined: 16 Aug 2010
Posts: 95

View user's profile Send private message

PostPosted: Wed Feb 16, 2011 6:23 pm     Reply with quote

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



Joined: 14 Mar 2005
Posts: 159

View user's profile Send private message

PostPosted: Wed Feb 16, 2011 6:51 pm     Reply with quote

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



Joined: 07 Jan 2004
Posts: 1609
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Wed Feb 16, 2011 7:00 pm     Reply with quote

scottc wrote:
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.


Ok, I'll be lookin...

:D
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group