| View previous topic :: View next topic |
| Author |
Message |
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
| PIC24HJ ROM and POINTING issue again |
 Posted: Tue Feb 11, 2014 1:50 am |
 |
|
| Code: |
rom char stringin = {"this is a test"};
const char stringin2 = {"Same as before..."};
char *t;
t = &stringin;
char *t2;
t2 = &stringin2;
|
these aren't working out right :(
im aware of the 24bit instrcution but i need the pointing to rom its strange.
in thins function cant use stringin[x..y]; as it does other things too.. |
|
 |
Jerson
Joined: 31 Jul 2009
Posts: 122
Location: Bombay, India
|
|
| Posted: Tue Feb 11, 2014 2:04 am |
|
|
The declarations are made in the const segment or the rom segment. While accessing, you are declaring t and t2 as pointers to the ram segment. You need to add qualifiers like
char rom *t
or
char const *t2
for the pointers to work correctly |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Tue Feb 11, 2014 2:16 am |
|
|
| the results are wrong, im also finding the location is OVER SHOOTING my 128Kb!?? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19384
|
|
| Posted: Tue Feb 11, 2014 2:20 am |
|
|
Also several syntax errors:
| Code: |
rom char stringin[] = {"this is a test"};
//need the brackets, or a *, to say this is an array....
//otherwise will be a single character, containing just the
//first character of the data.....
char rom *t; //Now t is a pointer to rom
t = stringin;
//In C, the name of an array, _is_ it's address. No '&' needed
//or
t=&stringin[0];
//does the same - gives the address of the first element
//&stringin, is 'wrong', giving the address of the address.....
|
Best Wishes |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Tue Feb 11, 2014 2:38 am |
|
|
its still not working correctly...
either im too tired... or the PIC24HJ isn't quite the same...
| Code: |
rom char stringin[] = {
"this is a test"
};
char rom *t;
t = stringin;
printf("location: 0x%08LX, output %u('%c')\n", stringin, t,t);
|
all wrong still :( |
|
|
alan
Joined: 12 Nov 2012
Posts: 357
Location: South Africa
|
|
| Posted: Tue Feb 11, 2014 3:50 am |
|
|
If I remember correctly this might have been discussed a while back. You need to copy to a RAM location before using printf.
Regards |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Tue Feb 11, 2014 3:51 am |
|
|
| yeah i just found it, but it sadly didn't work, copying into ram... its so slow :( |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19384
|
|
| Posted: Tue Feb 11, 2014 4:10 am |
|
|
No, on recent compiler, you don't have to copy to RAM.
However the printf format is screwed. To print a string, you need %s, not %u, or %c. |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Tue Feb 11, 2014 4:49 am |
|
|
newp... still doesn't work :( i have compiler, 4.130 so its probably unlikely i'll get it working anytime soon.. looks like im re-re-writing it! lol
thanks everyone  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19384
|
|
| Posted: Tue Feb 11, 2014 5:12 am |
|
|
By 'copy to RAM', you do understand that the compiler has an option:
#device PASS_STRINGS=IN_RAM
which does this for you?.
With this you can use const, rather than #rom.
However 'slow', well accessing a character in ROM, is a lot slower than in RAM. The ROM pointer has to be loaded, and the character transferred with a table read, but it doesn't take that long. It has to copy to RAM whichever way you do it, for the actual output. The point is that ROM allows a 'rom pointer' to be constructed, while the pass_strings option does this behind the scenes, but only for string data.
Best Wishes |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Tue Feb 11, 2014 5:35 am |
|
|
new issues...
| Code: |
typedef struct {
char set1[24];
char set2[24];
} type_s;
const type_s s_type[10] = {"Test1", "test2"};
char* text;
char* text2;
text = (char*)(&s_type[0].set1);
text2 = (char*)(&s_type[0].set2);
char nextChar = (&text[0]);
|
now this SHOULD be storing nextChar the set1[0]
on the pic18f44k22 works perfectly
on this PIC24HJ128..
frustratingly weird pointer things!!!
i need speed const=rom didn't fix too many things :(
seems that text = (&s_type[0].set1); is being totally ignored!!
its just pointing to the FIRST instance of the s_Type! no amount of changing the [0] to any other number changes this!!
works perfectly on the pic18 :( looks like I'm gonna have to totally re-think the source code :(:(
Last edited by neochrome32 on Tue Feb 11, 2014 10:42 am; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19384
|
|
| Posted: Tue Feb 11, 2014 8:54 am |
|
|
You do understand that a variable declared as 'const', is _read_only_.
In standard CCS form, it is in ROM, so cannot be written. In ANSI form, it is in RAM, but read only.
You cannot strcpy to a _const_ as the destination. |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Tue Feb 11, 2014 10:55 am |
|
|
Sorry Ttelmah, saw the mistake,
i understand the const, and that its its ROM..
strcopy should be copying the rom to the ram
;) the basics i do know ...
i am just baffled.... does the PIC24 have a different way of doing things?
even the read_program_eeprom wont work, i need to use
read_program_memory.. and even that only HALF works
gone back to the drawing board.
seems like it my old code for the other chip, the read_program_eeprom helps alot, i have to do it slightly different here...
do you work for CCS? you seem to know ABSOLUTELY everything here! (that is cool)
i thought i learned alot here, shamefully im going back to "school" |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Tue Feb 11, 2014 11:28 am |
|
|
I have quite a bit of experience with the dsPIC33 chips/PCD and I think you may be the victim of a PCD portability issue, as I discovered the hard way with various things myself.
What I've discovered is that in some instances, code that works perfectly on a PIC18 device just doesn't when ported to a dsPIC. I discovered a lot of problems with "basic" stuff like >> for instance just not working under PCD. Same goes for a lot of the CCS drivers (CAN specifically). Latest I discovered in December was with the built-in functions bit_set() and bit_clear() corrupting the stack and causing a stack trap to be thrown (but again, only under fleeting special circumstances).
Put together two small example programs, one that works for a PIC18 and one that doesn't for a PIC24 and send it to CCS. |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Tue Feb 11, 2014 12:01 pm |
|
|
i found this out the hard way too Newguy...
i found also that this seems more literal too... so i have to go around recoding a LOAD of it :(
cant just point a rom location to a pointer.
char *p;
p = mytext; // where mytext is a const to a string.
doesn't seem to match up.
but you CAN
char p;
p = mytext[0];
works nicely.. its annoying.. but got enough rom so i think its no issue...
OK i think the question i need to be asking is.
char tmp;
read_program_memory(&mywords[0].text_a,tmp,0);
i guess in this reasoning, read_program_memory isn't required! |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
