| View previous topic :: View next topic |
| Author |
Message |
rolox
Joined: 25 Dec 2014
Posts: 33
|
| String/array crossing page/segment border |
 Posted: Fri Jan 02, 2015 6:58 am |
 |
|
i'm passing string to a function which works with a ram generated string as well as a constant string (having | Code: | | #DEVICE PASS_STRINGS=IN_RAM |
activated)
| Code: | | void showStatus(char* pString) |
so i can use | Code: | | showStatus("hello world"); |
as well as | Code: | | showStatus(&myString); |
it works most of the time, but sometimes the string is cut. In this cases i can see in the File Registers window of MPLAB 8, tab "Linear Data" that the RAM copy of that constant string crosses a page border :-(
How can i prevent the compiler (V5.012) from doing so ?
I have a similar problem with a array of struct which crosses page border when making the array bigger ....
(BTW : i wonder why the addreses for a variable in the file Register Window is different in the "Linear Data" tab and the "Hex" or "symbolic" view)
Last edited by rolox on Fri Jan 02, 2015 7:07 am; edited 1 time in total |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9226
Location: Greensville,Ontario
|
|
| Posted: Fri Jan 02, 2015 7:00 am |
|
|
Which PIC ? kinda matters....
jay |
|
|
rolox
Joined: 25 Dec 2014
Posts: 33
|
|
| Posted: Fri Jan 02, 2015 7:08 am |
|
|
| ...forgot...PIC16F1788 |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Jan 02, 2015 9:53 am |
|
|
Post a compilable program that demonstrates your problem.
You have two problems. Post a program that shows one of them. |
|
|
rolox
Joined: 25 Dec 2014
Posts: 33
|
|
| Posted: Fri Jan 02, 2015 10:31 am |
|
|
HI,
the problem is, that it does not always occur, most likely not in a small test program - anyway, I'll strip it down.
Meanwhile a screenshot may clarify what i mean:
I was calling with | Code: | | showStatus("Hello nice World"); |
The string was copied by compiler to address 0x20F3 and would end up at 0x2103.(checked in File Register window)
In the function i did a strcopy() for the watch window, and there the string ends with "Hello nice Wo" - which is 0x20ff resp. 0x2000 which contains the 0x0
As the compiler knows how long the constant string is, it should be able to place it to RAM that the page border is not crossed....
(...just notice i cannot attach a screenshot as i have no facebook,tumblr or similar...)[/img] |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9226
Location: Greensville,Ontario
|
|
| Posted: Fri Jan 02, 2015 11:00 am |
|
|
You should add
device *=16 //
this should allow the PIC to see RAM as one contiguous space not individual pages.
worth a try.....
Jay |
|
|
rolox
Joined: 25 Dec 2014
Posts: 33
|
|
| Posted: Fri Jan 02, 2015 11:02 am |
|
|
did a short prg which shows behaviour :
| Code: | #include <16f1788.h>
#device *=16
#device ICD=TRUE
#DEVICE PASS_STRINGS=IN_RAM
#fuses NOWDT,NOPROTECT,NOLVP, NOPUT
#use delay(internal=16000000)
#include <string.h>
char t1 [50]="1111"; // dummy declaration to fill RAM
char t2 [50]="2222"; // dummy declaration to fill RAM
char t3 [50]="3333"; // dummy declaration to fill RAM
char t4 [50]="4444"; // dummy declaration to fill RAM
char t5 [45]="5555"; // dummy declaration to fill RAM
int8 l=0;
void showStatus(char* pString)
{
char test[20];
strcopy(test,pString);
//set breakpoint at next instruction and check 'test' and 'l' variables
l=strlen(test);
}
void main()
{
showStatus("Hello nice World");
} |
set a breakpoint at proposed position and check the values in the file Register view. Because of the dummy variables, the RAM copy of the "Hello nice world" starts at 0x20F7 up to 0x2107.
Here, the 'test' variable is placed at 0x210C and only contains 9 characters "Hello nic" - the ones from 0x20F7 up to 0x20FF
The question is : how can i prevent the compiler to place the variables accros page border ? |
|
|
rolox
Joined: 25 Dec 2014
Posts: 33
|
|
| Posted: Fri Jan 02, 2015 11:04 am |
|
|
| hello temtronic, you were quicker than i ...i have that pragma already in the prog ....doesn't help .... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Jan 02, 2015 11:36 am |
|
|
| Your code works in vs. 5.034 and fails in 5.012. I tested it in both. |
|
|
rolox
Joined: 25 Dec 2014
Posts: 33
|
|
| Posted: Fri Jan 02, 2015 12:25 pm |
|
|
ok....my company bought the latest version some weeks ago ....but i don't have it at my home office yet ...so if the problem is fixed, i'd be glad ...i can test next week ...so far...thanks a lot!
(would have saved a lot of time if i'd updated my home version immediately...but on the other hand i learned a bit instead of spending my free time in the realms of Diablo 3 :-) |
|
|
rolox
Joined: 25 Dec 2014
Posts: 33
|
|
| Posted: Wed Jan 07, 2015 1:28 pm |
|
|
installed V5.036 today, tested the mini-program - works as expected.
But now my "big" program does no longer work :-(
seems that the pointers to a rom data does no longer work :
char rom Font6x8Data[] = {.....}
accesed via
rom char *pFont0=&Font6x8Data[0];
worked
In my case the data were stored at address 0x35d9 - are still there
but now the pointer has the value 0x00D9.
But even if i set it manually to the old value (verified that the data IS there), the access gives wrong values :-(
In change history there is a note about that - but should be fixed :
"5.033 Some pointers to ROM bugs have been fixed on the 14 bit parts"
(btw : is there a way to switch back to older Version in MPLAB ?)
EDIT : meanwhile i found how to switch to other installed version - but then i have compile error :
"Unknown keyword in #FUSES "NOPUT" and
Option invalid No Internal Osc
..getting kind a crazy meanwhile.... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Jan 07, 2015 3:33 pm |
|
|
I tried it and I'm having problems with rom pointers with post-increment
when used in a printf statement.
Post your test program. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19513
|
|
| Posted: Thu Jan 08, 2015 2:17 am |
|
|
On switching versions, the problem is that it only half works...
Uses the older compiler, but the devices data table, and include files are the ones with the new compiler. A real pain.
I turned off the auto update ability, and still install manually into separate directories. This way I can have multiple versions, and load code and genuinely compile with the older version.
It looks as if the latest compilers have gone wrong in the area of handling rom pointers at times. I'm still running with 5.028, and 5.032 as 'reasonably stable' releases, and both parts of the problem seem to work OK in 5.028. |
|
|
rolox
Joined: 25 Dec 2014
Posts: 33
|
|
| Posted: Thu Jan 08, 2015 4:21 am |
|
|
Hello Ttelmah,
meanwhile i fixed a part of my problems (wrong read values even if pointer manually set - i destroyed that pointer during my own testing....)
What remains is, that the pointer to the ROM Data is not set correctly in v5.034 or 5.036
where could i get that V5.028 ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19513
|
|
| Posted: Thu Jan 08, 2015 5:14 am |
|
|
PCM_programmer, had your example program working in 5.034.
Is it not working for you in that version?. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
