• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 22 subscribers
  • Views 1545 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Memory Specific Pointer

Shail Patel

Hi.
I m facing a problem regarding data reading from one memory to another via pointer.

I am using LARGE memory model for ROM & RAM. I defined one function in idata as below:

unsigned char func1(void) small {
unsigned char status;
unsigned char xdata *pSrc;
unsigned char *pDst;

pSrc = (unsigned char xdata *) &Obj_Xdata;
pDst = (unsigned char idata *) &status;

*pSrc = *pDst;
}

here, Obj_Xdata is a 1 byte data located in XDATA. But writting the code as above, i m not able to get the proper value of Obj_Xdata in the status variable.

Please suggest the way to achive this.

Parents
  • 0 in reply to Pankaj Kashyap

    There are several separate issues here:

    1) you're going through all those explicitly constructed pointers, without any demonstrated need to for most of them. As I said, all that pointer gymnastics is equivalent to a plain and simple assignment

    status = Obj_Xdata;
    If you insist you need a pointer to the 4-byte XDATA object, you could still just write
    unsigned char xdata * pSrc = &Obj_Xdata;

status = *pSrc;


    2) You cast pointers without any need. The expression &status already is of type (unsigned char idata *) --- it's completely useless to cast it. The only effect of this cast is to clutter up the source code. Same goes for the cast applied to &Obj_Xdata.

    3) Worse yet, you're explicitly casting the right-hand side of an assignment to a type that's different from that of the left-hand side. That's a very good way of creating bugs, not of fixing any --- there will have to be a cast to the type of the left-hand side, but the compiler knows that by itself, and inserts it implicitly. So in the end, there will be a cast, but not the one you spelled out so carefully in the source code, turning the useless cast into a misleading one.

    The compiler knows about memory spaces already --- it's perfectly able to turn C instructions into the right combination of assembly instructions to copy the value from XDATA to IDATA space. It doesn't need your help.

    Thanks for the suggestion, actually i m reading a 32-bit data from XRAM which is slower type, so i have to perform clock stretching, so i m reading total 4 bytes using a pointer
    XRAM clock stretching is completely beside the point --- that's between the CPU setup and the hardware to figure out, not between you and the compiler.

Reply
  • 0 in reply to Pankaj Kashyap

    There are several separate issues here:

    1) you're going through all those explicitly constructed pointers, without any demonstrated need to for most of them. As I said, all that pointer gymnastics is equivalent to a plain and simple assignment

    status = Obj_Xdata;
    If you insist you need a pointer to the 4-byte XDATA object, you could still just write
    unsigned char xdata * pSrc = &Obj_Xdata;

status = *pSrc;


    2) You cast pointers without any need. The expression &status already is of type (unsigned char idata *) --- it's completely useless to cast it. The only effect of this cast is to clutter up the source code. Same goes for the cast applied to &Obj_Xdata.

    3) Worse yet, you're explicitly casting the right-hand side of an assignment to a type that's different from that of the left-hand side. That's a very good way of creating bugs, not of fixing any --- there will have to be a cast to the type of the left-hand side, but the compiler knows that by itself, and inserts it implicitly. So in the end, there will be a cast, but not the one you spelled out so carefully in the source code, turning the useless cast into a misleading one.

    The compiler knows about memory spaces already --- it's perfectly able to turn C instructions into the right combination of assembly instructions to copy the value from XDATA to IDATA space. It doesn't need your help.

    Thanks for the suggestion, actually i m reading a 32-bit data from XRAM which is slower type, so i have to perform clock stretching, so i m reading total 4 bytes using a pointer
    XRAM clock stretching is completely beside the point --- that's between the CPU setup and the hardware to figure out, not between you and the compiler.

Children
No data