Searching \ for '[OT] Digtally interfaced Analog Math circuits,' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/method/math.htm?key=math
Search entire site for: 'Digtally interfaced Analog Math circuits,'.

Exact match. Not showing close matches.
PICList Thread
'[OT] Digtally interfaced Analog Math circuits,'
1999\06\13@212433 by Mike Keitz

picon face
On Sun, 13 Jun 1999 13:59:14 -0600 Graeme Smith
<spam_OUTgrysmithTakeThisOuTspamFREENET.EDMONTON.AB.CA> writes:

>Anyway, problem is, I burned out before I got to understanding active
>analog circuits very well. Now I have a function I want to play with,
>that might be more efficient as an analog circuit...

The approach you suggest is not practical.  It is difficult to get any
analog circuit to work to more than 12 bits or so of precision.  A
circuit that multiplies two variable voltages together cannot be realized
with just op-amps (unless tricks are used).  Analog multiplier ICs are
made but they are kind of specialized and expensive and introduce several
more types of error.  So you're far, far ahead to do the math in
software.

>It involves floating point multiplication so its probably too
>expensive
>timewise for a PIC.

A PIC should be able to do this type of operation about 1000 times per
second with nothing too specialized.  The figure of 1000 evaluations per
second is based on running the PIC at 20 MHz; there are 5000 instructions
to do each evaluation.  (As an aside, making the analog version work much
faster than a few KHz will significantly complicate it).  If higher
speeds are needed then consider a microcontroller with multiply hardware
built in.  Most of the PIC 17CXXX's have this, as well as a more
effective way to place tables of data in the program EPROM.  But they are
also rather expensive and quirky so you may want to consider a different
brand of processor.  The various DSP chips are highly optimized for
multiplying 16 or 32 bit numbers quickly.


If you provide some more details of the formula and the size of numbers
to be used, some of the list's numerical experts could probably suggest
ways to optimize the computation.  My first advice would be at least for
now to forget about floating point.  It is very rarely necessary in
microcontroller applications since the range of values at each step in
the process can be determined beforehand.  Use binary integers that are
scaled so the formula works properly for all possible inputs.



___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: dl.http://www.juno.com/dynoget/tagj.

1999\06\14@021003 by Graeme Smith

flavicon
face
GRAEME SMITH                         email: .....grysmithKILLspamspam@spam@freenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Sun, 13 Jun 1999, Mike Keitz wrote:

{Quote hidden}

Actually I need to input a 16bit value, and output an 8 bit value, so the
precision is less than 12 bits. The problem is, that the circuit I need,
is characterized as a slope type formula... ie: y=mx+b, M tends to
have relatively small changes between different versions, so to get the
same result, in an integer I would have to go to a formula with both
multiplication and division in it. I was hoping to optimize to an easier
form. (hence the variable gain).


Analog multiplier ICs are
> made but they are kind of specialized and expensive and introduce several
> more types of error.  So you're far, far ahead to do the math in
> software.

Ok, I suppose that that was part of what I was asking....

{Quote hidden}

well that is why I asked, I have no idea what the response rate of an
active circuit should be in the linear range. Remember however this is
part of an accellerator circuit, and will be used for massive data arrays,
so I expect that even a thousand slopes a second, will tend to drag a bit
 ;)


 If higher
> speeds are needed then consider a microcontroller with multiply hardware
> built in.  Most of the PIC 17CXXX's have this, as well as a more
> effective way to place tables of data in the program EPROM.  But they are
> also rather expensive and quirky so you may want to consider a different
> brand of processor.  The various DSP chips are highly optimized for
> multiplying 16 or 32 bit numbers quickly.


I have a 17XX sample or two to work with, so I'll keep this application in
mind when I start trying to familiarize myself with them.

>
>
> If you provide some more details of the formula and the size of numbers
> to be used, some of the list's numerical experts could probably suggest
> ways to optimize the computation.

The values range from 1 to 128 for the 8 bit values (xmin), and
1.0 to 255.0 for the 16 bit values.

There are 63 values between 1.0 and 2.0, for M, of which 1.6XXX has the
most
subvalues, at about 5. I might be able to reduce the accuracy to 2 or 3
sig digits after the point.... but I will have to experiment with that,
and I am not sure I know how to evaluate the effect on my output. After
all I want a smooth function, without too much jitter to it.

Essentially what I need to do, is calculate the Y for a slope function
with a variable slope, and upper and lower limits.

Y = M * (X-Xmin) + -127

is the basic formula.... Simple math.

M is the 16 bit Float, it takes the place of the variable gain. Xmin is
what we lookup for each entry of M ( by index) X falls within the -127 to
128 range. I can reduce the storage for the 255 M values, and Xmin values
because of the particular formula involved to 1/2 of its normal value, but
that will require some fiddling with the index.

either I need to do hardware multiplication, or I need a full 32K-64K
lookup table. I can get by with a 32k one, if I can harness the
orthoganality of the formula at the two byte input level.

If I used a 32K serial eprom lookup, how long would it take to look up the
third value from the table... Assume a 256 X 128 table and two 8 bit
values as indexes.

This might be the most cost effective form of accellerator, but I hesitate
to dump 64k of constants into an eprom unless I know that I need to.





My first advice would be at least for
> now to forget about floating point.  It is very rarely necessary in
> microcontroller applications since the range of values at each step in
> the process can be determined beforehand.  Use binary integers that are
> scaled so the formula works properly for all possible inputs.
>

Harder to do than it might look.... I am still fighting with the metaphor
I am trying to achieve.... It's hard enough to see the metaphor in the
math right now.... This formula is easy to test, but it lacks the
sophistication I was hoping for.

>
Anyway... Thanks for your evaluation of Analog circuit limitations

                               Grey

1999\06\14@031121 by Peter Grey

picon face
At 12:07 AM 14/06/99 -0600, you wrote:



I had a similar problem but the equation went from linear to some complex
function. I used the floating point co processor from Al Williams - worked
a treat.


Good luck


Peter Grey


{Quote hidden}

1999\06\14@211435 by Mike Keitz

picon face
>The problem is, that the circuit I need,
>is characterized as a slope type formula... ie: y=mx+b, M tends to
>have relatively small changes between different versions, so to get
>the
>same result,

If you're considering a graphical accelerator or vector to raster
converter these problems have been extensively studied and optimized in
the past.  There should be plenty of literature available.

>The values range from 1 to 128 for the 8 bit values (xmin), and
>1.0 to 255.0 for the 16 bit values.

Use the 16-bit number as a fixed point with 8 bits of fraction.  Then the
high byte is the integer part and the low byte is the fraction (the LSB
is 1/256).  So there are 256 evenly spaced increments between 1 and 2 as
well as 2 and 3, etc.  The maximum value is 255 + 255/256.

To multiply these numbers by an integer, just multiply in binary.  The
the low 8 bits of the result are fraction and the rest is the integer.

>Essentially what I need to do, is calculate the Y for a slope function
>with a variable slope, and upper and lower limits.
>
>Y = M * (X-Xmin) + -127

If you are going compute values of Y for consecutive values of X it is
only necessary to evaluate the whole formula for the first one.
Subsequent values of Y can be obtained by just adding M to the last one.


___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: dl.http://www.juno.com/dynoget/tagj.

1999\06\14@215921 by Graeme Smith

flavicon
face
GRAEME SMITH                         email: grysmithspamspam_OUTfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Mon, 14 Jun 1999, Guy Sirton wrote:

> Hi,
>
> I am not sure I understand your problem.  Is this pure number
> crunching or a realtime control problem?
> If we're talking number crunching then why are you looking at the
> PIC?
>
Cause I have a few, and the programmer to program em ;)

I'ts actually a bit of both... its the application that is control
oriented, I just need to crunch a lot of numbers to achieve it.... Don't
Ask!

One reason I like the PIC, is I can build a really cheap co-processor
system so I can experiment with adding this to a real computer as a
peripheral.


{Quote hidden}

I can concieve of an application where that might be the requirement...
but, at least to start with, I would rather go with the hybrid
digital/analog or just straight digital circuit, so that I can interface
to it.

My experience is that digital development tends to move faster than
straight analog development because it is easier to munge up a new
metaphor.

However if you really think I can get by with a straight analog circuit
in the giga-slope range, it would be worth playing with once the concept
is proven. Stabilizing the circuit would be a real B-kitty.... so I might
need an engineer or two when I get to that point... Not going to be soon,
I would guess.

> If you can live with the tradeoffs there is
> no way any digital system will go faster.  You could trim the gain and
> offset manually or control them with a digital system.  You can use
> simulation tools such as Spice to try different configuration and get
> an idea of what you'll be getting.
>

No, I need control of the gain as well. One parameter goes to set the
gain, (M) another is a data element, X, and the third is a preset offset
for the particular gain XMIN. What I want to be able to do, is feed the
digital values, in, and read a digital value back out again quickly.



> <snip>
> > Y = M * (X-Xmin) + -127
> I didn't understand from your description where these numbers are
> coming from...  If you will be reading them with an A/D from
> somewhere then this could be your bottleneck.

M is derived from Z an 8 bit data element, and represents the slope of the
function, X is a second 8 bit data element, I want to punch in X and Z and
get Y, for any X and Z.

{Quote hidden}

Um... I don't think it is quite that easy.... for instance if I were to
use an I2C rom.... there would be some header, the address, and a code to
be sent, to get an 8 bit data unit. It might be a case of 24 bits in, for
every 8 bits out, but isn't there some latency time involved? 32uS on the
other hand is about 300 times faster than 1mS access time, suggested for
the Floating point math... 1/3 of a Mega-Slope?.... (use "m/" ....;)   )

Lets say that 0.3 "m/" is a theoretical maximum for a serial EEprom

> assuming your CPU can keep up (~30Khz).  Fast parallel roms offer
> access times in the tens of nanoseconds range.
>
Yes... well, if I am going to interface to a Fast Parrallel Rom, why not
go whole hog, and use a proper MPU, with a built-in bus... in which case
the PIC is a waste of time. I just build an PCI/ISA BUS CARD with a ROM
socket on it.

Still 10nS is approximately 100 mega-slopes

> If this is a one-off thing you should consider using your desktop PC
> with an analog interface card.
>

Its an experimental unit for testing the concept. I can't afford an analog
interface card, (or Spice as far as I know) I had heard that it was
available as shareware or something, but I haven't looked it up yet.

> If you describe your system in more detail (where the inputs are
> coming from and what bandwidth you need), I could try and give
> you more specific ideas.

Its a general proof of concept circuit, there are so many applications
where it might be useful, each with their own specific data requirements
that I would prefer not to move too quickly to a standard bandwidth.


>
> I hope this helps,
> Guy - @spam@mlsirtonKILLspamspaminter.net.il
>

1999\06\14@224126 by Graeme Smith

flavicon
face
GRAEME SMITH                         email: KILLspamgrysmithKILLspamspamfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.


On Mon, 14 Jun 1999, Mike Keitz wrote:

> >The problem is, that the circuit I need,
> >is characterized as a slope type formula... ie: y=mx+b, M tends to
> >have relatively small changes between different versions, so to get
> >the
> >same result,
>
> If you're considering a graphical accelerator or vector to raster
> converter these problems have been extensively studied and optimized in
> the past.  There should be plenty of literature available.

Nope, as far as I know, nobody else is working on this particular set of
applications yet.... but then, what do I know?

>
> >The values range from 1 to 128 for the 8 bit values (xmin), and
> >1.0 to 255.0 for the 16 bit values.
>
> Use the 16-bit number as a fixed point with 8 bits of fraction.  Then the
> high byte is the integer part and the low byte is the fraction (the LSB
> is 1/256).  So there are 256 evenly spaced increments between 1 and 2 as
> well as 2 and 3, etc.  The maximum value is 255 + 255/256.
>
I was thinking about that.... its still relatively slow, I would think,
and to do it properly I would need a more expensive chip...

{Quote hidden}

Sorry, not calculating consecutive values, values will vary, depending on
the individual application in ways that are not predictable at this point.


In fact the Slope might vary as often as X.

                               Grey

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...