trying to force scratch variables to specific locations

[guest]

Hello,

I am trying to force the scratch variables generated by the compiler to be in specificed locations. By default, it puts the scratch variables randomly.

I have tried "#locate @SCRATCH=0x44" (for example) but the compiler barfs on the "@" sign.

Thanks!

Bill

[Ttelmah]

There are two distinctly different types of scratch variable used by CCS. The first are the true 'system' scratch variables. These are located at the bottom of memory, and are global/static in nature. The location for these, can be defined from the device editor, under the 'memory' tab, and they will be located at the defined point, and grow upwards, normally occupying just five locations.
The second type, are _dynamic_ scratch variables, and these are allocated the same way as local variables, using the memory 'heap'. Their location, will depend on the memory available to the subroutine calling the routine using them. Trying to locate these to a fixed location, will result in a massive waste of memory, since the same memory can be re-used, when the particular routine is not being called. So:

[Guest]

Thanks, Ttelmah,

Unfortunately, I definitely have the need to locate the local scratch registers as fixed, even though there will be a waste of memory.

Bill

[ckielstra]

I can't think of any reason why you would want to locate the local scratch registers to a fixed address. Just imagine you were not using a PIC processor but a processor with a normal stack pointer, than nobody would even consider to locate a variable on the stack to a fixed location because it would be plain impossible. Now you are using a PIC processor where things are organized a bit different, but still the same principles apply and I think it is a very strange idea.

Can you explain why you want to locate a local variable to a fixed memory address? Most likely we than can suggest a more elegant solution to your problem.

[Guest]

Hi Ckielstra,

We have a complex bootloader, and the code in the bootloader uses scratch variables. The problem is that when a new "application" is loaded, the scratch variables used by the application can collide those previously used by the bootloader, unless we can force the bootloader to always use the same locations.

Bill

[Ttelmah]

Er. That shouldn't matter a jot.
When the bootloader is working it uses the memory. Once the bootloader has completed, and the code is running, it uses the same memory. This si normal, and acceptable...

Best Wishes

[ckielstra]

I agree with Ttelmah, the use of the same memory for scratch variables by the bootloader and your main application shouldn't matter. Remember why these variables are called scratch variables... when your function (or bootloader) has finished this memory is free for other uses.

[Santiago Moronho Arenas]

Hey guys/[spam]

I don't now if your are still there with this topic, but I have the same need for locating the _dynamic_ scratch variables to a certain position (bank 0).

Despite of the waste of memory, could you please tell me how can this location be done?

Best regards
_________________
Santi - Itelsis

[ckielstra]

Santiago,

I still can't think of an application requiring the dynamic variables to be located in a fixed memory location. Tell us more about your problem and I'm sure we can come up with a more elegant solution.

[Santiago Moronho Arenas]

Ok Ckielstra, I will be very glad to tell you, and take your suggestions in account.

It's a 16LC717 runnng at the 4MHz internal clock, and acting as a slave i2c device at 100Kbit/s. There are two irq enabled: i2c and a task dispatcher timer.

The slave i2c isr has to leave the reception buffer ready in a maximum of 90 instruction cycles, and could happen to interrupt just after the timer interrpt has started. The interrupt manager takes about 40 cycles to get into the isr user's code, and the isr timer is very short: 1 instruction.

The i2c isr is:

[ckielstra]

Tweaking your code to get the last bit performance out of it could indeed be a reason for desperate measures. Making the local variables as you did is one way to get more control over memory allocation.

Did you have a look at the symbol table, the *.sym file, for your program? You will see that the compiler tries to locate all dynamic variables at the start of memory, than all other variables are mostly added in sequence thay appear in your program. For minimizing bank switching it is good practice to put your large buffer variables at the end of the program. Some fiddling and shuffling with where you declare the variables in your program can save a lot of bank switches, in my program this gave me about 10% code size reduction!

In your application saving a few instructions by getting rid of the bank switching is nice, but will it do the job? A much larger improvement can be gained from getting rid of the interrupt routines. Yes, I know, this sounds strange but let me explain. The CCS compiler generates standard interrupt handler code which saves and restores all the registers you might possibly change in an interrupt routine, for a PIC16C717 and compiler v3.249 this is about 60 instructions overhead. Now for very tight timing applications you might be better of by polling the interrupt flags from the main loop, this will reduce the overhead with almost 60 instructions. Just make sure the loop is fast enough and doesn't get stalled by a function like printf.

[Santiago Moronho Arenas]

Thank's for the suggestion, but I'm afraid it's not feasible because there are a lot more things to be done in the main loop of the application (including a 2nd master i2c bus, adc readings, etc)

As far as I've tested now the system is working properly, It's only that I estimate margins are quite tight, and the immediate consequence of an overflow is the MSSP getting stuck until someone clears the SSPOV bit.

So, on one side I'm trying to loosen the tight margins with a faster isr and on the other side I'll put in a monitoring task to recover any eventual overflow.

I've just received a VERY INTERESTING answer from the CCS support:

[ckielstra]

Just two more tips
Make sure the most critical interrupt is serviced first, using the #priority directive.

Consider writing your own interrupt dispatcher code, check the manual for the paragraph on #int_global. Just copy the dispatcher as generated by the CCS compiler and then strip the saving of all registers that are untouched by your code. Not easy to do as this requires manual inspection of your interrupt handler code but for each register save/restore operation you can strip you will save 4 instructions.