I'm trying to implement code banking in the evaluation software. I've written code but doesn't compile, so I think code banking is the remedy. How do I dictate where the code goes? And what is the difference between variable banking and for the B_Mode user-provided bank switch code?
"I'm trying to implement code banking in the evaluation software."
Does the evaluation version even support banking? Have you checked?
even if it does, it is limited to generate only very small executables - for which code banking is totally unnecassary and possibly even impractical!
I'm not sure how I'd check to see if the software would support code banking.
I did read that code banking isn't enabled in the evaluation software. I just don't understand how I can debug the simplest program of printf("hello world"); everytime I hit the code size limitation barrier.
According to the posted restrictions on the eval software
http://www.keil.com/demo/limits.asp
the eval kit does not include the code banking linker.
To answer the earlier question (assuming the context of the full product), you generally assign modules to particular banks. In uV2, there's a dropdown box in the project list. So, I would typically make groups called "Common", "Bank 1", "Bank 2", etc; set their dropdown box to link to the appropriate bank; and then put the .c files in whichever group I wanted.
With the command line, the syntax for the linker directives (e.g., SEGMENTS) includes a bank designator, so you can force segments to various banks as well as addresses within those banks.
We found it useful to write a little tool that parses the map file and shows us the free space remaining in each bank, which is helpful for rebalancing code when a bank gets full. (Feature request for the linker!)
when the limit is 2K it would make ZERO sense to support banking.
if the eval does not give you enough code space contact sales@keil.com
printf is a codehog
Erik
" how I can debug the simplest program of printf("hello world");"
Trouble is, printf is not simple!
Just look at the description of printf in the Manual - it runs to several pages, doesn't it?
Clearly, a function that implements that much capability & flexibility cannot be "simple" - that is precisely why printf is a biiiiiiiiiiiig function!!
printf alone can use up most of the 2K limitation of the evaluation version!
So the answer is simple: don't use printf!
"the eval kit does not include the code banking linker"
Obviously - if it were that easy to get around the demo limits, there wouldn't be any point in having the limits, would there?!
"I'm not sure how I'd check to see if the software would support code banking."
You would read the Documentation, and see the bit where it says, "...not included in the Evaluation Version: Linker for Code Banking..."
Ok I understand there are limits, and I have been trying to read the manual. This is just a project given to me to see if I can learn. Not some cost efficient way to get around buying the program. Thanks for your time.
"...project given to me to see if I can learn"
I think they might be teasing you...!
Did they also send you down to the stores for some Elbow Grease...?
;-)
LoL, Well they're definitely driving me crazy...
Perhaps to evaluate the size/speed overhead of banking, or how painful it is to allocate code to banks?
if it were that easy to get around the demo limits, there wouldn't be any point in having the limits
Total code size of 2KB across all banks!
How many banks of angels can dance in the internal RAM?
"How many banks of angels can dance in the internal RAM?"
If it was triangular, the internal sum of angels would be 180...
Well they're definitely driving me crazy...
There is some evidence you are a beginner, do not worry about them driving you crazy.
After a few years of working with embedded, it will not be a problem because nobody can driver you to where you already are.