View Full Version : Saving space - close to 128k
longpole001
- 25th October 2014, 10:55
Hi guys,
i need to find more code space as a result this requires some " clean up " of existing working code
i have recovered 10k in space so far , by changing any thing with an " and " to 2 x 1f statements instead. but this is not the only answer ( this saves about 60 bytes per " and" statement - yes i have a lot of compares for data matching
is there some other common way to change code to save compile space ?
looking at Lookups and anything with a string seems to be the next targets
any further advise
regards
Dheldon
HenrikOlsson
- 25th October 2014, 12:24
Without seeing or knowing anything about the code it's not easy to say but here are two general things to try:
* Obviously, pretty much anything that you're doing more than once thru out the code AND is more than two or three instructions should be made into a subroutine and called with a GOSUB. Ie, it's not worth putting something like PortB.0 = 1 as the single instruction in a subroutine but as soon as there's a couple of instructions it gets worth it. Easy enough to try and see the effect.
* Use multiple IF's instead of SELECT CASE.
Post a specific section of code, wait and see what comes back.
/Henrik.
longpole001
- 25th October 2014, 14:54
hi hendrick,
there are some 25 major sections with over 60,000 lines of code in the main program structure and the 3 support code programs for sub structures that load the flash , with graphic fonts , symbols , menus , search tables , option dephalts tables , banners , strings for serial and xls file constructs codes , serial code tables etc before the main program can be run flash is full with about 1mb of data , so posting a specific section would not seem like it would help a lot just yet
so general approach to clean seems the best starting point.,
the code for the main is now at 115k , it was at 126k before the first sweep of clean which took me 12 hours to get to , i am hoping to still find about 15k , to allow the other sections to be be written and still fit into the 128k
the code has been growing slowly over the last 3 months , but i am faced with a clean that has to yield real space , now i want to get the next sections done . such secure bootloader , and search routines etc ,
i would love a larger chip but that just not an option using pbp after 128k and puting more chips on which may have to be a real option , is not one i want to do, if i can avoid ;(
options
1. longs - droping and modifying code that use longs so longs are not needed - save about 3k up front
2. search option for data , - i think i need to look how i maybe best to do this as " multi "and" and match statements are killing me on space
3. be a better programmer - still working on that one
mark_s
- 25th October 2014, 17:17
Hello,
Have you consider a serial eeprom? A 256k could hold your font tables and images etc, freeing up a lot space
on your main processor.
longpole001
- 26th October 2014, 01:39
yes , i have already put 64mb a flash chip , for fonts , etc
what i think i need to do is look at how to search / format of the record table better handled in pbp ,
currently the methode is
if value 1 AND value 2 and value 3 then
if value 4 or value 5 = 1 then
get those records
each value may have upto 20 indexed varables attached to it so so although searching can take a few moments the amount of " and" statements to do search parameters needs to be addressed
i removed all long varables for the 2 main routines that use them , and changed the code to use 2 word values , which gave me back a massive 5k
i like pbp , but now i am is hitting the wall cos of lack of support for larger chips
each record has a
bout the tables are 50bytes per record stored in flash as data is accumulated , some recor
rsocor01
- 26th October 2014, 03:13
There are a few threads that talk about this. I started one thread a few years ago asking on how to optimize the program and save programing space.
Try to use a lot of LOOKUPs. Avoid using WORD variables whenever is possible. If the same code is repeated a few times, then create subroutines and use GOSUB.
Saving your fonts and data in an external EEPROM memory is not a bad idea.
longpole001
- 26th October 2014, 06:16
yes i would recommend an external flash / eeprom for most projects , flash is so cheep ( 64mbit = $0.14c usd / per 100 ) and when designing boards , the extra design allows for alot of options for future expansion where a change of chip may be avoided due to code space issues.
putting EVERY serial string external to the PIC has saved me a lot of valuable program space , i have started to construct a library of common words , and phrases need for the project and is loaded into the flash
Powered by vBulletin® Version 4.1.7 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.