I actually looked this time. The TI part number is TMS320F240, but it
might
be TMS320F/C240 for the basic controller, I used a variant called the
TMS320F243. They have CAN, SPI, SCI, eight channels of 10-bit A/D - some
versions with 16 A-D channels, and they use a thing called JTAG that is like
the BDM single wire debug interface built-in. The '243 version has 8 A/D
inputs and converts in 1 uS. Interrupts don't automatically save context
(they figure you are in a hurry) and the A/D inputs really need a buffer amp
to drive them. The specs do tell you this, but I didn't pick up on the
A/D
buffer (opamp) need until I started playing with a development board.
I think they now have a newer family with a name like TMS320F/2000. It
might be called the "C2000 platform" that is part of the TMS320
family. The
'243 is considered part of this C2000 platform.
I have a book called "TMS320F/C240 DSP Controllers Peripheral Library
and
Specific Devices Reference Guide" 1999, SPRU161C. They have tons of
books
you can order, and this is one of many that I have. They'll even send you
a
book on their compiler, not part of the IDE (I think). The number of app
notes on motor driving is astounding. They're real popular for driving
switched reluctance motors, since those need a DSP to filter out unwanted
vibrations inherent to that type of new, cheap motor.
This is one of their Fixed-point processors, which live off in a world of
their own. It is a microcontroller, not unlike the Motorola HC11/12, with
lots of on-board peripherals. It is a real 16-bit machine, which addresses
16-bit memory, not a pseudo 16 bitter like the 12, which addresses 8-bit
memory.
I bought my development boards from an outfit called Spectrum Digital, Inc.
in Houston, TX. I think they also sold one system through TI.
But I do love the HC12. It's like a marriage and I made a commitment.
Now
if I had it to do over...
Bob White
----- Original Message -----
From: "Paul Johnson" <>
To: <>
Sent: Sunday, March 09, 2003 6:10 PM
Subject: RE: [68HC12] Quadrature Inputs
The only things I could find on TI's website with TMS340 in the part
number
were 32 bit graphics processors, all but one of which are listed as
obsolete. I didn't find anything like what you are describing.
Could it be a different series?
Thanks,
Paul
> -----Original Message-----
> From: Bob White [mailto:]
> Sent: Sunday, March 09, 2003 12:02 PM
> To:
> Subject: Re: [68HC12] Quadrature Inputs
> Check out the TI TMS340 series. Fixed point DSP. It's pretty
> much made for
> motor control and has quadrature decoding built in. A real fast, cheap
> (about same as HC12) flash DSP. You'll love the Code Composer IDE -
it
> comes with real books that tell you how to use it, written by
> technically-competent people whose primary language is English.
> Same story
> for the hardware. You'll probably want to code in C. The
> assembly language
> is amazing(ly complex). It has two ALUs, one just for address
> calculations.
> Modified Harvard architecture. True 16-bit machine. It'll do a
> MAC in one
> clock cycle. If I weren't stuck with a legacy product, I'd be
using TI.
> This is all from memory a few years old, so don't quote me.
>
> Bob White
>
> ----- Original Message -----
> From: "Paul Johnson" <>
> To: <>
> Sent: Sunday, March 09, 2003 8:16 AM
> Subject: RE: [68HC12] Quadrature Inputs
> > It's pretty simple:
> >
> > In a loop: Concatenate the actual two bit encoder information with
the
> > saved two bits of the last round. From these 4 Bits you get 16
> > combinations, forward, backward, no change and illegal (each four
> > times).
> >
> > Use a jump table to increment/decrement the counter (accumulator)
or
> > signal an error.
> >
> > Use some kind of handshake to the host if you output parallel data:
> > either a strobe signal triggered by the host, or a "data
illegal" bit.
> >
> > With a 20MHz PIC, I got 4,5us cycle time IIRC.
>
> It sounds like this is a polling approach. I was thinking of doing
> something similar to what Bob suggested, but attaching Quad-A to an
> interrupt which triggers on any transition, then checking the value of
the
> other line in the ISR. I suppose that if the encoder was sitting
> right on a
> line, however, this might swamp the interrupt input, but I have
> not commonly
> seen this with encoders. With low interrupt latency, I would think this
> would be pretty reliable, no?
>
> Paul
>
> --------------------
>
> ">http://docs.yahoo.com/info/terms/
>
> --------------------
>
> ">http://docs.yahoo.com/info/terms/
--------------------
">http://docs.yahoo.com/info/terms/
|