Briefly, maximum number of vars?

[Chris Barron]

Chris,


A possible workaround would be to place large arrays in their own RAM page where they cannot wrap around without PBP knowing.

I wonder if this helps

I guess it has something to do with my understanding of PBP as much as anything else, your description of the array pointer system ties in with my own thoughts.

Darrel can confirm that the only array types which might give cause for concern are WORD and LONG. The variables which I am pasting in contain a single LONG array of 8 elements. All other arrays being byte sized. I've just tried putting the LONG array at the start of the declaration section, but do you think it would be better to ORG it to somewhere ?

What pains me is that I took a piece of working code which I have been working on for months, imported some variables which are not duplicates and which are never implemented in my own code, and I end up with non-working code.

The shift to linear memory can't come soon enough !

Chris

[rmteo]

.... The shift to linear memory can't come soon enough !

Chris

Don't count on it happening any time soon. Right now the only Microchip products that have it (4Gb linear addressing space) is the PIC32 line.

[Darrel Taylor]

Darrel can confirm that the only array types which might give cause for concern are WORD and LONG. The variables which I am pasting in contain a single LONG array of 8 elements.

Well, they are handled a little different, but they are still no cause for concern.

The compiler simply makes sure that no single element of an array crosses a bank boundary. The array can span multiple banks, but LONGs or WORDs will always be on one side or the other, never split.

If you want to make sure that an array is completely inside a single bank ... specify the bank in the variable declaration.

MyArray VAR WORD[16] BANK3

This forces PBP to put the entire array in bank3 and will not allow it to cross a boundary.
However, I do not think that's your problem.

Can you at least post the interrupt routine.
That's the most likely place.
The second most likely is any ASM code (doesn't have to be the INT handler).
<br>

[Jerson]

Chris

Is it possible to let us have just "all" your variable declarations so that we can test it out?

I am suspecting that the compilers' symbol table is unable to cope with so many variables.

[Chris Barron]

Chris

Is it possible to let us have just "all" your variable declarations so that we can test it out?

I am suspecting that the compilers' symbol table is unable to cope with so many variables.

That is what I was alluding to.
If that is the case then one workaround may be to declare a large array, called 'MY_VARS' and then declare the existing program variables to be related to that one as aliases, because the number of aliases seems not to make a difference in the same way that the number of vars do.

[Bruce]

Chris,

Accessing your vars in your asm routine without knowing which bank they're in, or handling BSR, is most, if not all, of the problem I suspect.

If all of your vars will fit into 1 bank, just tell PBP to place them all in the same bank, then set BSR to this bank on entry to your int handler.

[Chris Barron]

Chris,

Accessing your vars in your asm routine without knowing which bank they're in, or handling BSR, is most, if not all, of the problem I suspect.

If all of your vars will fit into 1 bank, just tell PBP to place them all in the same bank, then set BSR to this bank on entry to your int handler.

Thanks Bruce. What i've assumed is that because all of my vars do fit into one bank if i put them at the start of the declarations they will be placed there. The problem with the extra vars is happening whether I place the extra vars before or after my own. it doesn't seem to matter where I put them the fault doesn't go away until I comment out enough of them to get the total number down. But I take your point about using the BSR in the interrupt. I think I have relied too much on PBP and overseen the fact that I still need to obey Microchip's laws !

[Bruce]

You could try a really quick test to see if this is the only problem. See if you can force YOUR variables all into bank13.

Change_delay var word[6] BANK13
Delay_set var word[6] BANK13

rest here.

NOTE: You only need to do this for all variables YOU are accessing directly in your int handler, or some other assembly routines. If you have vars you only access from PBP, don't bother trying to force locations.

Then make the first line in your assembly int routine MOVLB 0XD. You might want to have a look at the .lst file after compiling just to make 100% sure PBP really is placing all your vars in this bank.

If it works, it will be the easy fix. If not, then you're going to need to know where every single one of your variables are located, and select banks accordingly. Or learn how to use some of the PBP macros like CHK?RP.

[Darrel Taylor]

The problem with the extra vars is happening whether I place the extra vars before or after my own. it doesn't seem to matter where I put them the fault doesn't go away until I comment out enough of them to get the total number down.

With 18F's, PBP sorts the list of variables first by type, then alphabetically.
Arrays are always placed at the end, in the order ... byte arrays, word arrays then Long arrays end up last and will be the first things to end up in a different bank.

It doesn't matter where the variables are place in the code.