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

Mathieu SOULARD kazh29 at gmail.com
Mon Feb 8 19:46:41 CET 2010


Hi,


It seems that you have a good idea :)

I'm starting to check the Synchronous Serial Controller (SSC) and the SD
card pin assignment in SPI mode from the datasheet ProdManualSDCardv1.9.pdf
(http://www.cs.ucr.edu/~amitra/sdcard/ProdManualSDCardv1.9.pdf<http://www.cs.ucr.edu/%7Eamitra/sdcard/ProdManualSDCardv1.9.pdf>
)

Actually, in SPI mode, here is the SD card pin assignment:

DAT3 is Chips select, connected to SSC TF (Transmitter Frame Synchro)
CLK is clock, connected to SSC TK (Transmitter Clock)
Data IN (for commands and data from host) is connected to SSC TD
(Transmitter Data)
Data OUT (to send ata to host) is connected to SSC RD (Receiver Data)

Other pins are reserved in that mode

So it seems possible to use the SCC.

I'll know investigate how to use that, and check if I can use the PDC.
If someone has already experienced that S


Thanks a lot for your idea !

About your connections breakup, are you going to share the SPI bus between
SD Card and Audio codec? Won't you both use at the same time?




Thanks
Regards

Mathieu


2010/2/8 <uprinz2 at netscape.net>

>
> 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
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>



More information about the En-Nut-Discussion mailing list