I have a unique application that is about to overflow 64k. I can not use bank switching because of the overhead. PLEASE do not reply anything about how small the overhead is - I do not care, there IS overhead. Now this application process ONLY ONE OF two formats "classic" and "current". My idea is to locate all common code in the lower 32 k and, immediately after reset detect which format it is and set the COBANK bits so that either page 1 or page 2 would be code addresses 8000 to ffff to process the actual format. I know of no simple way to do this, suggestions appreciated. Erik Cross posted on the SILabs forum.
reading a response in my crosspost, I just realized that since only one call to the 'banked' part the overhead using regular banking will be nominal since calls from banked to unbanked have no overhead, I missed that bit in my analysis. This will only be trye if I can make sure that all that refer to "classic" is on bank 2 and all that refer to "modern is in bank 1 Any suggestions to a simple means of that (approx 40 modules / 200 functions) Erik
This enforcement shouldn't be too hard to do by inspection. Assuming the fairly normal practice of only calling functions that are properly prototyped in a .h file, then you don't include the .h's for cross-bank calls, and then can't call the function. One step further of enforcement would be to segregate the .h files into different directories, and omit the "include path" variable for one of them when compiling the restricted modules. That way, you can't even accidentally include the wrong .h. The compiler won't find it. You can check the map file afterward to make sure that there aren't any undesired interbank calls, despite good intentions and prohibitions.
INTERBANK CALL TABLE OF MODULE: xxxx ADDRESS FUNCTION NAME ------------------------- C:000150H _TimerAct C:000155H _FlashBlockWrite C:00015AH _FlashBlockRead ...
This enforcement shouldn't be too hard to do by inspection. Assuming the fairly normal practice of only calling functions that are properly prototyped in a .h file, then you don't include the .h's for cross-bank calls, and then can't call the function. No prototype = error - how does that locate functions?? something I do not understand Erik
The compile error doesn't locate a function. It makes sure that you don't mistakenly create a call from bank1 <-> bank2, which won't work without the full bank switching implementation. make sure that all that refer to "classic" is on bank 2 and all that refer to "modern is in bank 1" If there are two headers, FormatClassic.h and FormatModern.h, then you make sure that all .c files that belong in bank 1 (modern) do not #include FormatClassic.h. (More generally, you could have two directories full of .h files.) You can enforce the restriction with the include path (and maybe a grep in the build process). Actually getting the .c's into the right bank is fairly straightforward. If you wind up using the bank switch mechanism, there's a dropdown in uVision (or the linker directives). If you build two projects, then you just need the linker directive to put all the .c's in a group into high memory. Again, I'd probably keep the .c's in separate directories (common, classic, modern) to make it easy to generate a list of module names for each bank. If you pick your module names carefully, you can use the wildcard feature of the linker directives to avoid having to manually maintain the list. You might write something like
(separately built) SEGMENTS (?PR?Fmt*(0x8000)) or (banked) SEGMENTS (?PR?FmtCls*(B2:), ?PR?FmtMod(B1:))