Unable to fit variable XXX in requested bank 0

[MikeBZH]

Hi everybody,

A very recent problem has appeared with one of my old programs.

It was perfectly working but I want to add some new capabilities which means more code and more variables and I got the message following the compilation :
Warning : Unable to fit variable DataTX in requested bank 0
As I disregarded the Warning and continued to add code and variables I got a second additional message :
Warning : Unable to fit variable DataT1 in requested bank 0

DataTX is a LONG type variable (I use PBPL) and DataT1 is a BYTE. They are in bank 0 from the beginning without any issue.
The reason for using the bank 0 is that these data (and others) are used in a time-critical assembly language routine.

I was thinking about a memory overload but I use a PIC18F26K22 which has 3896 Bytes for its SRAM and I understand that its BANK 0 may contain up to 96 bytes.

I use only about 300 bytes (manually counted ...) for my variables and amongst them about 36 are stored in bank 0. None of the additional variables used for the new capabilities is stored in bank 0.

I don't understand ! Any idea ?

MikeBZH

[Ioannis]

If you send them to BANK1 does it resolve?

Ioannis

[pedja089]

PBP variables are allocated in bank0. There is a lot of variables if you have complex IF AND OR THEN statement.

[mpgmike]

Are these the only 2 variables you are trying to force in Bank0, or are there others the compiler is OK with? You might want to look at the .lst file to see how busy your Bank0 is. Remember, PBP uses Bank0 (Access Bank more specifically) for R0, R1, R2... and other PBP-specific variables.

[HenrikOlsson]

I use only about 300 bytes (manually counted ...) for my variables and amongst them about 36 are stored in bank 0. None of the additional variables used for the new capabilities is stored in bank 0.
Remember that PBP itself uses a bunch of variables and it most likely needs to use BANK0 for them for the same reason that you want to use BANK0. The number of variables PBP uses depends on what library routines it includes and, of course, if LONGs are enabled or not.

So, when you added new capabilities to your code PBP included some library routine that uses a system variable that wasn't needed before. It was put in BANK0 pushing your variable(s) out.

That's my guess at least.

[MikeBZH]

Hello,

Thanks to everybody for your advices and expertise. Nearly everything becomes understandable

PBP puts all the variables it can in the BANK0 including those which are not specified to be put there ! So, if a new variable comes with a BANK0 attribute and if the BANK0 is full it can not be placed there. It is placed where some room is available and a Warning is raised.

But this is not what is written in par 7.3 (RAM Allocation) of the manual. One can read in the middle of the page "If specific bank requests are made, those are handed first". Bug or misunderstanding from myself ? I don't know.

I have read somewhere (but where ?) that time critical assembly routines should use variables located in the BANK0. It has been very difficult to make this routine work and the execution time is still a little bit long. So I will not change BANK0 for BANK1 for the variables used there.

On the other hand I have specifed BANK1 for other non critical and recent variables and now the compilation gives no more warning

MikeBZH
.

[Ioannis]

I am sure that the order of the vars that appear in the program has great impact on compilation.

Ioannis

[HenrikOlsson]

But this is not what is written in par 7.3 (RAM Allocation) of the manual. One can read in the middle of the page "If specific bank requests are made, those are handed first". Bug or misunderstanding from myself ? I don't know.
I don't know but the way I understand and interpret it is that between user variables that HAVE specific bank requests and those that don't the first ones ARE handled first - but still AFTER the PBP system variables have been allocated space.

So, if PBP needs 74bytes in BANK0 you can specify 22bytes to be in BANK0 (if it happens to be 96bytes). If you try to specify a 23'rd byte in BANK0 it can't do that.

/Henrik.

[pedja089]

Same here. And you can confirm that looking at .LST file.

[MikeBZH]

Well, well, well :)

I have done some screen copies of my disassembly listing.
Unfortunately the version of my program for which I had some warning messages is no more available but, however, we can address the issue with these examples.

On the first page one can see the system variables (Flags, R0, R1, R2 ...) starting at 00H and in my case ending at 32H.
They do not take so much room.

The second page is an extract of the space which should be dedicated to BANK0 variables plus others if room is available.
The BANK0 goes up to FFH. I have no problem with "squatting variables" which feel well there but I am concerned when they stay if other more critical variables with a formal BANK0 declaration need to be there.

And believe me or not when the warning message raised I had some BANK0 variables at 102H and 104H and non BANK0 labelled variables inside the BANK0 space. This is what I have observed.

Anyway, placing some non critical variables in BANK1 or elsewhere looks as being a good solution. In my case it works.

Best regards

MikeBZH