Keil Logo

Cygnal constants in upper 64k w/o bankswitching

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Read-Only
Author
erik malund
Posted
16-Apr-2004 13:13 GMT
Toolset
None
New! Cygnal constants in upper 64k w/o bankswitching
The Cygnal f12x has 128k of flash and using code banking defeats the purpose of using Cygnal. The overhead of banking slows the program down as much as using the Cygnal speed it up.
Thus:

Is there a way in Keil to make all movc a,@a+dptr generated by the compiler/written in assembler access the upper 64k WITHOUT using bankswitching. The Cygnal chip has simple means of data bank select.

in advance thanks,

Erik
Read-Only
Author
Per Guldmann
Posted
17-Apr-2004 09:29 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
Hej Erik!

A Philips FAE once told me, that Keil tools couldnt acces anything beyond 64kb without using banking. Raisonance tools should be able to adress things straight linear.

happy programming!

and have a nice weekend

Per
Read-Only
Author
Dejan Durdenic
Posted
17-Apr-2004 21:12 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
The only method I can think of is to declare your constants as far, write your own far variable handler using Cyngal's ability to fetch constants from the page being different than the one holding the code. But, that's limited to 32K page size anyway...

regards

Dejan
Read-Only
Author
Andrew Neil
Posted
17-Apr-2004 22:38 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
I don't know how the Cygnal (Silicon Labs?) works, but this is quite easy with the Triscend - if I understand you correctly:

You use the XCONST option to place items defined as const into the Flash, and then use a Data Mapper to map this into XDATA space - without the need for any (Keil) Bank-switching.
String literals can similarly be placed in the Flash to appear in XDATA space.

You need the OHX51 Object-to-Hex converter, but I think the version shipping with C51 still has a bug:
http://www.keil.com/forum/docs/thread2074.asp
You may need to contact Keil direct for the fixed version.

Hope that heps,

A.
Read-Only
Author
Jon Ward
Posted
18-Apr-2004 05:09 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
The overhead of banking slows the program down as much as using the Cygnal speed it up.

Code banking only slows down calls to functions when a bank switch must occur. And, you, as the developer, are 100% in control of where those functions reside.

Also, only the CALL and RETURN instructions (for functions where a bank switch is required) are slowed and that's only by a very few instructions.

The following knowledgebase article describes a little of how the code banking mechanism works. The examples demonstrate what happens for various types of bank switches.

http://www.keil.com/support/docs/1059.htm


The following article discusses how to create code banking programs in general. Pay special attention to the Program Organization section. It shows you how to design programs to reduce the number of bank switches that happen.

http://www.keil.com/support/docs/158.htm


The following knowledgebase article explains just what to do to use Code Banking with the Cygnal devices.

http://www.keil.com/support/docs/2441.htm

Jon
Read-Only
Author
erik malund
Posted
19-Apr-2004 14:39 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
Code banking ...
I have neither need nor no desire for CODE banking, I just want constant data to reside an upper 64k and load with NO overhead.

Erik
Read-Only
Author
Jon Ward
Posted
19-Apr-2004 15:25 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
Well, it's going to be pretty hard to get a full 64K of constants.

The reason is that whenever a MOVC executes to READ the constant, it's going to have to do so from that extra code memory. So, before the MOVC, you're going to need instruction(s) to switch the code memory around. And, you'll need to switch it back when you're done.

If you want the compiler to do all of this for you, you'll need to use the XBANKING.A51 file to configure memory banking. And, you'll have to figure out the architecture of your system.

If you want to do this manually, you'll have to write some kind of routine to read const strings from the additional code space. This may be the way best suited to your application.

Jon
Read-Only
Author
erik malund
Posted
19-Apr-2004 15:49 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
So, before the MOVC, you're going to need instruction(s) to switch the code memory around. And, you'll need to switch it back when you're done.
No, the Cygnal F12x have SFR bits directing movc and other bits directing code fetch.
I can live with getting only 32k for this.

OK let me rephrase.
In hardware I can specify that movc goes to 64-96k by setting a SFR.
Will the software (specifically Keil "hidden functions") burp if I set those bits at the beginning of startup.a51.
Can I tell the compiler to forget about banking, and let the linker locate constants in 64-96k

Erik
Read-Only
Author
Dejan Durdenic
Posted
19-Apr-2004 15:56 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
You can do it only with CX51 and LX51 using far variable modifier and then by telling the linker where the constants are - howewer, compiler will generate a call to far variable handler (which you have to provide) for every access to far variables...some kind of bank switching anyway :(

- Dejan
Read-Only
Author
Andrew Neil
Posted
19-Apr-2004 16:48 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
"Can I tell the compiler to forget about banking, and let the linker locate constants in 64-96k"

Yes, that sounds exactly the same as what I'm doing with the Triscend (only the SFR names have been changed...)

This does require LX51, but not CX51, and not any 'far' modifiers.
Read-Only
Author
Jon Ward
Posted
19-Apr-2004 20:15 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
Can I tell the compiler to forget about banking, and let the linker locate constants in 64-96k

The problem is that there are no instructions or addressing mode of the Cygnal part for accessing 17 bits of address space. Addressing larger than 16-bit addresses must be done in software. The way this is done is by setting the COBANK sfr to the bank number (0-3) and setting the address (in DPTR). The compiler does not intrinsicly KNOW about the COBANK sfr. That's why the XBANKING.A51 file is required. This file allows you to use just about any memory banking scheme.

If you don't want to use it, you can easily create your own scheme of setting the COBANK sfr and reading memory. However, you'll have to manage all of it.

Jon
Read-Only
Author
Andrew Neil
Posted
19-Apr-2004 20:29 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
"The problem is that there are no instructions or addressing mode of the Cygnal part for accessing 17 bits of address space."

Same with Triscend.

"The way this is done is by setting the COBANK sfr to the bank number (0-3) and setting the address (in DPTR)."

Triscend does it via the Address Mappers.

"The compiler does not intrinsicly KNOW about the COBANK sfr."

Similarly for Triscend's Address Mappers.

"If you don't want to use it, you can easily create your own scheme of setting the COBANK sfr and reading memory. However, you'll have to manage all of it."

Yep, that's the way I do it on the Triscend.
Thus it sounds to me like a very similar approach should work with Cygnal.
Read-Only
Author
erik malund
Posted
19-Apr-2004 22:24 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
The problem is that there are no instructions or addressing mode of the Cygnal part for accessing 17 bits of address space. Addressing larger than 16-bit addresses must be done in software.

Incorrect
, if the compiler/linker allowed it.

The Cygnal (and based in the above the Triscend as well) have the ability to read data from one half and instructions from the other half of the 128k.
Read-Only
Author
Jon Ward
Posted
19-Apr-2004 22:50 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
The Cygnal (and based in the above the Triscend as well) have the ability to read data from one half and instructions from the other half of the 128k.

I'm not sure I understand what you are saying. Are you saying that the Cygnal devices fetch program code for address 0x0000 from one physical memory address but retrieve code using MOVC from address 0x0000 from a different physical memory address?

If that's the case, then this is a feature no one could possibly use. Static jump tables would not work with this scenario. Neither would tables of function pointers and so on.

I didn't get this from the Cygnal documentation but maybe I'm not reading the right part.

Nonetheless, I still stand by my previous statement that,

"...there are no instructions or addressing mode of the Cygnal part for accessing 17 bits of address space. Addressing larger than 16-bit addresses must be done in software."

Jon
Read-Only
Author
Dejan Durdenic
Posted
19-Apr-2004 23:39 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
Actually, only devices with 128K of flash can do that (F12x family) - you can programm page register to fetch opcodes from one bank and to fetch movc data from another...If you are careful, you use that as an advantage in the scenario Erik proposed...

- Dejan
Read-Only
Author
Jon Ward
Posted
20-Apr-2004 02:46 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
Ahhh. The PSBANK register.

The problem with having a different space for MOVC and instruction fetches is that the compiler stores constants in code space. Changing the target address for MOVC would cause the program to fail. Constant tables are generated by the compiler for all kinds of stuff (like switch statements, jump tables, static arguments, and so on).

Jon
Read-Only
Author
Andy Neil
Posted
20-Apr-2004 08:48 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
"The problem with having a different space for MOVC and instruction fetches is that the compiler stores constants in code space."

So, does XCONST only affect user constants defined with 'const' in the 'C' source code, and not these compiler-generated "internal" constants?

If so, sounds like an opportunity for enhancement there...?
Read-Only
Author
Jon Ward
Posted
20-Apr-2004 15:28 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
So, does XCONST only affect user constants defined with 'const' in the 'C' source code, and not these compiler-generated "internal" constants?

That's correct. The problem with compiler-generated tables is that they are not REALLY part of YOUR data/code. They are an extension of a library routine and, as such, they are all routine-specific.

For example, one method of switch-case implementation is similar to the following:

; Case # stored in registers
LCALL   switch_jump_table_handler
        DW 0005h          ;# cases
        DW case_0_func
        DW case_1_func
        DW case_2_func
        DW case_3_func
        DW case_4_func
; switch_jump_table_handler returns here

The switch_jump_table_handler function takes the return address, and adds 2* (1 + case #) to get the address of the case function. It then adds 2*cases to the return address and jumps to the case "function". There would probably be little to gain by moving this "constant" stuff into xdata space. There would be more overhead in that the jump table must have a label and now the switch case function must handle generic addresses instead of only code addresses. So, all switch statements implemented this way would suffer a little bit. Also, if there was an XDATA problem, the program would certainly crash in an unexplained way and that would be bad. Jon
Read-Only
Author
erik malund
Posted
20-Apr-2004 15:29 GMT
Toolset
None
New! RE: Cygnal constants in upper 64k w/o bankswitching
So, does XCONST only affect user constants defined with 'const' in the 'C' source code, and not these compiler-generated "internal" constants?

If so, sounds like an opportunity for enhancement there...?


Amen.

Allowing ALL non-code to be directed to a given place (upper 64k) would make the Cygnal/Triscend feature extremely useful.

I appreciate Keils reluctance to include features that only work on selected derivatives, but since Keil with banking as a standard seem to push >64k systems, it would be nice if this non-banking memory expansion could be used.

Erik

Next Thread | Thread List | Previous Thread Start a Thread | Settings

  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.