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

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

Expand Messages
  • rtstofer
    ... track the ... between A ... wont go ... type work, ... You may find the code in avrlib useful in designing this type of interface:
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.