To all the SD card users out there

[Interactive_Matter]

Again I a a bit puzzled - but it start to become my normal state of beeing - so no problem.

But next week I have to implement a SD card reading functionality in my project.
From the form I have learned that currently there are two implementations:

• The sample code from XS1-G dev kit, which uses some 1pin interface.
• The'old' xmoslinkers sd card implementation.

, which is discussed in this thread and seems to be maintained by Berni

First of all: Has anybody experience with one of the implementations. To my mind the SPI based xmoslinker library seems most suitable to me.

Has somebody uploaded this already to git hub?

Because we should start comitting on one sd card library - since there is alot of discussion going on, but no appearant implementation process. But probably it is going on in some project.

[kster59]

The SD card code isn't that well written.

The XMOS implementation is 1bit SD mode. Even though parts of the code say SPI, it is actually 1bit SD mode which is different. If you read through the old posts, even Berni was confused. There is no SPI implementation as far as I know.

This will save you a lot of headaches when you realize you don't use the CS pin since it's not SPI.

[Berni]

Well all of that is the same FAT16 code that does use 1bit mode even tho its not very apparent at first glance.A very nice FAT32 library that is worth porting is the one from elm chan, it is nicely optimized, is maintained and comes in a small memory footprint version.The full one with all the bells and whistles(write,directories,long file names,cache...) uses about half the memory of a xmos core and is pretty fast. Most of the work porting is it writing up the server-client thing so you can use it from other cores, the actual porting is just making the SPI work as that's the only hardware dependent part.

[Interactive_Matter]

At least the code from xmoslinkers works. My application is not really time critical - so it is OK.

But this is another repository which should be opened on github. Including FAT23 (and probably several more), SPI and so on.

But it works as described and that is a nice feature by itself.

[Interactive_Matter]

Ok,

final result: It does not really work, but most of the time, sometimes.

It seems that the code can work only with 'old' sub-2GB SD cards. With my 4GB SD card I can see that there is successfull communication between XMOS and the SD Card, but the XMOS does not like the answers it gets (presumably it is a HD SD Card which has a slight different initialisation routin - at least what I read and/or understood while googling for Linux drivers).

Any interest to improve the library?

Marcus

[mculibrk]

Any interest to improve the library?

Sure! I'll need that shortly so I could help also... (or you need just some moral support? ;) )
To be honest I did not (jet) analysed the available code... but did something similar some time ago - using a mmc/sd card in Linux via gpio pins...

[Interactive_Matter]

Any interest to improve the library?

Sure! I'll need that shortly so I could help also... (or you need just some moral support? ;) )
To be honest I did not (jet) analysed the available code... but did something similar some time ago - using a mmc/sd card in Linux via gpio pins...

Currently I do not really have enough time. I still need to clean up after my last project.
But from your answers I see that you seem to be the right for the job.
I think there are some very easy things to improve in the SD card library right now:

- asking XMOS to make it open source (administrative task only I think)
- adding a few comments to the current source
- adding support for HD cards (it is hard to get the olde cards these days) - perhaps other cards as well

- later we can add more physical interfaces to give more access options (2wire like now, SPI, high speed access (4bit support).

The good thing is that the current library works right now for old cards and there are a lot of examples out there so that we do not have to invent all the wheels ourselve ;)

[mculibrk]

OK then. I'll take a look as soon as can.
But, please, tell me which one of the existing libraries should I start on? The one from xmoslinkers or the one from XDK?
As I said, already have some code for HD, fat32... from linux drivers so it should be not a big deal.

regards,
mculibrk

[davelacey]

Hi,
If you want the code put into a xcore github account for you then let me know and I can do that to get you going (you can pm me or alternatively raise a new repo request in the community repo - see xcore.github.com for details).

Dave

OK then. I'll take a look as soon as can.
But, please, tell me which one of the existing libraries should I start on? The one from xmoslinkers or the one from XDK?
As I said, already have some code for HD, fat32... from linux drivers so it should be not a big deal.

regards,
mculibrk

[Interactive_Matter]

Hi,
If you want the code put into a xcore github account for you then let me know and I can do that to get you going (you can pm me or alternatively raise a new repo request in the community repo - see xcore.github.com for details).

Dave

OK then. I'll take a look as soon as can.
But, please, tell me which one of the existing libraries should I start on? The one from xmoslinkers or the one from XDK?
As I said, already have some code for HD, fat32... from linux drivers so it should be not a big deal.

regards,
mculibrk

I do not see any difference between the xlinkers and xdk code - but it was a very rough check.
@Dave: Yes it would be great to have an SD-Card repository. I would be happy if you open up one in the xmos github area. If you need a maintainer you can use me ;). Is there a simple way to include the SD Card bootloader in that repository too?
@mculibrk: I do not care If I am maintainer, you are some XMOS employee. So I let Dave decide. If adding functionality keep an eye on the licenses. Most linux stuff is prob. GPL. But if we do it exactly the same way as linux does it will not be 'stealing' ;)

It is nice to see that things are moving forward!

Marcus