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.
Hello, I am working on a project using the 8051. I am almost on my completion of the project. But my code size has cross the 64k limit. I have heard that by using paging technique it is possible to access more than 64K code. But i have no idea how to implement paging in 8051.Can any one help me for the same. Thanks in anticipation. Viral.
What optimisation level are you using? Have you checked your code for unnecessary bloat? Can you save some code space by moving constants and/or string literals into XDATA? http://www.keil.com/forum/docs/thread3361.asp If you still need to use Code Banking, Keil's support with their tools is described in the Manuals - especially the Linker manual. You should have an example in your Keil\C51\Examples folder - see the Bank_Ex1 Project.
If you have only just gone over the limit and you are near the end of your project, it may be much better to try to reduce the size of your code rather than complicate things by using paging. My apologies in advance if you have already done this. The first, most obvious step, is the get the very latest version of the compiler linker and then wind up the optimisation level to give the most aggressive code compression possible. Of course, you may need to make exceptions for time critical sections of code. Then you might reconsider re-examining some of your source code. See appendix C of the C51 user guide to get started. The single most significant factor is likely to be the choice of memory model. Source code that is built in the large memory model tends to generate a lot of object code; making individual functions build in small or compact memory model can make a dramatic difference to both speed and size. Similarly, carefully choosing individual variables to be placed in data or pdata will also make a big difference. Getting the very best out of C51 and the linker is a matter of experience and patience.
I would like to add just a couple of comments. The 80C51 is an 8bit device. The most efficient data type for code size will be the unsigned char. The next most efficient is the unsigned int and then to the signed data types. Try at all places possible to use unsigned. Next, get rid of the printf or scanf if you use them. Use puts and do you own formatting. Last but not least, get rid on float values if possible. Most of the time simple fixed point processing will calculate all the values you need. Of course Andy answered you initial question about code banking. Brad
"Next, get rid of the printf or scanf if you use them. Use puts and do you own formatting." Of course, all generalisations are bad! ;-) A single printf can cause quite a large hit on code size (it can use up most of the 2K size limit of the free eval version), but if you do a lot of formatting throughout a large application it becomes a lot less significant. You might want to search this forum for Graham Cole's user_printf, which was a streamlined version without the more esoteric formatting options.
Surprisingly, using Generic pointers can use less code than memory-specific pointers! This is because Generic pointers are handled by library calls, but memory-specific pointers use inline code.
Hi, Thanks every one for your valuable feedback. I have try using different optimising level but my code started behaving eraticly. It may be because my code is very time critical. I will try some of your other suggestion and hope it works. Regards, Viral.
If raising optimization levels makes your code behave erratically, that's almost certainly not just because the program is time-critical. It's because either there's a bug in the optimizer, a bug in your code, or bad design of the code. Bugs in your code would usually be lack of "volatile" qualifiers on some variables shared between main and interrupt routines. Design errors would be things like expecting that you can generate fixed-time delays by empty loops coded in C, which the optimizer may justifiably delete completely.
"I have try using different optimising level but my code started behaving eraticly." What levels have you tried? At what level do the problems appear? I agree that this is probably due to flaws in your code that only become evident at higher optimisations; therefore, you should debug these problems!
There were some compiler/linker problems with high levels of optimisation. See: http://www.keil.com/forum/docs/thread2094.asp. I belive that these have been fixed in the very latest versions of the tools, so make sure that you are up-to-date.