Problem in using Pointer functions in C18 compiler

[Jyothi@Pic]

Hi,

I have attached my code for correction since i am getting warning as

Warning [2054] suspicious pointer conversion

#include"string.h"                         // is included


void main()
{

  printlcd1(" Hello world ");

}

void printlcd1(unsigned char *str)
{
    unsigned char len,i;//RCIE=0;
    len = strlen(str);
    set_add(0x80);			//sets display position in  the first line
    for(i=0;i<len;i++)
    {
         data_lcd(*str);	//displays the character on LCD
	     str++;
    }
    //return;
}[CODE]




Above is the code when i build i am getting warning as

Warning [2054] suspicious pointer conversion

wat corrections is to be made
kindly reply for this

 

[Pommie]

There are two kinds of pointers on a Pic chip. One to ram and one to rom. Your function is defaulting to a ram pointer and the constant data "Hello World" is in rom.

There are two ways to fix this. First make them both rom pointers,

printlcd1((rom unsigned char*)" Hello world ");

void printlcd1(rom unsigned char *str)

The other way is to make them both ram pointers but the compiler will still store the constant string data in rom. You then have to copy the rom image to a ram buffer and point your function at the buffer.

Note that strlen expects a ram pointer so you would be better doing something like,

    while(*str){
        data_lcd(*str); //displays the character on LCD
        str++;
    }

Mike.

 

[Jyothi@Pic]

Thanks it worked

 

[biker12]

Help with pointer problem!!

Hi, some one can tell me how to point a pointer to a especific RAM location? That is, I want to create a pointer and point it to, for example, the address 0x300.

Thanks.

 

[Pommie]

unsigned char *P;

    P=0x300;

Mike.

 

[biker12]

Hi Pommie, thanks a lot for reply. But I already had tried that kind of assigment but the MPLAB give me a sintax error. The only thing that worked (not totally) was: int *ptr = 0x300;

But I receive the "suspicious pointer conversion" warning. It seems to function when run it in MPLAB but this warning worry me.

Thanks.

PDT: I forgot to say that i'am using the PIC C18 compiler if it is important.

 

[Pommie]

Doing int *ptr = 0x300; will make a pointer to an int at location 0x300. The address of the pointer is chosen by the compiler. However, this is dangerous as the compiler will not know what is at 0x300 and will happily assign it to another variable.

What are you trying to do?

Mike.

 

[biker12]

The problem is this, i'm doing a project in wich I have to mix some assembler code and other portion of the code in PIC C. The assembler code stores some data (91bytes ) at the location starting at 0x300. Then, with a USB aplication I must access at this data using PIC C code. Since that, my idea was to create a pointer that point to 0x300 and read all the data.

I know what you say, I am sure that could be a problem, in the assembler code I'm sure not other variables store in that memory space, but I don't know how to reserve this space in PIC C.

Thanks.

 

[Pommie]

The safe way to do this would be to make a section at 0x300 by doing,

#pragma udata MyData=0x300
unsigned char DataAt300[91];
#pragma udata

Then define a pointer and point it at the data,

unsigned char *ptr;

    ptr=&DataAt300[0];

Note, I changed it to char as I couldn't see how you would access an odd number of bytes (91) with an int.

Mike.

 

[biker12]

Thanks a lot Mike!!! I will try it! Thanks and sorry for the inconvenience. I'm new at PIC C. he he he

 

[Pommie]

As you mentioned USB I'm assuming that you are using something like a P18F4550. If so, the stack normally lives in bank 3 and so you will get an error. The way to fix it is to move the stack in the linker script.

Mike.

 

[biker12]

Mike! This time I bring good news!! he he he I reserved the memory space as you told me and all works well. About the stack, yes I'm using a PIC18F4550 and I just reduced it to 0x090 I don't know if it is wrong.

Thanks a lot again!!

 

[Pommie]

Yes, reducing it to 0x90 should work. It's a good job that you posted or your data and stack would have occupied the same RAM.

Mike.