|
HI Guys,
Yesterday I was experimenting with my AVR software and working with
the different controls I will have on my operator panel. I got
everything working good in the test rig but found something unusual
with the rotary encoder switches.
The encoder switches I have are called 24 PPR and have 24 detents.
However, when decoding them in software, I quickly noticed they
output 4 pulses per detent which makes them 96 "steps" per
revolution.
I know once before I got myself all messed up with encoder switches
(I have only used them once before). I guess what I am asking is
this...
Should I just count the 24 detent pulses?
OR
Should I count the 96 pulses per revolution?
If I work with the 96 PPR count, I can see some problems with things
getting a little bit confusing when you release the knob between two
detents and it moves itself into the detent position.
To me, it would just make more sense to have 24 detents per rev. and
24 counts per revolution. But, being cheap these days, it seems as
though I am "throwing away 75% of the steps" :-)
Chris (Confused from a tough weekend of programming)
|
Should I just count the 24 detent pulses?
OR
Should I count the 96 pulses per revolution? A link to a datasheet would help... Richard
|
--- In Electronics_101@..., "rtstofer" <rstofer@...> wrote:
Should I just count the 24 detent pulses?
OR
Should I count the 96 pulses per revolution? A link to a datasheet would help...
Richard
This link should take you to the datasheet (I hope) E/EC12E.PDF
|
--- In Electronics_101@..., "lcdpublishing" <lcdpublishing@...> wrote:
--- In Electronics_101@..., "rtstofer" <rstofer@> wrote:
Should I just count the 24 detent pulses?
OR
Should I count the 96 pulses per revolution? A link to a datasheet would help...
Richard
This link should take you to the datasheet (I hope)
E/EC12E.PDF
OK, the device has quadrature outputs. This produces 4 transitions between detents. The reason for quadrature is to provide an indication of the direction of rotation. On page 194 you will see a state diagram. Starting from the left indicated detent location the pattern is: A goes low then B goes low then A goes high then B goes high. In the other direction the transitions are: B goes low then A goes low then B goes high then A goes high. From the pattern of transitions, direction can be determined. Among other things, if you build a software state machine to track the changes, debouncing will be automatic. Sure, you may bobble between A is high, B is high back and forth with A is low, B is high (or A is high, B is low) (in other words both sides of the transition) but it doesn't matter because only one line is changing states - you wont go from A is high, B is high to A is low, B is low. You aren't transitioning far enough to upset the count or miss a detent position. But you can detect the difference between increase and decrease. Richard
|
On Mon, 01 May 2006 18:39:33 +0200, rtstofer <rstofer@...> wrote: Among other things, if you build a software state machine to track the
changes, debouncing will be automatic. Sure, you may bobble between A
is high, B is high back and forth with A is low, B is high (or A is
high, B is low) (in other words both sides of the transition) but it
doesn't matter because only one line is changing states - you wont go
from A is high, B is high to A is low, B is low.
You aren't transitioning far enough to upset the count or miss a
detent position. But you can detect the difference between increase
and decrease.
Richard Yes, even I managed to make the software for a encoder of this type work, and that says something! Good thinking really that quadrature stuff... ST
|
Thanks! That makes sense. Now I just need to decide how I want to
interpret that in the AVR. Right now I can do it both ways easily
(getting 96 counts per rev and 24 counts per rev).
I just know that there will be times when I don't want it to jump a
couple extra steps when the switch settles into a detent. That's when
it will be best to have it count 24 per rev.
I do like that quadrature signal system though - it's neat and
somewhat easy to understand (even for this dummy)
Chris
|
--- In Electronics_101@..., "lcdpublishing" <lcdpublishing@...> wrote:
Thanks! That makes sense. Now I just need to decide how I want to
interpret that in the AVR. Right now I can do it both ways easily
(getting 96 counts per rev and 24 counts per rev).
I just know that there will be times when I don't want it to jump a
couple extra steps when the switch settles into a detent. That's when
it will be best to have it count 24 per rev.
I do like that quadrature signal system though - it's neat and
somewhat easy to understand (even for this dummy)
Chris
Implicit in all this is the fact that you don't want to push the button unless the switch is in the detent position. I think you still have 24 positions per rotation and the fact that there are 4 transitions between positions is simply a software issue. Richard
|
On Monday 01 May 2006 12:48 pm, Stefan Trethan wrote: On Mon, 01 May 2006 18:39:33 +0200, rtstofer <rstofer@...> wrote:
Among other things, if you build a software state machine to track the
changes, debouncing will be automatic. Sure, you may bobble between A
is high, B is high back and forth with A is low, B is high (or A is
high, B is low) (in other words both sides of the transition) but it
doesn't matter because only one line is changing states - you wont go
from A is high, B is high to A is low, B is low.
You aren't transitioning far enough to upset the count or miss a
detent position. But you can detect the difference between increase
and decrease. Yes, even I managed to make the software for a encoder of this type work,
and that says something!
Good thinking really that quadrature stuff... Yes... What platform did you make that software for? -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
|
--- In Electronics_101@..., "Roy J. Tellason" <rtellason@...> wrote:
On Monday 01 May 2006 12:48 pm, Stefan Trethan wrote:
On Mon, 01 May 2006 18:39:33 +0200, rtstofer <rstofer@...> wrote:
Among other things, if you build a software state machine to
track the changes, debouncing will be automatic. Sure, you may bobble
between A is high, B is high back and forth with A is low, B is high (or A is
high, B is low) (in other words both sides of the transition) but it
doesn't matter because only one line is changing states - you
wont go from A is high, B is high to A is low, B is low.
You aren't transitioning far enough to upset the count or miss a
detent position. But you can detect the difference between increase
and decrease. Yes, even I managed to make the software for a encoder of this
type work, and that says something!
Good thinking really that quadrature stuff... Yes...
What platform did you make that software for?
You may find the code in avrlib useful in designing this type of interface: The avrlib implementation is fully interrupt driven from both input phases and works on a variety of AVR devices. It is written in C. Depending on the size of the AVR device, more than one encoder can be connected. That said, the overall state transitions can be coded in any language but the idea of using interrupt inputs is a good one. It is not possible to determine when a phase change may occur. I don't always use avrlib but I have been know to parphrase the code. Even convert it to an ARM processor. Richard
|
On Monday 01 May 2006 08:42 pm, rtstofer wrote: --- In Electronics_101@..., "Roy J. Tellason"
<rtellason@...> wrote:
On Monday 01 May 2006 12:48 pm, Stefan Trethan wrote:
On Mon, 01 May 2006 18:39:33 +0200, rtstofer <rstofer@...> wrote:
Among other things, if you build a software state machine to track the
changes, debouncing will be automatic. Sure, you may bobble between A
is high, B is high back and forth with A is low, B is high (or A is
high, B is low) (in other words both sides of the transition) but it
doesn't matter because only one line is changing states - you wont go
from A is high, B is high to A is low, B is low.
You aren't transitioning far enough to upset the count or miss a
detent position. But you can detect the difference between increase
and decrease. Yes, even I managed to make the software for a encoder of this type
work, and that says something!
Good thinking really that quadrature stuff... Yes...
What platform did you make that software for? You may find the code in avrlib useful in designing this type of
interface: Rather than downloading the whole mess, which would be a bit slow on dialup, I went to the online html documentation link, and selected encoder.c and encoder.h and downloaded the documentation and source pages for both of those. I hope that's what you were referring to. :-) The encoder.h source in particular has a nice explanation in there showing waveforms and such, and explains just how it is that they deal with processing the inputs from the device. I know nothing at all about these processor chips, but I can read c well enough to see what they're doing there, which is pretty nifty from what I see so far. The avrlib implementation is fully interrupt driven from both input
phases and works on a variety of AVR devices. It is written in C.
Depending on the size of the AVR device, more than one encoder can be
connected. That's interesting too -- would that depend on how many interrupt inputs you had available or how fast the chip in question could handle one and therefore be likely to be able to deal with more than one? I know *nothing* about these parts -- is there any place in particular where you could point me to that would get me going? I'm familiar with a bunch of way earlier chips, stuff like the 8080, 8085, z80, 68xx, 65xx, and similar, but just haven't kept up. (Like I *really* need another thing on my plate, which is already pretty full. :-) That said, the overall state transitions can be coded in any language
but the idea of using interrupt inputs is a good one. It is not
possible to determine when a phase change may occur. Yeah, I looked at that bit in the header file and it made immediate sense to me. Not a bad approach at all. I'll have to look it over and study it in some detail and see how they're handling the rest of it besides the input... I don't always use avrlib but I have been know to parphrase the code.
Even convert it to an ARM processor. I don't know about those, either. A while back I thought that maybe I oughta start catching up on this newer stuff. So I subscribed to the piclist. But there was way too much OT stuff in there even after I'd supposedly configured their end to not send me all that stuff... So I gave up on that list. Maybe one of these days I'll run across a better (more focused) source of info. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
|
On Tue, 02 May 2006 02:09:27 +0200, Roy J. Tellason <rtellason@...> wrote: Yes...
What platform did you make that software for? atmel i think. ST
|
Rather than downloading the whole mess, which would be a bit slow on dialup, I went to the online html documentation link, and selected encoder.c and encoder.h and downloaded the documentation and source pages for both of
those. I hope that's what you were referring to. :-) The encoder.h source in particular has a nice explanation in there showing waveforms and such, and explains just how it is that they deal with processing the inputs from the device. There is also a device configuration file 'encoderconf.h' which sets up the maximum number of encoders and pin configuration. It does not do this based on device selection, the user has to help a little.
I know nothing at all about these processor chips, but I can read c
well enough to see what they're doing there, which is pretty nifty from what I see so far.
Having avrlib or WinAVR available makes getting started about as easy as putting blocks together. There is a lot of code available and much of it adapts automatically to the processor selected. That's interesting too -- would that depend on how many interrupt inputs you had available or how fast the chip in question could handle one and therefore be likely to be able to deal with more than one? 'encoderconf.h' sets up as many as 3 encoders although the maximum is defined as two.
I know *nothing* about these parts -- is there any place in
particular where you could point me to that would get me going? I'm familiar with a bunch of way earlier chips, stuff like the 8080, 8085, z80, 68xx, 65xx, and similar, but just haven't kept up. (Like I *really* need another thing on my plate, which is already pretty full. :-) For Windows users there is WinAVR which includes the compiler and tool kit at For Linux users you can download avrlib from but that just gets you some interesting source code. You can follow the instructions at to build avr-binutils, avr-gcc, avr-libc and uisp. Then download and build avrdude from here: FWIW, I had a problem with gcc-4.0.2 so I am using gcc-3.4.3. You can add the Eclipse IDE by download the Java Runtime Environment (JRE) from www.sun.com then grab Eclipse and the C Development Tool (CDT) from This is a couple of hundred megabytes of download. Let me know if you decide to pursue the project. I can probably burn a CD and mail it to you. You still need the instructions from slacy.com As to development hardware: see I use the ATmega128, primarily. For a programmer see . I use the AVR STK Parallel Port Dongle Programmer with avrdude. Richard
|
On Tuesday 02 May 2006 10:09 am, rtstofer wrote: Rather than downloading the whole mess, which would be a bit slow
on dialup, I went to the online html documentation link, and selected
encoder.c and encoder.h and downloaded the documentation and source pages
for both of those. I hope that's what you were referring to. :-) The
encoder.h source in particular has a nice explanation in there showing
waveforms and such, and explains just how it is that they deal with
processing the inputs from the device. There is also a device configuration file 'encoderconf.h' which sets
up the maximum number of encoders and pin configuration. It does not
do this based on device selection, the user has to help a little.
Is that something fairly general also or is it more specific to these chips? I know nothing at all about these processor chips, but I can read c
well enough to see what they're doing there, which is pretty nifty from
what I see so far. Having avrlib or WinAVR available makes getting started about as easy
as putting blocks together. There is a lot of code available and much
of it adapts automatically to the processor selected.
Interesting. That's interesting too -- would that depend on how many interrupt
inputs you had available or how fast the chip in question could handle one
and therefore be likely to be able to deal with more than one? 'encoderconf.h' sets up as many as 3 encoders although the maximum is
defined as two.
Hm. I know *nothing* about these parts -- is there any place in particular
where you could point me to that would get me going? I'm familiar with a
bunch of way earlier chips, stuff like the 8080, 8085, z80, 68xx, 65xx,
and similar, but just haven't kept up. (Like I *really* need another
thing on my plate, which is already pretty full. :-) For Windows users there is WinAVR which includes the compiler and tool
kit at
I'm not a windoze user. :-) For Linux users you can download avrlib from
but that just gets you
some interesting source code. Ok... You can follow the instructions at
to build avr-binutils, avr-gcc, avr-libc and uisp. Then download and
build avrdude from here:
FWIW, I had a
problem with gcc-4.0.2 so I am using gcc-3.4.3.
You can add the Eclipse IDE by download the Java Runtime Environment
(JRE) from www.sun.com then grab Eclipse and
the C Development Tool (CDT) from
This is a couple of hundred megabytes of download. Let me know if you
decide to pursue the project. I can probably burn a CD and mail it to
you. That would at the very least make for some interesting reading. I'll send you my address offlist. You still need the instructions from slacy.com
As to development hardware: see
I use the
ATmega128, primarily. For a programmer see
. I use the
AVR STK Parallel Port Dongle Programmer with avrdude. How much hardware does it take to get started with these parts? And what about getting a handle on the parts themselves? One of the problems I perceived with the PIC stuff was that there were so darn many of them out there, and I have no clue about the differences among them... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
|
--- In Electronics_101@..., "Roy J. Tellason" <rtellason@...> wrote:
On Tuesday 02 May 2006 10:09 am, rtstofer wrote:
Rather than downloading the whole mess, which would be a bit slow
on dialup, I went to the online html documentation link, and
selected encoder.c and encoder.h and downloaded the documentation and
source pages for both of those. I hope that's what you were referring to.
:-) The encoder.h source in particular has a nice explanation in there
showing waveforms and such, and explains just how it is that they deal with
processing the inputs from the device. There is also a device configuration file 'encoderconf.h' which sets
up the maximum number of encoders and pin configuration. It does not
do this based on device selection, the user has to help a little.
Is that something fairly general also or is it more specific to
these chips? Very device specific because it deals with interrupt signals and device pins.
I know nothing at all about these processor chips, but I can read c
well enough to see what they're doing there, which is pretty
nifty from what I see so far. Having avrlib or WinAVR available makes getting started about as easy
as putting blocks together. There is a lot of code available and much
of it adapts automatically to the processor selected.
Interesting.
That's interesting too -- would that depend on how many interrupt
inputs you had available or how fast the chip in question could
handle one and therefore be likely to be able to deal with more than one? 'encoderconf.h' sets up as many as 3 encoders although the maximum is
defined as two.
Hm.
Easily redefined for 3 if the chip supports enough interrupt pins.
For Linux users you can download avrlib from
but that just gets you
some interesting source code. Ok...
You can follow the instructions at
to build avr-binutils, avr-gcc, avr-libc and uisp. Then download and
build avrdude from here:
FWIW, I had a
problem with gcc-4.0.2 so I am using gcc-3.4.3.
You can add the Eclipse IDE by download the Java Runtime Environment
(JRE) from www.sun.com then grab Eclipse and
the C Development Tool (CDT) from
This is a couple of hundred megabytes of download. Let me know if you
decide to pursue the project. I can probably burn a CD and mail it to
you. That would at the very least make for some interesting reading.
I'll send you my address offlist.
You still need the instructions from slacy.com
As to development hardware: see
I use the
ATmega128, primarily. For a programmer see
. I use the
AVR STK Parallel Port Dongle Programmer with avrdude. How much hardware does it take to get started with these parts? And what about getting a handle on the parts themselves? One of the problems I
perceived with the PIC stuff was that there were so darn many of them out there, and I have no clue about the differences among them...
That is a problem with AVRs as well. They come in all sizes with differing internal gadgets. Check out the datasheet for the ATmega32. If is a 40 pin DIP so it is easy to breadboard and it has an internal 8 MHz clock. This makes it particularly easy to play with. Now, I haven't programmed this with avrdude because I have the Atmel STK500 programmer but all of these devices program using either ICSP (avrdude) or JTAG (which I don't use). So, look at the Olimex development board $15.95, a chip $8.28, a programming dongle $11.95 and a wall wart $3.95. You are ready to go at a pretty high level for $40 (plus shipping). The device itself has 32k of code space, 2k of SRAM, 1k of EEPROM and just about every possible gadget (I2C, SPI, USART, 3 Timers, Analog Comparator, 8 channel A/D converter plus general IO ports if the gadgets aren't using the pins). The chip can also be run at 16MHz with a crystal/ceramic resonator and will execute about 16 million instructions per second - this is very fast. In my opinion about 5 times the speed of an equivalent mid-range PIC (say 16F877) and speed is always a good thing. It's no secret that I prefer the ATmega128 primarily because it has more IO and 2 USARTs. There are a lot of applications where the '128 would sit between a PC and some kind of serial gadget such as a 32 channel servo controller. Having dual USARTs is a plus. But, the 64 pin flat pack is a PITA. As to the development board, I would install a bunch of female headers and use prototype jumpers to get the signals over onto a standard prototype board. Soldering stuff to the Olimex board kind of limits its' future use. But, who knows? Richard
|
Roy,
I tried to respond to your email but it bounced. The CD will go out
today. Good thing we skipped the downloads, it is just about 700 MB.
There are two versions of GCC. At the moment I recommand 3.4.3
You will probably need to build the tool chain as root because the
files wind up in /usr/local
After the toolchain is built, you can move to the testproject
directory and type 'make clean all' and the files should be rebuilt.
I installed Eclipse for a test but it wasn't very satisfactory because
the system already had Eclipse. If you have a problem with Eclipse at
load time, it probably can't find a satisfactory version of the java
run-time. You will need to download the JRE (Java Runtime
Environment) from www.sun.com. I wasn't able to install the CDT
plug-in because it was also installed. I installed Eclipse in
/opt/eclipse (as root) and create a link in /usr/local/bin as:
ln -s /opt/eclipse/eclipse.sh /usr/local/bin
Apparently I used Eclipse as root to download the CDT via
Help->Software Updates from the IDE.
That's about it. If you have any questions, I'll be around.
Richard
|
--- In Electronics_101@..., "rtstofer" <rstofer@...> wrote:
Roy,
I tried to respond to your email but it bounced. The CD will go out
today. Good thing we skipped the downloads, it is just about 700 MB.
There are two versions of GCC. At the moment I recommand 3.4.3
You will probably need to build the tool chain as root because the
files wind up in /usr/local
After the toolchain is built, you can move to the testproject
directory and type 'make clean all' and the files should be rebuilt.
I installed Eclipse for a test but it wasn't very satisfactory because
the system already had Eclipse. If you have a problem with Eclipse at
load time, it probably can't find a satisfactory version of the java
run-time. You will need to download the JRE (Java Runtime
Environment) from www.sun.com. I wasn't able to install the CDT
plug-in because it was also installed. I installed Eclipse in
/opt/eclipse (as root) and create a link in /usr/local/bin as:
ln -s /opt/eclipse/eclipse.sh /usr/local/bin
Apparently I used Eclipse as root to download the CDT via
Help->Software Updates from the IDE.
That's about it. If you have any questions, I'll be around.
Richard
And, I included a couple of versions of the famous (over on the LPC group) ARM Tutorial. Primarily because it documents how to install Eclipse and integrate tools like AVRDude (although the example will use an LPC programmer). Richard
|
On Tuesday 02 May 2006 01:48 pm, rtstofer wrote: There is also a device configuration file 'encoderconf.h' which sets
up the maximum number of encoders and pin configuration. It does not
do this based on device selection, the user has to help a little. Is that something fairly general also or is it more specific to
these chips?
Very device specific because it deals with interrupt signals and
device pins.
Ah, okay, then I'm just as glad I didn't bother with it. Not much point until I get into the use of those chips... <...> How much hardware does it take to get started with these parts? And
what about getting a handle on the parts themselves? One of the problems
I perceived with the PIC stuff was that there were so darn many of
them out there, and I have no clue about the differences among them... That is a problem with AVRs as well. They come in all sizes with differing
internal gadgets.
Seems typical these days. So, look at the Olimex development board
$15.95, a chip
$8.28, a programming dongle
$11.95 and a wall wart
$3.95. You are ready to go at a pretty high level for $40 (plus
shipping). Not bad. But I can't invest in that stuff at this point in time. The device itself has 32k of code space, 2k of SRAM, 1k of EEPROM and
just about every possible gadget (I2C, SPI, USART, 3 Timers, Analog
Comparator, 8 channel A/D converter plus general IO ports if the
gadgets aren't using the pins). The number of pins seems to be a problem with a lot of that sort of thing. Even back to the early microcontrollers... The chip can also be run at 16MHz with a crystal/ceramic resonator and
will execute about 16 million instructions per second - this is very
fast. In my opinion about 5 times the speed of an equivalent
mid-range PIC (say 16F877) and speed is always a good thing. Yup! It's no secret that I prefer the ATmega128 primarily because it has
more IO and 2 USARTs. There are a lot of applications where the '128
would sit between a PC and some kind of serial gadget such as a 32
channel servo controller. Having dual USARTs is a plus. But, the 64
pin flat pack is a PITA. I'm *not* ready to go there, not any time soon, for sure. As to the development board, I would install a bunch of female headers
and use prototype jumpers to get the signals over onto a standard
prototype board. Soldering stuff to the Olimex board kind of limits
its' future use. But, who knows? Sounds like a good approach to me. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
|
On Tuesday 02 May 2006 04:07 pm, rtstofer wrote: Roy,
I tried to respond to your email but it bounced. Oops. That may have been my sometimes-overly-agressive spam filters... Got it. The CD will go out today. Good thing we skipped the downloads, it is just
about 700 MB. A bit much for me at this point. :-) There are two versions of GCC. At the moment I recommand 3.4.3 I've heard of folks having the occasional bit of trouble with later versions. Looks like I have 3.2.3 installed on this box. You will probably need to build the tool chain as root because the
files wind up in /usr/local Not a problem. After the toolchain is built, you can move to the testproject
directory and type 'make clean all' and the files should be rebuilt. Ok. I installed Eclipse for a test but it wasn't very satisfactory because
the system already had Eclipse. If you have a problem with Eclipse at
load time, it probably can't find a satisfactory version of the java
run-time. You will need to download the JRE (Java Runtime
Environment) from www.sun.com. Got one of those recently, too. For a package called "multivalent" (which may be of some interest as it's supposed to let you do things with pdf files :-). I wasn't able to install the CDT plug-in because it was also installed. I
installed Eclipse in /opt/eclipse (as root) and create a link in /usr/local
/bin as:
ln -s /opt/eclipse/eclipse.sh /usr/local/bin
Apparently I used Eclipse as root to download the CDT via
Help->Software Updates from the IDE.
That's about it. If you have any questions, I'll be around. Ok... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
|
