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

Re: [SeattleRobotics] Coin Toss Post Mortem

Expand Messages
  • don clay
    Aren t FSM s, objects, languages, & everything else just tools of the trade that are to be used where applicable? Everybody has their own style and
    Message 1 of 45 , Jun 1, 2007
    • 0 Attachment
      Aren't FSM's, objects, languages, & everything
      else just tools of the trade that are to be used
      where applicable? Everybody has their own
      style and preferences based on experience &
      specific engineering requirements. There isn't
      a single "golden" programming technique.

      On 31 May 2007 at 22:21, Tom Capon wrote:

      > Perhaps I'm being too simplistic in looking at things, but I've felt
      > all .....
    • Randy M. Dumse
      Ed Okerson responded: Thursday, June 07, 2007 2:59 PM ... 83? I remember being asked about it in an interview in 78. What concerned me most was what was
      Message 45 of 45 , Jun 7, 2007
      • 0 Attachment
        Ed Okerson responded: Thursday, June 07, 2007 2:59 PM
        > OK, but did you continue watching as it evolved, or did you
        > just decide you didn't like it in 1983 and went off to do
        > something else?

        '83? I remember being asked about it in an interview in '78.
        What concerned me most was what was wrong with it, and it took
        me until 1984 to really understand what you couldn't do with it,
        although everyone said there wasn't anything that couldn't be
        done. A retreat to a multitasker was just another kind of goto.
        A hidden one. A context switch is still a goto, a big fancy one,
        but a goto none the less.

        > Fair enough, so we need some education to teach C programmers
        > how to write better state machines.

        If you can only imagine C programmers need better state
        machines, then yes, C programmers need better state machines.
        For the rest of the world, including guys working in assembler,
        some of them need better state machines too.

        > To some extent that may be true, but time marches on, and
        > there is no shortage of silicon. When a 32 bit processor
        > that can run a full OS like linux costs less than the 8 or 16
        > bit micro that requires specialized non-standard software to
        > function, many will choose the 32 bit processor.

        Yes, that's fair. Time does move on. On the other hand 4-bitters
        lasted longer than lots predicted. I'm sure some are still in
        use. We haven't seen the end of 8-bitters by any means, yet,
        either. Declaring the conversion of all applications to
        32-bitters immediately is quite premature. May I suggest, as a
        designer, you're looking at the front end of new designs.

        But the factories are still turning out the designs of the past
        7 to even 14+ years. They're still profitable, and ripping them
        out to "improve" them at a huge new programming cost, isn't high
        on lots of peoples task list.

        How many PICs, HC11, and AVRs are commented on the robot lists?
        Introduced in what, 1980, 1987, 1995. These are probably the
        most common mentioned processors.

        > You simply haven't looked around lately then:
        > http://www.freescale.com/webapp/sps/site/homepage.jsp?
        > nodeId=02VS0l3208

        Sure... And you can show me those quadrature encoders and full
        featured, complimentary output, deadband protected PWM on those
        processors you're linking to there?


        Oh, doesn't look like any of these PowerQUICCs list any motion
        control. Industrial control is listed in one place, along with
        printers. I bet these aren't the controllers hooked to the
        steppers and servos though.

        I don't deny there are things that can run Linux. Never said it.
        I deny there are things that run Linux that do expert motion
        control without adding supporting hardware.

        > But according to the Freescale web site the DSP56F805
        > you use is not recommended for new designs, so it may be too
        > late to get it into the toolbox. Time marches on.

        Naw. It's still active. What they are recommending instead of
        the 56F8xx chips are the 56F8xxx chips. Nearly the same type,
        but faster, with much more memory (you know, for the guys who
        have to use the bloat tools to get anything done.) Our
        SuperPlugaPod(TM) will be based on the 56F8365. Hardware has
        been done a long time, just waiting for our software guys to
        catch up. We are porting our IsoMax(TM) to it. That's the
        project I mentioned where we were leaving C behind, and gaining
        a 5x improvement in speed.

        S'pose we can give this thread a rest now? Looks like we've left
        FSM's way behind, and off on a topic not of much interest to me.
        Or is my feeling about Linux like you're feeling about Windoze
        just too big a heresay to allow to stand?

      Your message has been successfully submitted and would be delivered to recipients shortly.