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

Ulrich Prinz uprinz2 at netscape.net
Thu Feb 11 21:10:52 CET 2010 

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>
> )
> 
> 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

More information about the En-Nut-Discussion mailing list