Searching \ for '[PIC]: Scaling down from 00 - FF' 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/microchip/devices.htm?key=pic
Search entire site for: 'Scaling down from 00 - FF'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Scaling down from 00 - FF'
2000\10\30@235626 by David Duffy

flavicon
face
Hi,
I want to scale an incoming byte 00 - FF into a smaller range of
values so that 00 still is 00 but FF gets cut down to say 28h with
all the values in between filled in. I though of a few ways to do it;
1) Divide by a constant & round the result.
    Maybe the best but I may need to change the curve of the scaling.
2) A 256 byte table.
    Very definable but large & a pain to change scale.
3) Lots of compares.
    Changeable points but woefully long & ugly.
I may need a few different scales in this application so does anyone
have any brilliant ideas on the the best way? Maybe there is another
solution that I've missed?
Regards...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\10\31@011843 by McMeikan, Andrew

flavicon
face
20h or 40h would be just some shifts, maybe shift to 40h then take off a
smaller proportion (shift down to 10h)
Enough of an idea?

       cya,    Andrew...

> {Original Message removed}

2000\10\31@050123 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,
if not simple rotate will be sufficient ( i.e. scale
by 1/2, 1/4 etc ) then try out the code generator on the
piclist site, here what came with scaling to 0xFF->0x28:

; ACC = ACC * 0.156863
; Temp = TEMP
; ACC size = 8 bits
; Error = 0.500000%
; Bytes order = little endian
; Round = no

; ALGORITHM:
; Clear accumulator
; Add input / 8 to accumulator
; Add input / 32 to accumulator
; Move accumulator to result
;
; Error in constant approximation : 0.390596, %


; Input:  ACC0  (8 bits)
; Output: ACC0  (6 bits)

       cblock
       ACC0
       endc

;copy accumulator to temporary
       movf    ACC0, w

;shift accumulator right 2 times
       clrc
       rrf     ACC0, f
       clrc
       rrf     ACC0, f

;add temporary to accumulator
       addwf   ACC0, f

;shift accumulator right 3 times
       rrf     ACC0, f
       clrc
       rrf     ACC0, f
       clrc
       rrf     ACC0, f


; Generated by http://www.piclist.com/cgi-bin/constdivmul.exe (September 13,
2000 version)
; Tue Oct 31 09:51:16 2000 GMT

Reached at:
www.piclist.com/techref/default.asp?from=/techref/piclist/../micr
ochip/math/../../piclist/codegen/&url=constdivmul.htm

/Tony


Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: spam_OUTtony.kubekTakeThisOuTspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@063523 by mike

flavicon
face
On Tue, 31 Oct 2000 14:56:36 +1000, you wrote:

>Hi,
>I want to scale an incoming byte 00 - FF into a smaller range of
>values so that 00 still is 00 but FF gets cut down to say 28h with
>all the values in between filled in. I though of a few ways to do it;
>1) Divide by a constant & round the result.
>     Maybe the best but I may need to change the curve of the scaling.
>2) A 256 byte table.
>     Very definable but large & a pain to change scale.
>3) Lots of compares.
>     Changeable points but woefully long & ugly.
>I may need a few different scales in this application so does anyone
>have any brilliant ideas on the the best way? Maybe there is another
>solution that I've missed?
>Regards...

Do an 8x8 Multiply with a constant and use the high byte of the
result. Think of the constant as a fraction of 256, e.g. to scale the input to
30%, multiply by (30% of 256), i.e. 77 dec (rounded to nearest).
Welcome to the world of fixed-point arithmetic!
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@090638 by Olin Lathrop

flavicon
face
> I want to scale an incoming byte 00 - FF into a smaller range of
> values so that 00 still is 00 but FF gets cut down to say 28h with
> all the values in between filled in. I though of a few ways to do it;
> 1) Divide by a constant & round the result.
>      Maybe the best but I may need to change the curve of the scaling.
> 2) A 256 byte table.
>      Very definable but large & a pain to change scale.
> 3) Lots of compares.

You don't say what machine you're on, how critical code space is, and how
critical execution speed is.  I think there are two basic solutions, a table
and a fixed point multiply.

Since you are multiplying by a number less than 1, this works well when
expressed in fixed point with 8 fraction bits.  Multiplying this value by
the original byte yields the scaled value in the high byte.  This solution
is especially attractive if you are on a machine with a hardware multiplier.

The table is more general and probably the fastest solution if you don't
have a hardware multiplier, but it can eat up code space.  However, note
that you don't need to index into the table with all 8 input bits.  If the
result is only in the 0 - 40 range you should look at using only the high 6
bits of the input value as the table index for exapmle.  I like to use
assembler loops to write such tables for me.  It prevents error in typing in
individual values, and it makes it simple to change the overall scale or
whatever of the table if needed.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam@spam@cognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@152317 by Don Hyde

flavicon
face
I prefer to cut-and-paste from a spreadsheet for tables.  That way you can
get real fancy with the calculations, then make a column in the spreadsheet
where the values are all scaled and rounded just the way you need them to
make the PIC computations as simple as possible.

I've got some radio code with a whole slew of tables for frequency selection
and modulation patterns and stuff.  Whenever the RF boys change their minds,
I just mess around with the spreadsheet a little, cut-and-paste, and voila!
I have new code faster then they can make up their minds about the next bout
of changes.

SNIP

 I like to use
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@175313 by David Duffy

flavicon
face
Olin wrote:
> > I want to scale an incoming byte 00 - FF into a smaller range of
> > values so that 00 still is 00 but FF gets cut down to say 28h with
> > all the values in between filled in. I though of a few ways to do it;
> > 1) Divide by a constant & round the result.
> >      Maybe the best but I may need to change the curve of the scaling.
> > 2) A 256 byte table.
> >      Very definable but large & a pain to change scale.
> > 3) Lots of compares.
>
>You don't say what machine you're on, how critical code space is, and how
>critical execution speed is.  I think there are two basic solutions, a table
>and a fixed point multiply.

Sorry, forgot to say it's on a 16F876 but may have to jam it into a 16F628
whenever they get released and readily available. (or even a 16F84A)
Not sure how much code space I will need - still early days yet. Execution
needs to be fairly quick as there is the possibility of multiple commands
arriving from the host system in quick succession.

>Since you are multiplying by a number less than 1, this works well when
>expressed in fixed point with 8 fraction bits.  Multiplying this value by
>the original byte yields the scaled value in the high byte.  This solution
>is especially attractive if you are on a machine with a hardware multiplier.

I've never needed to do math before in a PIC - might be time to learn!

>The table is more general and probably the fastest solution if you don't
>have a hardware multiplier, but it can eat up code space.  However, note
>that you don't need to index into the table with all 8 input bits.  If the
>result is only in the 0 - 40 range you should look at using only the high 6
>bits of the input value as the table index for exapmle.  I like to use
>assembler loops to write such tables for me.  It prevents error in typing in
>individual values, and it makes it simple to change the overall scale or
>whatever of the table if needed.

I think the table is probably the most quick & portable solution as present.
Just have to brush up on those page boundary crossing details.  :-)
Regards...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@181144 by Tony Nixon

flavicon
picon face
David Duffy wrote:

> I think the table is probably the most quick & portable solution as present.
> Just have to brush up on those page boundary crossing details.  :-)
> Regards...

This might be of help for table creation...

http://www.picnpoke.com/demo/dtimg.html

--
Best regards

Tony

mICro's
http://www.picnpoke.com
.....salesKILLspamspam.....picnpoke.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@233134 by Normand

flavicon
face
Easy solution is to divide by 8 then scale 0 to 32 with a table

Regards...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\10\31@234831 by David Duffy

flavicon
face
Normand <EraseMElassonspam_OUTspamTakeThisOuTVIDEOTRON.CA wrote:
>Easy solution is to divide by 8 then scale 0 to 32 with a table

Eh?  That only works if the smaller scale divides into 256 nicely.
My example was a final range of 00h - 28h.
Regards...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.





'[PIC]: Scaling down from 00 - FF'
2000\11\01@041550 by Alan B. Pearce
face picon face
>I prefer to cut-and-paste from a spreadsheet for tables.

Having been playing with VBA recently in Excel, I suspect you could persuade
your spreadsheet to write an include file at the push of a button, which would
speed the process up even further (once you had the VBA written, but that would
be a case of slightly modifying existing code for writing CSV files).

Then you could have the new code assembled before they have even stopped talking
about what they want ;))

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use listservspamspam_OUTmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@100821 by Nikolai Golovchenko

flavicon
face
David,

try http://www.piclist.com/codegen/constdivmul

About as quick as table (example below is 11 instruction
cycles) and much less code size. And it is automatic!

Nikolai

---- Original Message ----
From: Kübek Tony <@spam@tony.kubekKILLspamspamFLINTAB.COM>
Sent: Tuesday, October 31, 2000 11:57:02
 To: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
Subj: [PIC]: Scaling down from 00 - FF

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use spamBeGonelistservspamBeGonespammitvma.mit.edu?bodyT%20PICList%20DIGEST




2000\11\01@141302 by rich+piclist

flavicon
face
40/255=.15686... (probably irrational), 0.0010100 in binary is .15625
which appears to be closest, i.e. 40/256=1/8+1/32, so perhaps something
like:

 andlw 0xf8            ; avoid carry
 clc
 movwf temp            ; save N
 rrf temp,f
 rrf temp,f
 rrf temp,f
 movf temp,w           ; w = N/8
 rrf temp,f
 clc
 rrf temp,f
 addf temp,w           ; w=N/8+N/32

== Rich

On Wed, 1 Nov 2000, David Duffy wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@161429 by Olin Lathrop

flavicon
face
> 40/255=.15686... (probably irrational)

No.  Irrational numbers, by definition, are those that CAN'T be expressed as
the quotient of two integers.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinspam_OUTspamKILLspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservTakeThisOuTspamspammitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@183156 by rich+piclist

flavicon
face
Um. Good point. What's the right term for "infinite length non-repetitive
rational numbers"?

And anyway, who said I was talking about the number? :)

On Wed, 1 Nov 2000, Olin Lathrop wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use EraseMElistservspamEraseMEmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@185356 by Peter L. Peres

picon face
David, you can write a small program that will calculate a 'hard way'
mapping (scaling) using direct PIC code output if you want. It is very
much like the other table analysis example I gave. The output code outline
is:

1. Set acc = highest output code
2. compare input to the input step from table (that causes an output change)
 if above, done, return acc
3. apply some operation to the acc using data from table or not (e.g.
shift right or substract)
4. select next table entry, and continue from 2
 if no more table entries, return acc (which should be lowest output value)

This is a basic mapping function implemented 'a la pic' because on almost
any other machine you'd use some sort of lookup table instead. If you use
C code and can afford floats then you can try to write a function that
scales as you wish and see what the compiler produces from it. Otherwise
you can use a float function and then re-implement it using integer
arithmetic (some skill required) to reduce code size. I suspect that the
table will be less than 64 locations (32 values). This makes for a pretty
good approximation for most human-related purposes (inexpensive
logarythmic volume potentiometers can have the log curve approximated by
only 4 straight segments !).

The table can be computed by an auxiliary program described as above (in
the 1st paragraph of this mail) running on a PC.

hope this helps,

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use @spam@listserv@spam@spamspam_OUTmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@202834 by Scott Dattalo

face
flavicon
face
On Wed, 1 Nov 2000 rich+spamBeGonepiclistspamKILLspamLCLOGIC.COM wrote:

> Um. Good point. What's the right term for "infinite length non-repetitive
> rational numbers"?

As Olin said, there's no such thing - by definition.

Division by 255 repeats with (at most) a 17 digit pattern.


{Quote hidden}

.15686274509803921568627450980392 ...

repeats every 16 digits

> >
> > No.  Irrational numbers, by definition, are those that CAN'T be expressed as
> > the quotient of two integers.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use .....listservspamRemoveMEmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@204554 by Barry Gershenfeld

picon face
>> Um. Good point. What's the right term for "infinite length non-repetitive
>> rational numbers"?
>
>As Olin said, there's no such thing - by definition.

I think you call them non-terminating decimals.  Note that
'decimals' doesn't mean all that much to a piece of
base-two hardware (and "nice" numbers like 0.1 drive
it crazy!  They don't terminate in binary....)

Barry

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservspamspamBeGonemitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@210422 by rich+piclist

flavicon
face
> Division by 255 repeats with (at most) a 17 digit pattern.
Cool, how did you derive this?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use spamBeGonelistserv@spam@spamspam_OUTmitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@212716 by Bob Ammerman

picon face
> Um. Good point. What's the right term for "infinite length non-repetitive
> rational numbers"?

The right term is 'nonexistant'.

The decimal expansions of _all_ rational numbers either repeat or are
finite.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)


{Quote hidden}

expressed as
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use spamBeGonelistservEraseMEspammitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\01@212929 by Bob Ammerman

picon face
Not sure how Olin got this, but here is some thoughts on the matter:

255 can be expressed as prime factors as 5*3*17

I wonder if that 17 has something to do with it?

{Original Message removed}

2000\11\02@101238 by Olin Lathrop

flavicon
face
> Not sure how Olin got this, but here is some thoughts on the matter:
>
> 255 can be expressed as prime factors as 5*3*17
>
> I wonder if that 17 has something to do with it?
>
> {Original Message removed}

2000\11\02@101252 by Olin Lathrop

flavicon
face
> Um. Good point. What's the right term for "infinite length non-repetitive
> rational numbers"?

There is no such thing because all rational numbers will repeat in a finite
number of digits.  Arbitrary real numbers do not, or you could say
"irrational" to specifify that particular subset of real numbers that are
not rational.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinspamBeGonespamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspamBeGonemitvma.mit.edu




2000\11\02@114849 by Scott Dattalo

face
flavicon
face
On Thu, 2 Nov 2000, Olin Lathrop wrote:

> > Not sure how Olin got this, but here is some thoughts on the matter:
> >
> > 255 can be expressed as prime factors as 5*3*17
> >
> > I wonder if that 17 has something to do with it?
> >
> > {Original Message removed}

2000\11\02@131103 by Bob Ammerman

picon face
Sorry Scott, I certainly wouldn't want to confuse you with Olin... :-)

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\11\02@144934 by rich+piclist

flavicon
face
On Thu, 2 Nov 2000, Scott Dattalo wrote:

> Date: Thu, 2 Nov 2000 10:53:40 -0600
> From: Scott Dattalo <.....scott@spam@spamEraseMEDATTALO.COM>
> Reply-To: pic microcontroller discussion list <.....PICLISTRemoveMEspamMITVMA.MIT.EDU>
> To: .....PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU
> Subject: Re: [PIC]: Scaling down from 00 - FF
>
> On Thu, 2 Nov 2000, Olin Lathrop wrote:
>
> > > Not sure how Olin got this, but here is some thoughts on the matter:
> > >
> > > 255 can be expressed as prime factors as 5*3*17
> > >
> > > I wonder if that 17 has something to do with it?
> > >
> > > {Original Message removed}

2000\11\02@154807 by Olin Lathrop

flavicon
face
> Wow, I will need to ponder.
>
> So do you think this behavior is independent of conversion base, i.e.
> x/255 is no more than 17 digits even in binary, octal, base 1e17?
>
> If so, can we postulate that any rational number can be expressed as
> 'prime factor' repeating digits if written in the appropriate base?
>
> Then 1/bigprime in base X yields psuedo-random sequence of length bigprime
> in range 0 to X-1... potential for crypto system? Very cool, in any case.
>
> BTW, I can't find any examples where x/y yields y repeating digits (where
> y is prime), the best I can do is y-1, are you sure it's not 'prime factor
> minus 1'?

You are right.  The maximum number of digits in the repeating sequence
representing 1/y is y - 1.  Think of this as doing repeated integer divides
with the remainder of from one digit feeding the numerator value for the
divide of the next digit.  In that case, there are only Y possible
remainders, make at most Y possible "states" in the repeating sequence.
However, if the remainder ever becomes 0, then the sequence terminates (no
error left, number represented exactly) instead of repeating infinitely.
There are therefore at most Y-1 possible "states" in such a repeating
sequence.  This also shows that this is independent of the number base.

Lets do 1/7 in decimal as an example:

1/7 = 0 remainder 1, so the 1s digit is 0.  So far: 0.

take remainder 1 times the radix for numerator: 10/7 = 1 rem 3.  So far 0.1

30/7 = 4 rem 2:  0.14
20/7 = 2 rem 6:  0.142
60/7 = 8 rem 4:  0.1428
40/7 = 5 rem 5:  0.14285
...

As you can see, the only "state" between digits is the remainder, which is
always an integer from 1 to 6.  This sequence therefore must repeat in 6
digits or less.  This particular one happens to take 6 digits in base 10.

The same thing works in any radix.  Here is the same example in base two:

1/7 = 0 rem 1:  0.
2/7 = 0 rem 2:  0.0
4/7 = 0 rem 4:  0.00
8/7 = 1 rem 1:  0.001

at which point the sequence repeats because we have already encountered a
remainder of 1 before.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinEraseMEspam@spam@cognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu




2000\11\02@161654 by rich+piclist

flavicon
face
> As you can see, the only "state" between digits is the remainder, which is
> always an integer from 1 to 6.  This sequence therefore must repeat in 6
> digits or less.  This particular one happens to take 6 digits in base 10.
Thanks Olin, well said and now makes perfect sense :)

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu




2000\11\02@181336 by Bob Ammerman

picon face
Very nice thinking!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

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