View previous topic :: View next topic |
Author |
Message |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Fri Jan 21, 2011 4:09 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
mbradley
Joined: 11 Jul 2009 Posts: 118 Location: California, USA
|
|
![](templates/subSilver/images/spacer.gif) |
sseidman
Joined: 14 Mar 2005 Posts: 159
|
|
Posted: Mon Feb 14, 2011 9:15 am |
|
|
Ditto for going with one of the motor control 18Fxx31. It will make your life easier |
|
![](templates/subSilver/images/spacer.gif) |
John P
Joined: 17 Sep 2003 Posts: 331
|
|
Posted: Tue Feb 15, 2011 9:02 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Tue Feb 15, 2011 9:54 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
John P
Joined: 17 Sep 2003 Posts: 331
|
|
Posted: Tue Feb 15, 2011 11:20 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
scottc
Joined: 16 Aug 2010 Posts: 95
|
|
Posted: Tue Feb 15, 2011 12:27 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
sseidman
Joined: 14 Mar 2005 Posts: 159
|
|
Posted: Tue Feb 15, 2011 4:56 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Wed Feb 16, 2011 12:49 am |
|
|
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
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
sseidman
Joined: 14 Mar 2005 Posts: 159
|
|
Posted: Wed Feb 16, 2011 8:36 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Wed Feb 16, 2011 10:03 am |
|
|
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
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Wed Feb 16, 2011 10:11 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
scottc
Joined: 16 Aug 2010 Posts: 95
|
|
Posted: Wed Feb 16, 2011 6:23 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
sseidman
Joined: 14 Mar 2005 Posts: 159
|
|
Posted: Wed Feb 16, 2011 6:51 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Wed Feb 16, 2011 7:00 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|