• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 21 subscribers
  • Views 897 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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

DPTR constantly reloaded

Scott Leyh

I have some code to transfer a large amount of data over a SPI port running at the system clock/2 so I need my code to be as fast as possible. The code generated for my current method does not seem to be as optimal as it could be. I am using optimization (8, speed) with the 7.07 C51. Here is a simplified version of my code:

//this variable set in buffer data function
static unsigned char xdata * data spiDataPtr;

void transferData(void) small {
     //do not want to store changes in
     //spiDataPtr so use temp pointer
     unsigned char xdata * tempPtr;
     unsigned char data i;
     unsigned char data temp;

     tempPtr = spiDataPtr;

     //transfer set block size
     for(i = 0xff; i != 0; i--) {
          SPIDATA = *tempPtr; //initiate transfer
          tempPtr++; //prepare for next send while busy transfering
          while(!SPITXDONE); //wait for transfer to complete
          temp = SPIDATA; //read to avoid colission error
     }
}

The compiler increments tempPtr in its data location and then reloads it into the DPTR each time tempPtr is increased. I do not need the final value of tempPtr. What I would like is for the DPTR to be loaded when tempPtr is initially set and then for the DPTR to be increased by INC DPTR. I figure this would be quicker even if the value of tempPtr was needed because the DPTR could be moved back into tempPtr at the end of the loop. Is there a way to get the compiler to do this short of assembly?

Parents
  • 0 in reply to Jon Ward

    Ah, thanks for the information Jon. I was indeed doing a little bit more in the function but I did not think it would matter as I was not manipulating any other xdata variables, just resetting and reusing the tempPtr. After moving the extra code out of the function it compiled the way I thought it should have initially.

    The ASM example is interesing Oleg and I will keep it in mind for future projects, but for mantainability reasons I am trying to avoid ASM in this project. I actually have the C code set up to do the DJNZ during the wait state and with the DPTR being incemented properly now the extra code of the C version still takes just below the SPI transfer time. There will only be 2 clocks lost by not having the XCH command and that is acceptable. I am using a Cygnal chip so the commands take very few clock cycles. The SPI tx done flag is indeed bit addressable.

Reply
  • 0 in reply to Jon Ward

    Ah, thanks for the information Jon. I was indeed doing a little bit more in the function but I did not think it would matter as I was not manipulating any other xdata variables, just resetting and reusing the tempPtr. After moving the extra code out of the function it compiled the way I thought it should have initially.

    The ASM example is interesing Oleg and I will keep it in mind for future projects, but for mantainability reasons I am trying to avoid ASM in this project. I actually have the C code set up to do the DJNZ during the wait state and with the DPTR being incemented properly now the extra code of the C version still takes just below the SPI transfer time. There will only be 2 clocks lost by not having the XCH command and that is acceptable. I am using a Cygnal chip so the commands take very few clock cycles. The SPI tx done flag is indeed bit addressable.

Children
No data