SPI SD card access

Graham Stabler

I was wondering if there is any code available for SPI access of an SD card, I don't need file transfer from a PC just a load of storage space.

Am I also to understand that one way of getting a some more storage to is to change the EEPROM to a larger model, the first 32k being the program and the rest being free to use. What are the largest EEPROMs available that are suitable?

Cheers,

Graham

Mike Green

Atmel makes a 128K x 8 EEPROM that's compatible and you can put two on the same I2C bus for a total of 256K which is the limit for that type of EEPROM (based on the addressing scheme). There is a thread about a piggyback SPI EEPROM <http://forums.parallax.com/forums/default.aspx?f=25&m=135495&gt; up to 16MByte and there is a thread about read-only access of an SD card. No one has reported working code for read/write SD card access (ie file creation/deletion/extension). There are a variety of SD card interfaces on the market that are pretty cheap ($60-70) that use serial and sometimes I2C and SPI as well.

Graham Stabler

Thanks for the EEPROM details.

It is my understanding that you can put an SD card in SPI mode and just do block writes and reads, basically forget about files alltogether. I actually did this with a PIC and an MMC card, I ended up writing over the FAT so couldn't use it in a PC but I just wanted a massive but cheap store for data. I looked at the commercial boards for SD cards but I want to be able to acess all of the capacity if possible.

Graham

Mike Green

Try this thread <http://forums.parallax.com/forums/default.aspx?f=25&m=132844&g=132950#m132950>. Again, it's for read access only, but you should be able to expand it to read/write access.

David B

I've been doing some development on accessing SD and MMC cards.

You're right - sector access is independent of any particular filesystem. You could think of the filesystem as a logical layer completely above the sector access layer. I've been experimenting with spin object development by separating those layers.

Here's my latest development code, which has the raw sector access functions separated from filesystem access into separate spin objects. The raw sector access uses a separate assembly cog to speed up the bitwise card operations. All of my access is in SPI mode.

The top object demonstrates accessing raw card sectors as fast as possible, and it demonstrates FAT12 and FAT16 directory listing, displaying filenames and filesizes from the FAT root directory of both MMC and SD cards.

The card and filesystem objects contain several functions not demoed by the top object, but which may be handy - functions that let Spin read or write any address of the separate assembly cog, and a function that reads every sector of a card, counting bad sectors, if any are detected. (I have an old MMC card with some bad sectors).

I haven't gotten as far as writing a sector from the propeller, but from past experience, I don't think it would be too hard.

David

Graham Stabler

David, you are a legend, I am still learning spin but have started looking at your code already.

Cheers,

Graham

bambino

COULD THE PROGRAM BE LOADED FROM THE FIRST 32k OF SAY A NON-VOLATILE SRAM BATTERY BACKED CHIP AS WELL?

Paul Baker

Only if it's addressable via the I2C protocol.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
...

bambino

Any conditions on the speed the I2C would run at to be compatable?

Mike Green

There's a variety of slightly different specs for I2C speed depending on manufacturer and Vdd. Most parts will run with a 400KHz clock at 5V, many will run with a 1MHz clock at 5V, some will run at 400KHz at 3.3V, some may run at 1MHz at 3.3V. Quite a few non-EEPROM parts require a slower clock at 100KHz. If you want general purpose routines, choose 100KHz, otherwise you have to go through the spec sheets for the specific parts you will hang off the I2C bus and you're limited by the slowest part.