Post by thread:[PIC]: Rotary Encoders

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

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_OUTspeffTakeThisOuTinterlog.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

> 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, .....olinKILLspam@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

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

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}> > 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. 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

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}> 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. 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

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

----- Original Message ----- From: David J Binnington <davidKILLspamDJBELECT.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

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" .....speffKILLspam.....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

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.

> -----Original Message----- > From: pic microcontroller discussion list > [EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU]On Behalf Of Jeff DeMaagd > Sent: Sunday, October 21, 2001 12:52 AM > To: PICLISTspam_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.

{Quote hidden}> -----Original Message----- > From: pic microcontroller discussion list > [@spam@PICLISTKILLspamMITVMA.MIT.EDU]On Behalf Of Spehro Pefhany > Sent: Sunday, October 21, 2001 1:17 AM > To: KILLspamPICLISTKILLspamMITVMA.MIT.EDU > Subject: Re: [PIC]: Rotary Encoders > 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. 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.

> -----Original Message----- > From: pic microcontroller discussion list > [RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU]On Behalf Of Quentin > Sent: Sunday, October 21, 2001 8:38 AM > To: spamBeGonePICLISTspamBeGoneMITVMA.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.

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}>> 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. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email TakeThisOuTlistservEraseMEspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

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}> 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. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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}>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. Jerry Merrill RemoveMEjerrymTakeThisOuTtech-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-requestEraseME.....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.

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}> 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: > >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. > > Jerry Merrill > > EraseMEjerrymtech-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 > RemoveMEnewsletter-requestEraseMEEraseMEtech-tools.com?subject=subscribe> > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservspam_OUTKILLspammitvma.mit.edu with SET PICList DIGEST in the body