![]() |
Space Limit--What is expendable?
My problem is this: it appears that i am reaching the limit on the EDU controller for space. It has gotten to the point where i need to comment out portions of my code to get it to even transfer.
I am able to compile it with no problem using MPlab. When i transfer, it says opennign port, the "Erasing Device" where it stays for about 10 seconds, then, it says device not connected. When i comment stuff out, or use less memory by using ints instead of floats, it works fine. My real problem is that i only have the guidence program created, no autonomous control, no braking, no arms, etc. What in the default code can i get rid of? I need to recover as much space as possible so that i only use the absolute necessary code. Any help is appreciated. |
Hmm, well yes, you want to stick with as many ints as possible. The math is processed faster for them, and they take up less space.
There are a number of routines you can erase from the default code. Mainly, I would read through the Default_Routine sub and then clear it out. Depending on your method of executing auto mode, you could be eating lots of memory. If you're doing it case-by-case with lost of IFs, or a switch or something, that needs to change. The method I use is to hold an array of movement data and then have a small piece of code that executes it. It works fine, and you can have some massive arrays too. It also sounds like something might've gotten modified that shouldn't have...:D We had someone do this on our team and we had memory problems too. We had to restart from scratch from that point. |
Re: Space Limit--What is expendable?
Quote:
Also, if you haven't done it already, get rid of the printf_lib stuff. It takes up a ton of code space for essentially a debugging function. If you remove printf_lib, you can still output stuff to the serial port, just not as nicely as with printf. |
I did delete all of the Default section as well as a few functions that were not being used. I did keep the printf section, at least for now.
I believe i figured out the problem. I did not realize that floats were not native to the chip archetecture, so, in my one line i did a cast promotion to do : pwm01=pwm02*((float)in1/127.00) this i guess must have taken up a lot of memory, so instead i made it like this: pwm01=pwm02*in1/127, keeping it entirely integer mathematics. Shoulda thought of this in teh first place!. I do need to do a lot of if statements for my auto control, because my team plans on using only sensors to direct the bot, instead of some pre set auto control. We feel that this will work best for the Auto at teh end setup. And another note: which is more efficent in this chipset, the Switch statements, or nested ifs? And how do you do spanned switch cases? I know in Basic you could to Case 127 to 255, is there a similar way to do it in this langauge? And a final note, does using a void function take more processing power than incoded systems? or the same? ETA 30 seconds later: What can i do to figure out if it takes too much memory? with the pbasic editor i had a memory chart i could pull down to see my % on program and variable memory. Is there a similar way to do this in picc? And what are the hex limits for variable space and program space as reported by IFI loader? |
limits for variable and program space are given at the innovations first webiste. As for putting ranges in the switch-case loop, to the extent of my knoledge, it cannot be done like in PBasic; you need to use some if statements. If it is just for one range and everything else is a single value, put it as a comparison in the default: tag, or as just the default tag if the situation permits. The other meathod is to create a char variable just for your switch-case loop and do some comparisons first, so it would look something like this:
Code:
char case_rangeOn that note, does anybody know if you can nest the ?: operator? i.e. x=(condtion 1) ? 1 : (condition 2) ? 2 : (condition 3) ? 3 : ... (condition n) ? n : 0 |
really i only have like 4 ifs/ifelse statements, to cover the 4 sections of the stick. (x axis, y axis, left turn, and right turn), so its not too bad. I dont wanna create any more variables, but i think that i am fairly low now after taking out all printf statements(had 8 in there at one point. hehehe..)
|
Quote:
First of all, there is a separate code space and data space. One could be full and the other virtually empty. If you want to find out all about the program you are down-loading to the controller, the linker generates a file called... FNAME.LST where FNAME is the name of your project (for instance: IFI Default Code.LST). This file contains your C code, with the assembly next to it, with the line numbers of the code addresses where this code is getting dumped. It also contains the machine code translation of your instructions. If your code is getting too big, you should see addresses above 008000 in this file. [NOTE: this LST file only contains code which is being compiled. The library code is not disassembled in this file.] You can also look in the FNAME.map file (if you have the "generate map file" option checked in your MPLAB environment). This will show you the section information. At the end of the code section there is a little block which says: "Program Memory Usage" It gives start and end address. You will have a little subblock that says: xxx out of 33816 program addresses used, ... You get similar information for the data memory. Only, you'll have to look at the "data" section address of the last symbol to figure how close you are to full in the data space. |
Thank you andrew, that is exactly what i was looking for. Just 1 final question, what is the hex Address Limit for the data variables?
I found out that with program memory, im only at 25%(yay!), and i got my data memory down to 000fab or something like that. |
Limit is now 32k
A new version of IFI_Loader (1.0.5) is now available for download at: http://innovationfirst.com/FIRSTRobo...umentation.htm
Version 1.0.5 allows you to download the full 32k bytes of code to the User processor. If you are using an older version you will be unable to download any code which is over 16k bytes in size. |
Thank you for letting me know about this! It will be a big help in the future.
|
Quote:
This can also be seen in the 18f8f20user.lkr file, which contains the memory map. Although 0x754...0x7ff is allocated to something called "dbgspr" whatever that is and is listed as "PROTECTED." |
Quote:
I would even stay away from ints wherever possible. Unsigned chars take up the least code space and process the fastest. Also, try turning on the compiler optimizations. |
Re: Space Limit--What is expendable?
Quote:
Whats wrong with signed chars? I've converted all my PWM signals to signed to simplify the math. |
Re: Space Limit--What is expendable?
Quote:
signedpwm01=(char)pwm01-127; That way you dont loose any information. Now, in processing, remmeber that the values for your pwm's can NEVER reach a number higher than 127 or less than -127 without a well planned promotion. |
Re: Space Limit--What is expendable?
Quote:
Code:
signedpwm01 = (char) pwm01 - 128; |
| All times are GMT -5. The time now is 01:26. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi