Code Banking: Different banks reference to a table that store in CODE memory

You'll almost certainly have to either keep that table in the common bank, or change from a table to an OO-style accessor function. The reason is that C51 knows how to organize function calls across banks, but not data references. So data either has to be non-banked (in the common area), or it has to be replaced by functions.

Note that this isn't really a C51 limitation, but a limitation from the design of code banking.

Code bank 1 can be switched in and out of the address space of the processor. You've declared data to live in code bank 1. That data gets switched in and out of the address space along with bank 1. Only when code bank 1 is switched in can you see that data. That's generally only when code in bank 1 is executing.

And banks 2+ all replace bank 1 when they are switched in (in the usual 32K + N * 32K banking scheme). No code other than that in bank 1 can be sure to see that data in bank 1, and code in banks 2+ can be certain that it's not visible.

The common bank is always swapped in, which is why its the default location for constant data. You might also locate the constants in xdata, and copy them from code to xdata via some init function (that lives in bank 1).

"You might also locate the constants in xdata, and copy them from code to xdata via some init function (that lives in bank 1)."

Or, if your memory architecture permits, have some ROM mapped into XDATA space...

Thanks for everyone's kindly reply.
Common area is important for me to put some real time issue program code, I won't locate the table in common area(my table is very huge).

Hans-Bernhard Broeker said "or change from a table to an OO-style accessor function". Do you meen Object-Orient-Style? Keil compiler seem not support this coding style. Or do I misunderstand your idea? would you please give me some detail example or www link to study this idea?

Thank you.
Ovid.

"Do you meen Object-Orient-Style?"

Yes.

"Keil compiler seem not support this coding style."

It doesn't need to - it is just a style; ie, an approach to using the tools.

Instead of accessing the table directly:

result = table[x];

result = lookup( x );

Oh..
And it will switch in and out that table.
Further more, If I want to save the switching time(avoid switching). Is keil can duplicate the table automatically in that bank where the program reference to that table?

Thank you.
Ovid.

"And it will switch in and out that table."

Not directly. It will switch to the bank containing the function - you must ensure that the same bank also contains the table!

"If I want to save the switching time"

You can't.
If the switching time is a problem, why are you using banking?

"keil can duplicate the table automatically in that bank where the program reference to that table?"

Isn't that just the same as having the table in the common bank?!

What about copying the table to XDATA, or mapping it to XDATA, as mentioned earlier?

"Isn't that just the same as having the table in the common bank?!"
Ans:
Not exactly the same. I can put the most frequently used and real time issue subroutines in common area.

"What about copying the table to XDATA, or mapping it to XDATA, as mentioned earlier?"
Ans:
Unfortunately, base on cost issue, there is always no extra XDATA memory for a firmware programmer。:)

Thank you A.W. Neil。 I will take OO-style。 In order to reduce switching frequency, I will fine tune whitch subroutine should place in whitch bank. Now, I read the calling tree, and rearrange thousands of subroutine. It is really a hard work, and waste time。Do you know is there a better way or software can do this job？

Ovid.

"It is really a hard work, and waste time ... is there a better way?"

Code banking is always a bodge - you have too much code for an 8031, but you're still trying to cram it into an 8031!

You need to balance the costs of banking - both in runtime overheads, and development and maintenance headaches - against the consts of switching to a processor better suited to the size of code that you have.

A.W. Neil,
We(your company and my company) have different culture. The hardware chip cost down is always the first priority. Development and maintenance headaches......
The software group should find the best way and work overtime to solve it。
Thank you for your suggestion.

Ovid.

The hardware chip cost down is always the first priority.<p>

The decision should not be a "culture" thing but based on economics. If you're planning to build at most X units of a product, and you spend Y as development costs lower the cost of the hardware by Z, and you know that X*Z<y, and you do it anyway, then you should either have a darn good reason to do it ("culture" doesn't cut the mustard), or you're essentially deliberately and knowingly wasting money. there is a certain point at which development and expected support costs will exceed the savings of less expensive hardware. make sure you realize when you are approaching this point. < i>Unfortunately, base on cost issue, there is always no extra XDATA memory for a firmware programmer.

If you can _map_ the table to xdata memory space somehow, no extra xdata memory is necessary.

Have you tried compressing the table somehow ? For certain kinds of tables this can reduce the size by quite a bit (even if simple difference encoding is used), and you can trade cpu cycles for memory this way.

Do you know is there a better way or software can do this job

You can certainly do it in software.
Somehow. You'll probably have to code everything yourself, though.

Will it work? Quite probably.
Will it be fast enough? Don't know, depends on your project. I would guess not.
Will it be a royal pain in the neck to code and to maintain? Very likely.

"The hardware chip cost down is always the first priority."

Have you actually looked at currently available ARM-based chips?

Some are at comparable prices to 8051-based chips and, with plenty of on-chip Flash, you could do away with all the extra cost of separate flash, decoding, and banking hardware!

So the "chip cost" might actually be cheaper!

"The software group should find the best way and work overtime to solve it"

One reason for not moving to a different processor is often the learning curve - but is it better to break your neck trying to get code banking working, or to spend the effort on getting to know a new chip?

Your call.

Have you actually looked at currently available ARM-based chips?

Some are at comparable prices to 8051-based chips and, with plenty of on-chip Flash, you could do away with all the extra cost of separate flash, decoding, and banking hardware!

So the "chip cost" might actually be cheaper!


Agreed. ARM-derivatives are _very_ competitively priced, as are some other families of MCUs. Switching chips in this case could very well end up saving hardware costs and development costs at the same time.

"The decision should not be a culture thing but based on economics...."
Working overtime is not a cost to my company.

"If you can _map_ the table to xdata memory space somehow, no extra xdata memory is necessary."
How to do it? My entire program is in nand flash, It will be fetch into onchip ram(only 16k bytes), and execute.

"Have you tried compressing the table somehow ? "
The user interface script is also a table. If I have to decompress the table, the user may feel not so fluent.

"You'll probably have to code everything yourself, though."
There is no time for me to develope this tool and debug&#12290;:)

"Will it work? Quite probably...."
It seems on the margin.

"Have you actually looked at currently available ARM-based chips?"
My company develope our own IP, we don't have the ARM-based chips IP now.

"My entire program is in nand flash, It will be fetch into onchip ram(only 16k bytes), and execute."

Why is everyone suddenly trying to do paged virtual memory on 8051s??!!

http://www.keil.com/forum/docs/thread7519.asp