Any interest in an ARM version of SdFat

I am playing with a number of ARM development boards and looking at porting SdFat to various ARM processors.

Others have ported older versions of SdFat to ARM but I have not published a version of SdFat since Elm-ChaN's FatFs http://elm-chan.org/fsw/ff/00index_e.html is used in many ARM projects.

Would SdFat be useful for Due and other Arduino like ARM boards?

What would be the difference between SdFat and FatFs for ARMs? (or the differentiator)

pito,

FatFs is a C program with a older style API. SdFat has standard C++ support.

FatFs is not supported on Ardunio. Maybe the Arduino group will make a wrapper for it on Due.

SdFat has support for high speed write to contiguous files. This makes very fast data logging possible.

I plan to support SDIO which is about four times faster than SPI since it is a 4-bit bus. SDIO plus multi-block write to contiguous files could be ten times faster than FatFs.

Yes.

I am current designing an ARM board (PCB just finished) using a 4-bit interface and the HSMCI on a SAM3U4E.

I am certainly interested in having your library running on that (and maybe you can advise if I got the hardware right). Details available if you want.

FWIW the SAM3U4E was the chip they originally said the Due would use, that may or may not be the case now but I doubt that makes much difference to a peripheral driver like this.


Rob

maybe post this question on the mbed platform? - http://mbed.org/handbook/mbed-Developer-Website -

fat16lib: I plan to support SDIO which is about four times faster than SPI since it is a 4-bit bus. SDIO plus multi-block write to contiguous files could be ten times faster than FatFs.

You do not realize how awesome it would be for sdfatlib to support sdio there are no words to express how much I want sdio Please do have it support sdio.

Just to be clear Mr_Arduino, you want support for sdio :)


Rob

Graynomad,

Just to be clear Mr_Arduino, you want support for sdio

Good point, SDIO is not simple and not supported on many micro-controllers. The SDIO protocol is totally separate from the SPI protocol. Most SD modules/breakouts can't be used with SDIO since only the SPI lines are connected.

SDIO should be very fast if implemented correctly since more effort goes into the SDIO controller in an SD card because it is used in most consumer devices, PCs, and Macs.

I plan to change the SdFat architecture so it can be ported to a number of micro-controllers.

I will port SdFat to STM32/SPI first since that should be easy if I start without DMA. An old version of SdFat already has been ported to Maple. Next I will do SPI/DMA.

The STM32 processor used in Maple does not support SDIO so I will likely use the this board http://www.st.com/internet/evalboard/product/252419.jsp. I have several SD breakout boards that bring out all SD lines for SDIO.

The STM32F4 is really fast and I understand it. I will look at SAM3U4E and whatever is used in Due later.

bring out all SD lines for SDIO.

Can you advise what these are, it may not be too late to change something if it means not loosing SDIO functionality.


Rob

If all the SAM3U4E HSMCI line are available you should be fine.

The problem is SD modules and breakout boards. Most of these are designed for SPI so only bring out MISO, MOSI, SCK, and CS.

I have found breakouts on ebay from Asia that support SDIO.

The SAM3U4E supports 8-bit MMC. I don't expect to try that soon since it requires all 13 MMC pins.

I can only afford the HSMCI control and 4 data signals, so 4-bit should be OK but not 8-bit.


Rob

I was interested in using sdio with this interface chip using an nxp chip http://www.nxp.com/documents/data_sheet/SDIO101.pdf but it uses some weird mount and I can not find a dip adapter for it and also Graynomad I do want support for sdio and your comment made me laugh!

Mr_arduino,

Why do you want to use this part? It may be great in some product but maybe not in the Arduino hobby world.

Why are you laughing at Graynomad? His question is reasonable.

A DIP adapter for a 60-pin SDIO part could make some people laugh but not me.

fat16lib: Mr_arduino,

Why do you want to use this part? It may be great in some product but maybe not in the Arduino hobby world.

Why are you laughing at Graynomad? His question is reasonable.

A DIP adapter for a 60-pin SDIO part could make some people laugh but not me.

I want to use this part to improve transfer rate by using a hardware sdio controller and that is what the sdio ic does. I am laughing with Graynomad because as far as I am aware he was joking with me and the simily face to me signifies that he is joking. And no if I do make a shield it will not just be a dip adapter but I just want an adapter to prototype it to see how much faster it is and how well it works with the arduino.

An SDIO shield for an AVR Arduino? Tell us more.

I think I may hear laughter in the distance but lets wait

I think you may have gotten my comment about the shield mixed up with my comment on graynomad and that explaining were the laughter part must have came in but anyways to tell you more about the avr/arduino shield it will include a 1.8v regulator and a 3.3v regulator so that it is compatible with 5v the arduino and many other micro-controllers that use 5v also it will include a level shifter to get the logic down from 5v to 3.3v and it will include a regular sized sd card interconnect. And also I will include a real time clock. I have not worked out all the details yet as I still don’t even own this chip or an adapter for it but like I said if I do make a shield I will make sure that it is better than buying an sdio101 and a dip adapter.

SPI is the fastest bus on AVR. For Arduino the max speed is 8 MHz and it is programmed I/O so the The best speed to an SD is about 820 microseconds to write a 512 byte block. I don’t see how your shield will improve much on this. The current SdFat can do this.

Other modern micro-controllers have fine SDIO controllers so a shield makes no sense.

The problem is not so much hardware but how to handle file systems on SD flash. This is what I am working on.

There are at least two type of apps that one can optimize. One is data logging where latency is the problem so you don’t lose data. The other is where the average rate is important. These require different approaches.

What are you trying to accomplish? What is your application?

fat16lib:
SPI is the fastest bus on AVR. For Arduino the max speed is 8 MHz and it is programmed I/O so the The best speed to an SD is about 820 microseconds to write a 512 byte block. I don’t see how your shield will improve much on this. The current SdFat can do this.

Other modern micro-controllers have fine SDIO controllers so a shield makes no sense.

The problem is not so much hardware but how to handle file systems on SD flash. This is what I am working on.

There are at least two type of apps that one can optimize. One is data logging where latency is the problem so you don’t lose data. The other is where the average rate is important. These require different approaches.

What are you trying to accomplish? What is your application?

Thank you for that you brought up some points that I haven’t considered. Some of my current goals that I wish to accomplish some now some maybe later once I learn more include:
high sample rate audio playback and recording.
Right now I can playback 24khz 8-bit mono using pwm using a high sample rate just ends up playing to slow for example 44khz plays almost twice as slow.
Time-lapse using a camera and saving a raw image. using something like this:
http://www.ebay.com/sch/i.html?_nkw=ov7670+module&_sacat=0&_odkw=ov7670+module&_osacat=0&_trksid=p3286.c0.m270.l1313
see the one with lens for less than 9 dollars
And if it is relay just software then I would of course reconsider this sdio chip thing I thought that the reason why spi is so much slow than sdio is because sd cards are more designed for the sdio interface and spi was just more of an add-on but I may be wrong.

I think I may hear laughter in the distance

That would be me, I'm a long way away.

he was joking with me

Yep.

So is SDIO 4 or 8 pin data?


Rob

Mr_arduino,

I was hopping this topic would be about the future. What you want to do was done years ago with AVR Arduinos.

Hope Graynomad contains his laugher and I am sure he will. He is a gentleman.

Just buy an Adafruit Wave Shield and use my old WaveHC library or WaveRP library. WaveHC can play 16-bit 44.2 ksps files. The DAC on the shield is only 12-bit for cost reasons but Ladyada did a great job for the low price and the sound is good.

WaveRP can record 8-bit 44.2 ksps audio using the AVR ADC.

My binaryLogger sketch can record 8-bit data at 90 ksps and 16-bit data at 45 ksps using Microchip ADC chips.

My SdFatRawWrite sketch can write to an SD at about 500 KB/sec. This uses 100% CPU but at 250 KB/sec you have 50% cpu to generate data. This should do for your image data.