On 22.08.2010 17:11, Tim Jaacks wrote: > 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. > > Before starting the scheduler, all this works perfectly. But as I said, > after starting the scheduler the reading gets too slow. > > What do you mean with I am stretching the hardware?
Polling status/data from the FIFO generates quite a bit of traffic on the chip's bus - I don't know how exactly the APB and AHB/APB bridge work. I mean the speed you are demanding is maybe too much for the worst case that can happen on the bus (arbitrations etc). Add to that that you probably need an interrupt to tell you there is first data, interrupt latency and driver reaction time - maybe this is too much for a real application. I think for this case the DMA is surely a better idea. See also http://permalink.gmane.org/gmane.comp.hardware.arm.lpc2100/49688 - someone had problems even using the DMA ... Why this runs more 3 times slower if there is nothing but this thread running with disabled interrupts, I have no idea... -- Stano -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
