• 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 Karl Hamsher

    Hi henry..
    Thanks for suggestion.
    But i have modified as below:

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

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

    Now, this is working. I think both pointer should be generic inorder to have correct value.

Reply
  • 0 in reply to Karl Hamsher

    Hi henry..
    Thanks for suggestion.
    But i have modified as below:

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

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

    Now, this is working. I think both pointer should be generic inorder to have correct value.

Children
  • 0 in reply to Pankaj Kashyap

    No, it should not be necessary for both pointers to be generic for this to work. The real mistake in your original code was that you had the assignment backwards.

    But your code is still quite unreasonable:

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

    What good do you expect these pointer casts to do, especially since they're to a type that the object being cast already has, but which is different from the type of the pointer on the left hand of these assignments? This means these casts either do nothing, or the wrong thing, so you really should get rid of them.

    Actually, this entire function's could obviously be simplified to just

    unsigned char status = Obj_XData.

  • 0 in reply to HansBernhard Broeker

    Hi
    Hans.
    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. Well i m still not able to understand this.

    The function is defined for idata, so status will be stored in idata only and pDst is generic pointer, so the statement:
    "pDst = (unsigned char idata *) &status;"
    should be reasonable. As generic pointer can be casted to any type.

    Now, my 32-bit data Obj_Xdata is in XRAM, so i created memory-specific pointer pSrc for XRAM to reduced the pointer size to 2 bytes. So the statement:
    "pSrc = (unsigned char xdata *) &Obj_Xdata;"
    should be reasonable.

    Still there is some problem that i m not able to find out ..!!

    Guide me ..!!

    Thanks in advance.

  • 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.