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

Sat Feb 13 11:28:41 CET 2010

Hi,

I'm trying to use the SSC for SD card access to improve I/O performances on
my EIR board. I added to my application a modified version of the file
sbi_mmc.c joined to this mail (ssc_mmc.c).

The first step is to do the minimum of modifications in the low level layer
of the driver. The next step will be to modify it more, to allow SSC bursts
over PDC for data block transfers.

Actually I'm stuck with the first step: I read only '1' as data and the
status register of the SSC seems to be strange.

Unfortunately, I don't have an oscilloscope to check what is going on the
bus, which could help me to understand what happens...

Does someone had experienced the SSC peripheral could help me?

Thanks
Regards

Mathieu

2010/2/11 Ulrich Prinz <uprinz2 at netscape.net>

> Hi!
>
> Mathieu SOULARD schrieb:
> > 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>
> <http://www.cs.ucr.edu/%7Eamitra/sdcard/ProdManualSDCardv1.9.pdf>
> > )
> >
> > Actually, in SPI mode, here is the SD card pin assignment:
> >
> [...]
> >
> > 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
> >
> PDC and IIS should work as it is fundamental. Otherwise the CPU could
> not keep up sending synchronous data to the audio codec.
> >
> > Thanks a lot for your idea !
> Welcomed.
> >
> > 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?
>
> If you use the SPI implementation right, you can fire up to four devices
> per bus in a time slicing way. Internally the SPI has 4 data registers,
> one for each chip select. It then sends the data register by register.
> So sending a block of bytes to the codec and receiving a byte from the
> SD will show up on the bus like [co][sd][co][sd]...
> While [co] the hardware pulls the codecs chip select and vice versa with
> the sd card. Additionally you can set different timings and speeds per
> chip select.
>
> But one has to rewrite the whole SPI driver as it is not that easy. The
> trick is the data register. In the lower bytes you give up to 16 data
> bits. in the upper two bytes you give the address of the chip select. So
> to receive data from the SD card, you need a buffer of 1024 bytes. then
> you format every second word to be the address of the desired chip
> select. Then you fire up PDC and receive the incoming data into this or
> another buffer. Out of that buffer you have to filter the status
> information.... You can work with some tricks to have smaller buffers.
> And also with the content you can do some dirty tricks. By reading it as
> uint_fast32_t and casting it to uint_fast16_t while using it should
> improve speed.
> And you can read blocks of 32 bytes from the SD, storing it via PDC in a
> buffer of 32 uints. reformat the high words to right config for the
> codec and advice the PDC to throw it out to the codec on request.
> Working with two buffers switching back and forth, will give low
> interrupt and synced access to both, SD and codec.
>
> I have now worked a lot with SAM7X256 and can tell that with only a few
> tricks there is a lot of power available. My first self made MP3-Player
> was running on an ATmega32 with VLSI and SD at the same SPI. I intended
> to trick the system by addressing the right sector of the SD and then
> shortcut VLSI and SD, just sending Clock signals from the CPU. But it
> was not needed. The AVR runs with its internal 8MHz clock and there is
> enough time to give status messages and accept commands through a serial
> interface. I later switched to a 11.xyMHz crystal as I had problems on
> the serial port caused by the internal oscillators drift and there was
> no slower crystal laying around here.
>
> >
> >
> >
> >
> > 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
> >>
> > _______________________________________________
> > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>