It's the FIFO of the SD/MMC interface, which is 16 DWORDs long. I am
polling for FIFO_HALF_FULL and then read out 8 DWORDs.
I am running the interface with a 9MHz clock, so the data comes in
with 36Mbps. The SD card always sends a complete block of 512 bytes,
so I have to read the whole block within 114 us.
Humm, i thought SD/MMC was based on SPI and in this case you are SPI
master. So if the host gets behind, it should be able to just pause
the MCICLK until the host catches up?
Anyway, with 512 byte blocks, it makes more sense to use the DMA. I
don't know the DMA on the LPC devices, but often you can just say DMA
512 bytes and it will be triggered when the FIFO is 1/2 full. Also, if
you are worried about the complexity of interrupt handing, you should
be able to use the DMA in a polled mode.
Andrew
Ah yes, of course I could simply stop the clock... Haven't thought about
that, yet. But still this does not explain why the reading of the FIFO
takes more time than it did before.
Well, I already thought about DMA as well, and I intended to use it at
some time in the future. But I thought I could quickly build up a
prototype using a simple polling mechanism. Obviously I have to
implement it using DMA to get it working properly.
Anyway, thanks very much for your support. If you ever happen to have an
idea why this special timing problem occurs, feel free to drop me a line.
Tim
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
