[En-Nut-Discussion] SD card perf issue on EIR

Mon Feb 8 16:25:16 CET 2010

Hi, 

if the interface is done through bitbanging, there is no wondering, why it 
is slow. If you switch to hardware-SPI with software chip-select the speed 
should be 10 times higher. Hardware-SPI can go up to 25Mhz without a 
problem in one of my designs.  
Problem will be the interrupt latency and system business during the 
interrupts. There it helps to use PDC and transfer block wise. Then you get 
only one interrupt per block. 
And yes, there is a third stage of speed improvement, you might switch to 
MMC interface where you can fire four SPI channels in parallel to transfer 
data. But I doubt, that this will improve speed in a measure needed for the 
EIR application. With the hardware SPI the speed should be much faster than 
needed for transferring MP3. With a transfer rate of 1.5MBit you have 
already reached uncompressed audio in CD quality (16bit * 2 channels * 
44.1kHz sampling rate).  

But, you're right, the socket is not connected to the SPI bus but to GPIO. 
But the GPIO is mapped with the I2S interface. So one could write a driver 
to use I2S as SPI, what can work. I didn't check, if the layout maps the 
right pins of the I2S for use as SPI but as far as I kno Harald it should 
be possible.  

In the AT91SAM7SE512 documentation there is something written about MCI 
interface in the part of the PDC controller, but there is no description of 
any MCI interface or MMC interface in the rest of the text. Looks, that 
there is non in the chip or it is not working and therefore skipped in the 
official documents. Correct me if I am wrong. 

So you can try to use MMC mode by GPIO and increase speed by 4 by using 4 
serial lines. Or you can recycle the I2S interface for use as SPI if the 
connections routed correctly. 

I form myself would breakup the connections of the socket and route them to 
the SPI-Bus, including /CS routed to one of the official NPCSx outputs. 
This will give smartest software at highest througput. 

Best regards, Ulrich 

On Mon, 8 Feb 2010 14:51:48 +0100, Mathieu SOULARD <kazh29 at gmail.com> 
wrote: 
> Hi, 
>  
> Thanks for your answer. 
> Actually I had just sent another mail about that issue, I didn't see your 
> answer before... 
>  
> It is true that this should be better through DMA, but actually on the 
EIR 
> the SD card IO lines are driven by gpio, since the HW SPI controller is 
> dedicated to the audio codec. 
>  
> So the mmc driver is powered by software bit banging, which is the worst 
> case regarding data rate and CPU load. Anyway, I'm shure it is possible 
to 
> get it working enough since the data line of the SD card can work up to 
> 25MBit/sec. 
>  
> About the GPIO access from the driver, it is done with outr(). 
>  
> I'll try to understand the architecture of this driver, and the SD 
standard 
> to check if there is a way to improve the data rate. 
> Moreover, maybe it is possible to implement a driver using SD BUS bit 
> banging instead of SPI bit banging, since SD BUS allows up to 4 data 
lines, 
> making transferts 4x faster. 
>  
> I'll let you know if I get improvements. Maybe someone had expenrienced 
> that 
> issue on the EIR and will join the discussion. 
>  
> For information, I use the EIR to implement a multimedia audio system, to 
> play music from network, internet and SD card (if I can improve the data 
> rate...). 
>  
>  
> Thanks 
> Regards 
>  
> Mathieu 
>  
>  
> 2010/2/8 <uprinz2 at netscape.net> 
>  
>> 
>> Hi Mathieu, 
>> 
>> I didn't do anything with SD on my EIR so far. So I never checked for 
>> proper configuration of that part. But I know that Nut/OS is using a 
>> combination of hardware and software interfacing on the SPI bus. So, 
>> while 
>> using interrupt driven SPI, the chipselects are done by GPIO. There is a 
>> two-step improvement possible for that. 
>> First speed-up is possible by exchanging every NutGpioCfg() by its 
>> appropriate direct access outr(GPIO_xy, value). 
>> Second it is possible to configure the SPI interface to directly drive 
>> the 
>> chipselects by hardware. For that some real deep changes have to be 
>> implemented. Additionally one has to respect some problematic 
>> constellations given by the chips errata sheet. 
>> 
>> In general SD-Access should be done with DMA/PDC and then there are 
>> another 
>> one or two erratas to be obeyed. 
>> 
>> I am not sure if I am actually the only one experimenting with the EIR 
in 
>> this list ( besides Harald). This is the first support request on EIR 
>> since 
>> the few month I have the device. But I am actually busy with the http 
>> frontend of it. SD was on my list for a later date. 
>> 
>> Best regards, Ulrich 
>> 
>> On Mon, 8 Feb 2010 00:20:10 +0100, Mathieu SOULARD <kazh29 at gmail.com> 
>> wrote: 
>> > Hi all, 
>> > 
>> > I'm facing performances issues using SD cards on my EIR board powered 
>> > by 
>> > nut/os 4.8.6. 
>> > 
>> > It seems that I can read a file about 10Ko/seconds, which is not 
enough 
>> to 
>> > feed the audio codec with data. 
>> > The SD card is formated in FAT32. 
>> > 
>> > I would like to know someone has experienced such issue, and if you 
>> > know 
>> > what could I do to improve it ? 
>> > 
>> > 
>> > Thanks 
>> > Regards 
>> > 
>> > Mathieu 
>> > _______________________________________________ 
>> > http://lists.egnite.de/mailman/listinfo/en-nut-discussion 
>> _______________________________________________ 
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion 
>> 
> _______________________________________________ 
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion