The code banking mechanism that Keil provides has been available for about 12 years. It is pretty robust and well used. There are 2 knowledgebase articles that explain a lot about creating code banking programs:

• CREATING CODE BANKING PROGRAMS: Describes all the points of code banking that you need to know.


• THE CODE BANKING MECHANISM: Describes how the code banking mechanism works. This is interesting reading but you don't NEED to know it to use code banking.

A) Is it painless to set it up and use it?

Yep. You need to decide where the common area stops and the banked area begins. Then you decide which segments go into the common area and which go into the banked areas. The only requirement for the common area is that the interrupts and startup code go there. A code banking configuration file (L51_BANK.A51) lets you configure how banks are switched (I/O Port, XDATA memory location, or some other custom mechanism). For I/O ports or xdata mapped port, you simply type in the address (or SFR), starting bit position, and number of banks.

B) Does the resulting code seem to be efficient?

Yes. The same code is generated for code banking and non-code banking programs. The only difference is that inter-bank function callsmust switch the code bank--about 11 instructions of overhead are added for these kinds of calls only. The compiler is smart enough to simply call function in the same bank or in the common area. So, the trick is to keep functions that are used frequently in the common area (no bank switch is required) and to keep functions used together (like run-mode, edit-mode, report-mode) in the same bank.

C) How much does the bank switching effect the debug proceess?

From the uVision2 simulation side, not at all. uVision2 knows how to handle code banking programs. Most emulator vendors now support code banking. I know that Nohau, Metalink, Signum, Hitex, and Ashling support it. I'm certain that many other emulator vendors support code banking as well.

My suggestion is to create a simple program with 2 or 4 code banks and a function or two in the common area and take a look at the generated code and the bank switching configuration. I'd use an I/O port for bank switching because it's faster than xdata.

Most problems we see are due to developers who don't understand the 8051 architecture (or their own target architecture) trying to create a custom bank-switching configuration when the I/O port or xdata configurations would work fine.

Jon