View previous topic :: View next topic |
Author |
Message |
Andy Drummond Guest
|
Library routine argument locations |
Posted: Mon Feb 23, 2004 10:51 am |
|
|
I am using PCH version 3.142 to compile code for a PIC18F252.
I have a bootstrap loader routine which uses the standard I2C_Read() & I2C_Write() functions. I can make all code reside in the bootstrap area, and all variables too, EXCEPT for the argument to I2C_Write() which gets put into an ad-hoc location (like @I2C_WRITE_1_31763_31764.P1) that shifts whenever I change the program. I2C_Read has a similar problem.
This completely fouls up the system as the bootstrap loader and the new program both use I2C_Write() but they try and pass the argument in via different locations. Which is tragic.
Since the compiler assigns the location of these arguments, is there any way to force it to locate them at known addresses to avoid this problem? Or does anyone have any other helpful suggestions? |
|
|
Neutone
Joined: 08 Sep 2003 Posts: 839 Location: Houston
|
|
Posted: Mon Feb 23, 2004 11:29 am |
|
|
You cant use the compiler I2C functions in both the boot loader and the main program area because they can not be located. If you write your own functions and place them within the bootloader area you could call them from both main and the bootloader because the function location would become static. |
|
|
Andy Drummond Guest
|
Library routine argument locations |
Posted: Tue Feb 24, 2004 2:43 am |
|
|
Not so. You can force the location of library routines to be in the boot loader area, and I have done that. The trouble is that whether I use the standard routines or write my own, the ARGUMENTS to the function call are located automatically by the compiler in some convenient hole left after the other memory references are located.
If I write a function mywrite(char fred) { ... } then call it as mywrite(7), the compiler puts the 7 (or whatever) into a location of its own choice and then the function accesses it there. Trouble is that that location could be anywhere depending on all the rest of the memory assignments. And it can change between two compilations with a minor main-program change. Then the bootloader function looks in one place while the caller puts its argument someplace different. Whoo! Disaster!
If I could use one set of routines (in particular the i2c routines) in my boot area and one set in the main program then I guess it would work, but that would waste a lot of code space and I don't know how to do that either! |
|
|
Neutone
Joined: 08 Sep 2003 Posts: 839 Location: Houston
|
|
Posted: Tue Feb 24, 2004 8:16 am |
|
|
So all you need is to locate a passed variable? This seems like something CCS should support if they don't already. |
|
|
mpfj
Joined: 09 Sep 2003 Posts: 95 Location: UK
|
|
Posted: Tue Feb 24, 2004 9:04 am |
|
|
> This seems like something CCS should support if they don't already.
Yes ... you can use the #locate directive to force parameter locations !!!
For example ...
Code: |
void func(int x) {
#locate x=0x800
x++;
}
|
... compiles to ...
Code: |
.................... void func(int x) {
.................... #locate x=0x800
.................... x++;
0004: MOVLB 8
0006: INCF x00,F
.................... }
0008: MOVLB 0
000A: RETLW 00
|
Very handy stuff, although it would be nice if you could also force the location of *scratchpad* variables ... |
|
|
Andy Drummond Guest
|
|
Posted: Tue Feb 24, 2004 11:13 am |
|
|
Thank you, "mpfj" !
You have hit the nail on the head! I use #locate often but it never dawned on me that I could use it on a function argument. I shall do that now.
As for the scratchpad variables, yes, that is another can of worms. Anyone know how they can be #located??? |
|
|
ttelmah Guest
|
|
Posted: Tue Feb 24, 2004 3:31 pm |
|
|
Andy Drummond wrote: | Thank you, "mpfj" !
You have hit the nail on the head! I use #locate often but it never dawned on me that I could use it on a function argument. I shall do that now.
As for the scratchpad variables, yes, that is another can of worms. Anyone know how they can be #located??? |
You can define the scratchpad 'area' with the device editor. This doesn't allow you to locate a single variable, but does allow you to place the entire thing at a specific location.
Best Wishes |
|
|
mpfj
Joined: 09 Sep 2003 Posts: 95 Location: UK
|
|
Posted: Wed Feb 25, 2004 3:31 am |
|
|
ttelmah wrote: | You can define the scratchpad 'area' with the device editor. This doesn't allow you to locate a single variable, but does allow you to place the entire thing at a specific location. |
I didn't realise that ... thanks.
However, what I'd really like to see if the ability to define the scratchpad area per function ... that would be massively helpful to me !! |
|
|
Andy Drummond Guest
|
|
Posted: Wed Feb 25, 2004 3:59 am |
|
|
Hey, that IS useful. I always thought the line:
Quote: | //////// C Scratch area: 00 ID Location: 2000 |
in the device header file was just a comment. I suppose that IS what you edit if you want to move the scratch area? I can't see any other reference to it anywhere... |
|
|
|