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.
That would work fast enough to save an image I do not own the camera module yet as I am still learning alot and will save that for latter and it appears you are getting more out of your library than I am maybe it is the way I am reading the data maybe instead of just doing
OCR2B = myfile.read();
I should have 2 buffers and I could play buffer 1 while playing buffer 2.
Is this for real? This won't give you any performance.
OCR2B = myfile.read();
I am trying to understand. Are you a young student trying to learn electronics?
I am not a young student but I am a beginner to electronics and programming and I did come up with a solution by using 2 512 byte buffers and I can play buffer one while loading data into buffer 2.
I did come up with a solution by using 2 512 byte buffers and I can play buffer one while loading data into buffer 2.
Sorry that idea is from the 1960s and I was there. Actually we used circular buffers which is a better idea. If you want to be more than a dabbler go to school.
You need to learn about the internals of SD cards and how that relates to file systems. That's how you get performance.
