This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SDHC card Interface, taking long time while writing



HI,

I have written SDHC code,for writing block of data.Problem is block,italic part took long time i.e around 2ms.Return byte took long time to get to zero so that condition exits, My other code has 1ms interrupt in which it has to do other task, those tasks cannot be written in interrupt. Can someone suggest me some way how to deal with this. So that when control reaches here,I can jump to take my reading of 1ms  & return here after 2 ms to try again.

Or I am doing some mistake here in code & it should not take 2ms .

Rest my code is working fine, writing & reading SD card are OK. 

response = SD_Command(CMD24_WRITE_SINGLE_BLOCK , startBlock,0x00);   // if reponse not zero then there is error    // try calling sdhc_write_block again

if(response != 0)

return response; 


SD_CSenable(); //enable chip select by setting it zero

SPI_Byte( 0xfe ); // start block token 11111110b


for(i = 0; i < 512; i++) //write globally defined buffer into sd card
{
SPI_Byte(buffer1[i]);
}


SPI_Byte(0xff); // bogus CRC (16-bit), CRC ignored
SPI_Byte(0xff);

response = SPI_Byte(0xff);

if( (response & 0x1f) != 0x05)
{
SD_CSdisable();
return response;
}

count = 0xfffe;
while(!SPI_Byte(0xff)) // wait for write complete and go idle
{
if(count-- < 10)
{
SD_CSdisable();
return SDHC_ERR_W_TIMEOUT;
}
}

SD_CSdisable();

SPI_Byte(0xff); // 8 clock cycle delay while SS line high

SD_CSenable(); // reset SS line low to verify if card still busy

count = 0;
while(!SPI_Byte(0xff)) // wait for write complete and go idle
{
if(count++ > 0xfffe)
{
SD_CSdisable();
return SDHC_ERR_W_TIMEOUT;}
}
SD_CSdisable();


return SDHC_ERR_NONE;

  • The SDcards I've worked with (mostly SanDisk) all do write-behind, i.e. the SDcard will write into the backing store on its own, after telling you "OK". Receiving the 0x05 response means that the SDcard has taken responsibility for the data (and as I recall won't even tell you about any errors that happen later).

    What this means is that you might as well return after receiving the 0x05, and do other things while the SDcard is doing its thing. A corollary, though, is that if you come back to write (or read) another block very quickly, it might not be finished, so you need to move that "busy" check to precede the actual write. (You probably should do that anyway just on principle.) If you come back very Very fast, you might in fact end up spinning for (nearly) your 2ms anyway, but that sort of thing is rare outside of performance tests.

  • This is misconception that tasks cannot be "written in the interrupt". Remember that your application is... routine of reset interrupt :)

    There's lot of different approaches how to do more than one big task in parallel. Like: split one of tasks in segments which CAN be handled from (timer) interrupt routine. Or: call 2nd task partial execution function from 1st task periodically. Or just use task switcher.

  • Ilmars said:
    Like: split one of tasks in segments which CAN be handled from (timer) interrupt routine.

    Indeed, if things take a long time and especially if there are delays required, the bes thting is to write down how far you've got and return later to continue from there.
    This is usually called a state machine.

    Ilmars said:
    call 2nd task partial execution function from 1st task periodically

    Well, that's what interrupts do to main anyway. With hardware support instead of being explicitely called by the main task.
    Sometimes, this method (in software) can be useful, but this should be the very last thing to do, as it easily breaks on future code modifications.

    Ilmars said:
    Or just use task switcher

    Nice, convenient - and least efficient. As it requires a task switcher, multiple stacks, lots of management overheade etc. However, if you have more than just two major threads of operation, relative efficiency increases. With the 4th parallel job, it is (if coded efficiently) IMHO the best option. Especially if all jobs require constant attention. Or switch between periods of high and low activity.

**Attention** This is a public forum