We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am using mentor graphics 8051 based 8051EW device. I am using code banking (16 banks). After running my code i am using LX51 comman to link the lnk fie and than "OHX51" to convert the obj file to hex and than "hexbin2" to convert hex to bin. In my code i have 5 files each conatning one function and a main. c file. When i palce the main.c and all the other 5 files in common bank, the following is the size of file ifound obj format file -> 20 KB size after converting hex file--> 2 kb size and after coverting hex to bin bin file--> 1 kb size.
But if i place main.c in common bank and each of the five files in five seperate banks i.e bank1, bank2 so on than following is the file size odserved
obj format file -->29kb hex file --> 6kb bin file --> 193 kb can anone please tell me why is there such tremendous increase in the fianl executable file from 1 kb to 193 kb even though the bank switching code tht is inserted by complier is of afew bytes. Immediate help is highly appreciated
Why do you think you actually have a problem?
The sizes of the files are (almost) totally irrelevant to your actual target hardware - they are only of use to the tools that load your software into the target.
So, provided the code loads correctly & works correctly, there is no problem!
If you want to know the actual size of the code in your PROM, then look at the message given at the end of the build in the uVision build output window; eg:
Build target 'Simulator' compiling HELLO.C... linking... Program Size: data=30.1 xdata=0 code=1096 "HELLO" - 0 Error(s), 0 Warning(s).
http://www.keil.com/support/man/docs/uv3/uv3_ca_buildproject.htm
You can get more detailed information in the Linker Listing file, or map file.
For example, if you have a 128K PROM, then the binary file to represent the contents of that PROM will be 128K - but that size tells you absolutely nothing whatsoever about how many of those bytes are actually being used by your code!
Thanks Andy for the help........i want to know how bank switching happens i mean how to see the complier generated code that is inserted into the assembly code (generated by keil) when bank switch happens...i have L51_BANK.A51 file added in my project, but i don;t know how exactly it works...can you please throw some light on this
ok that means the program size in the MAP file is real indication of the total number of bytes that actually the application uses in the memory.
i want to figure out how to place files in different banks so as to optimize the memory usage of PROM, i have considered that there is minimum bank switching while writing the API, but does the format in which the file are placed in different banks affects the size of the code and also its runtime (of the 64 kbytes lower 32 kbyte is common area and upper 32 kbyte can be replaced by any of one 16 banks available)
Isn't that described in the Manuals?
I've never used the C51 banking - in my opinion, you should not be starting out with an 8051 if you know that you're going to need banking!
Anyhow, it's a different question - so start a new thread.
But be sure to study those Manuals first - and Application Notes, Examples, etc - you are far more likely to receive help when you show that you have done your basic groundwork!
Actually, I take that back!
The title of the thread is "Regarding bank switching" - it's just that you started it on an unrelated subject (file sizes).
Agreed!!!!!!! [:)] i thought bank switch and file size are related that's why but still why size of bin file increase so dratically is still a mystery for me
Probably, in the non-banked case, all the code lies in a single contiguous address range at the start of the PROM - so the the bin file contains only that address range.
With the Banked application, you probably have a small amount of code at the start of Bank 0, then the rest of Bank 0 is blank, then a small amount of code at the start of Bank 1, then the rest of Bank 1 is blank, then a small amount of code at the start of Bank 2, then the rest of Bank 2 is blank, etc, etc,...
The binary files has to include all these blank areas up to and including the last byte used in the last Bank.
You should be able to see this clearly if you look at the contents of the bin files using a suitable binary file viewer.
eg, www.catch22.net/.../hexedit
hey Andy thanks for help..........your post was of great help to me..[:)]