Searching \ for '[PIC]: Tips to reduce Program Size using CCS C' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/languages.htm?key=c
Search entire site for: 'Tips to reduce Program Size using CCS C'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Tips to reduce Program Size using CCS C'
2003\06\03@082819 by Mccauley, Daniel H

flavicon
face
I'm currently working on a large program using a PIC16C66x processor (8k)
using CCS C.  However, I'm already at 44% ROM space used and only about
half-way
through the program, so I am a little concerned about program space.  I
think the killers are the floating point numbers I'm using.

Anyways, are there anything else I can do to help conserve program space.
Does using the #SEPARATE directive for functions help reduce space (at the
cost of speed)?

Any help appreciated.

Thanks

Dan

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

2003\06\03@084909 by Wouter van Ooijen

face picon face
> I think the killers are the floating point numbers I'm using.

Use fixed-point arithmetic: integers that represent a certain base value
(not necessarily 1). more work for you, much less code.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2003\06\03@090557 by Kenneth Lumia

picon face
Dan,

First, look at the *.tre file that contains a list of the functions and
number of bytes
they consume. Review the functions that contain the largest number of bytes
for
possible code reduction.  Look at the *.lst file for those functions and see
which
"C" statements are hogging memory; then see if you can figure out how to
remove
them (i.e. think subroutine, etc. - just pass pointers).    Finally, do you
really
need the floating point?  Fixed point math is much smaller, but you need to
keep
track of the decimal point and its not as accurate as fp.  Multiplying the
value
by 256 (create a union and store the value in the high byte ) is very
efficient.

Ken
{Original Message removed}

2003\06\03@090809 by Mccauley, Daniel H

flavicon
face
So is that basically like taking a LONG INT (0-62536 or whatever it is) and
making it:

0 to 62.536
or
0 to 625.36 etc...????

Is that basically all one is doing here???

Thanks
Dan



> > I think the killers are the floating point numbers I'm using.
>
> Use fixed-point arithmetic: integers that represent a certain
> base value
> (not necessarily 1). more work for you, much less code.
>
> Wouter van Ooijen
>

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

2003\06\03@091614 by hael Rigby-Jones

picon face
> > > I think the killers are the floating point numbers I'm using.
> >
> > Use fixed-point arithmetic: integers that represent a certain
> > base value
> > (not necessarily 1). more work for you, much less code.
> >
> > Wouter van Ooijen
> >
>
>
> {Original Message removed}

2003\06\03@194259 by Herbert Graf

flavicon
face
> I'm currently working on a large program using a PIC16C66x processor (8k)
> using CCS C.  However, I'm already at 44% ROM space used and only about
> half-way
> through the program, so I am a little concerned about program space.  I
> think the killers are the floating point numbers I'm using.
>
> Anyways, are there anything else I can do to help conserve program space.

       Do you REALLY need to use floating point numbers? Fixed point will pretty
much due for almost all cases out there (unless you really do need the wide
range given by floating point) and yet not require any fancy arithmetic to
accomplish. TTYL

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

2003\06\03@194309 by Herbert Graf

flavicon
face
> So is that basically like taking a LONG INT (0-62536 or whatever
> it is) and
> making it:
>
> 0 to 62.536
> or
> 0 to 625.36 etc...????
>
> Is that basically all one is doing here???

       Yup, which is why it's so much more efficient then using floating point.
TTYL

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

2003\06\03@211340 by Bob Ammerman

picon face
You will find that a lot of the space you are using now is for the floating
point library. That will not grow much as you add more code.

Try this:

Create a small program that uses all the floating point operations and
functions that your program will. You will be surprised how big it will be
when compiled and linked.

If you really have 50% of the code done and are using 44% of the ROM space
you are probably going to be just fine.

Bob Ammerman
RAm Systems

ps: another HUGE gobbler of memory are the  ...printf() family of functions.
If you can eliminate all references to them you will be much happier.

{Original Message removed}

2003\06\03@211911 by Bob Ammerman

picon face
> So is that basically like taking a LONG INT (0-62536 or whatever it is)
and
> making it:
>
> 0 to 62.536
> or
> 0 to 625.36 etc...????

But really treating it more like

0 to 11111111.11111111b

ie: it is a binary point, not  a decimal point.

Bob Ammerman
RAm Systems

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

2003\06\04@081327 by Mccauley, Daniel H

flavicon
face
Thanks Bob.
Yes, I do use quite a bit of printf() functions for the LCD display.  I
definitely know thats eating up lots
of space!

Thanks again.
Dan



{Quote hidden}

> {Original Message removed}

2003\06\04@081915 by Mike Harrison

flavicon
face
Do you really need floating point ? How about using fixed-point longs ? I've yet to see a Pic-scale embedded app that really needs the range of FP. Remember FP gives you
range, not precision.
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\06\04@085935 by Bob Axtell

face picon face
I agree with Mike 100%. I can implement a 23-bit plus sign that runs 2000%
faster with 1/5 the code, works for every math application I ever needed.

For those of you who care, my front-end ISP had to be changed for
unreliability. This is it from now on. Thanks!

--Bob Axtell

At 01:16 PM 6/4/2003 +0100, you wrote:
{Quote hidden}

---------------
NOTICE

1. This account can accept email & attachments up to 10M in size.
2. Federal Monitors: At request of client, some attachments are encrypted.
Please DO NOT delay traffic; please reply with credentials for password.
--------------

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

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