Searching \ for '[PIC]: Rotary Encoders' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=encoder
Search entire site for: 'Rotary Encoders'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Rotary Encoders'
2001\10\20@051008 by David J Binnington

flavicon
face
Sorry missed the [PIC]: tag!

I shall be starting a project soon that has an outline specification for a
user interface of up to 21 keys.  This in itself is no problem but I have
now been asked to consider replacing 6 of the keys (Up/Down function x 3)
with 3 rotary encoders (probably low cost detented & contacting type).  1 to
3 more keys could also be replaced by using the momentary contact built into
some types of encoders.

I have not used panel type encoders before and although they seem simple
enough to use singly, I am not sure about using three together with up to 15
keys in a matrix.  The target micro at the moment is the 16F874/7, running
at either 16 or 20Mhz.  The I/O is going to be in heavy demand for other
functions, so the number used for the user interface needs to be kept as low
as possible. I cannot afford to dedicate 2 I/O for each encoder.  I also
don't want to increase the chip count by expanding the I/O, although I will
have to consider it if necessary.

Providing the scanning is carried out quickly enough (likely to be interrupt
driven via a timer) I am assuming that I can include the encoder outputs in
the same matrix as the keys. I know I need dedicated routines for detecting
direction but is there anything fundamentally wrong with this approach?  I
am trying to think about all the possible problems that could occur like the
user operating more than one at a time or slippage due to too fast rotation
etc.

Before I build a prototype to test the idea does anybody have any experience
(links?) they can pass on of using multiple encoders and keys together with
minimal hardware and software overhead?

Many thanks

David J Binnington

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\20@062022 by Spehro Pefhany

picon face
At 08:51 AM 10/20/01 +0100, you wrote:
>Sorry missed the [PIC]: tag!
>
>I shall be starting a project soon that has an outline specification for a
>user interface of up to 21 keys.  This in itself is no problem but I have
>now been asked to consider replacing 6 of the keys (Up/Down function x 3)
>with 3 rotary encoders (probably low cost detented & contacting type).  1 to
>3 more keys could also be replaced by using the momentary contact built into
>some types of encoders.

This is very efficient, and user-friendly. I particularly like the push-
switch type.

>I have not used panel type encoders before and although they seem simple
>enough to use singly, I am not sure about using three together with up to 15
>keys in a matrix.  The target micro at the moment is the 16F874/7, running
>at either 16 or 20Mhz.  The I/O is going to be in heavy demand for other
>functions, so the number used for the user interface needs to be kept as low
>as possible. I cannot afford to dedicate 2 I/O for each encoder.  I also
>don't want to increase the chip count by expanding the I/O, although I will
>have to consider it if necessary.

It's better to dedicate the I/O to the encoders as they are not momentary,
otherwise you need to add diodes or some other method of isolating the
contacts. It's not hard to share the encoder outputs with LED scanning,
using a couple of resistors each (ie. one SMT network per encoder). The
resistors provide isolation as they are overpowered by the PIC outputs,
for display drive, they are read by floating the outputs, waiting a bit
for the capacitance to charge, and reading.

>Providing the scanning is carried out quickly enough (likely to be interrupt
>driven via a timer) I am assuming that I can include the encoder outputs in
>the same matrix as the keys. I know I need dedicated routines for detecting
>direction but is there anything fundamentally wrong with this approach?  I
>am trying to think about all the possible problems that could occur like the
>user operating more than one at a time or slippage due to too fast rotation
>etc.

Don't forget the encoders are not momentary, so you can't use a simple matrix.
Also, the scan rate needs to be higher for an encoder, perhaps by 5:1,
a bit longer than the maximum bounce. I use about 400Hz. You should have no
problems at 16MHz clock. The typical detent-type encoder gives 4 states per
detent. 'Slippage' is inevitable, just write the routines to avoid going in
the wrong direction, using a state machine or just a lockout bit. You may
need to incorporate a timing routine to allow a 'fast' mode (eg. getting
to 10,000 from 0 on a 24 step encoder would be no fun.

Best regards,
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
     /.-.\
    (( * ))
     \\ //     Please help if you can:
      \\\      dailynews.yahoo.com/fc/US/Emergency_Information/
     //\\\
    /// \\\
    \/   \/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\20@090811 by Olin Lathrop

face picon face
> Providing the scanning is carried out quickly enough (likely to be
interrupt
> driven via a timer) I am assuming that I can include the encoder outputs
in
> the same matrix as the keys.

That depends on the fastest realisting pulse rate from the rotary encoders
and how fast you can scan all the inputs.  The other thing to consider is
that when a user is rapidly turning a knob, they probably don't care and
won't notice a little slippage.  Unless the knob itself is calibrated with
indicators nobody will know.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\20@103702 by Quentin

flavicon
face
OK, since you want to replace user interface keys with encoders I can
only surmise that you want to use the encoders as some kind of "scroll"
(as in MS mouse type) function? And I am allowed surmise a bit more
about the reason you were asked to considering encoders over keys is
that you must also be able to control the rate of change (speed) as
well?

Encoder back ground:
If B is high before A is high => count this way.
If A is high before B is high => Count other way.
And:
A is the count pulse, B determines count direction.

So let's go PICcing, IOW, the way I would approach it:
Connect  the three A pulses to RB4..6. Connect the three B pulses to say
RB1..3, leaving RB0 open for general interrupt.
Use RD for other keys (4x4 matrix =16 keys. Your 21 keys minus the 6
original up/down keys leaves you with 15).
If you run into I/O shortage problems, you still have RA, RC, and RE.
Also 2 RC pins are available for I2C for further expansion of I/O.
Actually, I would rather do the other 15 keys with I2C I/O giving me
more control over more important I/O's.
Back to RB4..6. Any change on these pins will set RBIF (Flag for pin
change interrupt on RB4..7), which will jump to your ISR.
In your ISR, you first check which pin set the flag, then you check if
the pin is set high. If not, RTFIE. If it is, test the corresponding B
input to see if high, count this way, if low, count other way.

Think that will do it?
Quentin

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\20@173220 by David J Binnington

flavicon
face
Quentin,

>
> OK, since you want to replace user interface keys with encoders I can
> only surmise that you want to use the encoders as some kind of "scroll"
> (as in MS mouse type) function? And I am allowed surmise a bit more
> about the reason you were asked to considering encoders over keys is
> that you must also be able to control the rate of change (speed) as
> well?

Not so much that I wanted to change to encoders but it is considered by some
to be an enhancement that might make the product more saleable despite the
higher cost! Previous similar designs use simple up/down keys with rollover
to increase the rate but it is intended that the encoders will do nothing
more than simply increment and decrement counters at whatever the input rate
(within reason) - speed sensitivity is certainly not a consideration at the
moment.

{Quote hidden}

No, that's the problem I don't have many pins available - RD is in use, RE &
part of RB was going to be used for the matrix scan, RB0 is in use, the UART
will be in use, I2C will be in use, A-D in use, 3 pins will be used to drive
the display (2 already multiplexed with the key matrix) and most of the
other pins are also in use for various I/O, enables etc.

> Also 2 RC pins are available for I2C for further expansion of I/O.
> Actually, I would rather do the other 15 keys with I2C I/O giving me
> more control over more important I/O's.

As I am already going to need I2C I thought about using it for the keys but
I am not sure of the best way i.e. No parts and cheap!  I am likely to have
at least 2 PCF8574 hanging on the I2C bus together with 2 other micros in
the system.  I suppose I could add something like a 16F628 just to do the
key scanning.  Any thoughts?

> Back to RB4..6. Any change on these pins will set RBIF (Flag for pin
> change interrupt on RB4..7), which will jump to your ISR.
> In your ISR, you first check which pin set the flag, then you check if
> the pin is set high. If not, RTFIE. If it is, test the corresponding B
> input to see if high, count this way, if low, count other way.
>
> Think that will do it?

If I can release enough I/O to do it that way then I don't think there would
be a problem.

Thanks

David

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\20@173242 by David J Binnington

flavicon
face
Spehro,

>
> This is very efficient, and user-friendly. I particularly like the push-
> switch type.
>

I couldn't disagree with that statement when I was originally asked to look
at it!

> It's better to dedicate the I/O to the encoders as they are not momentary,
> otherwise you need to add diodes or some other method of isolating the
> contacts. It's not hard to share the encoder outputs with LED scanning,
> using a couple of resistors each (ie. one SMT network per encoder). The
> resistors provide isolation as they are overpowered by the PIC outputs,
> for display drive, they are read by floating the outputs, waiting a bit
> for the capacitance to charge, and reading.

The LEDs and 7-segment displays have already been off loaded by using
cascaded MAX7219.  Not cheap but need just 3 I/O, 2 of which can be
multiplexed with other functions.

>
> Don't forget the encoders are not momentary, so you can't use a
> simple matrix.

I hadn't forgotten but I was hoping that I could somehow isolate them, hence
my original post.  It's beginning to look like I will need to off load other
I/O, in order to gain enough pins for the encoders.  The problem is they
will need 6 dedicated pins that I really can't afford.

{Quote hidden}

It is likely that a maximum count of no more than 100 will be required,
which I think can probably be managed without a 'fast' mode.

Thanks for your input.

David

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\20@173252 by David J Binnington

flavicon
face
Olin,

> > Providing the scanning is carried out quickly enough (likely to be
> interrupt
> > driven via a timer) I am assuming that I can include the encoder outputs
> in
> > the same matrix as the keys.
>
> That depends on the fastest realisting pulse rate from the rotary encoders
> and how fast you can scan all the inputs.  The other thing to consider is
> that when a user is rapidly turning a knob, they probably don't care and
> won't notice a little slippage.  Unless the knob itself is calibrated with
> indicators nobody will know.

Very true, and since the knobs will be as large as I reasonably can get away
with, that should slow them down a bit.  Whatever you believe to be
reasonable someone is bound to see how fast they can rotate the knob.
Knowing my luck they will probably try using an electric drill!

David

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\20@195957 by Jeff DeMaagd

flavicon
face
----- Original Message -----
From: David J Binnington <davidspamKILLspamDJBELECT.KEME.CO.UK>

> Very true, and since the knobs will be as large as I reasonably can get
away
> with, that should slow them down a bit.  Whatever you believe to be
> reasonable someone is bound to see how fast they can rotate the knob.
> Knowing my luck they will probably try using an electric drill!

Actually I have used an air drill to test the maximum speed on my own
projects.   On a 4MHz PIC I have managed to be able to use polling to detect
around 50kHz speed on a quadrature encoder, but that is running full bore
and doing nothing else other than increment/decrement the counter and
measuring the velocity.

I don't think you are in any real trouble on a user interface, even if you
have to worry about bounces, which I did not have to with an optical
encoder.

Jeff

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\20@201223 by Spehro Pefhany

picon face
At 10:29 PM 10/20/01 +0100, you wrote:

>I hadn't forgotten but I was hoping that I could somehow isolate them, hence
>my original post.  It's beginning to look like I will need to off load other
>I/O, in order to gain enough pins for the encoders.  The problem is they
>will need 6 dedicated pins that I really can't afford.

You can certainly isolate them with diodes. Using TTL threshold inputs,
you can use two diodes per encoder (6 total). Then two inputs (with resistors
to ground) are dedicated to the encoders, and you have 3 output pins connected
to the encoder commons (let's assume the shells are nicely grounded).
If you don't follow this, e-mail me.

Now, you've mentioned 21 keys, so I'll assume you have at least 10 port pins
already dedicated to the keyboard. (6 x 4 or 5 x 5 or 7 x 3). If you use
3 pins to drive the encoders and the remaining 7 as inputs, 2 for the
encoders,
that allows you to have 15 more keys (including the momentary ones in the
encoders, which don't require diodes).  Or, if you use the 6 x 4 method,
you can have a 4 resistor pulldown network, 6 diodes or (3 SMT duals),
3 encoders, and up to 12 keys without any additional components (including
the encoder switches). If you want the full complement of switches, as
implied by the x-y matrix, you'll have to isolate at least some of the
switches from the encoder inputs with diodes, but that may not be
necesssary.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
     /.-.\
    (( * ))
     \\ //     Please help if you can:
      \\\      dailynews.yahoo.com/fc/US/Emergency_Information/
     //\\\
    /// \\\
    \/   \/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\10\21@033915 by Quentin

flavicon
face
David J Binnington wrote:

> As I am already going to need I2C I thought about using it for the keys but
> I am not sure of the best way i.e. No parts and cheap!  I am likely to have
> at least 2 PCF8574 hanging on the I2C bus together with 2 other micros in
> the system.  I suppose I could add something like a 16F628 just to do the
> key scanning.  Any thoughts?

If you are going to add another PIC, then I would rather do the encoders
on that PIC as scanning the encoders is timing critical, so the PIC then
runs free to do it's own thing (and also freeing up the master a bit
more, code and pin wise). This PIC then sends the three count values to
the master PIC when asked.

Other than that, go tell whoever suggested the rotary approach to go fly
a kite.

:)
Quentin

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\21@110649 by David J Binnington

flavicon
face
> -----Original Message-----
> From: pic microcontroller discussion list
> [EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU]On Behalf Of Jeff DeMaagd
> Sent: Sunday, October 21, 2001 12:52 AM
> To: PICLISTspamspam_OUTMITVMA.MIT.EDU
> Subject: Re: [PIC]: Rotary Encoders
>
> Actually I have used an air drill to test the maximum speed on my own
> projects.   On a 4MHz PIC I have managed to be able to use
> polling to detect
> around 50kHz speed on a quadrature encoder, but that is running full bore
> and doing nothing else other than increment/decrement the counter and
> measuring the velocity.
>
> I don't think you are in any real trouble on a user interface, even if you
> have to worry about bounces, which I did not have to with an optical
> encoder.
>

I don't think a contacting type of encoder would last very long at that rate
anyway!

David

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\21@110702 by David J Binnington

flavicon
face
{Quote hidden}

Many thanks for the suggestions Spehro.  I think you have just confirmed my
original thoughts.

A 7 column x 3 row matrix was originally considered for just the keys. The
intention was to sequentially pulse the columns at a rate generated via a
timer driven ISR (50-100Hz scan). The scan result would then be available in
row registers for further processing in the body of the program. The reason
for scanning the columns was that I need to use at least 6 of the 7 outputs
as inputs for other functions.  Most I/O on this PIC is doing double duty
and sometimes more!  I know I have to isolate the various lines with diodes
and pulldown resistors to avoid conflicts as well as worrying about the
capacitance on the lines.

To add the encoders I was going to decrease the columns to 6 and increase
the rows to 4.  This would allow me to dedicate row 4 to a common point on
the 3 encoders with the 6 columns connected to A & B and still allow me to
have up to 18 keys.  AFAIK the contacting encoder can have A & B as inputs
as well as outputs since they are just switches.   I think this is similar
to what you are suggesting, although the rows and columns are swapped.
Despite my initial doubts and some negative feedback on using scanning I now
believe it can be done successfully providing the scan is fast enough and
the contacts are properly debounced in software.  What scan rate and
debouncing period to use will have to be determined in practice.  Some
slippage is acceptable but jumps or change in direction are obviously not.

The only killer now will be when I announce the increased cost!

Regards

David

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\21@110705 by David J Binnington

flavicon
face
> -----Original Message-----
> From: pic microcontroller discussion list
> [RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU]On Behalf Of Quentin
> Sent: Sunday, October 21, 2001 8:38 AM
> To: spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU
> Subject: Re: [PIC]: Rotary Encoders

> If you are going to add another PIC, then I would rather do the encoders
> on that PIC as scanning the encoders is timing critical, so the PIC then
> runs free to do it's own thing (and also freeing up the master a bit
> more, code and pin wise). This PIC then sends the three count values to
> the master PIC when asked.

I agree, but I now believe I can successfully scan the 3 encoders using the
master PIC.

>
> Other than that, go tell whoever suggested the rotary approach to go fly
> a kite.
>

I think I might be the one flying the kite if I did that.  ;-)

David

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\22@181724 by Mike Hardwick

flavicon
face
There's an old DOS encoder simulation program kicking around on the Net.
It's called ENCODER.EXE, and it uses the PC printer port to output
simulated quadrature encoder signals. It should help establish accuracy and
response time for developmental encoder interfaces...

Mike Hardwick
Decade Engineering


{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body



'[PIC]: Rotary Encoders'
2001\11\05@092146 by =?iso-8859-1?Q?=C5ke_Neehr?=
picon face
Hello!


OK! Here is a part of the code
RD_ENCDR.SRC


chk_encoder       mov    new, encoder
                             and    new, #00000011b
                            mov    temp, new
                            xor       temp, old
                            jz         :return
                            clc
                             rl         old
                             xor      old, new
                             jb         old.1, :up
:down                    dec      counter
                              skip
:up                          inc       counter
                              and      counter, #00001111b
                              mov      old, new
:return                    ret

My question are : What language is this?


Regards
ÅkeN

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\11\05@093843 by James Paul

picon face
All,
 I know this message isn't addressed to me, and I may be out of line here,
but I have to interject my bit of opinion.  There are probably others
out there with these same sentiments.  Those being the fact that I cannot
stand seeing PIC code written in the 8051 look alike nmemonics.  This just
drives me nuts.  Don't get me wrong here, there isn't anything wwrong with
it AFAIK.  It's just to me, it doesn't seem right.  It's kind of like  meeting someone who speaks your native language, and then talking to them  in a somewhat foreign language.  
Just a nitpick on my part.   I'm done now.  Carry on.....


                                        Regards,

                                          Jim







{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\11\05@095935 by Jerry Merrill

flavicon
face
This is CVASM/SPASM.

Parallax created this 8051-like language.  We (TechTools) support it with our CVASM16.

Read about it at:
http://www.tech-tools.com/cvasm16.htm

There is a download link at the top of that page.

Jerry

At 08:16 AM 11/5/01, you wrote:
{Quote hidden}

Jerry Merrill

RemoveMEjerrymspamTakeThisOuTtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814   VOICE:(972) 272-9392
TechTools  PO Box 462101  Garland,  TX  75046-2101

Join our PICmicro MCU discussion list at
http://www.tech-tools.com/picsource.htm

Subscribe to our MONTHLY news letter at
newsletter-requestEraseMEspam.....tech-tools.com?subject=subscribe

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\11\06@023917 by dr. Imre Bartfai

flavicon
face
Hello,

do you think to enhance the (excellent) CVASM16 so that it would support
the 17 and 18 family? I am an old-fashioned man using DOS for development
for obvious reasons and I see if the 18Fxxx family will be publicly
available it would be fine to have the tool also (beneath MPASM).

Regards,
Imre


+-----------------------------------------------------------------------+
| The information transmitted is intended only for the person or entity |
| to which it is addressed and may contain confidential and/or          |
| privileged material.  Any review, retransmission, dissemination or    |
| other use of, or taking of any action in reliance upon, this                |
| information by persons or entities other than the intended recipient  |
| is prohibited. If you received this in error, please contact the      |
| sender and delete the material from any computer.                     |
+-----------------------------------------------------------------------+

On Mon, 5 Nov 2001, Jerry Merrill wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...