>GRAEME SMITH email:
.....grysmithKILLspam
.....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:
>
>> On Sun, 13 Jun 1999 13:59:14 -0600 Graeme Smith
>> <
EraseMEgrysmithspam_OUTTakeThisOuTFREENET.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).
>
>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....
>
>>
>> >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).
>
>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
>
