Loading ...
Sorry, an error occurred while loading the content.
 

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

Expand Messages
  • Roy J. Tellason
    ... Yes... What platform did you make that software for? -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this
    Message 1 of 18 , May 1, 2006
      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
    • rtstofer
      ... track the ... between A ... wont go ... type work, ... You may find the code in avrlib useful in designing this type of interface:
      Message 2 of 18 , May 1, 2006
        --- In Electronics_101@yahoogroups.com, "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: http://members.home.nl/jmnieuwkamp1/AVRlib/

        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
      • Roy J. Tellason
        ... 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
        Message 3 of 18 , May 1, 2006
          On Monday 01 May 2006 08:42 pm, rtstofer wrote:
          > --- In Electronics_101@yahoogroups.com, "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: http://members.home.nl/jmnieuwkamp1/AVRlib/

          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
        • Stefan Trethan
          On Tue, 02 May 2006 02:09:27 +0200, Roy J. Tellason ... atmel i think. ST
          Message 4 of 18 , May 2, 2006
            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
          • rtstofer
            ... on dialup, ... encoder.c and ... encoder.h source ... such, and ... from the ... There is also a device configuration file encoderconf.h which sets up
            Message 5 of 18 , May 2, 2006
              > 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 http://sourceforge.net/project/showfiles.php?group_id=68108

              For Linux users you can download avrlib from
              http://members.home.nl/jmnieuwkamp1/AVRlib/ but that just gets you
              some interesting source code.

              You can follow the instructions at http://slacy.com/avr/compiler.html
              to build avr-binutils, avr-gcc, avr-libc and uisp. Then download and
              build avrdude from here:
              http://download.savannah.gnu.org/releases/avrdude/ 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 http://www.eclipse.org/ and
              the C Development Tool (CDT) from http://www.eclipse.org/cdt/

              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
              http://www.sparkfun.com/commerce/categories.php?cPath=2_10 I use the
              ATmega128, primarily. For a programmer see
              http://www.sparkfun.com/commerce/categories.php?cPath=1_7. I use the
              AVR STK Parallel Port Dongle Programmer with avrdude.

              Richard
            • Roy J. Tellason
              ... Is that something fairly general also or is it more specific to these chips? ... Interesting. ... Hm. ... I m not a windoze user. :-) ... Ok... ... That
              Message 6 of 18 , May 2, 2006
                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 http://sourceforge.net/project/showfiles.php?group_id=68108

                I'm not a windoze user. :-)

                > For Linux users you can download avrlib from
                > http://members.home.nl/jmnieuwkamp1/AVRlib/ but that just gets you
                > some interesting source code.

                Ok...

                > You can follow the instructions at http://slacy.com/avr/compiler.html
                > to build avr-binutils, avr-gcc, avr-libc and uisp. Then download and
                > build avrdude from here:
                > http://download.savannah.gnu.org/releases/avrdude/ 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 http://www.eclipse.org/ and
                > the C Development Tool (CDT) from http://www.eclipse.org/cdt/
                >
                > 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
                > http://www.sparkfun.com/commerce/categories.php?cPath=2_10 I use the
                > ATmega128, primarily. For a programmer see
                > http://www.sparkfun.com/commerce/categories.php?cPath=1_7. 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
              • rtstofer
                ... selected ... source pages ... showing ... these chips? Very device specific because it deals with interrupt signals and device pins. ... nifty from ...
                Message 7 of 18 , May 2, 2006
                  --- In Electronics_101@yahoogroups.com, "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
                  > > http://members.home.nl/jmnieuwkamp1/AVRlib/ but that just gets you
                  > > some interesting source code.
                  >
                  > Ok...
                  >
                  > > You can follow the instructions at http://slacy.com/avr/compiler.html
                  > > to build avr-binutils, avr-gcc, avr-libc and uisp. Then download and
                  > > build avrdude from here:
                  > > http://download.savannah.gnu.org/releases/avrdude/ 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 http://www.eclipse.org/ and
                  > > the C Development Tool (CDT) from http://www.eclipse.org/cdt/
                  > >
                  > > 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
                  > > http://www.sparkfun.com/commerce/categories.php?cPath=2_10 I use the
                  > > ATmega128, primarily. For a programmer see
                  > > http://www.sparkfun.com/commerce/categories.php?cPath=1_7. 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
                  http://www.sparkfun.com/commerce/product_info.php?products_id=31
                  $15.95, a chip
                  http://www.sparkfun.com/commerce/product_info.php?products_id=209
                  $8.28, a programming dongle
                  http://www.sparkfun.com/commerce/product_info.php?products_id=13
                  $11.95 and a wall wart
                  http://www.sparkfun.com/commerce/product_info.php?products_id=298
                  $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
                • rtstofer
                  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
                  Message 8 of 18 , May 2, 2006
                    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
                  • rtstofer
                    ... 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
                    Message 9 of 18 , May 2, 2006
                      --- In Electronics_101@yahoogroups.com, "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
                    • Roy J. Tellason
                      ... 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... ... Seems typical these days.
                      Message 10 of 18 , May 2, 2006
                        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
                        > http://www.sparkfun.com/commerce/product_info.php?products_id=31
                        > $15.95, a chip
                        > http://www.sparkfun.com/commerce/product_info.php?products_id=209
                        > $8.28, a programming dongle
                        > http://www.sparkfun.com/commerce/product_info.php?products_id=13
                        > $11.95 and a wall wart
                        > http://www.sparkfun.com/commerce/product_info.php?products_id=298
                        > $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
                      • Roy J. Tellason
                        ... Oops. That may have been my sometimes-overly-agressive spam filters... Got it. ... A bit much for me at this point. :-) ... I ve heard of folks having
                        Message 11 of 18 , May 2, 2006
                          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
                        Your message has been successfully submitted and would be delivered to recipients shortly.