 |
 |
| View previous topic :: View next topic |
| Author |
Message |
opvini
Joined: 27 Apr 2012
Posts: 50
Location: Brazil
|
|
 Posted: Sun May 13, 2012 8:04 pm |
 |
|
Thanks everybody!
I finally finished the driver for display Nokia 6100...
I will put to download...
Thanks a lot! |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon May 14, 2012 1:36 am |
|
|
There seems to be a new bug in PCD V4.132, which is apparently confused by the rom attribute of pFonte. It's not actually required with PSV, so simply omit it. The bug is not present in V4.128.
Regards,
Frank
| Code: | #include "24FJ32GA002.h"
#device PSV=16
#use delay(clock=8000000)
#pin_select U1RX=PIN_B4
#pin_select U1TX=PIN_B5
#use RS232(baud=9600, UART1)
rom int matrix[] = {0x00,0x1234,0x60,0x10,0x70,0x90,0x78,0x00};
rom int *pFonte;
int *pFonte2;
int i;
int x;
void main(void)
{
printf("\r\nPCD Bug with printf() and rom pointer\r\n");
printf("PCD Version %5.3f\r\n",getenv("VERSION")+0.0001);
pFonte = &matrix;
pFonte2 = &matrix;
for(i=0; i<8; i++){
printf("%d ",*(pFonte+i));
printf("%d ",*(pFonte2+i));
x=*(pFonte+i);
printf(" %d\r\n",x);
}
while(1);
} |
Result:
PCD Bug with printf() and rom pointer
PCD Version 4.132
0 0 0
-10281 4660 4660
-10281 96 96
-10281 16 16
-10281 112 112
-10281 144 144
-10281 120 120
-10281 0 0 |
|
|
opvini
Joined: 27 Apr 2012
Posts: 50
Location: Brazil
|
|
| Posted: Mon May 14, 2012 8:21 pm |
|
|
| Frank, x needs to be a rom int, doesn't it? |
|
|
opvini
Joined: 27 Apr 2012
Posts: 50
Location: Brazil
|
|
| Posted: Mon May 14, 2012 8:27 pm |
|
|
| And pFont2 needs to be a rom int too, doesn't it? |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon May 14, 2012 11:26 pm |
|
|
| Quote: | | Frank, x needs to be a rom int, doesn't it? |
No. A rom int is a constant object, you can't copy anything to a constant object at runtime.
| Quote: | | And pFont2 needs to be a rom int too, doesn't it? |
Did you run the demonstration program? The answer with PCD V4.1032 is pFont2 must not be a rom pointer to get a correct result in printf() with PCD V4.132.
But this is just a bug workaround.
With PSV in effect, there's no actual difference between rom and regular pointers. Both are pointers in RAM memory space. The rom storage qualifier can be still used to designate constant objects in flash memory, but const does the same.
By the way, I previously discussed the behaviour of strcpy() and printf() with PSV:
| Quote: | | Not actually expectable, string constants embedded in the code, either with memcpy(), strcpy() or printf() are still using legacy table read instructions. You need to separate the constant string from the copy instruction to take advantage of the more effective PSV methode. |
I got a response from CCS to my respective support request.
With strcpy, the usage of PSV strings can be enforced with a type cast:
| Code: | | strcpy(s,(rom char*)"Hello new world"); |
For printf(), there's no present workaround.
| Quote: | | printf() doesn't support PSV in this manner. We will look to update it in the future. |
|
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1328
|
|
| Posted: Tue May 15, 2012 7:01 am |
|
|
Curiosity question on pFonte:
How does the compiler know you want a pointer to a ROM int rather than a pointer that resides in ROM and points to an int?
I know in ansi C with const it has to do with location of the const keyword, but how does the CCS compiler distinguish between the two scenarios with the ROM keyword? |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue May 15, 2012 10:25 am |
|
|
| Quote: | | How does the compiler know you want a pointer to a ROM int rather than a pointer that resides in ROM and points to an int? |
The answer depends on the processor and selected flash memory handling.
Generally, that means for PIC16/18 and PIC24 without enabling PSV, a ROM pointer involves a special handling for some rom objects.
In the present case, PIC24 with PSV a 32k part of flash rom is mapped to data memory space and can be accessed wth regular pointers.
Without PSV, any read operation from flash rom must be implemented as a table read operation. It's the same for 8-bit PICs.
Other compilers are often solving the rom access problem by supplying a set of special library functions in addition to a storage class qualifier like rom, e.g. Microchip C18. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
