Hi,

Claudio Tagliola wrote:
>I want to represent a certain value in as little 8-bit bytes as
>possible. The value range is from -360.0 to 360.0, with 0.1 decimal
>accuracy, maybe 0.01 if room permits. This (0.1 acc.) is possible in 16
>bits, but what representation would be best/most convenient? I'm
>thinking about fixed point, but not shure (not my expertise). The
>operations I would need most is simple addition, but gonio calculations
>are needed too, albeit less used. PIC platform is the 16 family. Code
>space is an issue, code execition speed is not (except when it's > 1 ms
>per operation on a 40 Mhz PIC).

Well fixed point is definately the way to go for limited range numbers.
Floating point has it's main purpose with higly varying data (i.e. data with
different magnitude)
and this is not the case here.

The selection of your fixed point format needs to consider several facts
if you want the most efficient (in speed) solution. One way is as Spehro
suggested
if definately suitable if you wanty to present the data with 10x resolution
and
the granularity is sufficient for your app. It will still require
2bytes/sample though.
And it has the drawback that you need to multiply each sample. If for
example
you add samples frequently to an filter an extract data infrequently then
this would
be somewhat limited. Normally one used an fixed point format that is an
multiple of 2.
This way, particulary when using filter such as FIR, with size n samples (
where n is factor of 2 )
you just use the accumulated average as an 'fixed point' value.
For example let's assume an 16 sample FIR filter, when you use the
accumulated sum
you know it has the scale input*16, hence in this case your 'fixed point' is
located
between bit number 3 and 4 ( starting at 0 as lowest bit ). So bits 0-3 are
the
fractional part and all above is the 'integer' part. To 'extract' the
integer part
one just performs an right shift by 4.
Fixed point math are trivial in the sence that you do not need to know
that it is fixed point, use any standard add/subtract/mutliply etc routine
and you'll be fine. The only time one need to know the format is when you
want to 'extract'
your data to 'readable' format. Nicolais excellent code generator for
constant
multiplication can perform wonders for this type of calculations :)

For example, consider the following:
Fixed point data 3bytes where upper two bytes are integer part and lowest
byte
is fractional part ( 256 sample sum for example ) i.e. 16q8 format.
That is real_vaule= Value_24bit/256, this is trivial ofcource. However
now lets assume we want to have an resolution of 0.01 instead. We then
will have: real_value_in_hundreds = Value_24bit*100/256 =
Value_24bit*(100/256) = Value_24bit*0.390625
Now this could be a bit tricky and time consuming to calculate, here comes
the code generator to the rescue. Enter input data size in Nicolais
generator
and enter the constant 0.360625. Now it will generate very efficient code
for your fixedpoint raw data to 'readable' data with resolution 0.01.

It really is easy to deal with fixed point,


/Tony

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads