EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

Quadrature Inputs

Started by Paul Johnson March 8, 2003
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/


In a message dated 3/10/03 1:21:56 PM Eastern Standard Time,
writes:

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

My Tech Arts 812DX has 16 bit wide ram and rom....



----- Original Message -----
From: "John Smith" <>
To: <>
Sent: Monday, March 10, 2003 2:24 AM
Subject: Re: [68HC12] Quadrature Inputs > Hi,
>
> Some years back i did a winch controle wire out and speed for a ship
trawl
> warps.
> I used a 8051 then and did it as follows:
>
> Used a D-type latch 74HCT74 with PRE/CLR connected to Vcc. The one phase
> input connected to "D" input and the Q connected to a port pin (the /Q not
> used).
>
> The other phase goes to the Clock pin on the D type latch and at the same
> time to a interrupt line on the processor.
>
> Both phases should be buffered with hysterieses , barrier diode, caps etc.
>
> IT WORKS AS FOLLOW:......78>))
>
> The the one phase feeding into D and the other into the clock input of
the
> 74HCT74 we obtain the phase leading or lagging so we can figure out what
> direction the shaft turns. The Q output will indicate the direction "0"
one
> direction "1" other direction.
>
> The one phase feeding straight into the CPU has to functions. First, it is
> used to measure time intervals for measuring shaft speed. Second, it is
used
> as a pulse counter to measure length of wire. So we end up with 3 neat
> variables, speed wire out and direction!!
>
> Now just for the interrest of it. Do not place your sensors on the wire
> drum!!! Place your sensors on a roler that has a consistant diameter to
the
> cable spooling.............
>
> Frank van der Merwe(the info is free....) >
>
> ----- Original Message -----
> From: <>
> To: <>
> Sent: Saturday, March 08, 2003 8:04 PM
> Subject: Re: [68HC12] Quadrature Inputs > > In a message dated 3/8/03 8:52:38 PM Eastern Standard Time,
> > writes:
> >
> > > I'm surprised, given the number of embedded applications
> > > involving motor
> > > control or data capture, that almost no micros out there support
> > > quadrature
> > > input. On our products, we use Xilinx FPGA's that provide 8 sets of
> > > quadrature input and handle all the accumulation, etc.
> > > However, on small footprint boards, with a simple task, it
> > > would be very
> > > desirable to lose the Xilinx and just read quadrature directly. Even
> > > just
> > > one pair of quadrature inputs would be fine.
> > > Has anyone out there solved this problem?
> >
> > Just hook one of the encoder lines to an input with edge triggered
> interrupt,
> > arm for falling edge interrupt (for instance), read other encoder line
in
> > handler, inc on hi, dec on lo.
> >
> >
> >
> >
> >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/
> >
> >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/ >




--- In , "Paul Johnson" <paul@l...> wrote:
> > It's pretty simple:
> >
> 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

Reliable yes. I have done it exactly that way several times. You
don't need PICs or D-flops or anything, at least if you have two
spare inputs. If you don't need maximum resolution, set one as an
input capture on a fixed edge (either one), and every time you get an
interrupt, examine the level of the _other_ input. It works in
either direction, and the time between interrupts gives you the
speed. You can get much more resolution by interrupting on both
edges of both inputs, but that gets tricky, so only do it if you need
the resolution.

I live down the road from you, so if you need a higher level of
assistance, let me know, I can come by.

Gary Olmstead
Toucan Technology
Ventura CA



The 2024 Embedded Online Conference