¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: Encoder switches - trying to get a handle on how to use properly...


 

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

Join [email protected] to automatically receive all group messages.