View previous topic :: View next topic |
Author |
Message |
Futterama
Joined: 17 Oct 2005 Posts: 98
|
Help optimizing RAM usage |
Posted: Sun Dec 06, 2009 3:56 am |
|
|
Hi forum,
I'm using the PIC10F222 which has 23 bytes of RAM.
I'm running low on RAM and I have been reading on how CCS is using the RAM but I would like some help.
I have used 3 bytes as global variables (3 x int8) and 7 bytes variables in main() (1 x int16, 5 x int8 and 3 x int1). This should leave 13 bytes for CCS and me to use.
I have 1 delay_ms() in main, according to the Call Tree, this consumes 1 byte of RAM. I guess this 1 byte is used temporary, right?
Also I have some calculations consuming temporary RAM.
The thing I don't understand, is that when I look at the Call Tree, I only use the 10 bytes permanently, and the rest is temporary (for calculations) but the .lst file says:
Code: | RAM used: 18 (78%) at main() level
23 (100%) worst case |
When using calculations, does these behave like functions with local variables? So the RAM is only used temporary?
When calling the function GetFramerate, this also consumes 1 byte of RAM, but I don't pass any variables to the function and it's inline, so I don't understand what that one byte is used for.
Do I need to post all my code, for you guys to help?
Here is the Call Tree:
I'm using version 4.093.
Thanks. |
|
|
Futterama
Joined: 17 Oct 2005 Posts: 98
|
|
Posted: Sun Dec 06, 2009 7:45 am |
|
|
Well, I figured out why GetFramerate uses 1 byte RAM, it is because of the while-loops I have in there - a while() apparently uses 1 byte RAM. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Dec 06, 2009 7:53 am |
|
|
Post the first part of your .SYM file. It will show the RAM allocation. |
|
|
Futterama
Joined: 17 Oct 2005 Posts: 98
|
|
Posted: Sun Dec 06, 2009 8:34 am |
|
|
Code: | 001 TMR0
006.0 GP0
006 GPIO
006.1 GP1
006.2 GP2
006.3 GP3
007.0 ADON
007 ADCON0
007.1 GODONE
007.2 CHS0
007.3 CHS1
007.6 ANS0
007.7 ANS1
008 ADRES
009 @SCRATCH
00A @SCRATCH
00A _RETURN_
00B @SCRATCH
00C @SCRATCH
00D @SCRATCH
00F-010 MAIN.TMR0value
011 MAIN.PotValue
012 MAIN.Counter
013 MAIN.BrakeTimes
014 MAIN.Timer
015 MAIN.FrameRate
016 MAIN.PWMhigh
017 MAIN.ActTime
018.0 MAIN.Output1ON
018.1 MAIN.BrakesON
018.2 MAIN.PotHigh
018.3 MAIN.Hyst
019 MAIN.infdb
01A-01B @DIV1616.P1
01A @DIV88.P2
01A-01B @MUL1616.P3
01A MAIN.@SCRATCH1
01B @delay_ms1.P1
01B @DIV88.P2
01C-01D @DIV1616.P1
01C-01D @MUL1616.P2
01C @DIV88.@SCRATCH1
01E @MUL1616.@SCRATCH1
01E @DIV1616.@SCRATCH1 |
I'm currently trying to rewrite a part of the code to reduce RAM usage (using a int1 instead of a int8). I have plenty of codespace, so I'm trying to use more code and save RAM this way. |
|
|
mbradley
Joined: 11 Jul 2009 Posts: 118 Location: California, USA
|
|
Posted: Tue Dec 08, 2009 12:07 pm |
|
|
If I may ask, and forgive me I dont want to be someone who just throws things out there...
But could you change chips? use a different PIC?
a jump to a pic12 would offer alot more ram, but 2 extra pins on the footprint.
I ask, becouse I have tried optimizing my code to make it fit a small chip, the project worked great, client bought a reel of chips, programed at the factory, then asked me if I could add a feature. it was too late, not becouse they were programed, we could reflash after assembly, but too late becouse he bought the reel, and a new feature required more space.
Today, I tend to prototype on a larger chip, see what my usage is, then reduce the chip from there, but I try to always stay at a min of 25% free on ram and rom. _________________ Michael Bradley
www.mculabs.com
Open Drivers and Projects |
|
|
Futterama
Joined: 17 Oct 2005 Posts: 98
|
|
Posted: Tue Dec 08, 2009 12:40 pm |
|
|
mbradley, you have a good point and I also considered this - I realized that EEPROM would come in handy too.
But going from a 6-pin SOT to a 8-pin SOIC would increase my board size by 25% and the device I'm making has to be small. And well, I also bought 200 chips already
But apart from the EEPROM issue, I have solved my memory problems by optimizing my code. It now uses less RAM, but also more ROM, but the overall program execution speed has increased.
I managed to save so much RAM that I now have 2 bytes free for extra features to come.
I considered this to be a good challenge to write efficient code for the small PIC. Also a PIC12F683 is twice the price of a PIC10F222 at digikey.
Maybe next time I will make a prototype board and completely finish the PIC program before buying chips or mass produce boards. |
|
|
mbradley
Joined: 11 Jul 2009 Posts: 118 Location: California, USA
|
|
Posted: Thu Dec 10, 2009 5:25 pm |
|
|
I kinda work backwards today, I have a few favorite chips I use, and end up putting lots of features in. Then as I scale it down in physical size and prices, my clients just get happier _________________ Michael Bradley
www.mculabs.com
Open Drivers and Projects |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Fri Dec 11, 2009 6:07 am |
|
|
mbradley wrote: | I kinda work backwards today, I have a few favorite chips I use, and end up putting lots of features in. Then as I scale it down in physical size and prices, my clients just get happier | Yes, that's what I also consider the best way of designing with PIC processors. Do the prototyping from a small selection of the largest processor types available, and then when going to production you can do the optimizations. From the hundreds of processor types available at Microchip this process makes deciding the best fitting processor a lot easier.
Strive to keep 25 to 50% of ROM & RAM and 10% of the I/O pins free in the first prototype for future enhancements that will definitely pop-up.
I've spent way too much time (==money) on optimizing a product that wouldn't have been necessary when we had spent a little bit more on the next larger processor type. |
|
|
Futterama
Joined: 17 Oct 2005 Posts: 98
|
|
Posted: Fri Dec 11, 2009 6:29 am |
|
|
Working with PIC's is only a hobby for me, but determining the right chip AFTER the code has been written also applies to me |
|
|
|