|
|
View previous topic :: View next topic |
Author |
Message |
sean_tpc
Joined: 21 Aug 2008 Posts: 10
|
Pointer handling by PCWH |
Posted: Mon Sep 01, 2008 7:39 am |
|
|
Hello and good day to all! Since i am new in PIC C programming, i want to know how does the compiler handle a pointer; Code: | char const MyName[]={"Newbie PIC-C Programmer"};
char *charptr = MyName; | I got an error on this line. I'm using PCWH v7.074 |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Mon Sep 01, 2008 8:37 am |
|
|
An initialized string defined as const char means a ROM constant in default compiler configuration. (Your syntax char const, although not mentioned in the compiler handbook, is apparently understood in the same way).
A data space pointer can't access a ROM constant, a dedicated ROM pointer would be needed. The compiler handbook is suggesting a syntax for a ROM pointer in the Using Program Memory for Data paragraph, but apparently it's not working, neither in PCH nor PCD. With CCS C V3.xxx, the manual stated regarding ROM constants
Quote: | In this case, a pointer to the table cannot be constructed. |
It seems to me, that this statement still applies to CCS C V4, the handbook may be talking of a feature to come.
But I would be glad to hear different. |
|
|
Ttelmah Guest
|
|
Posted: Mon Sep 01, 2008 9:03 am |
|
|
It is very complex!.....
If you declare the constant using 'ROM', rather than 'const', the compiler constructs it differently, and will handle pointers to it. There is a slight 'overhead' to doing this.
The compiler will handle pointers to a const declaration, if you add the declaration "#device CONST=ROM" to the top of the file. This maes 'const', function like the ROM declaration.
It does work (using either this declaration, or the ROM format), but still sometimes has problems.
You can also construct pointers to const declarations, using the 'ANSI' declaration, but then constants are actually copied to RAM (just like a normal 'non constant' value), and just marked as 'read only' (not very well, because the chip has no memory management to implement this....).
These forms are in the documentation, as a 'readme.txt', in the compiler directory. How well they work, is improving. I prefer using the 'ROM' declaration, since it then leaves the normal 'const' declaration available (without the extra overhead), for things you don't want to use with pointers.
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Mon Sep 01, 2008 9:13 am |
|
|
Sounds interesting, I'll try. I wonder, however, why the online documentation contains erroneous information in this respect. |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Mon Sep 01, 2008 10:03 am |
|
|
It seems to be different than complex. With PCD, I see that the default
#device CONST=ROMI and the new #device CONST=ROM are mutual exclusive, thus with CONST=ROM, indexed ROM constants don't work any more. If so, that's far from a solution for using ROM pointers, to my opinion. Furthermore, at least with PCD, I can't get ROM pointers operating yet.
Perhaps someone can show a complete example, including rom constant definition, assigning a pointer to the rom, using the pointer in string operations. Something, that you can copy and past to a project and see: Yes, it's working.
For the time beeing, I can accept to regard it as unsupported feature. Trying to guess (and probably miss) a suggested syntax is somewhat fruitless, to my opinion. I'm spending a lot of time distinguishig existing and non-existig PCD features, anyway. |
|
|
Ttelmah Guest
|
|
Posted: Mon Sep 01, 2008 10:30 am |
|
|
It is pretty simple (for PCH):
Code: |
//Need fuses here to suit target chip
char ROM test[2][10] = {"abcde","fghil"};
char ROM *ptr;
void main()
{
int8 i;
char dummy[10];
//Need setups here to suit target chip
ptr = &test[1];
for(i=0; i<6; i++)
{
dummy[i] = *(ptr++);
}
}
|
Will happily result in 'fghil' being stored in 'dummy'.
It works with direct pointer access like this, but not treated as a 'string' for printf.
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Mon Sep 01, 2008 11:56 am |
|
|
Thank you for the example. It clarifies the concept.
I didn't look yet into the implementation details, but I understand that the ROM pointer is treated as a different data type, that isn't assignment compatible with char*. Thus it can't work with char* parameters of string functions. Consequently it shouldn't be able to assign it to a char* parameter, but that's a less important point.
The new pointer type requires a set of char ROM * specific functions, e. g. a romstrcpy(), but they can be user coded. To loose the existing indexed strings with the new type, however reduces it's value to my opinion. Generally, a compiler modification, that invalidates existing code is somewhat dubious.
I noticed, that e. g. the existing USB driver is incompatible with CONST=ROM. Also, it apparently doesn't work with PCD, yet. |
|
|
Ttelmah Guest
|
|
Posted: Mon Sep 01, 2008 2:20 pm |
|
|
Yes. You would have thought though, that CCS, would have overloaded their internal functions, to support this, or added a new printf type specifier.
Best Wishes |
|
|
sean_tpc
Joined: 21 Aug 2008 Posts: 10
|
|
Posted: Mon Sep 01, 2008 4:27 pm |
|
|
Thank you guys! Now i learned something today...cheers! |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|