Briefly, maximum number of vars?

[Chris Barron]

Hope this makes things clearer...

I have the usual var declarations (over 200). The following names are for example only.

abc var byte
bcd var byte
cde var byte
def var byte[75]
efg var long[8]
-
-
-
-
-
-
-
wxy var byte
xyz var byte


If I comment out the second last variable 'wxy' (or comment out any of the later bytes) the code runs. If I leave wxy in the list then elements of array 'def' become corrupted. At first I suspected it was something to do with using too much ram, so I reduced the size of array def to 50 elements. But the problem is exactly the same, even though I freed up 25 bytes of ram when I reduced the size of 'def' (and of course, made sure I didn't point to any of the now missing array elements, in practice I only use the first 20 elements at the moment)

Commenting out 'wxy' allows the code to run properly, and also wxy is never actually used yet at any point in my code.

This is what leads me to wonder if it is not the actual _number_ of variables which is the key, rather than the amount of space which they use. I have 211 variable names (excluding aliases), that's 211 pointers to individual addresses, and presumably that info is saved on a table. How many variables does PBP require, because if it uses 45 or more then that would cause overflow of an 8-bit table or variable.

Chris

[sinoteq]

Hi
To make sure PBP does not break any RAM boundries I would like you to do a small test. Take the code that does not work and add some extra code to it at the start of your program.

Dummy_0 Var Byte $FF
Dummy_1 Var Byte $1FF
Dummy_2 Var Byte $2FF
Dummy_3 Var Byte $3FF

This will force PBP to load byte variables at the end of each RAM bank.

I am really interested in the results.

[Chris Barron]

Hi
To make sure PBP does not break any RAM boundries I would like you to do a small test. Take the code that does not work and add some extra code to it at the start of your program.

Dummy_0 Var Byte $FF
Dummy_1 Var Byte $1FF
Dummy_2 Var Byte $2FF
Dummy_3 Var Byte $3FF

This will force PBP to load byte variables at the end of each RAM bank.

I am really interested in the results.

Thanks fro the suggestion but there is no change.
in keeping with the original problem, using your suggestion has increased the number of vars by 4, and if I comment out 4 of the unused vars to compensate the code runs. Changing the location of the dummy vars has no impact on the problem

[Jerson]

Chris,

I suggest you try loading all your BIG arrays right at the top. Then put all the little single variables like bytes or words or longs after that.

As to how many variables PBP needs, I think you can look at the generated LST file and see the variables before your own.

There is another possibility that you need to consider - is there any asm interrupt code of your own that might be disturbing the register banks.

Regards

[Chris Barron]

Chris,

I suggest you try loading all your BIG arrays right at the top. Then put all the little single variables like bytes or words or longs after that.

I've tried this method, it seems to make no difference

There is another possibility that you need to consider - is there any asm interrupt code of your own that might be disturbing the register banks.
Regards

I do have an ASM interrupt.
In the interrupt I use indirect addressing to load an array (the array in question) with data received from the serial port, before it is transmitted out of the serial port again, trapping the received data for analysis and real-time display.

Before I give the details, the gotcha here is that the code works fine without these additional unused variables. but once I add a few vars in the declarations, after my own var declarations or before them, the problem occurs. At no time are those additional vars referenced in the program code.

I have looked at the PBP files and it seems that FSR0 and FSR2 are used by PBP, but not FSR1. To do the indirect addressing I load FSR1 with LFSR 1,_RX_BUFFFER, the address of the 1st byte in the RX_BUFFFER array. Then I use POSTINC1 to put each successive received byte into the buffer. I then _save_ the values for FSR1L and FSR1H, so the next time I need to load the next array element I restore FSR1L and FSR1H with the last values in the interrupt. I actually get the same problem even when I don't save the values for FSR1, which suggests that it is pointless to do that anyway

What I have not done, is to save the values in FSR1L and FSR1H when the program interrupts, but then I don't see any need because PBP doesn't seem to make any use of FSR1, plus the same code works as expected when I reduce the number of unused variables.

Chris

[Chris Barron]

I do have an ASM interrupt.
In the interrupt I use indirect addressing to load an array

Just for confirmation I have reverted to a previous interrupt routine which does not use indirect addressing, does not access the FSR's at all. The same problem is happening.

Would someone be able to tell me what is the best way to force PBP to locate my variables in places which I know will all my LONG and WORD arrays to fit on one bank of memory

Chris

[mackrackit]

There was a thread awhile back where someone was having the same trouble, to many variables. Sounds like this is the same thing.

Maybe a work around would be to scale things in your code and SDFS by not declaring some of the pins as VARs.

An example would be in SDFS if you are not using the card detect

SD_CD		Var	PORTB.4	' SD card detect
SD_CD_TRIS	Var	TRISB.4	' SD card detect direction

to comment that portion out. Probably some things in your code that could be re-done also???

Just thoughts.

[mackrackit]

BTW, are you using the SDFS from MElabs? The one for FAT16 or the one from Jeremy posted on the forum, SDFS32.

Maybe seeing your code would help too.

[Chris Barron]

There was a thread awhile back where someone was having the same trouble, to many variables. Sounds like this is the same thing.

Maybe a work around would be to scale things in your code and SDFS by not declaring some of the pins as VARs.
Just thoughts.

I could do that, but I would rather not be limited to a smaller number of variables than I have ram locations for.

I would post the code, but it's over 40k now. Take out the data tables and it's down to about 28k, so it's still a massive post ! The essence remains the same though.

I'm using the FAT16 MELabs version of SDFS. If the FAT32 version uses less space and doesn't have the same caveats I would like to try it out, but even after that I still would like to include more variables.

As I've said, the number of ram variables declared seems to be deciding factor and the problem doesn't seem to be affected by the number of aliases. I might consider declaring some large byte arrays and then declare the current individual byte vars which I am using as aliases of the larger array.

Chris